OpenERP : Comprendre et mieux maitriser l'open-chatter
La zone de dialogue et de notification d'OpenERP, appelée OpenChatter et inspirée du « Chatter » de Salesforce, est la zone bleue disponible en bas de quasiment tous les formulaires d'OpenERP.
Intérêt de l'OpenChatter
Son intérêt est énorme pour une entreprise : il permet la fusion entre ERP/PGI et Réseau Social d'Entreprise. Alors que les freins et obstacles à l'adoption d'un RSE sont nombreux, et que ceux-ci sont parfois déconnectés du métier ou restreints à une zone particulière, par exemple l'équipe commerciale, l'OpenChatter permet quant à lui de rassembler tous les métiers autour d'un outil collaboratif unique. L'adoption est directement favorisée par le fait que le logiciel est lui-même une zone de travail et une souce de partage autour de ce qui intéresse directement les utilisateurs dans leurs tâches quotidiennes. Inutile de forcer les gens à se connecter au vieil intranet maison pour visualiser les messages unidirectionnels de la direction. Inutile non plus de les forcer à se connecter à un réseau social sans contenu vraiment utile. Avec OpenERP un responsable des stocks pourra directement visualiser les messages transmis par le SAV autour d'un bon de livraison. Un commercial pourra aussi échanger des informations avec les équipes opérationnelles autour d'un projet, sans que l'information soit diluée dans des dizaines d'e-mails éparpillés dans leur boite aux lettres. Il est ainsi possible de diminuer l'utilisation de l'e-mail, comme ce qu'essaye de faire Atos depuis 3 ans, sans pour autant l'éliminer. L'email devient alors une source d'alertes, incitant via un simple lien à se connecter à l'OpenERP pour visualiser et traiter directement le travail à faire.
Son utilisation devient assez rapidement naturelle et virale : il suffit d'un seul catalyseur dans l'entreprise, qui comprend bien son fonctionnement et peut l'expliquer aux autres, puis le dialogue se crée, l'échange se propage, et d'autres utilisateurs commencent à l'adopter à leur tour.
Compréhension de son fonctionnement
Néanmoins, un frein à l'adoption de cet outil que nous avons constaté, aussi bien en interne que chez des clients, est justement le manque de compréhension de ce fonctionnement. Les utilisateurs ont l'impression de ne pas toujours maîtriser quels sont les destinataires des messages envoyés. La règle de base est pourant assez simple: les personnes qui recoivent les messages de l'OpenChatter sont les abonnées aux documents. L'idée maitresse d'OpenERP et de laisser la liberté aux utilisateurs de choisir les messages qu'ils recoivent. Quand on est émetteur d'un message il suffit donc de visualiser la liste des abonnés en bas à droite.
Mais il reste un problème : lorsque vous envoyez un message à un destinataire qui n'était pas abonné, il devient automatiquement abonné au document. Les autres abonnés, qui reçoivent donc aussi par e-mail le message, peuvent répondre par e-mail, mais n'ont à ce moment pas forcément conscience qu'il y a un nouvel abonné et que leur réponse peut tomber par exemple dans la boite d'un client (cas de la CRM).
En effet, un OpenChatter correctement configuré est branché sur une boite e-mail qui doit être sondée périodement ou en temps réel par OpenERP. Il peut s'agit soit une boite Catch-All, soit une boite spécifique. Quand OpenERP y trouve un message qu'il peut associer à un document de l'ERP (grâce au header "references" inclu dans l'e-mail), il le renvoie à tous les abonnés du document. La seule façon pour un destinataire d'avoir vaguement conscience de ceci est de regarder le texte de l'adresse Reply-To, qui reprend en général le titre du document. L'openchatter se comporte donc comme autant de listes de diffusion qu'il y a de documents.
Désactiver l'abonnement automatique
Mais cet abonnement automatique peut être pénible voire dangereux, car il peut donner lieu à des fuites d'information non désirables. Il n'est pas possible de le désactiver via de la configuration, mais il est possible de le faire en quelques lignes de Python, par exemple dans un module, sans toucher au code d'OpenERP.
L'idée est de surcharger l'AbstractModel utilisé pour gérer les fonctions de l'OpenChatter, donc ça ne marche pas avec un _inherit, mais avec un héritage Python :
from openerp.addons.mail.mail_thread import mail_thread
class mail_thread(mail_thread):
""" Disable autofollow
"""
def message_post(self, *args, **kwargs):
if kwargs.get('context') is None:
kwargs['context'] = {}
kwargs['context']['mail_post_autofollow'] = False
kwargs['context']['mail_create_nosubscribe'] = True
return super(mail_thread, self).message_post(*args, **kwargs)
De cette façon, vous pouvez envoyer un message à une personne externe qui ne sera pas ajoutée à la liste des abonnés. Et si un abonné répond au message, la personne externe ne le recevra pas : de cette façon la communication externe est mieux contrôlée. Ceci n'empêche pas d'abonner une personne externe, mais cette action est alors explicite, donc mieux maitrisée et mieux comprise.
Souvenez-vous :
Explicit is better than implicit ! ;-)