Notification / subscription system on BB discussion

Tags: #<Tag:0x00007f5124db0700> #<Tag:0x00007f5124db01b0> #<Tag:0x00007f5124da7a60>

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


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_user

  • user_subscribed_author

  • user_subscribed_work

  • user_subscribed_edition

  • user_subscribed_editon_group

  • user_subscribed_publisher

  • user_subscribed_collection

  • 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 @CatQuest , 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.

@mr_monkey please have a look at it :smiley:

6 posts were split to a new topic: Editor subscription notifications broken?