Project

General

Profile

Feature #9884

Intitulé des objets de mails de notifications

Added by Jérémie Le Guillou 11 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Category:
Notifications
Start date:
06/21/2018
Due date:
% Done:

100%

Estimated time:

Description

Bonjour,

C'est un sujet dont nous avons déjà parlé mais je me demandais si il était prévu prochainement de changer l'intitulé des objets de mails de notification.

En effet, actuellement je reçois des objets de ce type : "Communication interne - Actualités communication interne : Notification de Marie Duris" alors que l'expéditeur est déjà Marie.

Ne serait-il pas plus utile de mettre : "Don du sang / Communication interne - Actualités communication interne" en objet, histoire d'avoir à la fois le contexte et l'objet réel du mail ?

Par ailleurs, avec cela vient le corollaire : Est-il prévu de pouvoir personnaliser le texte de ces mails aussi ? Je suis toujours horrifié par les "..." après "l’actualité suivante".

Je ne sais pas si il faut mettre le ticket ici ou dans les features Silverpeas mais en tout cas c'est très demandé, notamment au plus haut niveau, chez nous.


Related issues

Is duplicate of Silverpeas Core - Feature #954: Personnalisation de l'objet des notificationsClosed09/02/2010

Actions
Is duplicate of Silverpeas Core - Feature #1865: Personalisation du sujet des notificationsClosed04/06/2011

Actions
Is duplicate of Silverpeas Core - Feature #6421: Amélioration des notifications manuellesClosed03/26/2015

Actions

History

#1

Updated by Sebastien Vuillet 11 months ago

  • Project changed from Château de Versailles to Silverpeas Core
  • Category set to Notifications
  • Assignee deleted (Sebastien Vuillet)
#2

Updated by Nicolas Eysseric 7 months ago

  • Status changed from New to Assigned
  • Assignee set to Miguel Moquillon
  • Target version set to Version 6.1

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'applicationNom 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).

#3

Updated by Nicolas Eysseric 7 months ago

  • Is duplicate of Feature #954: Personnalisation de l'objet des notifications added
#4

Updated by Nicolas Eysseric 7 months ago

  • Is duplicate of Feature #1865: Personalisation du sujet des notifications added
#5

Updated by Nicolas Eysseric 7 months ago

  • Is duplicate of Feature #6421: Amélioration des notifications manuelles added
#6

Updated by Miguel Moquillon 6 months ago

  • Status changed from Assigned to In progress...
#7

Updated by Miguel Moquillon 5 months ago

  • Status changed from In progress... to Resolved

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

La notification manuelle (ou l'envoi de message aux utilisateurs) est centrée autour de deux objets logiciels principaux :
  • 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.
La notification manuelle suit les étapes suivantes :
  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;
  }
Ce contexte est initialement passé en argument à sp.messager via sa fonction open(instanceId, context). Par exemple, avec l'application Quizz :
sp.messager.open(compoId, {recipientUsers: users, recipientGroups: groups, recipientEdition: false});

Un certain nombre de propriétés de contexte sont prédéfinis :
  • 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

Le sujet d'une notification aux utilisateurs est fixée et donnée par la propriété GML.st.notification.subject qui contient une expression StringTemplate. Celle-ci peut-être personnalisée par les composants de deux manières différentes :
  • 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.
A côté de cette personnalisation, une plus globale peut aussi être définie. Par défaut, le sujet d'une notification est préfixé par le nom de l'espace suivi du nom de l'instance de l'application à partir duquel la notification est envoyée. Or, dans certains cas, cette information peut être redondante, voir non désirée pour des raisons diverses et variées. Pour ce faire, deux propriétés ont vue le jour dans le fichier de propriété SILVERPEAS_HOME/properties/org/silverpeas/notificationManager/settings/notificationManagerSettings.properties :
  • 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.
#8

Updated by Nicolas Eysseric 5 months ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100

Validé et intégré...

Also available in: Atom PDF