GDPR - Revision history

Jb4@ecs.soton.ac.uk at 08:46, 14 June 2018

2018-06-14T08:46:55Z

2018-06-01T10:34:17Z

‎Request a copy Dataset

2018-06-01T10:33:36Z

2018-06-01T10:28:45Z

2018-06-01T10:27:18Z

2018-06-01T10:24:47Z

2018-05-22T08:31:52Z

‎Add 'Agree to privacy and data statement' checkbox on registration or request forms

2018-05-11T08:42:14Z

‎Add 'Agree to privacy and data statement' checkbox on registration or request forms

2018-04-25T16:08:02Z

‎Delete User Action

2018-04-25T16:01:31Z

‎Delete User Action

@@ Line 19: / Line 19: @@
 * Web access logs
 ** In the History Dataset
 ** In the Apache logs in the operating system (this will not be dealt with on this page, but should not be forgotten)

@@ Line 82: / Line 82: @@
 ===Adding a Privacy Statement===
 ==History dataset (used for access stats)==
 TODO

@@ Line 19: / Line 19: @@
 * Web access logs
 ** In the History Dataset
-** In the Apache logs in the operating system
+** In the Apache logs in the operating system (this will not be dealt with on this page, but should not be forgotten)
 == Users Dataset ==
@@ Line 71: / Line 71: @@
 Chris Gutteridge has written a blog post on GDPR with a few comments about the EPrints Request a Copy feature: http://blog.soton.ac.uk/webteam/2018/05/10/gdpr-preperations/#post-content-1793;char=5429-7155

@@ Line 51: / Line 51: @@
 See [[GDPR/Last Login Time]]
-== Non-Active Users Report ==
+===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==
+===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.

@@ Line 49: / Line 49: @@
 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.
-First a new user field for storing the time is required in user_fields.pl
+See [[GDPR/Last Login Time]]
 == Non-Active Users Report ==

@@ Line 1: / Line 1: @@
-This page has been created to gather information and share code snippets to help EPrints repositories handle GDPR responsibilities.
+This page has been created to gather information and share code snippets to help EPrints repositories handle GDPR responsibilities.  Some of the issues around GDPR will be specific to a repository contents, but others are quite generic. nb. We're not lawyers!
-==Last Login Time==
+As a general rule of thumb, this is about people's rights and privacy. Imagine a worst case scenario where the entire filesystem and database is made entirely public -- it's not a great situation, but consider what steps you could take to reduce the damage if that did happen - don't store any information about people that you don't actually need.
 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.
@@ Line 67: / Line 112: @@
 </source>
-==Non-Active Users Report==
+== Non-Active Users Report ==
 TODO
 worth having a count of items linked with the user on the report, along with their statuses?

← Older revision		Revision as of 08:31, 22 May 2018
Line 86:		Line 86:
	Possibly a set/namedset, with the available options limited to only one when rendered to a user?		Possibly a set/namedset, with the available options limited to only one when rendered to a user?

−	Chris Gutteridge has written a ~~blofg~~ post on ~~GDRP~~ with a few comments about the EPrints Request a Copy feature: http://blog.soton.ac.uk/webteam/2018/05/10/gdpr-preperations/#post-content-1793;char=5429-7155	+	Chris Gutteridge has written a blog post on GDPR with a few comments about the EPrints Request a Copy feature: http://blog.soton.ac.uk/webteam/2018/05/10/gdpr-preperations/#post-content-1793;char=5429-7155

← Older revision		Revision as of 08:42, 11 May 2018
Line 85:		Line 85:
	TODO - should be 'versioned' - so if the statement changes, the version that was agreed to can be shown.		TODO - should be 'versioned' - so if the statement changes, the version that was agreed to can be shown.
	Possibly a set/namedset, with the available options limited to only one when rendered to a user?		Possibly a set/namedset, with the available options limited to only one when rendered to a user?
		+
		+	Chris Gutteridge has written a blofg post on GDRP with a few comments about the EPrints Request a Copy feature: http://blog.soton.ac.uk/webteam/2018/05/10/gdpr-preperations/#post-content-1793;char=5429-7155

@@ Line 77: / Line 77: @@
 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?
 ==Add 'Agree to privacy and data statement' checkbox on registration or request forms==
 TODO - should be 'versioned' - so if the statement changes, the version that was agreed to can be shown.
 Possibly a set/namedset, with the available options limited to only one when rendered to a user?