Editing Talk:GDPR (section)

== 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)

----

<blockquote> >date maths less onerous</blockquote>
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)
----