Talk:GDPR: Difference between revisions
No edit summary |
No edit summary |
||
| (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 | |||
---- | |||
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. | ||
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)