Difference between revisions of "Talk:GDPR"

From EPrints Documentation
Jump to: navigation, search
m
(Code queries)
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

Revision as of 15:23, 25 April 2018

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. - 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