Reduce noise in system error reports and pass specific errors directly to the membership team
Background
Jon receives a regular report of errors and anomalies in our systems. This report includes issues in various different systems, and a lot of noise. We'd like to find a way to reduce the noise, and also siphon off the errors that the membership team can fix in Sugar to a separate distribution list so we're reducing the toil for Jon in having to identify relevant errors and pass them manually to the membership team.
Observed behavior
Single report with a lot of errors/anomalies relating to Sugar, CS, Intacct, ORCID etc.
Expected behavior
-
Remove the noise from the report Where a prefix is identified as deleted in the admin tool, don't alert that the prefix is no longer in Sugar. (eg | 10.30444 | |----------| | 10.30446 | | 10.30449 | | 10.30453 | | 10.30450 | | 10.30451 | | 10.30443 | | 10.30448 | | 10.30447 | | 10.30452 | | 10.11585 | There may be more!
-
Put some of the messages in a separate report with a distribution list of member@crossref.org Errors that the membership team can fix in Sugar should be included in this list. This includes:
- Errors relating to invalid email address or no email address being present
- Errors of prefixes against multiple accounts
- System prefix not found in Customer DB (Sugar)
How urgent
This is not causing an immediate problem, but will help to reduce toil for a developer and mean that genuine problems in the data are fixed faster, reducing the risk of the wrong members being invoiced, reports not being sent to the right place, and metadata being incorrect.
Definition of ready
-
Product owner: @SaraBowman -
Tech lead: @jonmstark -
Service:: or C:: label applied -
Definition of done updated -
Acceptance testing plan: verify memx team gets one email daily with error summary -
Weight applied
Definition of done
-
Unit tests identified, implemented, and passing -
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 -
Once daily email of memberinfo errors to memx team -
AC 2
-
-
Acceptance testing passed -
Deployed to production