Difference between revisions of "Talk:GDPR"

From EPrints Documentation
Jump to: navigation, search
 
(2 intermediate revisions by one other user not shown)
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. - 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.
 
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).
 
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.
 
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
 
  
 
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
+
- JLRS (John)
 +
 
 +
----
 +
 
 +
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 (Rory)
 +
 
 +
----
  
 
<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
 +
 
 +
Also, rather than using the 'expiry' field, there is a 'time' field - which makes more sense (I think)
 +
 
 +
- 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)
 +
----

Latest revision as of 11:18, 1 June 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


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

- JLRS (John)


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 (Rory)


>date maths less onerous

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

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. Cjg (talk) 11:18, 1 June 2018 (UTC)