A meeting was held to discuss matters concerning Prometheus and the Informatics database. A list of topics was circulated before the meeting and provides the headings below. Further information for each topic and a vague summary of discussion and decisions made is recorded. Additional topics, which weren't trailed before the meeting, are also included.

Present: Toby, Alison, Roger, Neil, Graham, Tim, Lindsey, George

formally define interface between db and prometheus

As prometheus makes fairly important decisions based on information it receives from the database, it would be good to write down what we can expect/not expect.

This was generally agreed.

(toby/gdutton to begin process)

which roles does/should the database provide

The database currently provides the following roles to prometheus:

  • module-*
  • year-*
  • degree-*
  • old-degree-*
  • new-degree-*
  • demonstrator-*
  • tutor-*
  • ta-*
  • staff
  • ex-staff
  • tempvisitor
  • visitingstudent
  • *-member
  • class-* [deprecated]

The use of database roles was discussed at some length. More detail in the next topic...

reliance on degree-* role to create student login accounts

All degree-* roles include the active-person role, which confers the appropriate capabilities for a user to have an account on our systems. This generally works well for Informatics students, but external students (those who possess the degree-ext role) also get accounts where many don't need or use them. There was some discussion about not automatically creating accounts for degree-ext students, but instead moving the account-granting capabilities to the module-* role level. Concerns were raised that relying on account-granting capabilities in module-* roles means the accounts are generated much later than using new-degree-* and degree-*. In the short term we would only consider using module-* for external students. Any plan for implementing this change may not be in place for this year's intake.

There was much discussion about how we can/should manage our roles. At the moment they are managed entirely within rfe, so a new module appearing in the database does not mean there will be a corresponding rfe file. A lot of this falls under the remit of the Roles Revamp project, so we will feed our input into that.

One suggestion which was generally agreed was that the active-person role should probably not be the place where account-granting capabilities are given, but they should instead be moved out to something like a new 'full-account-holder' role. This can then be allocated to the appropriate roles (such as staff, degree-*, module-* (?) etc, etc.) The reasoning behind this was that the active-person role includes the person role (which in turn includes many others...) It was felt desirable that account-granting be decoupled from the person hierarchy.

(toby to investigate creation of full-account-holder role and its implications - we can create a test roles->prometheus->system-ldap structure for this)

(toby/gdutton to look at what we can do automatically to ensure modules from the database have corresponding rfe maps)

(all to feed opinions on roles management to roger)

development views for prometheus

Many of the smaller changes we want to make to the data we get from the database are trivial, but require planning/moderation in case they break anything within prometheus. We should have a prometheus_dev_* view for every prometheus_* view in which we can test changes without fear of repercussions.

theon trac: development database views for prometheus testing

users disappearing from view / user deletion

We had initially thought that nobody (with the exception of visitors) would ever disappear from prometheus's database view. This doesn't seem to be the case. It is still the case that no regular, confirmed user should disappear, but that people could legitimately be removed from the feed (e.g. due to upstream error, mis-registration, etc.) The plan at the prometheus side is for users who disappear to be handled by lifecycle (i.e. archival, deletion, etc. rather than just be immediately deleted).

(toby to provide list of disappeared to gdutton)

There was some discussion over whether visitors should disappear from the database view, as it's different behaviour from that for other users (e.g. staff go to ex-staff, students go from degree-* to old-degree-*). It would be nice if all users were treated consistently, but this probably requires more thought.

(toby to provide further thought, probably once lifecycle code lands)

There was some further discussion over whether/when we should ever delete people from either the database/prometheus. It matters for prometheus, as the more entities we have, the slower the conduit loop runs. Also we probably have data protection responsibilities. This definitely requires further thought.

all visitors getting accounts

All visitors to the school receive a full account. Many do not need this, so we are concerned that we are over-creating accounts. We may, in the future, stop doing this and adopt a model similar to that suggested above for external students. This issue is not particularly urgent, so may go on the back-burner for the moment unless its priority is reassessed.

grace period for visitors (remove?)

There is currently a 1 month grace period for visitors, implemented within the database. This should arguably not happen and it should instead happen in prometheus, when prometheus can handle lifecycle properly. This should probably wait until lifecycle.

people with empty username - include or not?

The database 2g feed currently gives us 1648 people with empty usernames. We can't do anything with these, other than ignore them and log the matter. It would be nicer if we didn't see them at all.

theon trac: prometheus 2g feed gives us records with empty usernames

database input validation

Prometheus is occasionally troubled by usernames (and other fields) containing spaces (usually leading or trailing).

theon trac: whitespace in usernames

theon trac: prevent leading/trailing spaces in username

reliability of end dates for account deletion decisions

ktd's old scripts for finding out people to archive/delete

We'd really like to be able to get accurate information from the database on which we can base archival/deletion decisions. We can't currently do this as we have no reliable mechanism for determining when people have left. This is something we're keen to get as soon as possible - the account reconciliation project is being delayed because of it.

theon trac: expiry date for users

theon trac: Getting a list of current users out of the db

case (upper/lower) of uuids

We don't care either way uc vs lc but I think it stores up problems that we have both in the db. prometheus store is case-insensitive, but fetching a rec from prometheus then looking it up in the db may fail. We need to just make a decision and change accordingly.

theon trac: standardise case of uuids in theon

rename of 'default' field in prometheus_email_3g

We need this to write a proper test suite for infdb3g, 'default' is a reserved word in SQLite.

theon trac: rename of 'default' field in prometheus_email_3g

getting more information (staff/visitors) out of central auth/idms

We have requested via Graeme Wood that staff/visitor number is added to central auth - it's up to HR now, as it's their data.

email lists, grace period, etc.

We didn't discuss email lists. My plan was that we would talk about how they are currently managed and whether we can do it more automatically, using prometheus. One for services, perhaps?

Grace period matters were covered extensively elsewhere.

new student intake

We were unclear what the procedure was for new students concerning what information they receive, etc, etc. We need to speak to IGS to plan for this year.

(alisond to organise meeting between relevant computing staff and admin staff to discuss plans for new intake)

lifecycle

So much of what we want to do depends on us implementing grace periods and properly managing account lifecycles in prometheus itself. We can't do this, we don't know when we'll be able to do this or if we have to develop this all ourselves from near scratch. This is very far from ideal.


-- TobyBlake - 15 May 2012

Topic revision: r5 - 10 Jul 2012 - 08:30:05 - GrahamDutton
 
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