Requests
(UXPROD-790)
|
|
| Status: | Draft |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Requests |
| Type: | New Feature | Priority: | P4 |
| Reporter: | Cate Boerema (Inactive) | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | privacy, requests | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Epic Link: | Requests |
| Development Team: | Vega |
| Kiwi Planning Points (DO NOT CHANGE): | 1 |
| PO Rank: | 38 |
| PO Ranking Note: | 2020-10-04 - CB: Making my PO rank same as the calculated total rank for now.
2019-07-12: Keeping PO rank same as calculated rank (with potential minor adjustments to avoid having two features with same rank) |
| Rank: Chalmers (Impl Aut 2019): | R4 |
| Rank: Chicago (MVP Sum 2020): | R4 |
| Rank: Cornell (Full Sum 2021): | R2 |
| Rank: Duke (Full Sum 2021): | R2 |
| Rank: 5Colleges (Full Jul 2021): | R4 |
| Rank: FLO (MVP Sum 2020): | R4 |
| Rank: GBV (MVP Sum 2020): | R2 |
| Rank: Grand Valley (Full Sum 2021): | R1 |
| Rank: hbz (TBD): | R1 |
| Rank: Hungary (MVP End 2020): | R1 |
| Rank: Lehigh (MVP Summer 2020): | R4 |
| Rank: Leipzig (Full TBD): | R1 |
| Rank: MO State (MVP June 2020): | R4 |
| Rank: TAMU (MVP Jan 2021): | R4 |
| Rank: U of AL (MVP Oct 2020): | R4 |
| Description |
|
Description: The purging will need to be done in batch, both manually run and automated, based on intervals set by the institution |
| Comments |
| Comment by Theodor Tolstoy (One-Group.se) [ 16/Oct/18 ] |
|
Tania Fersenheim why will the purging need to be done in batch? |
| Comment by Theodor Tolstoy (One-Group.se) [ 16/Oct/18 ] |
|
Cate Boerema Leaving this as a requirement for Go-Live since it seems to have effects on user privacy |
| Comment by Tania Fersenheim [ 16/Oct/18 ] |
|
Purging in batch is a standard function of ILSes. For patrons, for closed fines/fees, closed loans. etc. |
| Comment by Theodor Tolstoy (One-Group.se) [ 22/Oct/18 ] |
|
Yes it might be a standard function, but would it not make more sense if the purging was done in a more automated way? I just want to understand the underlying reasons for doing it in batch. Is it due to performance? For reporting reasons? Say for example, a request gets closed, and you have set the system to automatically purge closed request, then it would get closed right away instead of lying around waiting for that batch handler to do it. |
| Comment by Tania Fersenheim [ 22/Oct/18 ] |
|
I think what you are asking for - automatic deletion of a request when it becomes Closed - is a different function than batch purging. If that is a function you feel is necessary for your institution, definitely ask for that functionality to be discussed and specified in the SIG. |
| Comment by Karen Newbery [ 26/Mar/19 ] |
|
If requests are purged/archived (Duke's preference is archiving), will we be able to report on statistics of how many requests an item has? |
| Comment by Brooks Travis [ 14/Apr/21 ] |
|
Karen Newbery Not as things are currently architected, if they're purged. If they're archived, it would depend on how, but likely yes. |
| Comment by Holly Mistlebauer [ 07/Mar/22 ] |
|
This feature is marked DRAFT until Brooks Travis has a chance to review it for validity. |