As a Crossref employee, I want the suspension/unsuspension process for Metadata Plus tokens to be automated to save toil across several team

What When a Metadata Plus subscribers access is suspended due to unpaid invoices, the following process occurrs:

Membership ticks the suspended tick box in Sugar, and removes the service altogether from Sugar (making a note in the general notes section of the fee and start date for when/if we need to reinstate it). This cuts off the subscriber from OAI-PMH. Membership then raises a Zendesk ticket for the support team who make a note of the suspension on this spreadsheet

Support then remove the token from the sla_tokens.dat file used by Haproxy on cr5c and cr5d and the development team put this into production. As soon as the token has been removed, REST API access will be disabled.

If the member pays their invoice, then their access is reinstated going through the process again - membership unticks the suspension tick box, and has to add the service back in again with the original start date and fee. Support makes a change to the file, and the developers have to make this live.

Are we able to:

  • Cut off OAI PMH access based on the suspended box being ticked in Sugar (or even just by adding an end date to the service in Sugar). Reinstate OAI PMH access based on the suspended box not being ticked, or there not being an end date.
  • Automate the removal of the token from haproxy based on the suspended tick box or the addition of an end date to the service in Sugar. Automate the reinstitution of the token based on the suspended box being unticked in Sugar, or the removal of the end date to the service in Sugar.

Why

This will remove a lot of toil and back and forward between membership, support and the development team, will speed up the process and make things smoother for subscribers.

How urgent

Revoking tokens happens at the beginning of each year, so ideally have this in place by the end of 2021.

Definition of ready

  • Product owner:
  • Tech lead:
  • Service:: or C:: label applied
  • Definition of done updated
  • Acceptance testing plan:
  • Weight applied

Definition of done

  • Unit tests identified, implemented, and passing
  • SONAR on merge request branch checked by tech lead
  • SONAR on merge request branch checked by reviewer
  • Code reviewed
  • Available for acceptance testing via a staging URL, or otherwise
  • Consider any impacts to current or future architecture/infrastructure, and update specifications and documentation as needed
  • Knowledge base reviewed and updated
  • Public documentation reviewed and updated
  • Acceptance criteria met
    • AC 1
    • AC 2
  • Acceptance testing passed
  • Deployed to production

Prior to and during Backlog Refinement, consider the potential impacts this user story may have on the following areas:

  • Billing/costs
  • Internal documentation
  • External documentation
  • Schema
  • Outputs
  • Operations
  • Support & Membership experience
  • Outreach & Communications
  • Testing
  • Internationalization
  • Accessibility
  • Metrics, analytics, reporting

Additional details about the above items can be found here.

Notes

Edited by Patrick Polischuk