Visitor Account Meeting, 9th Dec 2014

Agenda

  1. Should we be reconciling visitor accounts in the future ?
  2. Probably due to a bug with VRS, we now have a number of reconciled accounts which no longer appear in the staff feed. This would mean that the users would have to use a v1 account if we implemented lifecycle code or 'we' would have to manually add a staff record for them. What action should we be taking ?
  3. What grace periods should we apply and how are we going to get round the issues that Toby raised in his email of 20th Nov (see below) ?

Toby's email of 20th Nov

We have approximately 800 accounts which are active in the KDC, but which do not appear in the database feed (because they no longer qualify for an account).

We have no way of programmatically knowing when these people lost their right to an account, thus no way of knowing when their grace period should begin. All we know is that they're no longer entitled to an account now. We also don't know what grace period is applicable, i.e. is a student a PGR or a PGT? We can make informed decisions based on roles they currently have in prometheus (if they have them).

These are made up of approximately 76 staff accounts, 85 visitors and 634 students.

I'm unsure as to how to go about the process of disabling these accounts. I was originally going to pick off those who hadn't authenticated in the past 3 months, i.e. send them an email and disable in two weeks, but there are approximately 560 of these, so this could present quite a support burden if lots of them reply. Alternatively I could give them all an arbitrary grace period and let lifecycle deal with them, but that would only defer the problem for a few months and obviously setting the same grace period at the same time for a large number of accounts would mean they all lost their roles and entitlements on the same day, hence potential support chaos.

Alternatively, I could process them in groups - students, visitors, staff.

My concerns are primarily that any email-wait-disable procedure could have a big support burden. Do we have to send an email to everyone whose account we want to close? I'm thinking of students here, not so much staff and visitors. I think we probably do, but I'd like to know what support and others think.

My second concern, which works against the first one, is that attempts to work through this in a piecemeal fashion are horrendously time-consuming.

A lot of this is pointless waffle without some kind of proposal, so I'm currently leaning towards the following:

  • let lifecycle deal with all of this *
  • set arbitrary grace periods for the separate categories
    • 240 days from day X for students who look like they were phd students
    • 150 days for all other students
    • 180 days for staff
    • 30 days for visitors
  • send mail in weekly batches of, e.g.
    • all visitors first
    • staff in two/three batches
    • students in batches of 100 or so at a time

(day X being the day we enable lifecycle code)

The mail sent will be of the form "our database records indicate your entitlement to the DICE account 'blah' has expired, your account will be disabled on date X+grace period, please let us know if you think this is in error"

The main problems with this proposal are:

  • we're giving too much grace period to most people
  • it's difficult for me to monitor correct behaviour of lifecycle code with 800 accounts in it from the beginning (I suppose that's my problem though)

A quick reminder, in very brief summary, for how lifecycle works for people who disappear from the database:

  • the roles and entitlements they have are preserved for the duration of their grace period
  • all of these are lost once the grace period expires
  • accounts are disabled/deleted manually

Conclusions

  • We should continue to allow visitor/staff records to be reconciled. This is a service provided by the University which is widely used within Informatics. When a staff account is reconciled with a visitor account, HR will need to manually update the UUN in the visitor record.
  • We should disable all student accounts which have not authenticated in the last 3 months.
  • We can then let lifecycle code pick up all the other remaining accounts.
    • We should be able to get end dates for most of these accounts and will use these to adjust expiry dates.
    • Where accounts have no end date, we will give them an arbitrary grace period.

-- AlisonDownie - 09 Jan 2015

Topic revision: r1 - 09 Jan 2015 - 15:02:23 - AlisonDownie
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies