LifecycleΒΆ
Lifecycle of the Service records
Service record statuses:
- current - visible to the public, provider, and staff after approval by IRC staff
- draft - pending review by IRC staff. visible to provider and staff.
- canceled - provider canceled review before IRC staff acted on it. visible to provider and staff. OR provider withdrew the service after it was approved.
- rejected - IRC staff rejected it visible to provider and staff.
- archived - no longer visible in most interfaces, just keeping around because there might be links back to it from JIRA etc.
Provider creates a new service. It needs approval:
pk: 1 status: draft
Three possible new states:
Provider cancels it:
pk: 1 status: canceledOr, IRC rejects it:
pk: 1 status: rejectOr, IRC approves it:
pk: 1 status: current
From state current, provider submits some proposed changes. Now we have:
pk: 1 status: current
pk: 2 status: draft update_of: 1
Both of these records are visible to the provider, so they can see that they have a pending update.
From draft, pk 2 can go to canceled or rejected as before, which would leave pk 1 unchanged, but if it is approved then we don’t need pk 1 anymore, so we archive it and nobody sees it anymore. We get:
pk: 1 status: archived
pk: 2 status: current update_of: 1
So now the only records anyone sees are:
pk: 2 status: current
Suppose provider had submitted a change but it’s been rejected, so we have these two records lying around:
pk: 1 status: current
pk: 2 status: rejected update_of: 1
Now they submit a new proposed change. We only want 2 non-archived records around at any one time, so change the rejected record to archived before adding the new draft record:
pk: 1 status: current
pk: 2 status: archive update_of: 1
pk: 3 status: draft update_of: 1
The archive records don’t show up anywhere for now, unless you have a link to them.
If we had a canceled record lying around, we’d do the same thing with it (change status to archived before proceeding).
Suppose the provider doesn’t want their service published anymore. If we have
pk: 1 status: current
they can withdraw or cancel it, giving
pk: 1 status: canceled
leaving the service not visible to the public.
If the provider has a rejected or canceled record, they might reasonably want to edit it a little and “re-open” it, putting it back in draft status and requesting a new review.
But for phase I, let’s not implement that to save time. We can always add it later.
The working spec says that even while a change is pending, the provider can edit the draft service record and an update will be sent to the JIRA ticket to let the staff know that the data has been updated again.
Here’s that scenario with a new service pending. We start with:
pk: 1 status: draft update_of: none
Now the provider “edits” that draft, and we end up with:
pk: 1 status: archived
pk: 2 status: draft update_of: none
And we send a new comment to the JIRA ticket that was created when the first service record was submitted. The comment includes a link to the new record.
Now suppose we have one current record, and another record with a draft change to it:
pk: 1 status: current
pk: 2 status: draft update_of: 1
Now someone submits an edit to pk 2. We archive 2 and create 3:
pk: 1 status: current
pk: 2 status: archived update_of: don’t care
pk: 3 status: draft update_of: 1
and we submit a comment to the JIRA issue from pk: 2 and include a link to pk: 3.