[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] Data protection and the user table



That's why we've been thinking about it. Another one that people might 
forget is the request-a-copy data seems to be stored in a dataset. 
That's not unreasonable but we think we need to add a data protection 
statement at least and maybe a think to delete them after N years. If 
that's changes everybody needs maybe that's a script that needs to go on 
the eprints files server or something similar. EPrints doesn't manage 
it's own periodic tasks, so you can't just add housekeeping scripts as a 
plugin or upgrade, they need to be added to the crontab.



On 07/12/2017 16:56, Alan.Stiles wrote:
> Hi Chris,
> We do similar in terms of updating the table from central records.
> We set a flag on the user record to indicate that they are currently in that update feed and run a periodic job to flag users as no longer active when they aren't, then another periodic job to remove users where they are not named depositors or authors / editors (based on the eprint.userid and eprint.creators_id etc. fields matching to the user table entries).  I'd need to double check how we handle inbox items - I think there's a possible need for a manual review in case there are items being deposited 'on behalf of'  that we wouldn't want to lose just because the depositor left.
>
> Whatever the solution it's certainly something to bear in mind - particularly with the GDPR looming next year!
>
> Alan
>
> -----Original Message-----
> From: eprints-tech-bounces at ecs.soton.ac.uk [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Christopher Gutteridge
> Sent: 07 December 2017 16:42
> To: eprints-tech at ecs.soton.ac.uk
> Subject: [EP-tech] Data protection and the user table
>
> Hi, I've realised we might have a (minor) data protection issue with EPrints. Don't panic! This is a result of how we use it, not the software iteself.
>
> Every day we update the "users" table from our central users database.
> However we don't *delete* people when they leave the central database, even if they've got zero papers in the system. We do set a boolean field called "active" to FALSE, but that's probably not good enough.
>
> I've not put much thought into this yet, but it seems like good practice would be to also set a "inactive since" datestamp field and then have a script similar to life-embargos which clears out their record and any old "inbox" items.. however there may be an operational need to keep track of who deposited a record indefinitely.
>
> This isn't an issue just for EPrints, but for any system with user accounts created from an external source.
>
>
> --
> Christopher Gutteridge -- http://users.ecs.soton.ac.uk/cjg
>
> University of Southampton Open Data Service: http://data.southampton.ac.uk/
> You should read our Web & Data Innovation blog: http://blogs.ecs.soton.ac.uk/webteam/
>
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive: http://www.eprints.org/tech.php/
> *** EPrints community wiki: http://wiki.eprints.org/
> *** EPrints developers Forum: http://forum.eprints.org/
> -- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302). The Open University is authorised and regulated by the Financial Conduct Authority in relation to its secondary activity of credit broking.
>
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-tech
> *** Archive: http://www.eprints.org/tech.php/
> *** EPrints community wiki: http://wiki.eprints.org/
> *** EPrints developers Forum: http://forum.eprints.org/

-- 
Christopher Gutteridge -- http://users.ecs.soton.ac.uk/cjg

University of Southampton Open Data Service: http://data.southampton.ac.uk/
You should read our Web & Data Innovation blog: http://blogs.ecs.soton.ac.uk/webteam/