pod : un outil de travail collaboratif pour suivre et gérer tâches, documents et autres

Posté par (page perso) . Édité par Xavier Claude, Benoît Sibaud, palm123 et Nÿco. Modéré par Nils Ratusznik. Licence CC by-sa
49
18
juin
2014
Bureautique

POD est un outil de travail collaboratif conçu pour partager documents, tâches et données variés. Il est totalement versionné et propose une granularité fine de gestion des droits. Il est distribué sous licence AGPL.

Exemple de todo-list

L'intérêt de POD est d'augmenter la productivité du travail collaboratif :

  • en centralisant l'information (tâches, documents, commentaires, pièces jointes)
  • en implémentant la traçabilité sur vos données : tout est versionné, on ne travaille donc plus seulement avec des données « en l'état » mais également des données « qui ont vécu ».
  • en proposant un outil qui vous permet de gérer au même endroit vos bases de connaissances, vos listes de tâches, vos contacts

Sommaire

Statut du projet

Initialement, il s'agissait d'un outil à cheval entre un wiki et un bug-tracker sans possibilité de partage. Désormais l'outil est collaboratif, permettant notamment de gérer les droits d'accès en lecture/écriture de manière fine sur chaque document, de travailler sur le contenu et de savoir qui fait quoi.

POD est à un stade alpha : il est utilisable mais a un périmètre d'utilisation limité car certaines fonctionnalités sont incomplètes, et des cas limite ne sont pas tout à fait correctement gérés. Il est fiable dans la mesure où vous ne perdrez pas de données.

Le code est sale, vous n'allez pas rêver ;) Un grand refactoring est nécessaire, en terme de maintenabilité et également d'architecture afin de découpler backend / frontend.

Les fonctionnalités en détail

Un peu à la manière de « tout est fichier » dans UNIX, POD implémente un modèle de données « tout est document ».

Les documents sont organisés sous forme arborescente, comme on organiserait des fichiers.

Les données que vous pouvez manipuler sont de différents types :

  • commentaire
  • contact (titre + détail du contact)
  • fichier (titre + description + contenu du fichier + nom du fichier)
  • document (titre + description + statut)

Sur ces données, vous pouvez :

  • créer / modifier / déplacer / supprimer des données
  • partager / gérer les droits d'accès à ces données
  • rechercher ces données et filtrer les résultats par type

À la manière d'un wiki, les données sont totalement versionnées ; l'avantage de pod réside dans les différents types de données disponibles.

Les droits d'accès sont gérés avec une granularité fine : chaque élément peut être partagé ou privé, s'il est partagé on peut définir finement les utilisateurs et groupes d'utilisateur y ayant accès en lecture ou lecture/écriture. On peut par exemple stocker au même endroit un document partagé avec toute l'équipe, un document personnel et un document partagé avec des clients.

Captures d'écran

Création de documents et autres

Gestion des droits d'accès

Recherche et filtrage

Exemples d'utilisation

Base de connaissances

On crééra simplement des documents, organisés sous forme arborescente. C'est un cas nominal.

Todo-list / gestion de tâches

On pourra créer une todo-list en opérant de la manière suivante :

  1. créer un document intitulé « Mes choses à faire »
  2. créer X sous-documents intitulés « Tâche A », « Tâche B »…
  3. lorsqu'on visualise "Mes choses à faire", l'onglet "sous documents" à droite contient la liste des tâches à réaliser et leur statut.

Si l'on modifie le document « Mes choses à faire » et qu'on lui attribue le statut « automatic », alors « Mes choses à faire » devient une « méta-tâche » dont le statut sera « terminé » lorsque toutes les sous-tâches seront dans le statut « terminé ».

Partage de données, données individuelles et collectives au même endroit

Un des intérêts de POD est de présenter un modèle de gestion de droits d'accès très granulaire. Chaque document peut être accessible en lecture ou lecture/écriture pour une liste de groupes et/ou de personnes. Concrètement, cela permet par exemple :

  • de partager un document en lecture avec vos clients mais en écriture avec vos partenaires
  • de stocker au même endroit les éléments à publier et les éléments internes à l'entreprise (ou l'équipe).
  • de stocker au même endroit des documents que vous partagez avec vos collaborateurs et d'autres qui vous sont personnels. Par exemple, vous mettrez un commentaire privé qui sera associé à un document partagé, ce commentaire sera visible de vous seul

Comment ça marche ?

Il s'agit d'une application web basée sur les technologies python3, TurboGears, PostgreSQL. Le thème est à la bootstrap, l'interface est +/- fonctionnelle sur téléphone mobile.

Tester pod, l'installer

Test simple

Vous pouvez tester l'application en ligne à l'adresse suivante :

Test avancé

Pour tester l'aspect collaboratif, connectez-vous en demo@localhost, créez un compte via le menu admin -> users (l'adresse de courriel n'est pas vérifiée, aucun courriel n'est envoyé), et utilisez ce nouveau compte dans un onglet de navigation privée ou dans un autre navigateur.

Installation locale

Si vous souhaitez installer l'application, le code source est disponible sous licence AGPL sur un dépôt git sur Bitbucket : https://bitbucket.org/lebouquetin/pod.git

Le dépôt contient également la doc d'installation, qui inclut notamment les premiers pas à suivre pour les utilisateurs qui ne maîtrisent pas PostgreSQL !

La suite…

Plusieurs orientations s'offrent à nous pour transformer cette version en véritable application de travail collaboratif. Les évolutions que l'on envisage sont :

  • Implémenter un modèle de données générique donc personnalisable. Cela permettrait de personnaliser les données que l'on manipule, on peut par exemple imaginer :
    • un modèle de type « ouvrage » qui aurait un titre, un résumé, des auteurs, un numéro ISBN, etc
    • un modèle de type « Compte Rendu d'intervention » qui aurait un auteur, des intervenants, une date d'exécution, un champ description, des remarques, etc, etc
  • Implémenter une véritable API REST/JSON pour proposer un backend générique et permettre à chacun d'implémenter sa propre interface (ou des connexions avec le monde extérieur)
  • Enrichir les modèles de données actuels,
  • Développer une interface réellement responsive probablement en AngularJS,
  • Ajouter différentes fonctionnalités telles que notifications par courriel, tableau de bord, pagination sur la recherche, etc, etc.
  • Corriger les bugs ;)

Remarques, critiques et questions bienvenues

Nous sommes ouvert aux remarques, critiques et questions… c'est d'ailleurs pour cette raison que nous sommes là :-p

  • # Redmine mis à jour ou Un sympathique gestionnaire de projets

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

    Cet outil de travail est juste magnifique, certes il ne dépasse pas encore toutes les possibilités de redmine mais il a de bonnes ambitions comme un thème moderne et s'accueillant avec l'internet d’aujourd’hui.

    L'outil est bien fait, j'attends avec impatience les prochaines mises à jours !

    SysAdmin GNU/Linux et joueur assidu de Minecraft | Combattant du #libre

  • # Pourquoi POD a-t-il été créé ?

    Posté par . Évalué à 6. Dernière modification le 18/06/14 à 20:05.

    Ça m'a l'air sympathique comme projet. Mais qu'est-ce qui différencie POD d'un autre GED comme Alfresco Share ou nuxeo ? Quelle est ou sera sa plus-value ?

    • [^] # Re: Pourquoi POD a-t-il été créé ?

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

      Déjà, c'est pas du java…

      Ce serait bien un connecteur CMISYNC. On doit pouvoir éviter le tralala CIFS pour avoir un truc pratique et bien plus léger.

    • [^] # Re: Pourquoi POD a-t-il été créé ?

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

      Ce que je vois comme plue-value dans POD :

      • l'outil se veut simple à utiliser et flexible. Quand j'ai testé Alfresco, j'ai été incapable de créer un document sans partir d'un fichier (est-ce possible ?) ; l'interface nécessite un apprentissage.
      • POD n'impose pas d'organisation des données. Il n'y a pas un espace documents, un espace tâches, un espace wiki, etc : ici chacun est libre d'organiser ses données comme il le veut et d'associer des documents avec des tâches, des contacts, etc.
      • Un des axes d'évolution est d'implémenter un modèle de données évolutif, de manière à s'adapter à n'importe quel besoin et donc de manipuler des données structurées.

      L'outil cible plutôt des équipes ou des projets de taille modeste où les workflow de validation ou assimilé sont trop lourds.

    • [^] # Re: Pourquoi POD a-t-il été créé ?

      Posté par . Évalué à 3.

      Alfresco attention c'est peut être puissant mais c'est aussi une vrai galère à administrer :
      - utilisation de certificat pour la recherche ??? la rech ne fonctionnait plus a cause de la date de validité du certif. par contre scripts de debug nickel.
      - trop de RAM consommé même s'il ne fait rien … Java Style !
      - lent très lent même avec très de doc
      - surabondance de log (tomcat style :) )… trop de log tue les logs et finissent par tuer le serveur :) … conseil d'admin : nommez le serveur alfresco Lazare :)
      - au final difficile a utiliser au quotidien si on a de 0 à 3 documents par jour, le temps imparti à faire les choses correctement est supérieur au temps gagné
      - Pas convaincu par la recherche qui ne semblent n'en faire qu'a sa tête

      Alfresco c'est valable à mon avis pour pour la gestion de BEAUCOUP de document
      peut être puissant … mais pas assez KISS

      POD m'intéresse et des que je peu je teste … et c'est du python :)

  • # LDAP ?

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

    Il y a un connecteur LDAP pour la gestion des utilisateurs et des groupes ? Je pense que plein de laboratoire de recherche publique serait intéressé par un outil de GED à taille humaine mais il ne faut pas un outil qui recrée encore d'autres comptes…

    • [^] # Re: LDAP ?

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

      En fait, pour être plus précis, on travaille beaucoup avec des extérieurs, donc l'idéal serait aussi de pouvoir faire un partage en RO ou en RW via une clef de type sha256 avec des personnes dont on ne souhaites pas forcément créer un compte. Je me souviens d'un outil qui proposait cela, un truc du genre Sorg… Le soucis est de bien poser le commutateur sur les URL afin de pouvoir déléguer l'authentification à Apache pour les comptes utilisateurs mais par les externes. J'ai bien plus confiance dans le code Apache que dans le code applicatif ;-)

      • [^] # Re: LDAP ?

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

        Concernant LDAP, pour le moment rien n'est prévu. Par contre, vu les technos qu'on utilise, je pense que c'est très faisable de développer un tel plugin.

        Pour ce qui est du partage, on avait prévu un accès en lecture sur des documents sans création de compte, par contre on n'avait pas prévu de collaboration active sur ce principe. Et on n'était pas parti sur ce genre d'authentification. C'est un peu overkill pour ce genre d'outil, non ?

        • [^] # Re: LDAP ?

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

          C'est un peu overkill pour ce genre d'outil, non ?

          Oui et non ;-)

          C'est vrai que cela complique pas mal les choses aussi. Déjà pouvoir partagé via une clef est pas mal. Pour moi, l'idéal est alors d'avoir un chemin, URL, distincte assez proche de la racine afin de pouvoir forcer l'authentification Apache sur la partie RW mais pas RO. On utilise alors le code C d'Apache pour le LDAP qui a été lu et relu, à mon sens, c'est plus sur. Je ne sais pas si je suis bien clair.

          Pour prendre un autre exemple, on utilise SPIP pour notre site web sauf qu'on la un peu tordus dans le sens ou on l'utilise en http et https et que le /ecrire n'est pas utilisable en http. SPIP n'ayant pas du tout été conçu pour cela, c'est pas parfait mais cela marche quand même pas si mal (bien sur, en https, tu te prends l'authentification LDAP apache avant que le moindre code php ne soit exécuter sur le serveur).

          Bref, c'est bien si dès la base, les choses sont clairement séparées nous permettant de mieux blindés les choses ensuite et éviter de se retrouver avec un site porno sur son serveur ;-)

      • [^] # Re: LDAP ?

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

        La fédération d’identité ne serait-elle pas la solution (SAML2) ?

        • [^] # Re: LDAP ?

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

          Et ta fédération, elle fonctionne avec SSH, FTP… Le peu que j'ai vu est que ce n'était pas assez bien intégré dans l'OS donc ingérable dans un petite structure. Mais j'espère me tromper.

          • [^] # Re: LDAP ?

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

            Je ne vois pas le rapport avec d’intégration avec l'OS puisqu'on parle ici d'une application web (Service Provider) qui lui redirige vers le gestionnaire d'identité (IdP) pour la partie authentification et information sur la personne.

            Mais dans l'absolu, rien n’empêche à des client lourd de faire de la fédération d'identité (c'est d’ailleurs possible pour de petit service comme Office365)

  • # Implémenter un modèle de données générique donc personnalisable.

    Posté par . Évalué à 4.

    Pourquoi pas CouchDB ? Je ne connais pas bien ce moteur, sauf pour en avoir lu quelques articles dans Linux Magazine. Ce type de moteur ne serait-il pas plus pertinent pour ce genre de tâche qu'un moteur SQL relationnel?

    • [^] # Re: Implémenter un modèle de données générique donc personnalisable.

      Posté par . Évalué à 3.

      Si et j'y verrais quelques avantages :

      • tout est document, donc semble assez proche de la notion autour de laquelle s'articule pod;
      • il est possible d'attacher des pièces jointes aux documents, ce qui reste assez efficace sauf pour des fichiers de centaines de Mo ou supérieurs;
      • enfin, cela permettrait de profiter de la synchronisation maître à maître offerte par CouchDb, vers d'autres noeuds Couch mais aussi, pourquoi pas, PouchDb, TouchDb et autres cousins des documents ainsi que des pièces jointes.

      En revanche, si CouchDb a un concept de révision employé à chaque nouvelle version de document, il ne faut pas l'utiliser pour l'historique, car les anciennes révisions n'apparaissent pas dans les réplicats ni ne sont conservées après compactage de la base.

      • [^] # Re: Implémenter un modèle de données générique donc personnalisable.

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

        En fait, si tu prends du PostgreSQL avec un champ de type JSON, tu as les même propriétés qu'avec une base SQL "classique" et le modèle générique en plus.

        Tout ce que j'ai lu sur les bases NoSQL me laisse penser qu'on ne gagne pas en perf, le tunning pour avoir des perfs correctes étant un peu pointu, et aucune validation de modèle de données minimal (ce qui est possible avec PostgreSQL). Avec PostgreSQL tu peux en plus envisager d'implenter des fonctionnalités géographiques ; au final je ne vois pas l'intérêt de passer sur une base orientée documents.

        • [^] # Re: Implémenter un modèle de données générique donc personnalisable.

          Posté par . Évalué à 2.

          le tunning pour avoir des perfs correctes étant un peu pointu

          Pas vraiment. Le tout est de respecter le concept clé/valeurs dans la modélisation de la base. Le reste est une histoire de views - guère plus complexe qu'une requête SQL 92…

          L'intérêt de passer par une base orienté document hors la performance est de ne pas réimplémenter du code déjà écrit et testé à grande échelle. En particulier le versionning.

          Je préfère PouchDB à CouchDB parce qu'il implémente le GQL - XPath/Xquery étant selon moi les grands responsables de l'échec des BDD XML…

          Sinon Pod part vraiment sur de bonnes bases. Je vais le suivre de près. Je rejoins les comms plus haut sur le module LDAP : indispensable pour un passage à l'échelle.

          Bon courage ! Continuez !

        • [^] # Re: Implémenter un modèle de données générique donc personnalisable.

          Posté par . Évalué à 3.

          Oui tu peux en effet utiliser hstore ou JSON sur PostgreSQL. L'intérêt de Couch est surtout à chercher du côté de sa réplication des données et de sa gestion des pièces jointes. Pour les performances, voir le commentaire ci-dessous, pour la validation sur mesure d'un modèle, c'est possible dans la base et cela se fait par le biais une fonction javascript.

  • # POD comme Cloud

    Posté par . Évalué à 1.

    Super projet ! Actuellement j'utilise owncloud pour mes synchro/share de doc, mais c'est quand même bien buggé, et POD à l'air plus light, mais les utilisateurs que je gère ne sont pas du genre à changer leur petites habitudes (à savoir qu'ils ont un dossier de travail synchronisé dans le cloud via le client owncloud) donc je me demandais s'il y a des possibilités de synchro type webdav voire des clients pour différentes archi en prévision ?

    • [^] # Re: POD comme Cloud

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

      On a un peu travaillé sur webdav, je sais pas si c'est vraiment adapté par rapport à CMIS

      • [^] # Re: POD comme Cloud

        Posté par . Évalué à 1.

        hmm…effectivement. En fait je parlais de webdav parce que c'est ce que j'utilise, mais du moment que je peux proposer un mode de fonctionnement transparent pour mes utilisateurs, peut-importe ! Disons qu'avant j'utilisais un bête FTP/sFTP et ça obligeait les utilisateurs à se logguer à chaque fois et à faire la manip du versement/téléchargement. Là si POD propose une solution qui ne nécessite aucune intervention de l'utilisateur, à la manière d'un cloud, peu importe le backend utilisé :-)
        En fait, je cherche même une solution qui me permette d'uploader sans poser de question ce que les utilisateurs ont mis dans leur dossier de travail, mais de laisser le choix à ces derniers de télécharger seulement ce dont ils ont besoin (et ce pour des question de place, certains utilisateur ont des machines avec très peu de place type notebook avec SSD ou tablette)
        Bref…je conjecture je conjecture :-p

  • # pourquoi postgresql ?

    Posté par . Évalué à 1.

    Question subsidiaire qui va sûrement générer du troll, mais bon, je m'interroge, pourquoi PostgreSQL au lieu de MariaDB ?

  • # Dans la série pourquoi, Turbogears ?

    Posté par . Évalué à 2.

    Et pas Pyramid, Django, Flask…
    Sachant que la question qui me turlupine d'avantage, c'est pourquoi TG2 est basé sur Pylons et pas Pyramid (qui en est le successeur).

    • [^] # Re: Dans la série pourquoi, Turbogears ?

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

      Dans la série pourquoi, Turbogears ?
      Et pas Pyramid, Django, Flask…

      • par rapport à Pyramid et Flask : parce que Turbogears est un framework full-stack, tu setup ton projet et tu as tout ce dont tu as besoin, de l'authentification et la gestion de groupes et utilisateurs à un moteur de templates intégré (mako) et une couche ORM (sqlalchemy). Tu peux faire ça avec Pyramid et Flask, mais tu dois refaire le "glue code"
      • par rapport à Django : parce que Turbogears réutilises des modules standards et que le code manipulé est réutilisable par ailleurs. SQLAlchemy, par exemple. Si je veux migrer sur Pyramid ou Flask, je ne recode pas tout.

      Sachant que la question qui me turlupine d'avantage, c'est pourquoi TG2 est basé sur Pylons et pas Pyramid (qui en est le successeur).

      Lorsque Pylons a basculé en Pyramid, Turbogears n'était pas prêt à suivre, c'était prévu mais ça n'est pas arrivé. J'aimerais que la bascule arrive, je ne me rends pas bien compte de la quantité de travail que cela implique pour les mainteneurs, mais j'aimerais bien que ça arrive.

      • [^] # Re: Dans la série pourquoi, Turbogears ?

        Posté par . Évalué à 1.

        Est-ce que tu as quand même regardé ce qu'il en était du glue-code ? Il me semble que pour les parties dont tu parles (authentification, mako, sqlalchemy) le glue-code ne tien que sur une poignées de lignes avec Pyramid. Où alors tu penses à autre chose ?

  • # ça c'est bête

    Posté par . Évalué à 2.

    Je travaille par intermittence sur un projet qui fait exactement la même chose… Si j'avais connu pod avant !

    Et quand je dis exactement, c'est vraiment exactement.

    • [^] # Re: ça c'est bête

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

      ça s'appellerait pas pod ton truc ?

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: ça c'est bête

      Posté par . Évalué à 1.

      Salut,
      ça serait possible de tester ton appli web ? car je m'apprêtais à continuer un projet déjà développé en PHP/SQL mais dont le code était vraiment pourri. C'est une appli super simple avec aucune sécurité mais dont on a l'avantage de profiter en intranet en groupe restreint et qui ne bouffe pas les ressources des autres appli LAMP.

  • # Suite à mes tests

    Posté par . Évalué à 1.

    Génial comme outil, j'en aurai l'utilité dés qu'il sera finalisé.

    Pour l'instant, ce qui m'empêche de l'utiliser :
    - tous les utilisateurs sont admins
    - plantage lors de la suppression d'utilisateurs
    - les accents ne sont pas supportés (ou erreur de conf de ma part ?)

    (liste soumise à édit si nécessaire)

    • [^] # Re: Suite à mes tests

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

      Merci pour ce retour. Par curiosité (et si tu peux en dire plus), tu l'utiliseras dans quel contexte ?

      Note: les accents sont supportés d'après nos tests. Tu parles d'accent dans le nom des utilisateurs ? Dans le contenu des documents ? Je pencherais pour une configuration inappropriée… Je suis curieux d'avoir tes retours plus détaillés (on n'a pas mis en place de bug-tracker pour le moment, mais si tu veux m'envoyer un email (tu as mes coordonnées à la fin de la page d'accueil sur BitBucket)

      • [^] # Re: Suite à mes tests

        Posté par . Évalué à 1.

        En mode collaboratif : pour un jeu, Ingress. C'est un jeu à forte collaboration, et pour la préparation d'opérations avec des agents répartis sur la région, voire la France, c'est un outil idéal. Il manque peut-être la création de tableaux cependant.

        Pour les accents, j'ai eu ça au moins sur la création de documents, pas testé ailleurs avec pour erreur :

        UnicodeEncodeError: 'ascii' codec can't encode character '\\xe9' in position 14: ordinal not in range(128)

  • # Interface - petite question

    Posté par . Évalué à 1.

    Bonjour

    Bravo pour le projet!
    Je me posais une petite question sur les briques logicielles utilisées.

    En regardant les captures, je trouve que ça ressemble très fortement à l'interface par défaut du projet sonata admin…
    http://sonata-project.org/uploads/media/default/0001/01/bcc2ed07da79e7a4339d613e49eee971c9a439fd.png

    Cependant, le projet Sonata est un bundle symfony2 (donc php). Or, ici, si j'ai bien suivi, on parle de python.

    C'est simplement l'utlisation du bootstrap qui donne cette ressemblance ou bien il y a un lien ?

Suivre le flux des commentaires

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