Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

BlueMind sort sa version 5.0 : tous les détails techniques

BlueMind est une suite logicielle libre (AGPL v3) de messagerie d’entreprise, d’agendas et de travail collaboratif.

Poursuivant l’objectif global de permettre aux utilisateurs de concrétiser l’abandon des messageries Microsoft, Exchange et 365, cette nouvelle version apporte plusieurs nouveautés et des changements profonds d’architecture, pour supporter les différents clients et simplifier la transition des utilisateurs.

Sommaire

Nouveautés architecture

Le Remplacement de Cyrus-IMAP

Jusqu’à sa version 4 incluse, BlueMind intégrait Cyrus-imap – une brique open source bien connue – comme serveur de stockage des mails.

BlueMind 5 a remplacé Cyrus Imap par un composant maison.

Il y a plusieurs raisons derrière ce choix :

  1. La première consistait à se libérer de la dépendance à un code non écrit par BlueMind qui apportait des limitations techniques de plus en plus contraignantes sans possibilité réelle d’évolution.
  2. La deuxième raison majeure concernait le stockage objet, un point faible de Cyrus qui ne correspondait plus aux besoins d’évolution de BlueMind.
    Jusque-là, beaucoup d’éléments de BlueMind étaient construits de façon à s’adapter ou contourner les limitations de Cyrus-imap. Le choix a donc été fait de s’en affranchir.

Les limitations de Cyrus IMAP

Cyrus accuse son âge et engendre des limites de plus en plus fortes dans un contexte de messagerie moderne, en plus des contraintes inhérentes au protocole IMAP, loin d’être toujours efficient (performances & limites fonctionnelles). Les principaux inconvénients de Cyrus sont :

  • Consommation de ressources élevée (RAM et CPU). Le modèle 1 connexion = 1 process a fait long feu.
  • Pas adapté au stockage objet, car conçu pour stockage disque local (les mails et toutes les méta-données sont stockés directement sur le filesystem local, et les traitements sont adaptés à ceci).
  • Les partages sont limités au périmètre d’un backend, donc à ce que peut supporter un seul serveur. Pas de partage global. Les mécanismes de contournement sont très archaïques, limités et peu fiables.
  • Modèle de mail figé et limité, qui ne permet pas d’ajouter des informations (catégories enrichies, infos diverses de collaboration ou gérées par des plugins, etc.) ou de façon très limitée.

À noter : BlueMind 4 intègre de nombreux contournements ou palliatifs afin de dépasser ces limites.

La fin de la réplication

BlueMind propose le support natif d’Outlook, sans ajout d’extension ou modification d’Outlook (que ce soit au niveau des IHM, des fonctionnalités ou du comportement), car c’est ce que veulent les utilisateurs : Outlook (tel qu’il fonctionne aujourd’hui chez nous avec Exchange). Cela se traduit par le support des protocoles/formats natifs d’Exchange/Outlook, soit MAPI côté serveur.

Cependant, MAPI fonctionne comme une base de données, par synchronisation, et les requêtes qu’effectue Outlook ne sont absolument pas compatibles avec le fonctionnement/principes d’un serveur IMAP.

Pour supporter MAPI et répondre de façon correcte et rapidement à ses requêtes, qui nécessitent des lectures/écritures très rapides et très fréquentes, il était nécessaire de contourner le serveur IMAP Cyrus et donc de stocker les données des e-mails (plus exactement les méta-données et la structure des e-mails) dans une base de données. Le corps des e-mails étant gardé uniquement dans Cyrus.

C’est ce qui a été fait dans BlueMind 4, mais cela engendre une double gestion des données et donc la nécessité d’assurer la cohérence globale entre les deux stockages de données (Cyrus et la BD) avec la complexité inhérente à ce type de système.

Assurer cette cohérence était le rôle de la réplication de BlueMind 4 qui utilisait la réplication native Cyrus. Cette opération est coûteuse et nécessite d’attendre que Cyrus ait effectué ses opérations avant de les répliquer. Ce processus asynchrone passait par des workers de réplication qui devaient faire un retour après chaque opération afin de communiquer les modifications à Outlook (et aux mobiles). Il pouvait occasionner un délai entre les actions et donc générer une différence entre le client et le serveur. Une opération contradictoire pouvait casser la synchronisation avec Outlook.

Nous arrivions donc aux limites du système, contraignant les transitions vers une architecture cloud-ready, les grosses montées en charge, le support très avancé du client Outlook et les interfaces intelligentes vers les outils de Digital Workplace.

Les gains

Avec la version 5 de BlueMind, Cyrus a donc tiré sa révérence. Les fonctionnalités de stockage et gestion qui lui incombaient encore sont maintenant prises en charge directement par le cœur de BlueMind, de façon plus moderne et sans les limitations précitées.

En v5, quand un e-mail arrive, là où BlueMind stockait dans Cyrus puis attendait la notification de la réplication avant de stocker en base de données, BlueMind effectue simplement un insert en base de données, suivi d’une copie du mail dans le stockage sur le disque (ou objet), et a immédiatement tous les éléments nécessaires à la communication avec Outlook.

À noter : Au-delà d’Outlook, cette nouvelle infrastructure prend en compte et améliore la communication avec les clients IMAP, mobiles, Thunderbird et Apple Mail.

Des gains importants sont constatés au niveau de :

  • La consommation de ressources, notamment la RAM.
  • La fin de la limitation de partages au niveau d’un backend.
  • Le format d’un e-mail, maintenant évolutif, qui permet le développement de fonctionnalités comme les catégories.
  • L’implémentation possible et réalisée du stockage objet.

Le stockage objet

En version 5, avec la suppression de Cyrus, BlueMind a fait le choix de passer nativement sur un stockage objet pour les raisons suivantes :

  • Capacité à traiter de gros volumes.
  • Avoir une architecture plus cloud-ready au niveau du stockage.
  • Permettre la corbeille à double-fond (l’e-mail est stocké sous forme d’un fichier sur le disque ou réseau, auquel est associé une clé - hash du mail - en BD. Lorsqu’un client demande un accès au fichier, BlueMind sait très rapidement dire au client où sont stockées les données et comment y accéder).
  • Backup plus simple et direct.
  • Meilleure sécurité. Par exemple, l’API S3 permet de rendre immuable un objet, une fois qu’il est écrit il ne peut pas être modifié et donc, un ransomware par exemple, ne pourra jamais chiffrer le fichier.

L’ensemble de BlueMind a été modifié pour s’adapter à la conception objet. En effet, il ne s’agit pas uniquement de changer les appels de lecture ou d’écriture des informations, mais d’adapter l’application (modélisation et traitements), du backend aux clients comme le webmail, aux paradigmes du stockage objet (latences sur la récupération des objets, gestion des listes d’objets ou mails via les méta-données, etc.) sous peine d’obtenir une application aux performances déplorables.

BlueMind v5 est compatible S3 et Scality et permet de fonctionner avec un disque local en émulant nativement un stockage objet sur des disques.

Ainsi, les installations actuelles ou nouvelles de BlueMind n’ont pas à subir de modifications, le disque local suffit et le stockage objet est possible sur les partitions habituelles.

OpenID et le SSO

À partir de sa version 5, BlueMind prend en charge le protocole OpenID, notamment pour avoir un support SSO (Single-Sign On) et pouvoir s’inclure dans un système d’information proposant déjà un service de SSO.

OpenID est mis en place par l’intermédiaire de Keycloak.

Cela va permettre d’ajouter progressivement de nouvelles fonctionnalités comme le MFA (authentification multi-facteurs).

Note : Le Keycloak intégré à BlueMind n’a pas vocation à être la brique SSO centrale du SI client. Si un client veut mettre en place un SSO global pour son système d’information, il faut qu’il mette en place un système externe (un Keycloak par exemple). BlueMind a choisi de rester maître de sa brique Keycloak et de communiquer avec la brique SSO externe.

AuditLog

Afin d’améliorer la traçabilité métier (voir le parcours d’un email dans le système), BlueMind 5 inclut un Auditlog, outil basé sur ElasticSearch et RocksDB, qui permet de stocker de nombreuses informations pertinentes dans le cadre de l’administration d’un serveur BlueMind :

  • Toutes les opérations de chaque e-mail : les déplacements, les suppressions, les différents flags (lu/non-lu, important, deleted…), les timestamps et les auteurs.
  • Les événements et les séries d’événements, ou sur les ACL les grant et revoke accès sur les partages de dossiers, de mailshares, sur les calendriers ou les carnets de contacts, etc.
  • Les connexions des utilisateurs, peu importe le moyen de connexion.

Auditlog est actuellement disponible uniquement en CLI. Une IHM sera proposée ultérieurement.

Nouveautés utilisateur

Le nouveau webmail est le webmail officiel

Le nouveau webmail, proposé en test à partir de BlueMind 4.6, s’est considérablement enrichi et est maintenant l’interface officielle. Il est aux normes de l’architecture logicielle de BlueMind (application JS qui fonctionne via API et synchronisation en utilisant le cache du navigateur).

L’ancien webmail, qui était basé sur Roundcube, peut encore être installé (il ne l’est plus par défaut sur les nouvelles installations), mais il n’est plus recommandé, notamment pour des raisons de sécurité.

Parmi les nouveautés du webmail :

  • Meilleure intégration des carnets d’adresse.
  • Corbeille à double fond.
  • Disponibilité d’un mode sombre et accessibilité encore augmentée.
  • Plus de capacités de tris et filtres.
  • Prévisualisation des messages attachés à un mail.
  • Support du S/MIME.

Autres nouveautés

De nombreuses autres nouveautés sont apportées par la v5, comme :

  • Un plugin BlueMind Visioconférence pour Outlook.
  • La gestion des délégations « à la » Microsoft.
  • Le transfert d’invitation de réunion.
  • Les disponibilités affichables sous forme d’agenda dans l’agenda.
  • Gestion de l’état Annulé d’une réunion.

Le détail des nouveautés est disponible dans le changelog.

Le passage en version 5

La version 5 recommande maintenant 24 Go minimum.

L’outil de migration bm-migrator permet de passer d’Office365/Exchange/Zimbra/Kerio/Kopano/Dovecot, etc., à BlueMind 5, en automatisant la récupération de presque toutes les données.

À noter : Une migration nécessite toujours un travail et des tests préparatoires.

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de Crème CRM en version 2.6

Le 5 août 2024 est sortie la version 2.6 du logiciel de gestion de la relation client Crème CRM (sous licence AGPL-3.0), environ 11 mois après Creme 2.5 (11 septembre 2023).

Icône de Crème CRM

Au programme notamment, un système de notification, des améliorations pour le calendrier ou des filtres réservés aux rapports. Les nouveautés sont détaillées dans la suite de la dépêche.

Sommaire

Description du logiciel

Crème CRM est un logiciel de gestion de la relation client, généralement appelé CRM (pour Customer Relationship Management). Il dispose évidemment des fonctionnalités basiques d’un tel logiciel :

  • un annuaire, dans lequel on enregistre contacts et sociétés : il peut s’agir de clients, bien sûr, mais aussi de partenaires, prospects, fournisseurs, adhérents, etc. ;
  • un calendrier pour gérer ses rendez‐vous, appels téléphoniques, conférences, etc. ; chaque utilisateur peut avoir plusieurs calendriers, publics ou privés ;
  • les opportunités d’affaires, gérant tout l’historique des ventes ;
  • les actions commerciales, avec leurs objectifs à remplir ;
  • les documents (fichiers) et les classeurs.

Crème CRM dispose en outre de nombreux modules optionnels le rendant très polyvalent :

  • campagnes de courriels ;
  • devis, bons de commande, factures et avoirs ;
  • tickets, génération des rapports et graphiques…

L’objectif de Crème CRM est de fournir un logiciel libre de gestion de la relation client pouvant convenir à la plupart des besoins, simples ou complexes. À cet effet, il propose quelques concepts puissants qui se combinent entre eux (entités, relations, filtres, vues, propriétés, blocs), et il est très configurable (bien des problèmes pouvant se résoudre par l’interface de configuration) ; la contrepartie est qu’il faudra sûrement passer quelques minutes dans l’interface de configuration graphique pour avoir quelque chose qui vous convienne vraiment (la configuration par défaut ne pouvant être optimale pour tout le monde). De plus, afin de satisfaire les besoins les plus particuliers, son code est conçu pour être facilement étendu, tel un cadriciel (framework).

Du côté de la technique, Crème CRM est codé notamment avec Python/Django et fonctionne avec les bases de données MySQL, SQLite et PostgreSQL.

Principales nouveautés de la version 2.6

Voici les changements les plus notables de cette version :

Le nouveau système de notification

Depuis toujours Crème possède un système de Mémentos (Reminders), qui permet de recevoir des e-mails pour vous prévenir d’une échéance. Ce système est utilisé par les Alertes & les ToDos ; par exemple vous recevez un e-mail lorsqu’une Alerte qui vous est attribuée va expirer dans 30 minutes. Et comme vous pouvez créer des Alertes dont la date d’expiration est un champ date de la fiche associée, cela permet par exemple d’être prévenu qu’une activité importante à laquelle vous participez va bientôt avoir lieu.

Le nouveau système de notification qui a été introduit amène 2 avancées principales :

  • les notifications envoyées ne sont pas limitées à des e-mails, vous pouvez aussi les voir dans votre navigateur (donc sans quitter Crème).
  • si les mémentos ont été retravaillés pour utiliser ce nouveau système, d’autres parties de Crème en profitent aussi. Par exemple, une notification vous est envoyée si un administrateur a changé votre mot de passe ; ou bien quand un job d’import CSV vient de s’achever.

Une notification web est arrivée

Chaque notification est associée à un canal, et vous pouvez configurer les canaux pour savoir si la notification est envoyée dans le navigateur, par e-mail ou bien les 2. Si le canal n’est pas obligatoire, vous pouvez aussi choisir de ne pas recevoir les notifications du tout. Chaque utilisateur peut utiliser sa propre configuration si la configuration générale du canal ne lui convient pas.

La configuration des canaux

Améliorations du calendrier

  • Le composant JavaScript FullCalendar est passé à la version 5. Même si ce n’est pas la toute dernière version (il faut dire qu’il y a pas mal de changements cassants entre chaque version), on profite de pas mal d’améliorations diverses.
  • Il est maintenant possible de configurer graphiquement le calendrier (premier jour de la semaine, plage horaire, jour travaillés…). Il y a une configuration globale utilisée par tout le monde, mais comme presque toujours dans Creme, il est possible de créer des configurations par rôle.

La configuration des calendriers du module « Activités »

Filtres spécifiques aux Rapports

Les Rapports utilisent généralement un filtre, afin d’affiner leurs résultats. Ces filtres sont les mêmes que ceux qu’utilisent les vues en liste ; par exemple si vous faites un Rapport sur les Devis, il peut utiliser les filtres disponibles sur la liste des Devis.

Un problème que cela entraîne est que beaucoup d’utilisateurs créent des filtres un peu spécifiques afin de les utiliser dans leurs Rapports, mais ces filtres viennent « polluer » la vue en liste correspondante (car la sélection de filtres proposent de nombreux filtres non pertinents). Afin de corriger ce souci, il est désormais possible de créer des filtres utilisables uniquement dans les Rapports. Les Rapports peuvent bien sûr continuer à utiliser les filtres classiques, mais les filtres spécifiques aux Rapports ne sont pas utilisables dans les vues en liste évidemment.

La création d’un rapport avec un filtre spécifique sélectionné

Quelques autres améliorations notables

  • Python 3.12 est officiellement géré.
  • Dans le module facturation, vous pouvez maintenant configurer les statuts sélectionnés par défaut (dans les formulaires), ainsi que les statuts utilisés par les Factures lorsque leur numéro est généré.
  • Un nouveau bouton, qui peut être mis sur la vue détaillée des Contacts, est disponible: « Créer un appel non abouti » (détails).
  • La configuration des blocs d’un rôle peut maintenant être créée en clonant la configuration d’un autre rôle (les rôles pouvant avoir des configurations assez proches, ça peut être un gain de temps appréciable).
  • Les blocs basés sur OpenStreetMap sont maintenant utilisés dans l’installation par défaut (à place de ceux basés sur GoogleMaps).
  • Un rôle «Utilisateur normal» est créé dans les nouvelles installations. Dans la mesure où c’est une bonne chose que tout le monde ne soit pas connecté en tant que super-utilisateur, ce rôle devrait permettre de gagner du temps et servir au moins de base de travail.
  • Un bouton permettant de transformer un simple Contact en utilisateur a été ajouté. Auparavant il fallait fusionner ce Contact avec le Contact automatiquement créé à la création d’un utilisateur.
  • Les Graphes ont reçu de nombreuses améliorations : plus de champs sont disponibles en abscisse, plus de champs sont disponibles pour le filtrage, les couleurs associées aux petits modèles auxiliaires (du genre « Statut ») sont utilisées…
  • La validation des URLs est désormais moins stricte dans les champs informatifs. Cela posait pas mal de problèmes notamment lors des imports, les gens mettant rarement le « http:// » dans leur base de données.

Le futur

La prochaine version marquera notamment le passage à Django 5.2, la future LTS qui sortira en avril 2025. À l’année prochaine !

Commentaires : voir le flux Atom ouvrir dans le navigateur

❌
❌