Talk:GDPR - Revision history

Cjg at 11:18, 1 June 2018

2018-06-01T11:18:42Z

Libjlrs: /* Code queries */

2018-04-27T14:13:25Z

‎Code queries

Libjlrs at 08:46, 26 April 2018

2018-04-26T08:46:00Z

Libjlrs at 08:43, 26 April 2018

2018-04-26T08:43:40Z

Rory.mcnicholl@ulcc.ac.uk: /* Code queries */

2018-04-25T16:35:32Z

‎Code queries

Libjlrs: More pondering

2018-04-25T15:54:09Z

More pondering

Libjlrs: /* Code queries */

2018-04-25T15:23:54Z

‎Code queries

Alan.stiles@open.ac.uk at 13:28, 25 April 2018

2018-04-25T13:28:49Z

Alan.stiles@open.ac.uk: /* Code queries */ new section

2018-04-25T13:28:27Z

‎Code queries: new section

Alan.stiles@open.ac.uk at 13:12, 25 April 2018

2018-04-25T13:12:58Z

← Older revision		Revision as of 11:18, 1 June 2018
Line 34:		Line 34:
	- JLRS		- JLRS

		+	The logic of the weird time fields in EPrints is to distinguish between vague dates eg. year only. In retrospect using a timestamp and a "resolution indicator" would have been better. Sigh. [[User:Cjg\|Cjg]] ([[User talk:Cjg\|talk]]) 11:18, 1 June 2018 (UTC)
	----		----

@@ Line 3: / Line 3: @@
 == Code queries ==
-John, Are you deliberately storing just the expiry date of the login ticket rather than the specific login time?  Grand scheme I don't suppose it makes a lot of difference if there's an extra 7 days in the delete check. - Alan
+John, Are you deliberately storing just the expiry date of the login ticket rather than the specific login time?  Grand scheme I don't suppose it makes a lot of difference if there's an extra 7 days in the delete check.
 No real reason - I was thinking that the retention period would be e.g. a year or so - and was trying to make things as least impactful as possible - so reusing a value that was already set.
 The problem with this is that if a repository has set a long expiry time, it could be bad (so maybe Will's suggestion is better).
 I initially looked at using a commit trigger on the login ticket - but this changes every time you do anything - so introduces a lot of 'churn' on the system.
 Thinking about it again, a simple `time` call might be better (storing it as seconds).
 In the cleanup scripts, you can then calculate the '1-year-ago' seconds and do a 'last_login < 1_YEAR_AGO'.
-I prefer the trigger to using user_login.pl was going to suggest using the trigger + localtime (like Will's done), but int timestamps do make date maths less onerous as John points out - RM
+- JLRS (John)
 <blockquote> >date maths less onerous</blockquote>
-And 1 DB field rather than 3 or 6 - simpler queries, more efficient - JLRS
+And 1 DB field rather than 3 or 6 - simpler queries, more efficient
-Also, rather than using the 'expiry' field, there is a 'time' field - which makes more sense (I think) - JLRS
+----

← Older revision		Revision as of 08:46, 26 April 2018
Line 19:		Line 19:
	<blockquote> >date maths less onerous</blockquote>		<blockquote> >date maths less onerous</blockquote>
	And 1 DB field rather than 3 or 6 - simpler queries, more efficient - JLRS		And 1 DB field rather than 3 or 6 - simpler queries, more efficient - JLRS
		+
		+	Also, rather than using the 'expiry' field, there is a 'time' field - which makes more sense (I think) - JLRS

← Older revision		Revision as of 08:43, 26 April 2018
Line 16:		Line 16:

	I prefer the trigger to using user_login.pl was going to suggest using the trigger + localtime (like Will's done), but int timestamps do make date maths less onerous as John points out - RM		I prefer the trigger to using user_login.pl was going to suggest using the trigger + localtime (like Will's done), but int timestamps do make date maths less onerous as John points out - RM
		+
		+	<blockquote> >date maths less onerous</blockquote>
		+	And 1 DB field rather than 3 or 6 - simpler queries, more efficient - JLRS

← Older revision		Revision as of 16:35, 25 April 2018
Line 14:		Line 14:
	Thinking about it again, a simple `time` call might be better (storing it as seconds).		Thinking about it again, a simple `time` call might be better (storing it as seconds).
	In the cleanup scripts, you can then calculate the '1-year-ago' seconds and do a 'last_login < 1_YEAR_AGO'.		In the cleanup scripts, you can then calculate the '1-year-ago' seconds and do a 'last_login < 1_YEAR_AGO'.
		+
		+	I prefer the trigger to using user_login.pl was going to suggest using the trigger + localtime (like Will's done), but int timestamps do make date maths less onerous as John points out - RM

← Older revision		Revision as of 15:54, 25 April 2018
Line 11:		Line 11:
	I initially looked at using a commit trigger on the login ticket - but this changes every time you do anything - so introduces a lot of 'churn' on the system.		I initially looked at using a commit trigger on the login ticket - but this changes every time you do anything - so introduces a lot of 'churn' on the system.
	- JLRS		- JLRS
		+
		+	Thinking about it again, a simple `time` call might be better (storing it as seconds).
		+	In the cleanup scripts, you can then calculate the '1-year-ago' seconds and do a 'last_login < 1_YEAR_AGO'.

← Older revision		Revision as of 15:23, 25 April 2018
Line 4:		Line 4:

	John, Are you deliberately storing just the expiry date of the login ticket rather than the specific login time? Grand scheme I don't suppose it makes a lot of difference if there's an extra 7 days in the delete check. - Alan		John, Are you deliberately storing just the expiry date of the login ticket rather than the specific login time? Grand scheme I don't suppose it makes a lot of difference if there's an extra 7 days in the delete check. - Alan
		+
		+	Alan:
		+	No real reason - I was thinking that the retention period would be e.g. a year or so - and was trying to make things as least impactful as possible - so reusing a value that was already set.
		+	The problem with this is that if a repository has set a long expiry time, it could be bad (so maybe Will's suggestion is better).
		+
		+	I initially looked at using a commit trigger on the login ticket - but this changes every time you do anything - so introduces a lot of 'churn' on the system.
		+	- JLRS

← Older revision		Revision as of 13:28, 25 April 2018
Line 3:		Line 3:
	== Code queries ==		== Code queries ==

−	John, Are you deliberately storing just the expiry date of the login ticket rather than the specific login time? Grand scheme I don't suppose it makes a lot of difference if there's an extra 7 days in the delete check.	+	John, Are you deliberately storing just the expiry date of the login ticket rather than the specific login time? Grand scheme I don't suppose it makes a lot of difference if there's an extra 7 days in the delete check. - Alan

← Older revision		Revision as of 13:28, 25 April 2018
Line 1:		Line 1:
	I'm kind of torn between the two methods - John's has the advantage that it isn't dependent upon the mechanism by which someone creates a login ticket so should be more universal (e.g. for us), but Will's has the advantage that it's perhaps easier to understand for the less specialist eprints dev / admin. I.e. it doesn't use the magic of triggers, and it uses a date format that can be easily read rather than epoch timestamp (which apparently not everyone tracks on a daily basis) - Alan (2018-04-25 14:12:30z+01:00)		I'm kind of torn between the two methods - John's has the advantage that it isn't dependent upon the mechanism by which someone creates a login ticket so should be more universal (e.g. for us), but Will's has the advantage that it's perhaps easier to understand for the less specialist eprints dev / admin. I.e. it doesn't use the magic of triggers, and it uses a date format that can be easily read rather than epoch timestamp (which apparently not everyone tracks on a daily basis) - Alan (2018-04-25 14:12:30z+01:00)
		+
		+	== Code queries ==
		+
		+	John, Are you deliberately storing just the expiry date of the login ticket rather than the specific login time? Grand scheme I don't suppose it makes a lot of difference if there's an extra 7 days in the delete check.

← Older revision		Revision as of 13:12, 25 April 2018
Line 1:		Line 1:
−	I'm kind of torn between the two methods - John's has the advantage that it isn't dependent upon the mechanism by which someone creates a login ticket so should be more universal (e.g. for us), but Will's has the advantage that it's perhaps easier to understand for the less specialist eprints dev / admin. I.e. it doesn't use the magic of triggers, and it uses a date format that can be easily read rather than epoch timestamp (which apparently not everyone tracks on a daily basis)	+	I'm kind of torn between the two methods - John's has the advantage that it isn't dependent upon the mechanism by which someone creates a login ticket so should be more universal (e.g. for us), but Will's has the advantage that it's perhaps easier to understand for the less specialist eprints dev / admin. I.e. it doesn't use the magic of triggers, and it uses a date format that can be easily read rather than epoch timestamp (which apparently not everyone tracks on a daily basis) - Alan (2018-04-25 14:12:30z+01:00)