Hey Everyone !
I have been planning for drafting a proposal for implementing email subscription this summer on BB.
I researched some mechanisms and came up following :-
I divided types of subscription into 3 :-
Also rough Database Design will be as follows
Database
There will be total 8 new table , because we will have 7 relation with editor(user) --> entity, where entities are ( revisions,author, work, editon, editon_group, publisher, collection ) + 1 for user–>user subscription
They will be like :-
user_subscribed_<entity_type>
-
user_subscribed_user
-
user_subscribed_author
-
user_subscribed_work
-
user_subscribed_edition
-
user_subscribed_editon_group
-
user_subscribed_publisher
-
user_subscribed_collection
and -
user_subscribed_revision
Every table will contain three fields
-
user ( linked to primary key of editor or a BB user )
-
entity ( linked to primary key of that entity )
-
id ( basic uuid )
1) user_subscribed_revision
Suggested by @ApeKattQuest_MonkeyPython , whenever a user make revision to any entity then they should automatically be added to user_subscribed_revision table and they should recieve email if anyone comments ( add note) on that revision .
- whenever a user hits the endpoint “/revisions/:id/note” the controller will find the subscribers of that revision from user_subscribed_revision table using revision_id and then send them mail.
2) user_subscribed_entity
Suppose a user subscribes a work entity ,I have assumed following mechanism in order to process subscription :-
- Any changes made to that entity will count as its revision , so whenever a new revision happens we will seek to the database user_subscribed_work database to find all its subscribers (BB user)
- We will find what we need to send in email by followig method :-
- work_revision table contains data_id column
- using that data_id we will find the final state of work and then
- Either we can list the changes made to the email body or simply we can use edit-note entered by user while editing the work entity + link of that revision
- And finally Use the mailer to send the mail to subcribers.
Likewise we will do the same for rest of entity( author, edition, edition_group, publisher, collection).
3) user_subscribed_user
Here i am not very much sure how things should flow , i explored MB notifiication system and subscribed a user , but when that user created a work/label i didnot get any email regarding this. Is this intentional .Or subscribing a User means something else ?
What i think it should be is , notify all subscribers to when any edit is made( either creation of some entity or editing of any entity which should be asked from user as its preference ) .
This is the rough idea the mechanism , Before going to the proposal part , it would be great to have feedback and discussions.
