Notifications

[cdparra]

Summary: implemente a new model of subscriptions management and notification signaling.

Old model: each user had N Subscriptions to specific Events. Each Event was identified by an eventId equal to a UUID (of the campaign, contribution, etc.) + EVENT_NAME (e.g., 3de5a9f3-232d-4527-83b6-c850aeaf7388_NEW_IDEA). Whenever the EVENT_NAME occurred, a Signal was sent with the eventId, title, text, data (in JSON) and a filterBy (service to send the signal too). The signal processing then would find all subscribers of the eventId and send a message to the exchange identified by the alertEndpoint in the subscription.

New Model: store subscriptions to top level entities (campaign, assembly, working group, contribution) and manage, within the subscription, which events are being tracked (new idea, updated idea, etc.). Signals would then work the same, using the eventId but adding a resourceUUID to identify the top level entity. The signal processing would be updated to send the message via rabbitmq to subscribers that have the event enabled for that entity. If a subscription is of type "newsletter", then a newsletter service will process signals for these subscriptions and send periodic aggregated messages.

To implement this new model we need to update the https://github.com/socialappslab/subscription-manager and implement some things in AppCivist too.

ToDo list (to be converted in specific issues)

• [ ] Add a model in AppCivist to store subscriptions and update the model (

  {
  "subscriptionId" : 999, 
  "userId": 999,
  "entityUUID": "UUID of the target campaign, contribution, assembly, or WG",
  "type": "regular | newsletter",
  "frequency": 7, 
  "serviceMap" : {
      "email": true, 
      "facebook_messenger": false, 
      "UI": true
  },
  "eventMap" : {
     "NEW_IDEA": true, 
     "NEW_PROPOSAL": false
     "NEW_WG": false
     ...
  }
  }

  ServiceMap and EventMap will have a default value

• [ ] Modify subscribe endpoint to use the model above frequency info (defaulted to values above), and also including potential overrides.

• [ ] Extend the signal notification model in AppCivist to include an attribute to track if the signal was included in a newsletter

• [ ] Add a model for Newsletter, that would contain the full text to send

• [ ] Re-engineer the https://github.com/socialappslab/subscription-manager to extend subscription and signal processing to this new model

• [ ] When an user joins an assembly or working group, automatically create subscriptions to the assembly, the WG and the campaigns contained in the assembly

• [ ] Implement a newsletter service that will read the signal log every day, and create newsletters for campaigns every 7 days, looking at the signal log and creating an aggregated signal of the type newsletter

[cdparra]

@rafaelangarita can you add details about your latest improvements to the social-bus in the comments? Particularly, you mentioned something about having some form of user management and additional services.

[cdparra]

Moreover, I am linking here the original paper on the social bus by @rafaelangarita. I don't think is necessary to read to develop this issue, but just in case.