Notes from the 11 Dec 2013 meeting to decide what needs to be done about mailing lists' grace periods.

Attended: alisond, gdutton, lmb, neilb, toby.

* where do the come from?
 - auto: database -> rsync
 - manual: don't care.

not just staff - any entitlement
- COs, e.g. needs immediate removal

* Cases:
 - some staff WANT to remain on lists
 - teaching however needs overlap.
     * rollover is before resits

* Classes of students
 - could be done in conduit
 - but needs dated data

* Manual overrides
 - in 2g database only
 - needs to be updated

* Mailman overrides
 - normal suppression possible
 - manual manual catting possible (but very difficult)

* A Prometheus conduit would be the ideal
 - tied directly to entitlements
 - needs timed / delayed entitlements
 - allows overrides, etc.
 - 2g data needs to be cleaned (parse upto first comma, replace unqualified domains)
 - who does exception administration, and where? DB? conduit? mailman?
    - access control is important here, but is possible within mailman

SHORT TERM:
 - remain as-is for short term
 - fix email data interface to Prometheus [T/G]
 - but monitor the situation for problems
 - add comment to mailing list conduits [N/G]

MEDIUM TERM:
 - document mechanisms for querying / addition / removal exceptions [N/L/A]
 - propose a mechanism for generation using a Prometheus conduit, driven by entitlement

LONG TERM:
 - Add grace periods to Prometheus mechanism (pending life-cycle code; itself pending code review)
   (with default for removal)

-- GrahamDutton - 11 Dec 2013


This topic: DICE > WebHome > ResearchAndTeachingUnit > GracePeriodsMeeting2013
Topic revision: r2 - 15 Jan 2014 - 13:05:44 - 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