The privacy thing is a good point, however we also use staff ID’s on our public facing staff directory so I’m not sure it’s an issue.

 

At present any leaving members of staff are removed from the user table when the nightly cron job runs and farmed off into another table in the EPrints database which retains them for future reference. When the browse pages are rendered, creator browse also cross references this table as well as the main EPrints user table. The main issues I have surrounding this is that, as the work has been done at a core EPrints level, past updates to the EPrints software has wiped out the work and it has had to be retrofitted into the system. On top of that, it doesn’t seem to be compatible with the most recent version of EPrints for whatever reason – in short, it’s a bit of a maintenance nightmare!

 

Thinking about this in detail, I can see why users were farmed – we reuse usernames within the institution, so if John Smith, jsmith, were to leave and a Jane Smith were to subsequently start, she would be given the username jsmith. In the instance of using this to log into EPrints we would have a situation where Jane would inherit John’s records. So we’d need to keep some kind of “identifier” table going, or somehow de-username users in the main table when they leave, but still retain the ability to be able to identify them by their old staff ID. Tricky.

 

I think this needs to be thought through by the team – all this work was done before I started so now I’m just unpicking the reasoning behind a lot of the choices. I think there is more efficient ways of putting the code into the system to make sure that we keep it sustainable but I can also see why the method was put in place as it was.

 

 

We have viewed the LDAP auth/users subsystem and the creator/author/browse views subsystems as separate.

 

We abstracted it out one extra level, so the author_identifier, isn’t their employee/staff id (you know, for privacy’s sake ;) ).. it instead links to an ‘author’ system we built.

The staff directory etc, used an api call (passes in the employeeID and gets the AuthorID), to build the url for the publications chunk, to include in the staff profile page.

We also have 6 usertypes, so we can allow LDAP or NON-LDAP logins.

 

This way we can remove/disable user accounts, and have no impact on the ePrint pubs side of things.

How does your system handle the removal of ex-staff from the user tables, but if there are linked ePrints to that userID… does it cause any problems?

 

 

 

The use case for us is the generation of pages for creators. As a background, we currently do LDAP login via a bulk import, but the script that controls this is quite destructive and is intrinsically tied into a number of core EPrints files which I want to get away from – basically it tears down the user table nightly, reimports a fresh dump from LDAP but also harvests off any users who may have left the university into a separate table. One of the things that using their internal staff number, which is a six digit numeric string, does for us is it allows us to use a constant identifier for that member of staff across all systems we want to join up.

 

Take, for example, a user John Smith with username jsmith and staff ID of 123456. John can log into the system using his normal user details through LDAP authentication which is fine, but when his creator browse page is created it is as http://eprints.lincoln.ac.uk/view/creators/123456.html which is great for us to be able to point other systems or apps at to drag his records back and use on, say, our internal staff directory. For us it’s that single point of truth that we know we can use everywhere as an identifier, as well as not making members of staff use a different login for different systems.

 

 

 

What’s the use case for the id being the internal one, rather than an EPrints one?

 

We’ve got the internal id as the username, which seems to be effective.

 

Lizz

 

 

 

Okay, related to but separate from my ongoing quest to migrate and improve our EPrints install, I’m looking into options for getting an LDAP authentication script up and running. I’ve had a look online and found a couple of different ways to implement this, one of which (http://wiki.unimas.my/unimaswiki//bin/view/HOW-TO,+Tutorial+&+User+Manual/HOW-TO+:+Install+Eprints+v3.3.12++on+Ubuntu+14.04+With+LDAP+Authentication) I’ve tried to no avail.

 

Does anyone have any particular way of implementing this that they can recommend? I’m on the fence as to whether we should be doing this on a bulk import or creating users as and when they log in, however I DO want to ensure that the ID associated with the user is the one from our internal system and not a naturally generated one from EPrints.

 

As always, thanks in advance!

Andrew

_____________________________________________________________

This email (including any attached files) is confidential and is for the intended recipient(s) only. If you received this email by mistake, please, as a courtesy, tell the sender, then delete this email.

The views and opinions are the originator's and do not necessarily reflect those of the University of Southern Queensland. Although all reasonable precautions were taken to ensure that this email contained no viruses at the time it was sent we accept no liability for any losses arising from its receipt.

The University of Southern Queensland is a registered provider of education with the Australian Government.

(CRICOS Institution Code QLD 00244B / NSW 02225M, TEQSA PRV12081 )