Difference between revisions of "GDPR"
(→Delete User Action) |
(→Add 'Agree to privacy and data statement' checkbox on registration or request forms) |
||
Line 85: | Line 85: | ||
TODO - should be 'versioned' - so if the statement changes, the version that was agreed to can be shown. | TODO - should be 'versioned' - so if the statement changes, the version that was agreed to can be shown. | ||
Possibly a set/namedset, with the available options limited to only one when rendered to a user? | Possibly a set/namedset, with the available options limited to only one when rendered to a user? | ||
+ | |||
+ | Chris Gutteridge has written a blofg post on GDRP with a few comments about the EPrints Request a Copy feature: http://blog.soton.ac.uk/webteam/2018/05/10/gdpr-preperations/#post-content-1793;char=5429-7155 |
Revision as of 08:42, 11 May 2018
This page has been created to gather information and share code snippets to help EPrints repositories handle GDPR responsibilities.
Contents
Last Login Time
Storing the last login time of a user can be useful to identify which users are active and which are not to help ensure data is not being stored longer than is necessary.
First a new user field for storing the time is required in user_fields.pl
##user_fields.pl
push @{$c->{fields}->{user}},
{
'name' => 'last_login',
'type' => 'timestamp',
},
};
And then add the following code to $c->{check_user_password} in user_login.pl to store the time at which a user successfully logs in.
##user_login.pl
#get user from username
my $user = EPrints::DataObj::User::user_with_username( $repository, $username );
return 0 unless $user;
#get time and compile a string
my( @local ) = localtime( time );
my ( $sec, $min, $hour, $day, $mon, $year ) = ( $local[0], $local[1], $local[2], $local[3], $local[4]+1, $local[5]+1900 );
my $loginTime = "$year-$mon-$day $hour:$min:$sec";
#store the value
$user->set_value( "last_login", $loginTime );
$user->commit();
#return user
return 1;
JLRS: An alternative approach (please discuss which is better) is to set the trigger on the loginticket dataset (different field spec from above - bigint):
push @{$c->{fields}->{user}},
{
name=>"last_login",
type=>"bigint", #same as 'expires' field in EPrints::DataObj::LoginTicket
required=>0,
volatile=>1
}
;
$c->add_dataset_trigger( 'loginticket', EPrints::Const::EP_TRIGGER_CREATED, sub
{
my( %args ) = @_;
my( $repo, $loginticket ) = @args{qw( repository dataobj )};
# trigger is global - check that current repository 'user' dataset has last_login field to be updated
return unless $repo->get_dataset( "user" )->has_field( "last_login" );
#update volatile field in user record
my $user = EPrints::DataObj::User->new( $repo, $loginticket->get_value( "userid" ) );
if( defined $user ){
$user->set_value( "last_login", $loginticket->get_value( "time" ) );
$user->commit();
}
}, priority => 100 );
Non-Active Users Report
TODO worth having a count of items linked with the user on the report, along with their statuses?
Delete User Action
- Suggestion* Cron job to select all user accounts which have been inactive over a certain time threshold, check those users for affiliation to a publication (creator, editor, depositor etc.) which is either archive or buffer status and, where no connection exists, remove those user accounts.
Admin will be able to select user accounts from the report to delete (within the report or individually?)
Could be similar to: EPrints::DataObj::LoginTicket::expire_all - but with an $c->{'account_retention_time'} param taken away from the time() call?
Need to check logintickets too? Someone may not have actually logged in for ages, but maintained a browser session/cookies for a long time? (currently our longest 'active' login is ~20 days).
Add 'Agree to privacy and data statement' checkbox on registration or request forms
TODO - should be 'versioned' - so if the statement changes, the version that was agreed to can be shown. Possibly a set/namedset, with the available options limited to only one when rendered to a user?
Chris Gutteridge has written a blofg post on GDRP with a few comments about the EPrints Request a Copy feature: http://blog.soton.ac.uk/webteam/2018/05/10/gdpr-preperations/#post-content-1793;char=5429-7155