Actuellement, il existe deux mécanismes de notification aux abonnements :

• la notification aux abonnés des changements de contributions
• la notification aux abonnés à des positions sur le Pdc

Notification aux abonnés des changements de contribution¶

Ce mécanisme s'articule autour de trois axes fonctionnels :

• des utilisateurs s'abonnent à une application, à un thème (dossier, album, catégorie) ou à une contribution
• tout changement qui s'opère sur une ressource d'abonnement conduit à notifier les abonnés au sujet du changement :

• une contribution a été publiée dans une application ou un thème
• une contribution dans une application ou thème abonné a été modifiée
• une contribution abonnée a été modifiée

• les notifications sont envoyées groupée sous forme de synthèse si l'abonné préfère les envois retardés par mail selon une périodicité définie par lui (les envois retardés ne peuvent être que par mail).

Les messages des notifications sont définis au niveau de chaque application. Le contenu des synthèses, quant à elles, sont gérées directement par le mécanisme de notification (le sous-mécanisme de notification retardée/synthèse de notifications)

Notification aux abonnés à des positions sur le Pdc¶

Ce mécanisme s'articule autour de deux axes fonctionnels :

• des utilisateurs définissent des centres d'intérêts pour lesquels ils souhaitent être informés ; ces centres d'intérêts sont définis par des positions sur le Pdc.
• le classement d'une contribution sur le Pdc ou la modification d'une contribution conduit à notifier les abonnés aux positions du Pdc sur lesquelles la contribution est classée.

Les messages des notifications sont gérés directement par le mécanisme.

Le problème¶

Ces deux mécanismes s'ignorent. Ce qui fait que, par exemple, si un abonné est abonné à un thème et qu'une publication dans ce thème est classée sur des positions sur Pdc pour lesquelles l'abonné est aussi abonné, alors tout changement dans la publication va produire deux notifications, l'une par le mécanisme d'abonnement aux contributions, l'autre par le mécanisme d'abonnement au Pdc.

De plus, parce que ce sont deux mécanismes disjoints, des améliorations dans l'un sont souvent oubliés dans le second. C'est ainsi que la fonctionnalité de synthèse de notifications (notification retardée) n'a pas été portée dans le mécanisme de notification d'abonnement au Pdc.

Nous avons donc ici une duplication du mécanisme de notification d'abonnement qui n'est pas souhaitable. Certes, ces deux mécanismes recouvrent deux couvertures fonctionnelles différentes, mais les attendus sont les mêmes : être notifié de toute modification d'une contribution liée à la source d'un abonnement, quelque soit la nature de celle-ci : un thème, une application, la contribution même, ou un centre d'intérêt (un ou des positions sur le Pdc).

Objectif¶

N'avoir plus qu'un seul mécanisme de notification des abonnés, que l'abonnement porte sur une ressource (application, dossier, contribution) ou sur des critères de classement du PdC, afin qu'une amélioration apportée aux notifications d'abonnement profite d'office aux deux.

Ceci est la continuité de l'existant :

1. Le stockage est déjà unifié. Depuis la Feature #15409, un abonnement PdC est un abonnement comme les autres : PdcSubscriptionPositionCriteria est une SubscriptionResource de type PDC , enregistrée dans la SubscriptionFactory , et ses abonnés s'obtiennent par SubscriptionService.getSubscribers(...) . Il ne reste à unifier que la notification
2. Côté contributions, il n'y a qu'une porte d'entrée pour connaître les abonnés : ResourceSubscriptionProvider , et qu'un seul socle de construction des notifications : AbstractUserNotificationBuilder , qui reconnaît déjà les notifications d'abonnement par l'interface @UserSubscriptionNotificationBehavior@adelaide.lenogues@o2.fr
3. Le passage contribution → classement existe déjà dans core-library : ContentManagementEngine.getSilverContentId(idContribution, idInstance)