Editing GDPR (section)

== Users Dataset ==
This dataset is either populated with a web based sign up form, or in many cases, it is automatically built from an institutional accounts system. These cases need to be addressed in different ways.

=== Imported users Dataset ===

First of all, stop importing any fields you don't actually need and remove those fields from EPrints. nb. Removing the field in the config may not remove it from the database (citation required.. how the hell does that work?)

Next stop importing any users you just don't need -- if they can't do anything while logged in they should never exist in the Users dataset.

Next implement a data retention policy. This will be a script that removes or blanks the data of users that match a criteria. eg. have not appeared in the import script for more than 90 days and never made a deposit.

=== Web signup users Dataset ===

You should ensure that the privacy policy is up to date and in line with GDPR best practice.

Stop collecting any information you don't actually need, and remove those fields from the database.

Next implement a data retention policy. This will be a script that removes or blanks the data of users that match a criteria. eg. accounts more than a year old that have never made a deposit.

=== Removing vs Blanking ===

In some cases it may be more desirable to remove all the personal metadata from a record in the Users dataset rather than delete it completely. This has pros and cons.

If you remove a user entirely who has deposited EPrints you may wish to reassign those deposits to an admin user, or a fake user called "left".

=== Last Login Time===
Storing the last login time of a user can be useful to identify which users are active and which are not to help ensure data is not being stored longer than is necessary.

See [[GDPR/Last Login Time]]

===Non-Active Users Report ===
TODO
worth having a count of items linked with the user on the report, along with their statuses?

===Delete User Action===
*Suggestion* Cron job to select all user accounts which have been inactive over a certain time threshold, check those users for affiliation to a publication (creator, editor, depositor etc.) which is either archive or buffer status and, where no connection exists, remove those user accounts.

Admin will be able to select user accounts from the report to delete (within the report or individually?)

Could be similar to: <tt>EPrints::DataObj::LoginTicket::expire_all</tt> - but with an <tt>$c->{'account_retention_time'}</tt> param taken away from the <tt>time()</tt> call?

Need to check logintickets too?
Someone may not have actually logged in for ages, but maintained a browser session/cookies for a long time?
(currently our longest 'active' login is ~20 days).