Réalisation¶
Première approche (abandonnée)¶
Dans un premier temps, une tentative a été faite de réutiliser et étoffer l'existant des abonnements à des positions sur des axes du PdC (les PdCSubscription). Le soucis est que les abonnements au PdC existant s'appuient sur le fait qu'ils adressent un seul utilisateur. Or l'objectif est de pouvoir ici créer des abonnements au PdC pour plusieurs utilisateurs, soit directement, soit par le biais de groupes d'utilisateurs. Or, à ce point là, il s'est avéré que du code (et donc du fonctionnel) de l'API des abonnements utilisateurs allait être dupliqué.
Refactorisation du mécanisme des abonnements au PdC¶
Pour éviter de dupliquer le mécanisme d'abonnement forcé existant dans le code propre au PdC, les abonnements au PdC ont été refactorisés pour s'appuyer entièrement sur l'API des abonnements de Silverpeas. Ceci a permis de fusionner l'API des abonnements au PdC à celui des abonnements utilisateurs aux ressources : une seule API d'abonnement unifiée.
Les modifications¶
Pour ce faire, il a fallu réifier l'ensemble des positions sur des axes du PdC comme une ressource d'abonnement (implémentation de l'interface
SubscriptionResource). Or l'ancien
PdcSubscription mélangeait trois notions :
- l'ensemble de positions sur les axes,
- son libellé,
- et l'abonné (
ownerId).
Le refactoring les sépare.
C'est ainsi que PdcSubscriptionResource réifie l'ensemble nommé de positions sur des axes du PdC (SubscriptionResource de type PDC), enregistré dans SubscriptionFactory par un bean Initialization, sur le modèle éprouvé de CALENDAR et PUBLICATION. Son nom et ses positions sont chargés paresseusement, la ressource étant instanciée pour chaque ligne lue par SubscriptionDao.
PdcSubscription devient alors un AbstractSubscription<PdcSubscriptionResource> : il porte l'abonné, le créateur, la date, et la méthode d'abonnement SELF_CREATION / FORCED du mécanisme générique.
En base, SB_PDC_Subscription ne décrit plus que les ressources (id, name) ; les abonnements migrent vers la table existante subscribe. Le script de migration SQL up003 transfère les abonnements existants en SELF_CREATION avant de supprimer le champs ownerId.
Ce que le mécanisme générique apporte gratuitement¶
Les groupes d'utilisateurs sont désormais gérés : checkSubscriptions résout ses destinataires par getSubscribers(resource).getAllUserIds(), qui développe les groupes en utilisateurs. Un utilisateur abonné via son groupe voit également l'abonnement dans sa fenêtre personnelle, ce qui n'était structurellement pas possible auparavant. La purge des abonnements à la suppression d'un utilisateur ou d'un groupe est prise en charge par les listeners existants, et l'écran de sélection des abonnés est celui de la plateforme.
Sept méthodes de PdcSubscriptionService qui géraient l'abonnement lui-même ont ainsi pu disparaître ; le service ne conserve que le cycle de vie des ensembles de positions et les règles métier propres au PdC.
Deux obstacles rencontrés¶
Oracle et l'identifiant d'instance vide. Le PdC est transverse aux applications, sa ressource n'a donc pas d'instance applicative. Or subscribe.instanceId est NOT NULL et Oracle stocke la chaîne vide comme NULL — la contrainte aurait sauté, à la migration comme à l'exécution. La constante NO_COMPONENT_INSTANCE = "-" suit la convention déjà en vigueur dans cette même table pour l'espace non défini.
Le gestionnaire qui s'abonne lui-même. AbstractSubscription déduit SELF_CREATION quand l'abonné est le créateur ; un gestionnaire se désignant parmi les abonnés aurait fait sortir son propre ensemble de la liste des abonnements forcés. Un constructeur acceptant explicitement la méthode permet à la fenêtre PdC de forcer FORCED .
Notifications devenues multilingues¶
Bâties pour un destinataire unique, les notifications composaient leur message dans la langue du propriétaire. Elles s'adressent maintenant à plusieurs abonnés de langues potentiellement différentes : titres, contenus et NotificationResourceData sont produits pour chaque langue de la plateforme via addLanguage et setNotificationResourceData(lang, …).
Couche web¶
La fenêtre « Mes abonnements » conserve son onglet PdC dédié ; PDC est exclu des catégories génériques pour éviter le doublon d'onglet qu'aurait induit son enregistrement dans le registre. La suppression d'un abonnement personnel ne détruit l'ensemble de positions que s'il ne reste plus aucun abonné.
Dans la fenêtre PdC, l'écran d'édition accueille la liste des abonnés et un bouton vers le userpanel. L'édition en cours — nom, positions, abonnés désignés — est encapsulée dans une classe interne PdcSubscriptionEdition conservée en session pour survivre à l'aller-retour ; rien n'est persisté avant validation du formulaire.
Tests¶
Treize tests unitaires ont été écrits sur les règles métier du PdC, qui n'en avaient aucune — correspondance d'une classification avec un ensemble de positions, suppression de valeur d'axe.
Interface Web¶
Abonnements personnels au PdC¶
Lorsque l'utilisateur accède à ses abonnements au PdC, il obtient la vue suivante :
Comme avec les autres types d'abonnements, une nouvelle colonne l'informe si l'abonnement à des positions sur des axes du PdC vient de lui ou lui a été imposé par un administrateur ou un gestionnaire du PdC. Seuls ses abonnements personnels peuvent être modifiés ou supprimés, et ceci même s'il est lui même administrateur ou gestionnaire du PdC.
La fenêtre d'édition d'un abonnement personnel reste la même :
Abonnements forcés au PdC¶
Un administrateur ou un gestionnaire de PdC ne peut accéder aux abonnements forcés que dans l'onglet "Plan de Classement" du backoffice, via le menu "Les abonnements" :
De là, il accède à la page des abonnements forcés au PdC :
Sur cette page, il pourra à loisir créer un nouvel abonnement à des positions sur des axes du PdC :
ou encore modifier un des abonnements existants :
Dans les deux cas, c'est le même écran d'édition qui s'ouvre et par lequel il peux sélectionner des utilisateurs ou des groupes d'utilisateurs via le panneau des utilisateurs :
Mis à jour par 
Mis à jour par 
