Define and Implement a functional, minimal, "tracer bullet"

[artntek]

See included Items on MVP board

Define and implement a functional, minimal implementation of the most simple, basic functionality possible for an end-to-end implementation to do something useful. This is the "Tracer Bullet" approach defined in "The Pragmatic Programmer"; i.e.:

you might construct a tracer consisting of a trivial implementation of the [...] algorithm [...] and a simple but working user interface. Once you have all the components in the application plumbed together, you have a framework to show your users and your developers. Over time, you add to this framework with new functionality, completing stubbed routines. But the framework stays intact, and you know the system will continue to behave the way it did when your first tracer code was completed.

---

The simplest-possible, first-iteration example in our case might be:

INCLUDES

1. Add a "subscribe/follow" button on dataset landing pages
2. Button action records the user's orcid and email address, associated with the dataset identifier
   • Look into using the seriesId for the binding point rather than specific pids.
   • ASSUMES FOR NOW - default email address from orcid account?,
   • Notification frequency
   • event granularity
   • Record other assumptions as they are discovered
3. Verifies user has read access to requested dataset. If not, return an error
4. When dataset is updated
   1. Verifies user has read access to requested dataset. If not, send email saying access denied
      • (OK to leak info about updates, even though contents hidden?)
   2. an email is sent to the address above, containing a link to the dataset

---

DOES NOT YET INCLUDE

(These will be added in subsequent iterations)

Other triggers

• Notifications available for both portal owners/editors and the community (when the portal/dataset is public)
• If dataset or portal subsequently made private, unsubscribe public "followers"

Settings - view summary and edit values:

• unsubscribe
• email address
• frequency of notifications
• fine grained control over each event, e.g. following only citation events and not view events.

...or anything else not mentioned above

---

Initial implementation: https://github.com/artntek/notification-service