NotesGroup : application GPL de travail collaboratif

Posté par . Modéré par Jaimé Ragnagna.
Tags :
0
6
avr.
2005
Python
Créée initialement pour nos besoins internes, NotesGroup est une solution Zope/PostgreSQL libre permettant de créer rapidement et simplement des espaces de travail collaboratif entre vos collaborateurs et partenaires.

La particularité de NotesGroup est d'avoir été conçue pour répondre de la façon la plus simple possible à des configurations indéterminées de travail collaboratif. Ainsi avec les seuls concepts d'arborescences de Notes et de droits hiérarchiques disséminés, NotesGroup est à la fois :

* un outil de gestion de projet ;
* un outil de gestion de ticket ;
* un agenda ;
* une application de gestion électronique de documents ;
* un forum ;
* un weblog ;
* un wiki, etc... L'application NotesGroup utilise seulement 4 concepts :
  • celui de note : tout dans NotesGroup est une note, chaque note peut elle même en contenir d'autres. On peut facilement faire le parallèle avec l'arborescence d'un système de fichier.
  • celui des droits hérités (zope) : une note est lisible et modifiable par un groupe d'utilisateurs et toutes ses sous-notes également. Des droits d'accès peuvent être rajoutés à de nouveaux utilisateurs dans les sous-notes. On peut ainsi représenter une hiérarchie de droits où les utilisateurs les plus près de la racine ont le plus de droits.
  • celui de notification par courriel : tout changement apporté à une note est notifié par courriel aux utilisateurs ayant le droit de lecture dessus. Le sujet du courriel est formaté de telle façon à ce qu'il soit trivial d'utiliser des règles de messages.
  • celui de demande et d'attribution : chaque note peut être, à la création, attribuée à quelqu'un, avec un certain statut, par exemple "ouvert". Cet utilisateur reçoit une notification, et peut résoudre la note par une modification de statut.


Ces quelques concepts associés à l'éditeur en ligne Kupu et la gestion de fichiers attachés, permet de résoudre la plupart des problèmes de travail collaboratif au sein d'une entreprise (et des ses partenaires). Il est actuellement utilisé par plusieurs de nos clients.

Exemples d'utilisation :
  • Gestion de tâches : Affectez des tâches à vos collaborateurs, ils seront prévenus immédiatement et pourront décrire l'avancée de leurs travaux dans un espace historisé, jusqu'à la clôture de la tâche.
  • Communiquer avec vos partenaires Invitez vos partenaire à venir communiquer sur un projet au sein de NotesGroup. Par une simple notification courriel, et sans pré-requis, ils pourront dialoguer avec vous dans un espace historisé.
  • Gestion des connaissances : Utilisez NotesGroup pour écrire vos documents à l'aide de son éditeur intégré. Définissez pour ceux-ci des contributeurs et simples lecteurs et vous obtiendrez un espace documentaire centralisé et toujours actualisé.
  • Suivi clientèle : Invitez vos commerciaux à employer NotesGroup pour effectuer leur suivi clientèle. Ils disposeront ainsi d'une solution itinérante flexible pour entrer leur prospects, des évènement de rappels, etc...
  • # impossible de tester

    Posté par . Évalué à 0.

    pour accéder à la démonstration, il faut apparemment être inscrit comme client et posséder un login+password pour zope... dommage
  • # Comparaison avec CPS / Plone ?

    Posté par . Évalué à 4.

    Je connais pas fortement CPS et Plone mais j'ai l'impression que certaines fonctions y sont déjà.

    Pourquoi n'etes vous donc pas reparti d'un de ces deux projets pour l'enrichir ?
    • [^] # Re: Comparaison avec CPS / Plone ?

      Posté par . Évalué à 3.

      CPS et Plone sont des produits Zope de gestion de contenu.

      NotesGroup permet une gestion de contenu simple à travers Kupu et des fichiers attachés mais c'est aussi un gestionnaire de projet et de ticket.

      Mais la différence fondammentale est l'utilisation d'une base PostgreSQL maîtresse de l'application : à partir de la base SQL, toute la ZODB est reconstruite, ensuite PostgreSQl et la ZODB sont synchrones.

      Cela a été fait dans un soucis de
      1) compatibilité avec d'autres logiciels qui ne peuvent pas lire la ZODB
      2) garantir la stabilité de l'application : si la ZODB est corrompue, elle peut être générée à nouveau depuis POsgreSQL.
      • [^] # Re: Comparaison avec CPS / Plone ?

        Posté par (page perso) . Évalué à 2.


        Cela a été fait dans un soucis de

        1) compatibilité avec d'autres logiciels qui ne peuvent pas lire la ZODB
        2) garantir la stabilité de l'application : si la ZODB est corrompue, elle peut être générée à nouveau depuis POsgreSQL.



        Pour le premier point, pourquoi pas. Mais il aurait mieux valu développer un connecteur SOAP.

        Pour le deuxième... Faire la sauvegarde d'un base de données transactionnelle avec une autra base de données transactionelle...
        En général, pour que la ZODB soit corrompue, il faut l'aider un peu.
        • [^] # Re: Comparaison avec CPS / Plone ?

          Posté par . Évalué à 2.

          une base de données relationnelle comme postgreSQL c'est ici pour nous
          l'assurance d'être facilement, et efficacement accessible depuis n'importe qu'elle autre point du système d'information contenant notesgroup.

          En ce qui concerne la stabilité de l'application, la zodb est effectivement
          stable mais il est beaucoup plus evident de reconstruire les données dans la zodb après un changement de code et un alter de table postgresql que
          faire des chagements dans les instances d'objets dans la zodb.

          mais le point fondamental chez nous est le choix de postgresql comme base maitresse dans les systèmes d'informations que nous déployons.
          • [^] # Re: Comparaison avec CPS / Plone ?

            Posté par . Évalué à 2.

            > il est beaucoup plus evident de reconstruire les données dans la
            > zodb après un changement de code et un alter de table postgresql
            > que faire des chagements dans les instances d'objets dans la zodb.

            Il serait encore plus évident de ne pas stocker de code dans la zodb, en ne rendant pas la logique persistante. C'est ce que fait ikaaro par exemple (http://www.ikaaro.org/(...) ). Je pense que son modèle resource/handler est ce que tu cherchais à faire.
          • [^] # Re: Comparaison avec CPS / Plone ?

            Posté par . Évalué à 1.

            Et Pourquoi ne pas utiliser le système de fichier plutôt qu'une base de donnée relationelle pour une structure en père/fils ?
            • [^] # Re: Comparaison avec CPS / Plone ?

              Posté par (page perso) . Évalué à 2.

              Parce qu'on a beau avoir une structure qui peut se représenter sous forme d'arborescence, le fait qu'on puisse également bien la représenter dans une base de données relationnelle comporte pas mal d'avantages.

              Je ne voudrais pas lancer le débat sdbdoo/sdbdr (on utilise les 2 dans ce produit), mais en gros, le modèle relationnel permet de disposer d'une algèbre simple et d'un langage de requêtes puissant.

              Le sgbdoo (ici la zodb) fonctionne très bien tant qu'on reste dans le cadre d'un parcours dans sa représentation objet, mais dès qu'on veut faire des opérations ensemblistes, on a d'un côté un script qui rame, de l'autre une petite requête SQL qui ...pouf-ça-y-est.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.