Sending notifications to users (Proposal: Subscription model)

[cpbscholten]

Copied conversation from alpha-banana-api (dutch):
@cmitz Webpush

Ik ben bezig met het mogelijk maken van push notificaties mbv de Webpush API. Echter komt daar ook bij kijken dat we op de server gaan bijhouden welke notificaties een gebruiker wil hebben. Ik wil graag discussiëren hoe we deze settings gaan bijhouden.
Voorstel

Ik denk dat een gebruiker zich moet aanmelden voor notificaties. Per email of webpush, ik zou een verschillend type notificatie verwachten bij een nieuw QP bericht dan bij een nieuw bericht op een forum topic dat ik volg. Met het onderstaande model kan je de volgende notificaties maken:

Bij een nieuw QP berichtje
Bij een nieuw forumtopic
Bij een nieuwe post in een topic dat je volgt
Bij nieuwe fotoalbums
etc

Een persisted model: Subscription
Velden:

user
content_type (QuickpostMessage|Forum::Thread|Article|PhotoAlbum|Photo )
content_id (optional, bij nil op alle van dit type)
notification_type (:email|:webpush)

Het nadeel hiervan is het polymorphisme. Je wilt een User koppelen met een "unit" op de website, maar omdat het meerdere types kunnen zijn (en een notificatie wel vrijwel altijd hetzelfde is) denk ik dat dit het mooiste is.

Ik wil hier graag ook een reactie van @tcoenraad op :-)
In de UI

Bij bijvoorbeeld een forumthread of fotoalbum verwacht ik een knopje in vinkje "Thread volgen". Volg algemenere notificaties zoals QuickPost, nieuwe artikelen of threads en andere dingen verwacht ik deze opties aan te kunnen zetten op de settings pagina.

Daar verwacht ik ook een stukje waar je alle bestaande subscriptions kan inzien/uitzetten.

@Matthijsy Ik vind het een goed idee. Ik zou echter het mail type niet doen, verwacht niet dat dit echt gebruikt gaat worden. Wat ik in de ui nog zou toevoegen is een notificatiecentrum (zoals Facebook ook heeft) zodat je daar alle notificaties ook te zien krijgt

@cmitz Een notificatiecentrum klinkt goed, alleen moeten we dan naast subscriptions ook notifications gaan bijhouden. Ik kwam met het type mail, omdat ik het zelf erg prettig vind om bij een nieuw forumbericht een mailtje te krijgen. Net zoals ik dat eigenlijk ook met github heb. Mail is wat persistenter dan een pushnotificatie, en zoveel nieuwe content is er niet op de alpha website - helaas

@Dennis17 Oeh. Cool.
Willen we ook zowel mail als webpush tegelijk ondersteunen? Dan moeten het aparte velden worden.

Het subscriptionmodel lijkt met goed. Misschien is het nog wel te onduidelijk. Als je op Forum::Thread met id 218 geabbonneerd bent, wat houdt dat dan in? Krijg je alleen notificaties van nieuwe posts in die thread, of ook als de thread gewijzigd wordt? Terwijl Forum::Thread met id nil je abboneert op nieuwe forum threads? of is dat Forum?

Misschien moet er nog een soort actie bij. Bijvoorbeeld Forum::Thread met id 218 en event new_post is een subscription op nieuwe posts binnen thread 218.

Als we notificaties willen bijhouden, moet er ook een Notification model komen. Wordt dit dan een algemeen model, of komt er voor elke soort notificatie een aparte subclass (ik ben voor het eerste)

@cmitz
Willen we ook zowel mail als webpush tegelijk ondersteunen? Dan moeten het aparte velden worden.

Hoeft niet per se. Dan maak je gewoon twee subscriptions aan.

Als je op Forum::Thread met id 218 geabbonneerd bent, wat houdt dat dan in?

Ik denk dat we dat per type content apart moeten bekijken. Niet alles hoeft configureerbaar voor de gebruiker, ik denk dat een goed doordachte default genoeg is. Met een actie erbij specificeer je al wel vrij veel in het subscription model, terwijl die logica juist bij het content type zelf zou kunnen blijven.

Is het bijhouden (een persisted Notification model) echt nodig?

@Matthijsy Aangezien de notificaties zoals eerst uitgewerkt niet werkte wil ik een (beter voorbedachte) nieuwe poging doen. Ik denk aan het volgende:

Een gebruiker kan zich inschrijven voor notificaties van een bepaald object. Denk hierbij bijvoorbeeld aan alle nieuwe QP berichten, een forum thread (ofterwijl alle nieuwe posts binnen die thread), of bijvoorbeeld een wijziging van een gebruiker. Let hierbij op dat een gebruiker zich dus kan inschrijven voor nieuwe objecten maar ook voor het wijzigen of verwijderen van objecten. Dit subscription model heeft de volgende velden (ongeveer zoals Casper voorstelde):
Velden:
    user
    model (QuickpostMessage|Forum::Thread|Article|PhotoAlbum|Photo )
    model_id (optional, bij nil op alle van dit type)
    model_action (Create, Update, Destroy)
    type (email xor ui)

Voor elke actie die er op een model wordt uitgevoerd (Create, Update, Destroy) wordt er voor de ingeschreven leden een Notification aangemaakt. Dit zorgt mogelijk voor wat load op de server maar door dit alleen voor de ingeschreven leden te doen zal dit beperkt blijven. Dit model ziet er dan als volgt uit:
    user
    content (het model waar wat mee gebeurd is)
    model_action (Create, Update, Destroy)
    did_read (boolean)

Dit notificatie object kan vervolgens gebruikt worden om de bolletjes in de UI te weergeven. Bijvoorbeeld het laten zien dat er een nieuwe activiteit is aangemaakt door een rood bolletje met een 1 erin bij activiteiten in het menu te zetten. Lukas had hier volgens mij al ideën voor.

Ik ben benieuwd wat iedereen van dit idee vindt. Het is een beetje hetzelfde als de vorige keer maar met de uitzondering dat je je er nu specifiek op moet subscriben