La plate-forme émet de nombreuses notifications qui, selon le paramétrage de l’utilisateur, sont adressées par mail. Certaines notifications sont manuelles. Via l’action Notifier du menu Que voulez-vous faire ?, elles sont adressées par un utilisateur à une liste de destinataires (groupes et utilisateurs). Avant envoi, l’émetteur peut ajouter un message complémentaire qui sera ajouté au contenu de la notification.

Ces notifications peuvent être personnalisées. Grâce au mécanisme de StringTemplate, le contenu peut être modifié aussi bien dans le fond (dans la limite des éléments disponibles) que dans la forme. Le sujet, quant à lui, ne peut pas être personnalisé. C'est l’objet de cette évolution.

Actuellement, le sujet des notifications reçues par mail est formé des éléments suivants :
Nom de l’espace parent de l'application – Nom de l'application_ : _titre de la notification
Les deux premiers éléments sont ajoutés automatiquement. Le titre de la notification est quasi systématiquement Notification de Prénom Nom.

Silverpeas propose de mettre en œuvre les modifications suivantes :

• Pouvoir paramétrer le titre par défaut de la notification pour chaque type d'application (par exemple : A propos de titre de la contribution).
• Permettre à l’expéditeur de changer ce titre lors de l’envoi de la notification. Sur l’écran qui permet déjà d'ajouter un message complémentaire, le titre par défaut sera affiché dans un nouveau champ texte et sera modifiable.
• Pour les notifications par mail, ajout de paramètres globaux à la plate-forme qui permettent de personnaliser la localisation de la contribution : Affichage de l'espace parent Oui/Non, Affichage de l'application Oui/Non. Ces paramètres s'appliqueront à toutes les notifications reçues par mail.

A cette occasion, la page d'envoi sera modernisée (liste des destinataires notamment).

La réalisation de cette feature a permis d'unifier les différents mécanismes de notification manuelle aux utilisateurs. En effet, il existait non seulement plusieurs IHM mais aussi deux principaux services sans parler de ceux propres à certaines applications ou composant dans Silverpeas.

Désormais, le service AlertUser est supprimé et c'est celui UserNotification (anciennement NotificationUser) qui est utilisé et qui a été amélioré en vue d'offrir un seul et unique mécanisme transverse. Ce service est associé avec le widget Javascript sp.messager qui fourni l'IHM. sp.messager est la partie traitement de la vue userNotification/jsp/notificationSender.jsp qui elle génère la représentation HTML.

Le nouveau mécanisme¶

• ManualUserNotificationSupplier : une interface qui a pour objectif de fournir une instance de UserNotification, représentation d'une notification manuelle créée par et pour un composant Silverpeas (service transverse comme la notification aux administrateurs ou une application comme Kmelia). Les implémentations de cette interface ont pour but de préparer la notification manuelle à envoyer en fonction du contexte dans lequel elle est demandée (nous détaillerons ceci plus bas).
• ManualUserNotificationSuppliers : une classe qui représente une collection d'objets ManualUserNotificationSupplier. Elle est alimentée par chaque composant de Silverpeas et elle est directement utilisée par le service UserNotification pour obtenir la notification à personnaliser avec les informations qu'a rentré l'utilisateur (l'envoyeur) pour ensuite l'envoyer.

1. Ajout d'une implémentation à ManualUserNotificationSupplier dans la collection ManualUserNotificationSuppliers par chaque composant dans Silverpeas qui souhaite supporter la fonctionnalité de notification manuelle.
2. Lors d'un appel à la notification manuelle par un utilisateur, ici l'envoyeur, sp.messager est invoqué avec l'identifiant du composant par lequel la notification est demandée et un contexte de notification. sp.messager requête alors à UserNotification, avec les informations passées, l'IHM de la rédaction de message pour l'ouvrir dans une popup Javascript.
3. A la requête de sp.messager, UserNotification demande à ManualUserNotificationSuppliers l'objet ManualUserNotificationSupplier correspondant au composant Silverpeas et demande à ce dernier de lui fournir, en fonction du contexte de notification, une instance de UserNotification qu'il pourra par la suite personnaliser. Il renvoie à sp.messager l'IHM généré par notificationSender.jsp.
4. Une popup est affichée à l'utilisateur par sp.messager et l'envoyeur peut alors indiquer des destinataires (si ces derniers ne sont pas déjà fixé et non éditables), un sujet et un contenu de message. A la validation du message, sp.messager poste celui-ci au service UserNotification.
5. Le service UserNotification, à la réception du message de la part de sp.messager, personnaliser la notification utilisateur qu'il a précédemment récupérée avec les destinataires, le sujet et le contenu du message puis l'envoie ensuite.
6. sp.messager ferme la popup.

Afin d'automatiser le 1., l'ajout d'un ManualUserNotificationSupplier dans la collection ManualUserNotificationSuppliers est faite directement dans la classe ComponentRequestRouter qui est héritée par l'ensemble des routeurs Web de Silverpeas. Celle-ci, à la création d'une instance de ComponentSessionController, demande à cette dernière de lui donner un ManualUserNotificationSupplier qu'elle enregistre sous le nom du composant :

 private void registerManualUserNotificationSupplier(final String componentId, final T ctrl) {
    if (StringUtil.isNotDefined(componentId)) {
      final String componentName = getSessionControlBeanName();
      ManualUserNotificationSuppliers suppliers =
          ServiceProvider.getService(ManualUserNotificationSuppliers.class);
      suppliers.set(componentName, ctrl.getManualUserNotificationSupplier());
    } else if (!PersonalComponentInstance.from(componentId).isPresent()) {
      final String componentName = ComponentInst.getComponentName(componentId);
      ManualUserNotificationSuppliers suppliers =
          ServiceProvider.getService(ManualUserNotificationSuppliers.class);
      suppliers.set(componentName, ctrl.getManualUserNotificationSupplier());
    }
  }

Pour ce faire, une méthode a été ajoutée à ComponentSessionController : #getManualUserNotificationSupplier(). Par défaut, cette méthode retourne une notification utilisateur vide :

default ManualUserNotificationSupplier getManualUserNotificationSupplier() {
   return c -> new NullUserNotification();
}

La conséquence de ceci est que tous les composants de Silverpeas (doté du trio MVC) ont par défaut un ManualUserNotificationSupplier dans ManualUserNotificationSuppliers. Celui-ci fournit une notification utilisateur vide et donc, pour supporter la notification manuelle, en dehors d'ajouter la fonction dans son IHM, le composant Silverpeas a juste à implémenter la méthode #getManualUserNotificationSupplier() avec son propre ManualUserNotificationSupplier dans son contrôleur web.

Un petit mot sur ManualUserNotificationSupplier. Ce dernier supporte qu'une seule méthode qui accepte comme argument une instance de NotificationContext. Cette instance est construite par UserNotificationRequestRouter à partir des paramètres de la requête HTTP reçue de sp.messager :

private NotificationContext getNotificationContext(final HttpRequest request) {
    final NotificationContext context = new NotificationContext();
    Enumeration<String> parameters = request.getParameterNames();
    while (parameters.hasMoreElements()) {
      final String name = parameters.nextElement();
      context.put(name, request.getParameter(name));
    }
    return context;
  }

sp.messager.open(compoId, {recipientUsers: users, recipientGroups: groups, recipientEdition: false});

• recipientUsers: une chaîne de caractère avec les identifiants d'utilisateurs destinataires, séparés chacun par un virgule.
• recipientGroups: une chaîne de caractère avec les identifiants de groupes destinataires, séparés chacun par un virgule.
• recipientEdition: un booléen indiquant si oui ou non l'envoyeur peut éditer les destinataires de la notification.

Mais n'importe quelle propriété peut être spécifiée avec l'assurance que celle-ci soit transmise au ManualUserNotificationSupplier du composant afin qu'il puisse fournir correctement la bonne notification utilisateur.

La personnalisation programmatique¶

• en définissant la propriété custom.st.notification.subject dans leur ressources multi-langue,
• en surchargeant la méthode AbstractTemplateUserNotificationBuilder#getBundleSubjectKey() pour lui faire retourner la clé relative au sujet à utiliser dans la ressource multi-langue du composant.

• notification.source.spaceLabel : un booléen pour indiquer si ou non le nom de l'espace doit être indiqué dans le sujet d'une notification manuelle,
• notification.source.componentLabel : un booléen pour indiquer si ou non le nom de l'instance d'application doit être indiqué dans le sujet d'une notification manuelle.

Validé et intégré...