Users App
(UXPROD-784)
|
|
| Status: | Open |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Users App |
| Type: | New Feature | Priority: | TBD |
| Reporter: | Ingolf Kuss | Assignee: | Amelia Sutton |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | Folijet-UI-candiate, reporting, resourceaccess, usermanagement | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||
| Epic Link: | Users App | ||||||||||||||||||||||||
| Kiwi Planning Points (DO NOT CHANGE): | 2 | ||||||||||||||||||||||||
| PO Rank: | 0 | ||||||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R2 | ||||||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R5 | ||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R5 | ||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R4 | ||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R4 | ||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R2 | ||||||||||||||||||||||||
| Rank: Grand Valley (Full Sum 2021): | R2 | ||||||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R2 | ||||||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R1 | ||||||||||||||||||||||||
| Description |
|
As a member of library management, I need to get the number of users who have borrowed at least one item within a calendar year. More than 7000 German libraries count the number of active users (patrons with at least one loan in the reporting year) for Deutsche Bibliotheksstatistik (DBS) (German Library Statistics). DBS 2018 total numbers: https://service-wiki.hbz-nrw.de/download/attachments/99811335/dbs_gesamt_engl_2018.pdf?version=1&modificationDate=1564558387167&api=v2 Loan record deletion, patron record deletionMany of them delete loan data when the item is returned or a few days or weeks after it is returned to comply with GDPR. In addition the Right to erasure (GDPR Article 17) requires them to remove a patron record on request if all loans have been returned and all fees have been paid. Some libraries automatically delete the patron record of students that have left the university. As some loan records and some patron records no longer exists at the end of the year the tenant's "active borrowers count" cannot be calculated at the end of the year, it has to be incremented when the loan is opened. Therefore the tenant's "active borrowers count" needs to be incremented the first time a patron loans something in a year; at least one of these in-app counting algorithms are needed: Date/Time and GDPREuropean Court of Justice has ruled that date and time are "personal data" and are protected by GDPR. Therefore tenants need to evaluate which date/time components (year, month, day, hour, minute and seconds) they actually need and ensure that only the needed components are stored. Judgment of the Court (Third Chamber), 30 May 2013 in case C-342/12: https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX:62012CJ0342 After this judgment the European Parliament has moved the definition of "personal data" from Article 2 of Directive 95/46 to Article 4 of GDPR. "further processing for [...] statistical purposes shall [...] not be considered to be incompatible with the initial purposes (‘purpose limitation’)" – Article 5 1. b) GDPR. "Processing for [...] statistical purposes, shall be subject to appropriate safeguards [...]. ". Those safeguards shall ensure that technical and organisational measures are in place in particular in order to ensure respect for the principle of data minimisation. Those measures may include pseudonymisation provided that those purposes can be fulfilled in that manner." – Article 89 1. GDPR Active borrower flag algorithmRemove the "active borrower" flag from all patron records on January 1st. Last loan date algorithmThe tenant can configure the "last loan date" granularity to be year, quarter or month (or full date+time if no GDPR compliance is needed). |
| Comments |
| Comment by Sharon Beltaine [ 30/Jun/20 ] |
|
Met with patty.wanninger to discuss building this in the UM app as a feature and she recommended we see if it is a better fit for the Resource Access Circulation Log. Next step will be for the Reporting Data Privacy subgroup to meet with Emma Boettcher to discuss possibilities. @Sharon to set up meeting with Ingolf, Vandana, Julian, and Nassib. |
| Comment by Sharon Beltaine [ 07/Jul/20 ] |
|
Holly Mistlebauer will work on figuring out the next steps for this issue. |
| Comment by Holly Mistlebauer [ 08/Jul/20 ] |
|
Holly met with Cate Boerema today and these are the next steps:
|
| Comment by Holly Mistlebauer [ 08/Jul/20 ] |
|
This feature needs to be completed in Q4 2020 at the latest... Hi Holly! We do not know the plans of all German implementers, yet. But we already know that the feature "active borrowers count increment" will not be needed before January 1st, 2021. I will inform you as soon as I can give you a more concrete date for that it will really be needed for the first time. Best, |
| Comment by Brooks Travis [ 11/Oct/20 ] |
|
Having multiple active borrower counters (monthly, quarterly, semesterly, other custom, etc.), definable via settings could be very useful. The last loan date algorithm is probably the most generally useful method for accomplishing this feature. |
| Comment by Brooks Travis [ 12/Oct/20 ] |
|
Ingolf Kuss In Sierra, the closest equivalent for "last loan date" would be the "CIRCACTIVE" fixed field on the patron record, but that also accounts for renewals, requests, checking your account via the catalog or another API interface (eg. discovery), or using SIP2 checkout. Do those need to be accounted for in this stat, as well, or do we just care about new loans? I would think having this attribute present on the user record would be very helpful in a mid-year migration, too. |
| Comment by Ingolf Kuss [ 13/Oct/20 ] |
|
Hi Brooks Travis, renewals are not counted in DBS 4 (this report). (They are counted in DBS 170). |
| Comment by Kristin Martin [ 04/Feb/21 ] |
|
Hi Ingolf Kuss, from our Chicago RA folks, "We don't currently need a report like this, though having something like "Last CKO date" might be useful (if that doesn't already exist)." So we've ranked this R5. Let us know if there is something out there for the Last CKO date. Thanks. |
| Comment by Molly Driscoll [ 14/Sep/21 ] |
|
Have there been any recent developments on this feature, patty.wanninger? Are there plans for a last activity date on the user record? |
| Comment by Ann-Marie Breaux (Inactive) [ 19/Nov/21 ] |
|
Hi patty.wanninger There's no mockups for this. Do you have some? Also, while there's lots of description, there's not really clear scenarios for the UI devs |
| Comment by patty.wanninger [ 03/Dec/21 ] |
|
Ann-Marie Breaux I will take this back to the SIG and get some wireframes. |
| Comment by Brooks Travis [ 09/Dec/21 ] |
|
Julian Ladisch patty.wanninger Would using a one-way hash of the user UUID with the date-based counter be sufficient to satisfy GDPR, since all we care about is the count of users, not the actual users? The only way you could deanonymize would be to run every user UUID through the same hashing algorithm and if the user has been deleted you wouldn't even be able to do that. Otherwise, I don't really see a way to reliably provide this data (reliably) AND comply with GDPR. |
| Comment by Julian Ladisch [ 10/Dec/21 ] |
|
The UUID (id of user record) is already a pseudonymisation. A hash of that UUID is a pseudonymisation of the pseudonymisation and therefore is not exempted from GDPR. Most users records don't get deleted and therefore this is not anonymisation, only pseudonymisation, and pseudonymisation reduces risk but GDPR still applies. For a given user simply hash the UUID and you get last loan date. Therefore I don't see how the additional hashing can give significant advantages to be an "appropriate" safeguard and "appropriate" measure. Can you explain why the "last loan date algorithm" doesn't comply with GDPR? |