Here at USQ we have cases where we have departmental staff in faculties or research centres that deposit papers on the behalf of academics. These might be secretararies or research assistants who handle the initial entry of data into the system, attaching the paper and the other tasks that are required. At the end of this process the library wanted to change the depositor from this user and reassign it to the primary author of the paper. So they needed a way to reassign the depositor. They didn’t want this to occur immediately and wanted to have some control over the reassignment. Initially I built it with a user picker for the depositor to select the new user however the Library requested a generic text field instead that the depositor could use to type the details of the person to which they wished the depositor reassigned.

So the first step in all of this drama is to add a few fields. We ended up with three fields: the first was a field for the depositors to enter the name of the user who the item should be reassigned to, the second was an ItemRef field which linked to the user table to have a representation of the user and the last was a checkbox which controlled if the user of the item is reassigned. The first field is visible to any one in the repository who has an account whilst the last two are visible only to repository staff (e.g. editors or administrators).
So to do this, we need to navigate to /opt/eprints3/archives/[archivename]/cfg/cfg.d/eprints_fields.pl and add the following:

Once we’ve done this, you need to run “/opt/eprints3/bin/epadmin update_database_structure [archivename]” to add the new fields to the database.

The next task we need to do is add this to the eprint workflow so that the fields turn up on the screen. This can be achieve by going to “/opt/eprints3/archives/[archivename]/cfg/workflows/eprint/default.xml” and adding it into one of the stages. I picked the “Notes” stage or tab to put it in, eventually it looked like this:

If you don’t have a “notes” stage already, you will need to add a new one to the flow at the top, if you’re using a standard ePrints configuration, it will look similar to this:

Pretty easy! The next step is to add some translations in “/opt/eprints3/archives/[archivename]/cfg/lang/en/phrases/eprint_fields.xml”. Add these lines before the final </epp:phrases> line:

So there is are two phrases for each field, the name and the help text that goes with it. Most of it is pretty self explanatory. The final step in this trip is to alter “/opt/eprints3/archives/usqep3/cfg/cfg.d/eprint_fields_automatic.pl” to set it so that it will change the depositor of the item once the tick box is checked.

# Depositor Reassignment
if( $eprint->get_value( “new_depositor_update” ) eq “TRUE” && $eprint->get_value( “new_depositor_assignment” ) != 0 )
{
$eprint->set_value( “userid”, $eprint->get_value( “new_depositor_assignment” ) );
$eprint->set_value( “new_depositor_assignment”, “” );
$eprint->set_value( “new_depositor_name”, “” );
$eprint->set_value( “new_depositor_update”, “FALSE” );
}
# End Depositor Reassignment
my $type = $eprint->get_value( “type” );
if( $type eq “monograph” || $type eq “thesis” )
{
These nine lines surrounded by Depositor Reassignment is inserted where it is and at this point we’re done. We’ll need to restart the server before we get too far just to ensure that everything takes properly and then we can test it all out.

The workflow at this point is that a user of the system marks down the person they wish to reassign as the depositor. We have an overnight report which runs to email one of our repository editors to notify them of items that are being requested to be transferred. They then view these items and enter the user ID of the user in question into the new depositor field (they can use lookup to validate it) and at this point they need to check the box to actually update the assignment. In ticking the box the the depositor is set to the value of the new depositor field, the reassignment field is blanked, the new depositor field is blanked and the check is cleared.

The most unfriendly aspect of this is finding the user in question. To do so you need to traverse the user search, find the user and then grab their user ID and put it in the field. This is a bit much. We also wanted to have the option to send an ameila but the editors need to be able to customise the email before it is sent and wanted control.

Fortunately the solution to the first problem was to utilise the Itemref custom InputForm Component that I created for the Author ID project. The second was to create a new one that primitively created a “mailto” link with a lot of the details pre-populated. For the latter I might have been able to do it within the workflow language but I felt it was easier to build in Perl.
Before we begin, we’re going to need a few files:

• The “Itemref.pm” file needs to be put in the “/opt/eprints3/perl_lib/EPrints/Plugin/InputForm/Component” directory.
• The “USQ_DepositorEmail.pm” file needs to be put in the “/opt/eprints3/perl_lib/EPrints/Plugin/InputForm” directory.
• The “user” file needs to be put in the “/opt/eprints3/cgi/users/popup/user” directory. The “popup” directory might not exist in your installation and will probably have to be added first.

Once you’ve got these files in place we’re ready to do some more modifications. In the “/opt/eprints3/archives/[archivename]/cfg/workflows/eprint/default.xml” file where we had the following:

We’re going to change that to the following:

This then tells the system to add a new “Find Entry” button which will popup with the user search window. The user search is limited to repository users so anyone who isn’t authorised will receive a login request form. It also tells ePrints to use the new Itemref InputForm Component to handle this field as well, which is what puts the Find Entry button and handles the other logic.
To add the email option, we add a single line after the above mentioned on to load it up:

Pretty simple changes here so far – this then puts some text with a link up if we need it. The last change we need to make is to include this into our language files. There are a few strings, we’ll just put them into the “/opt/eprints3/archives/[archivename]/cfg/lang/en/phrases/eprint_fields.xml” file we used previously:

All pretty simple, again these lines should be inserted before the </epp:phrases> line in the file. Once you’ve done this, restart the server again to pick up all of the changes and you should see a user picker interface and a little bit of text you can click to make a quick email message. You can customise the email message by altering the language strings to change what you want to display.

Currently ePrints lists authors by using the creator field of an ePrint. This is usually entered as the cited name of the author. If you have a small number of authors with different names this works reasonably well as the system can differentiate between people without much issues. The problem comes in when people are cited differently or have very similar names but are distinct people. Then it becomes bad.

One way of solving the problem is really quite ugly: you go through and change the cited author to make it look “neater”. In fact one of our library staff decided that they would do that greatly damaging the value of the data stored with in the system, tainting it horribly and creating more work for themselves. The cynic in me wonders that they’re just creating more work for themselves later to go back through and fix it all up. So there is a solution, non technical and pretty ordinary.

So our solution was to turn authors into a first class data set within ePrints. They’re not some unidentifiable free text field with no great purpose (there was a creator ID field but email address was suggested to be used for it) but in fact they are now their own entity which is cool.

We’ve done some different stuff with the author ID project at USQ that I’d like to share:

So an author has a name, they can be linked back to a user ID, they have an email address (both primary email address which should be used for contact and alternate addresses for aiding search), a biography and external identifiers. A cool feature of the primary email address is that when it is updated it automatically gets copied to the alternate email address list,  so you can easily update an email address and still retain the old one (you can still remove them from the alternate email address easily). The external identifiers section provides the ability to list useful identifiers for the author that mean something outside of ePrints. This could be stuff like a staff or student number that you record against the author to help with recognising your users. This is also a new field type developed called ‘Name-Value’ to represent name value pairs of data and provide an editing interface.

But the problem with authors is that they don’t stay the same: they’re dynamic. So they might move around an organisation, shift faculties, join a research centre or even leave the organisation. Recording this in the author record is more than possible but it starts to get messy – we start talking about ‘versions’ of the author but versions imply the wrong concept. A researcher might be working on papers in two different faculties, each paying for his time and each deserving of recognition. In our case we also need to use that information for reporting so that we can properly allocate funds based on research outcomes as well – for us it is important to know who paid for the research.

So to solve this problem I created a system called “author instances”. Author instances provide a subrecord of the authors that permits instances of specific data to be created and associated with the author. Then when an author creates a paper a link is created to this instance and not directly to the author. This allows the author record to contain information that is relatively static and data that might periodically change (such as department or even which institution someone is at) is then located in the author instance. As this isn’t ‘versioning’ per se it also works well for when a researcher is concurrently producing papers for different parts of the institution (or even for bodies external to the institution).

This screen depicts the edit view for an author instance.

The author instance is very light by default, it only contains the author that it is linked to, its display name and a preferred flag. The preferred flag is mutually exclusive within author instances – if one instance for an author sets the flag then it is cleared for all other authors. In the screen shot you will notice an untranslated field called “deptid”. This is another new metafield that has been developed called “Externalitemref” which is similar to the built in ItemRef field however it works on tables managed outside of ePrints. ExternalItemRef takes the params of a table name, a key field and a name field to operate in a similar manner to the ItemRef and link data back in.

The observant will notice that both the ExternalItemRef and the built-in ItemRef field also have a find entry button. This button has also been added to the ePrint item editing screen as well and triggers a popup window which allows easy searching for the particular item (user, author, author instance) that you are interested in.

The standard ePrints creator fields have a "Find Entry" button as well.

So as we can see there is now a “Find Entry” button that pops up with a new window allowing us to select an author instance for this author easily and not have to worry that we’re going to mistype their email address or similar.

This is just a quick introduction into some of the changes that the Author ID system which USQ has developed provides. Ideally we’d love to feed this back to the ePrints core so that everyone can use this, or a similar system, in a great way. If you want to read more you can check out the “Author ID Notes” document on my knowledge base download site.