search

n7consulting / Incipio

ERP / CRM for Junior-Entreprises.
http://jeyser-crm.n7consulting.fr
GNU Affero General Public License v3.0
42 stars 17 forks source link

Discussion à propos de l'ajout d'un module de relecture #296

Closed polyedre closed 3 years ago

polyedre commented 5 years ago

Bonjour,

je suis amené à devenir DSI pour la junior-entreprise AEI.

Je projette d'étendre le module de suivis pour faciliter la relecture des documents.

Pour l'instant, plusieurs features sont envisagées :

  1. Ajouter le nom du réalisateur lié au document lors du listing (Je comprend que cette feature n'est utile que lorsqu'il y a plusieurs réalisateurs sur une étude, et que ce changement n'a pas sa place dans la version générale)
    1. Changer le comportement lorsque l'on clique sur un nom de fichier : actuellement, cela lance le téléchargement, j'aimerais pouvoir lire toutes les informations relative à ce document (une page voir.twig)
    2. Sur cette page, avoir un fil de discussion entre le suiveur de l'étude et le responsable qualité de l'étude. À chaque commentaire de l'un, l'autre est notifié (par email, chatbot, ...)

Je comprend que ces modifications ne s'appliquent pas forcément à toutes les JE (quoique peut-être la gestion de la relecture). J'aimerais en discuter avec vous.

Merci pour ce projet !

Stoakes commented 5 years ago

Bonjour,

Bienvenue :tada:

Les modifications que tu proposes sont assez ambitieuses. J'ai plusieurs questions:

  1. "Ajouter le nom du réalisateur lié au document lors du listing" Je ne comprends pas ce que ça couvre. Marquer à coté du document qui l'a rempli ? Si c'est bien ça, alors ça a totalement sa place dans la version générale.

  2. Ok, mais plutôt rajouter un bouton pour accéder à la page de relecture/revue plutôt que de changer le comportement de toutes les installations.

  3. Je ne suis pas sûr de comprendre l'usage que vous comptez faire de cette page. En dehors des quelques champs liés au chiffrage, il y a très peu de place pour la créativité: ce qui est saisi dans les champs de Jeyser est publiposté dans le document-type. Un mécanisme de revue complet pour juste le chiffrage me semble beaucoup.

Une des difficultés de cette page sera de faire un mécanisme de revue du document: le responsable qualité commence une revue, commente puis clôture la revue; afin de n'envoyer qu'un mail pour toute la revue et non un mail par commentaire.

A bientôt

polyedre commented 5 years ago

Pour le point 1, il semblerais que les documents puissent déja être liés aux réalisateurs, j'aimerais simplement que lorsque l'on liste les documents d'une étude, si il y a plusieurs réalisateurs sur cette étude, que le nom du réalisateur soit affiché dans une colonne (cela permettrait aux chargé d'étude de mieux s'y retrouver).

  1. C'est un boin point, il y a une colonne "action" lorsque l'on liste les documents. Est-ce que ce serait un endroit approprié ?

  2. Je voyais la procédure de rédaction de la façon suivante:

    • Le chargé d'étude rempli le formulaire du fichier et cliques sur "générer"
    • Il modifie le fichier (tout ce qui n'a pas pu/n'a pas été automatisé par twig)
    • Il upload le fichier sur l'ERP, (si c'est un RM par exemple, il lie à un réalisateur)
    • Le chargé qualité reçoit une notification (par important dans un premier temps, mais un mail suffirait)
      • Le chargé qualité lit le document et fait un commentaire ("Il faut modifier ... / fais gaffe à ... ")
      • Le chargé étude adapte son fichier
      • Le chargé qualité valide le document

Il y aurait donc une "file de discussion" pour que les deux chargé puissent communiquer sur le document.

Est-ce que ça semble utile (temps d'utilisation > temps de programmation) ? Y aurait-il un autre moyen ?

Merci

Stoakes commented 5 years ago

Ok,

Ca fait un moment qu'il n'y a pas eu de nouveaux modules sur Jeyser, cette idée de module de relecture me semble très bien. Si on s'inspire de ce qui est fait pour la revue de code sur les différentes plateformes (Github, Gitlab , Gerrit), on doit pouvoir faire quelque chose de qualité et d'utile.

Pour les autres points:

  1. Pour les documents, nous n'utilisons pas Jeyser comme stockage de fichiers, donc j'ai mis un peu de temps à comprendre. Ton point concerne plutôt les documents uploadés dans Jeyser plus que ceux générés avec, c'est bien ça ?

  2. Si on part sur un nouveau module, on peut même introduire une nouvelle colonne, qui porterait toutes les infos autour de la relecture. Par exemple un badge de couleur selon le statut du document (vide, rédigé, en attente de revue, corrections demandées, validé ...)

polyedre commented 5 years ago

  1. Oui effiectivement, même si les documents uploadés sont ceux qui vont être généré. Les documents qui doivent avoir une revue sont ceux qui sont générés (les autres documents internes ne sont pas sur l'ERP).

  2. Ça me semble être une bonne option !

polyedre commented 5 years ago

J'ai du temps à partir de maintenant pour m'y consacrer, je voulais savoir comment tu préfères qu'on s'organise :

  1. Soit à AEI on développe le module de notre coté sur notre fork, et tu regardes si c'est ok
  2. Soit on le développe à plusieurs

Dans tout les cas, je veux bien savoir les outils de revue de code qui existent déjà auxquels tu veux qu'on s'inspire :)

Stoakes commented 5 years ago

Désolé, pour le temps de réponse, Jeyser n'est pas dans le haut de mes priorités actuellement.

Le mieux pour l'organisation serait que vous fassiez une branche qui parte de notre master dans votre fork et ouvriez directement une Pull Request contre ce dépôt. Ça me semble allier les avantages des 2 approches: vous le contrôlez entièrement, mais on peut rapidement le merger dans le dépôt principal.

Pour les outils de revues de code, c'est peut être trop ambitieux de regarder dès le début. Peut être vaut-il mieux que tu fasses quelque chose qui vous corresponde, et on ajustera si besoin au fur et à mesure