This is a POC for report unsubscriptions. Maybe someone could have a look if the implementation is fine that way.
Would add tests and some more doc blocks and so on after a first review...
Thanks for the PR! Feedback after a quick review:
@mattab I'll implement a Nonce in the unsubscription form, that should help avoiding iterating automatically over possible tokens (which have up to 100 chars).
For sure we could also update the subscription when the reports are added/updated. I've Implemented it that way to ensure a subscription is created/available if an email is sent. Otherwise it might happen that for example third party plugins somehow manipulate reports without calling a method that updates the subscriptions.
Came up w/ one question that probably only @mattab can answer: Is it important for admins to see who unsubscribed?
@diosmosis Thought about that as well. Will add an event triggered when someone unsubscribes from a report. That way we can at least show it in the Activity Log
It may be needed to keep trace of those who unsubscribed. Would it maybe work to have a column in the table "subscribed" or so and set it to 0 when not? This way we could have the data who has unsubscribed, which later we may show in the UI maybe.
But probably only showing this info in the activity log is required for now?
@mattab I've pushed an update. The table now also includes two columns with timestamps for subscription and unsubscription date. When someone unsubscribes the unsubscription date will be set, and the token will be nulled. If the email is readded in the report this entry will be overwritten with a new one (with unset unsubscribe date). That way we could later show a list of emails that unsubscribed or maybe even block readding unsubscribed emails in report admin.
Update looks great @sgiehl :+1: Just left a few comments, let me know if these could be applied soon?