Change Tracker
(UXPROD-782)
|
|
| Status: | Draft |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | Trillium (R1 2025) | Parent: | Change Tracker |
| Type: | New Feature | Priority: | P2 |
| Reporter: | Dennis Bridges | Assignee: | Dennis Bridges |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | LC4, acquisitions, loc, volaris-candidate | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||
| Release: | Trillium (R1 2025) | ||||||||||||||||||||
| Epic Link: | Change Tracker | ||||||||||||||||||||
| Front End Estimate: | Large < 10 days | ||||||||||||||||||||
| Front End Estimator: | Khalilah Gambrell | ||||||||||||||||||||
| Front-End Confidence factor: | 20% | ||||||||||||||||||||
| Back End Estimate: | XL < 15 days | ||||||||||||||||||||
| Back End Estimator: | Khalilah Gambrell | ||||||||||||||||||||
| Back-End Confidence factor: | 20% | ||||||||||||||||||||
| Development Team: | Thunderjet | ||||||||||||||||||||
| PO Rank: | 0 | ||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R1 | ||||||||||||||||||||
| Description |
|
Current situation or problem: When records are deleted from the system there is no way for the user to know they once existed or who deleted them. This means the library looses information that could be required by auditors In scope TBD Out of scope TBD Use case(s)
Proposed solution TBD - Incorporate the tracking of deleted records into the version history functionality. Provide an exportable list of deleted records with very limited data. Use mod-audit to capture deleted record data. Links to additional info Questions |
| Comments |
| Comment by Erin Nettifee [ 14/Feb/23 ] |
|
Dennis Bridges how does this relate to
|
| Comment by Dennis Bridges [ 19/Feb/23 ] |
|
Erin Nettifee I think it relates to change tracker because the users desire is to be able to understand what has happened to a deleted record. In a way you could consider that part of the record "history". I think what we have implemented for orders could be the ideal mechanism for serving this information to users. Ie. mod-audit is used to track version history "changes" made to orders and order lines. Perhaps it should also note which ones have been deleted so we can serve up that information to users/applications in some way. Mainly it is related in that deletion is making a "change" to a record. User want to be able to identify when that has happened and possibly understand a little about why that happened. |
| Comment by Khalilah Gambrell [ 14/May/23 ] |
|
Unsure what the difference is between
|