Roster self entry

[tim-pearce]

We have 'Roster Unavailability'. Don't know if that's available in the members area.

I've heard of systems where members enter themselves onto a roster.

I propose a restricted access to rosters in the members area.

Firstly would be a 'Member roster view' - this defines a roster and date range which can be accessed from the members area. A given member would only see rosters where they are a member of one of the volunteer groups on that roster.

When the member opens the roster :-

• date range is predefined
• they can only add or remove themselves or members of their own family (makes it more convenient for couples)
• they can see other members assignments but not change them, even to replace them with someone from their family
• unavailabilities still apply

I believe this would entail minimal change to the roster editing page and would be quite willing to make those changes. Adding a new dialog is not something I've done in Jethro so that would be more challenging.

[tbar0970]

Yes interesting feature idea. It would be worth discussing it further here (including implementation details) to ensure a smooth path into the main branch :)

[tbar0970]

More context: In the members area currently, you can manage your unavailabilities, and you can view any roster view which has its visibility set to "members area" or "public".

[tbar0970]

Some initial questions that arise for me:

• Why limit the date range, instead of having it open-ended?
• If Joe Bloggs adds himself to the roster on a certain date, and the pastor thinks "great, that date is covered", then Joe Bloggs comes back and removes himself, the pastor gets a nasty surprise when that date rolls around, nobody shows up to serve, and there's no record of Joe Bloggs other than the pastor's hazy memory. If people are able to remove themselves, we probably need some sort of audit trail.

[tim-pearce]

The 'Member roster view' only exists while the roster is being prepared thus :-

• there is a set date range
• eventually the view is closed/deleted so the administrator of the roster can finalise the roster.

[tbar0970]

Ah I see, it's like a draft roster for a particular period. A 'working document'.

[tbar0970]

"Member roster view" probably isn't the best name, because "roster view" already refers to a collection of roster roles, without the time-restricted draft concept. Maybe "Roster draft" is a better name?

[tbar0970]

So I can see it working like this:

• Administrator creates a "roster draft" object, which references roster view and has a start and end date.
• In the members area, members can assign themselves/family members to allocations within the roster draft (In the DB this creates rosterdraft_role_assignment records which are distinct from roster_role_assignment records in a 'real' roster).
• After a while, an administrator can close the roster draft
  • At this point, the administrator can (probably will) choose to save all the rosterdraft_role_assignments as roster_role_assignments (ie they get saved into the 'real' roster)
  • After this point, the roster draft is no longer visible in the members area, and its assignments can't be edited

[tim-pearce]

I wouldn't bother with a 'rosterdraft_role_assignment'. The 'roster_draft' object defines a restricted view of the roster. Processing via the draft is the same process as the 'real' one with a few restrictions.

[tbar0970]

Yes I guess that's fair enough. A roster_draft record signifies "assignments for roster view X between dates Y and Z are open for self-editing".

I wonder if there would be value in defining a built-in closing date for edits? Eg a roster_draft signifies "Until 1 Feb, members may add themselves to the "morning church" roster for dates between 2 Feb and 1 April"

And/or there could be a blanket rule that self-edits can't be done for dates in the past, even if a roster_draft is in effect.