is there a (documented) way of deleting an existing "Team Development" Feedback Entry via API, knowing the apex_team_feedback.feedback_number / ID? Or at least setting its status to "Closed"?
I have built an APEX page that transfers one complete user feedback entry (received via the application's feedback page) to the "Bug Tracker" Productivity Application, and I'd like to get rid of the APEX feedback entry right thereafter.
For now, I just perform an "apex_util.submit_feedback_followup(...)" and mark it that way. Haven't found anything useful elsewhere.
Thanks for your ideas.
There are of course plenty of attributes to choose from.
But unfortunately it can't be done automatically, because
It seems it can only done manually via the APEX Team Feedback pages.
I might join the table APEX_TEAM_FEEDBACK_FOLLOWUP to decide which Feedback Entries to show in Reports (because a FOLLOW_UP can be written by a PL/SQL process), but anyway, we don't want to keep redundant data in the first place.
In my mind it's not redundant.. A feedback request was submitted and it was entered into the bug tracking system, showing the request flow.. Now being able to make it as migrated from feedback to the bu tracking system would be a request I'd make to Oracle to allow a workspace admin to do this...
Well, Bug Tracker and APEX Feedback are two completely independent applications. After moving(!) Feedback from APEX to another application, there's no reason to keep stale data in its original place - plus it disturbs selections as described above.
So there's no other solution apart from "looking into" the APEX Feedback pages...?
To be honest, the bug tracker is a optional application separate from APEX, the feedback module IS a part of the APEX product along with the team development module which feedback is part of... I would disagree that deleting the feedback is an option, as apposed to flagging it as transferred to an external process outside the team development module.....
I prefer to error on the side of keeping documentation around as long as possible, versus just accepting the current source of data is the most valid.. Keeping the path around helps...