Informatics is one of the few schools that maintains its own separately authenticated local user accounts (DICE) rather than using EASE/AD centrally managed accounts. Our accounts are automatically created and expired based on data we receive from the centre. However this is a much more complex process than at first might seem.
We need to pull data from a number of central sources to determine whether a local Informatics account should be generated for a user:
- EUCLID (Edinburgh University Complete Lifecycle Integrated Development) is used to provide data on which students are on our programmes, or on other School’s programmes but taking some of our courses, and we use this to create the set of “current” students that need an account. When the programme registration ends for whatever reason (hopefully the result of an award) or the course ends (effective at the end of a session) or status indicates withdrawal then the local account will enter expiry. There are plenty of issues we see with this data such as changes of programme/status, or a dependence on when the centre update key data that can all cause a lag in local account creation. We also use data from EUCLID to be informed of our “upcoming” students (principally PG students) so that the local account can be created in advance of the actual programme start date.
- OracleHR/IDM (Identity Management System) is used to provide data on which staff are associated with our School and are entitled to a local account. There are many subtle issues with this particular data set (primarily due to the fact that OracleHR at least was never intended to be a feed of live data) that means we often see a lag in account creation for staff, which we would prefer not to have. Also we see issues with new staff that have transferred from elsewhere in the University. Staff that are not “contractually” associated with our School but nevertheless for whatever reason need a local account are also problematic.
- VRS (Visitor Registration System) is used to provide data on visitors who need a local account (not all do). There are issues with this data set due to upstream bugs that have not been fixed and also with handling aspects of the UUN reconciliation process.
As a meta issue we also have to track many accounts that traverse (and change associated UUN as they do) from one data set to another. For example, a student on one of our programmes that after finishing becomes employed as a member of staff and then leaves but is kept on as a visitor. Different account types often overlap as well, temporarily while traversing or for a longer period of time (for example a member of staff who is also registered to do a PhD).
So while we deal automatically with the creation and expiration of many local accounts every day, the vast majority of the few thousand or so we have causing us no trouble, we still often have to deal with anomalies in specific edge cases. Unfortunately individual anomalies can cause a delay in account creation or can result in erroneous account expiration. Each instance must be manually investigated and progressed.
If you do have an issue with your own account or an account you have requested for someone else please contact frontline support who will be able to investigate.