From EPrints Documentation
Revision as of 15:57, 25 April 2018 by Libjlrs (Talk | contribs)

Jump to: navigation, search

This page has been created to gather information and share code snippets to help EPrints repositories handle GDPR responsibilities.

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
push @{$c->{fields}->{user}},
        'name' => 'last_login',
        'type' => 'timestamp',

And then add the following code to $c->{check_user_password} in to store the time at which a user successfully logs in.
#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 );
#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}},
        type=>"bigint", #same as 'expires' field in EPrints::DataObj::LoginTicket
$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" ) );
}, 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?)

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?