This section is dedicated to informing you of all the latest and greatest updates to the MVault API.

Membership PATCH: 'on_conflict' 

View more information

Problem

Currently, MVault resolves the activation process for two or more memberships that share the same UID by [under the covers] assessing which membership appears to be the better candidate for activation, while deactivating the lesser candidate. See here for more details on that assessment.

There are times, however, when this automated means of conflict resolution may be at odds with how an implementer (a station or CRM) wants to handle such conflicts. For example, what if an implementer wants to delete the extra membership? Or, what if the implementer wants to handle the membership conflict in some other manner, on their own?

Solution

The 'on_conflict' parameter.

How does it work?

The on_conflict parameter should be passed along with a PATCH:

HTTP Request
PATCH https://mvault.services.pbs.org/api/{membership_id}/activate?on_conflict={value}

URI Parameters

ParameterValueDescription
on_conflictdeactivate / delete / failSpecifies how overlapping memberships are handled

Example

Membership M1 is associated to a station S1 with a "uid" U1. Let's say there also exists another membership M2, also associated to station S1 but with a blank "uid". If S1 tries to activate M2 with "uid" U1, then if M1's 'expire_date' > M2's 'start_date', M1 is an overlapping membership.

Such memberships can be handled in different ways depending on the value of the 'on_conflict' parameter. If 'on_conflict" is:

valuebehavior
deactivateM1 is deactivated. (this is the current behavior)
deleteM1 is deleted
failthe API returns HTTP 400 BAD REQUEST and nothing happens

Status: RELEASED

"Current State"

Problem

There has been much confusion about what exactly constitutes an activated membership. Why the confusion? Understandably, because there are a multiplicity of conditions that lead to a membership being considered active. For example, looking at the following set of JSON attributes could be a bit confusing:

"status": "On",
"activation_date": {yesterday}
"start_date": "{tomorrow},

Despite having a status of 'on', this membership would not be active because, due to time windowing, it has not started. 

The GOAL of Current State is to have just ONE attribute you can look at to determine if a membership is active.

Solution

A JSON block that explicitly indicates a membership's activated status is produced along with a brief explanation.

{
   # .... other membership keys
   "current_state": {
       "has_access": false,
       "explanation": [
           "status":"off",
           "timing":"grace_period_over",
           "token_activated":"false"
       ]
   }
}

Hopefully, this clears things up!

Status: RELEASED

Fixing the 'activation' algorithm

Status: RELEASED. Documentation coming soon.

Bulk DELETE

Coming soon.