Je suis actuellement à la recherche d'un logiciel pour gérer les tickets/workflows (issue-tracking systems). Typiquement pour gérer des demandes de changement, remonter des bogues, demande d'authorisation, gestion des risques, affectation de tâches, etc.: en gros tout ce qui demande le traitement et l'accord de plusieurs personnes successives.
J'ai l'impression que l'ont peut déjà établir 2 catégories de logiciels:
1) ceux pour qui l'entreprise doit s'adapter au logiciel
2) ceux pour qui le logiciel soit s'adapter à l'entreprise
Le première catégorie semble plutôt s'adresser aux "développeurs": il est recommandé de ne pas trop personnaliser les workflows standards pour conserver la simplicité (Trello par exemple).
La seconde catégorie semble plutôt s'adresser aux "managers": ici l'outil doit se conformer aux (lourdes) procédures de l'entreprise, et on doit pouvoir personnaliser à volonté les workflows jusqu'à créer des workflows monstres, rempli d'intervenants à chaque étape (Jira par exemple).
(bien entendu rien n'empêche une entreprise d'utiliser intelligement Jira pour conserver la simplicité ou de prendre un simple Trac et d'en faire un monstre)
J'ai un peu fouillé pour trouver un logiciel qui entre dans la seconde catégorie (personnalisation aisée de workflows, je sais c'est mal, merci de ne pas me juger) et je suis rentré un peu bredouille. Il y a bien a des solutions comme Jira ou ServiceNow, mais cela semble lourd et fermé.
J'aurais aimé trouver quelque chose de plus ouvert à la communauté (idéalement open-source) et surtout plus sympathique d'un point de vue utilisateur (toutes les solutions que j'ai trouvées demandent l'intervention de l'administrateur IT pour ajouter/modifier des champs ou pour créer un nouveau workflow).
En open-source, il semble que le temps s'est arrêté il y a quelques années et que l'on reste sur BugZilla, Trac ou Redmine (loin de moi l'idée de vouloir lancer un troll le vendredi…). J'ai bien vu Tuleap passer sur linuxfr, mais il semble que pas grand monde ne l'utilise.
Est-ce la grande expérience cumulée des lecteurs de linuxfr aurait un logiciel miracle à me recommander pour une gestion flexible des workflows ?
Note: je m'étais initialement tourné vers les issue-tracking systems mais peut-être que les outils de Business Process Management (Nintex par exemple) ou de Gestion de workflow sont plus adaptés. J'avoue ne pas avoir bien compris la différence et chercher "BPM vs workflow" m'a encore plus embrouillé. De plus tout cela me semble encore bien plus fermé. Si quelqu'un a une expérience avec ce type de logiciel ?
# Tuleap
Posté par Benoît Bailleux (Mastodon) . Évalué à 9.
Dans ma (plutôt grosse) boîte, on a historiquement utilisé Tuleap depuis pas mal de temps, en commençant par ses ancêtres. Le but était de proposer un système complet en « self service » pour gérer / piloter des projets, que ce soit de développement ou pas.
Du coup, beaucoup de fonctionnalités (e.g. gestion documentaire, gestion de configuration, hébergement de pages web, trackers etc.) ont été mises à disposition et utilisées assez longuement.
NB : disclaimer – des collègues ont contribué activement au développement et à certaines orientations de l'évolution du produit.
Récemment, un mouvement de migration vers GitLab a été initié, Tuleap ne satisfaisant plus certains critères requis par nos activités. Je n'ai pas d'avis sur ce point précis.
Par contre, le constat a été fait que le « tracker » intégré à GitLab est très nettement moins bon que celui de Tuleap. C'est pourquoi l'outil va être conservé pour cet usage exclusif (enfin, pas tout à fait, il y a une seconde fonctionnalité qui va être maintenue, pour être exact) !
De mon point de vue, les trackers de Tuleap sont :
Par contre, je dois avouer que pour les trackers que j'ai eu l'occasion d'utiliser et de (un peu) configurer, on n'a pas mis en œuvre un workflow de folie.
Donc si vos besoins sont un peu complexes (tu cites plutôt une série de besoins restant assez simples), cela pourrait ne pas faire l'affaire…
Si vous avez le temps et les moyens d'installer et d'évaluer Tuleap, je suggère de lui donner une chance.
[^] # Re: Tuleap
Posté par desktop.ready . Évalué à 2.
Sympa comme retour, merci !
Oui j'ai aussi observé ce mouvement vers Github/Gitlab: c'est peut-être la raison pour laquelle BugZilla/Trac/Redmine sont un peu tombé en désuétude et qu'il n'y a pas eu beaucoup de sang neuf sur le sujet depuis un moment.
Il faut avouer qu'avec Jira, on peut vraiment implementer presque n'importe quoi. Avec l'extension ScriptRunner, tu peux même rajouter des scripts aux endroits que tu veux. Et l'interface utilisateur est OK (bien moin moche que Tuleap).
Je serais intéressé par les raisons qui vous font abandonner Tuleap.
Merci
[^] # Re: Tuleap
Posté par David Demelier (site web personnel) . Évalué à 3.
Note : je suis pro redmine
Je ne pourrais pas dire que redmine (ni bugzilla) soit tombé en désuétude. Il manque certaines fonctionnalités modernes c'est vrai mais il est encore largement développé et utilisé par quelques gros projets. D'ailleurs les quelques questions que j'ai posées sur le forum ont rapidement eu réponses par les développeurs eux mêmes.
redmine ❤
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Tuleap
Posté par desktop.ready . Évalué à 2.
Oui je ne doute pas qu'ils soient encore utilisés et maintenus.
Mais je vois passer beaucoup de migration vers Github/Gitlab et pas beaucoup dans l'autre sens.
[^] # Re: Tuleap
Posté par El Titi . Évalué à 6.
Je pense que les 2 produits (Tuleap et Gitlab) ne se positionnent pas exactement sur le même périmètre, même s'il y a d'importants recoupements de fonctionnalités en tant que forges logicielles.
La cible de Tuleap est clairement la pile Atlassian complète pour permettre ce qu'on appelle pompeusement la "Gestion du Cycle de Vie" (ALM=Application Lifecycle Management) dont voici quelques fonctionnalités:
* Le contrôle de source et la revue de code
* L'intégration continue
* Le suivi des demandes de changements
* La gestion de projets
* La gestion des tests
* La gestion documentaire
* La gestion de portefeuilles de projet
…
Je vais te donner quelques références du monde Atlassian pour servir de base de comparaison:
* Le contrôle de source = Bitbucket
* L'intégration continue = Bamboo ou n'importe quel outil de CI (Jenkins,
* Le suivi des demandes de changements = JIRA + integration avec Bamboo et Bitbucket
* La gestion de projets = JIRA (et JIRA Agile pour Scrum et Kanban)
* La gestion des tests = plugins dans JIRA par exemple Xray ou Zephyr
* La gestion documentaire = Confluence(wiki)
* La gestion de portefeuilles de projet = JIRA Portfolio
Et il y a pléthore d'extensions possibles (Help Desk, Q&A à la Stack Overflow, …)
Gitlab ne couvre que:
* Le contrôle de source et la revue de code
* L'intégration continue = Gitlab CI (uniquement mais très bien intégré)
* Le suivi des demandes de changements
* Gestion de projet (relativement limitée mais suffisante pour de petits projets agiles)
* La gestion documentaire =wiki
J'ignore si tous ces éléments sont en opensource et il faut bien avoir conscience que certaines fonctionnalités cruciales pour une entreprise (integration avec des annuaires par ex) sont payantes. Ce qui est normal puisque c'est leur business model.
Pour Tuleap:
* Le contrôle de source et la revue de code (compatibilité Subversion)
* L'intégration continue (connecteur Jenkins)
* Le suivi des demandes de changements
* Gestion de projet (relativement limitée mais suffisante pour de petits projets agiles)
* La gestion documentaire (wiki)
* La gestion des tests = incluse mais payante.
A toi donc de faire ta liste de spec pour mieux cibler la solution que tu recherches mais aussi distinguer ce qui est en opensource (ou gratuit) ou non dans leurs offres.
Sinon, si tu recherches juste une extension open source qui ne couvre que la gestion de projet et qui s'adosse à une forge hébergée (Github, …), tu peux aussi jeter un coup d'oeil à https://taiga.io/.
Il est vraiment très simple d'approche (voir simpliste) mais quand même à peine plus structuré qu'un Trello de base sans plugin.
[^] # Re: Tuleap
Posté par El Titi . Évalué à 2.
Et accessoirement un projet opensource que certains connaissent utilisent Taïga activement:
https://teams.fedoraproject.org/discover
[^] # Re: Tuleap
Posté par desktop.ready . Évalué à 1.
En fait je m'intéresse uniquement à la gestion des tickets (issue-tracking), tout le reste c'est vraiment du bonus.
Donc Gitlab est clairement hors-sujet pour moi.
Taiga rentre clairement dans la première catégorie que j'avais évoquée (i.e. il faut garder des workflows simples).
Pour ma part, j'essaye de modéliser des workflows complexes qu'il faut fortement personnaliser.
Pour ne donner qu'un exemple : un ticket atteint un certain état, cela doit déclencher automatiquement l'ouverture de différentes sous-tâches liées à ce ticket. Lorsque toutes les sous-tâches sont effectuées, le ticket parent passe automatiquement à l'état suivant.
C'est un besoin qui n'ait clairement pas orienté développeur, mais plutôt (micro-)manager.
Je peux faire cela avec Jira mais c'est assez lourd à mettre en place et il faut les droits administrateurs (ce qui n'est pas vraiment autorisé dans mon entreprise).
[^] # Re: Tuleap
Posté par El Titi . Évalué à 2.
Tu as un peu péché par omission :)
Oui Gitlab et consorts sont clairement orientés projets de développement informatique.
Déjà, es-tu certain que ce que tu recherches est un outil de gestion de projet et pas plutôt un outil de BPM
(https://en.wikipedia.org/wiki/Business_process_management) ?
Les projets sont-ils indépendants ou as-tu besoin de coordination entre eux (Gestion de portfolio) ?
Es-tu ouvert à des solutions fermées ou uniquement open-source ?
Quelle est la taille de ton entreprise ?
Pose un cahier des charges précis et tu trouveras sans doute par toi-même la solution qui te convient.
[^] # Re: Tuleap
Posté par desktop.ready . Évalué à 2.
Tu remarqueras que le titre du journal s'appelle "Gestion des tickets" et que la question du journal était : "[…] recommander pour une gestion flexible des workflows ?".
Je n'ai pas du tout parlé de tout le reste qui ne m'intéresse pas vraiment.
Je te renvoie aussi à la note à la fin de mon journal ;-)
Projets indépendants
De préférence open-source, mais je ne suis pas fermé aux logiciels fermés.
Plusieurs centaines voire milliers d'utilisateurs.
[^] # Re: Tuleap
Posté par n.rigaud . Évalué à 1.
Je suis aussi pro redmine. Et d'un point de vue professionnel, je le croise encore souvent dans le (vieux) monde industriel sur de gros projets (mais on parle aussi d'un monde ou les habitudes changent lentement). Je dirais donc que cela dépend avant tout du besoin. Si on souhaite effectivement pouvoir gérer des échanges en respectant un workflow bien défini, Redmine me semble assez facile d'accès et efficace (en ce qui me concerne ce sont des critères importants). Son apparence par défaut et son ergonomie peuvent sembler un peu désuètes.
Dans un autre cadre, j'avais aussi eu l'occasion d'essayer OpenProject qui a l'air assez séduisant. Il est lui même issu de ChiliProject il y a donc un certain lien historique vis à vis de Redmine.
OpenProject semble plus orienté sur le confort d'utilisation et l'ergonomie.
[^] # Re: Tuleap
Posté par desktop.ready . Évalué à 1.
Je ne suis pas expert de Redmine mais il me semble que pour créer ou personnaliser un workflow il faut les droits administrateurs (de Redmine) ?
Il semble aussi possible de faire à peu près ce que l'on veut, mais pour cela on doit installer ce plugin:
https://www.redmine.org/plugins/custom-workflows
(qui ne semble pas mis à jour depuis 2015, peut-être qu'il n'y plus de bogue ou de besoins de nouvelles fonctionnalités ?)
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . Évalué à 6.
Je réponds ici même si je ne réponds pas précisément à ce commentaire en particulier parce que je suis impliqué la dedans => je suis le CTO d'Enalean qui est l'éditeur de Tuleap.
Pour faire simple, Tuleap est précisément dans le scope que tu vises même si tu ne pourras pas tout faire dans ta wish list (à partir de l'interface, avec l'API, c'est autre chose). Par exemple, créer des sous-tickets ça demande de taper l'API par contre définir des changements d'état de parents en fonction des statut des enfants, c'est built in.
En plus ça tombe bien, le workflow a été profondément refait depuis le début de l'année et 2 nouvelles post actions sont en cours de développement: la capacité à geler progressivement un "ticket" (rendre les champs en lecture seule en fonction de l'état) et la capacité à cacher/afficher des groupes de champs, toujours en fonction de l'état.
La grande force de Tuleap c'est précisément le point que tu relevais à propos de Jira: l'indépendance pour configurer des choses. Dans ton projet tu peux créer autant de trackers que tu le souhaite, les configurer en toute autonomie. Tu n'es pas obligé d'hériter des 120 champs du tracker de bug "groupe".
Alors c'est vrai que l'on a pas la force de frappe de communication la plus folle du marché mais on a pas à rougir de nos utilisateurs et on est plutôt fiers quand ils acceptent de témoigner des trucs de zinzin qu'ils font avec. Le plus gros déploiement connu par nous regroupe plus de 45'000 utilisateurs et à bientôt 2 milions d'artifacts (tickets) au compteur et sur une infra pas folle.
Ah et côté interfaces, on a un ou deux trucs sympa en préparation et on a pas chomé l'année dernière sur le sujet non plus ;)
[^] # Re: Tuleap
Posté par desktop.ready . Évalué à 1.
C'est sympa d'avoir le CTO d'une entreprise qui vient directement répondre !
Très intéressant tes réponses, cela donne envie d'aller voir de plus près.
Une question cependant, pourquoi ne pas simplement ajouter la possibilité de programmer quelque chose dans Tuleap. C'est ce que fait le plugin de Redmine dont on parle plus haut:
https://github.com/anteo/redmine_custom_workflows/wiki/Example-Workflows
Je vois deux avantages :
1) vous pouvez utiliser cela pour créer proprement vos pre/post actions
2) vous laissez à l'utilisateur qui le souhaite de créer ses propres actions
En tout cas cela fait plaisir de voir une entreprise française avec un logiciel (en grande partie) open source tenir tête au bulldozer Atlassian. Bravo !
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . Évalué à 2.
Le point n°1 c'est la sécurité. On ne va pas laisser "n'importe qui" écrire son bout de code et l’exécuter "les yeux fermés".
On pourrait considérer que seuls quelques utilisateurs sélectionnés ont le droit de le faire mais se posent alors deux autres problèmes
- la dépendance aux admins centraux. Ce sont à eux d'écrire ou de revoir le code en question => ca ne sera pas fait et le point n°1 reste valable.
- la dépendance aux APIs internes de Tuleap. Tuleap bouge beaucoup et bouge vite, il n'y a aucune garantie de compatibilité sur les APIs internes. Le coût de mise à jour serait énorme pour garantir une upgrade "smooth".
La meilleure solution aujourd'hui est de se baser sur les mécanismes d'extension déjà présent (post-action "jenkins" du workflow ou webhooks) et d'avoir une implémentation indépendante qui utilise les APIs publiques (testées et stables) pour faire la logique particulière.
Peut être qu'a terme nous mettrons à disposition des éléments pour faciliter ces déploiements (genre github actions & co) mais c'est assez "lourd" à concevoir quand on doit prendre en compte le passage à l'échelle (autant j'imagine assez bien comment faire ça pour une petite instance à quelques dizaines d'utilisateurs, autant les instances avec 10k trackers et 45k personnes, la dépendance c'est une truc comme k8s ou OpenFaaS).
[^] # Re: Tuleap
Posté par desktop.ready . Évalué à 1.
Jira, Bugzilla, Trac et Redmine ont un mécanisme de plugins permettant de faire à peu près ce que l'on veut.
L'idée serait la même pour Tuleap: intégrer un mécanisme de plugin permettant d'étendre les fonctions.
Typiquement on peut imaginer un plugin permettant d'ajouter une pre/post action qui exécuterait un fichier présent sur le serveur.
Si un utilisateur veut une action permettant de créer des sous-tâches, il n'aura qu'à "payer" un développeur pour concevoir et valider le fichier implémentant l'action. L'administrateur n'aura alors qu'à uploader le fichier sur le serveur pour le mettre à disposition de tout le monde.
C'est ce que fait votre post-action "jenkins" ? je croyais que c'était pour l'intégration continue ?
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . Évalué à 2.
Ah, si tu veux passer par un plugin, c'est tout à fait faisable puisque la mécanique est déjà présente et il y a une belle collection déjà disponibles.
Cela dit, ca reste plutôt coûteux (en temps ou en argent) comme approche car le dev d'un plugin doit être un tant soit peu générique pour qu'il ait un sens (c'est à dire pour couvrir plus que le cas d'une seule personne sur un serveur).
Jenkins est un serveur de build, il permet de déclencher des jobs. Que ces jobs fassent du build de logiciel ou qu'ils exécutent des scripts pour automatiser de la création de "stuff" C'est la même chose. Et ça permet de bénéficier de l'écosystème de plugins Jenkins aussi (genre ne serait ce que pour avoir un truc propre pour gérer les creds)
[^] # Re: Tuleap
Posté par desktop.ready . Évalué à 1.
Je ne voulais pas dire développer un plugin à chaque fois que l'on a une nouvelle action.
Je voulais dire développer un plugin ajoutant une action "File" où l'utilisateur aurait la possibilité de choisir un fichier préalablement uploadé sur le serveur.
Cela permet de contrôler un tant soit peu ce que peut faire un utilisateur (il faut pouvoir uploader le fichier sur le serveur) tout en gardant la flexibilité.
Autrement s'il manque une fonctionnalité, il faudra toujours passer par Enalean pour l'ajouter (pas sûr que vous acceptiez, pas sûr que vous ayez le temps, etc.).
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . Évalué à 1.
Alors les plugins peuvent être développés par n'importe qui donc ce n'est pas le problème.
Par contre, fondamentalement on retombe sur le même problème de base: la sécurité du code de ces fameux fichiers uploadés + la maintenance des dits fichiers/scripts à la mise à jour (voire, pire, la prise en charge de plusieurs versions en parallèle).
[^] # Re: Tuleap
Posté par desktop.ready . Évalué à 1.
Fondamentalement je ne vois pas vraiment la différence entre:
1) on développe un plugin pour chaque nouvelle pre/post action
2) on développe un unique plugin et on upload un fichier pour chaque nouvelle pre/post action
On a exactement les mêmes soucis de sécurité et de maintenance non ?
La seule différence que je vois, c'est que l'option 1 est plus fastidieuse.
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . Évalué à 1.
En théorie oui c'est la même chose.
En pratique, se mettre dans le contexte du dev d'un plugin impose un cadre beaucoup plus formel. S'il s'agit d'un plugin qui a vocation à être intégré dans la distribution communautaire il devra suivre des phases de revue de code, devra avoir des tests, ne pas casser les tests existants, etc.
De ce que j'ai pu voir dans les autres outils qui proposent ce genre de Feature, même limité aux admins plateforme, la qualité de l'implémentation est généralement très en dessous des critères d'exigence d'un code "publique". Pour ne prendre qu'un exemple, il n'est généralement même pas possible d'écrire des tests pour les fameux fichiers ou scripts.
[^] # Re: Tuleap
Posté par desktop.ready . Évalué à 1.
Oui ce n'est donc pas un problème (direct) de sécurité ou de maintenance (la qualité peut avoir ensuite un impact sur la sécurité ou la maintenance, mais bon la qualité a un impact sur tout donc…).
Si on se place dans une entreprise ayant besoin d'une pre/post action précise, utile seulement pour elle. Ce serait un peu overkill de développer un plugin communautaire (qui n'intéressera sans doute personne). Du coup elle va développer en autonomie son plugin.
Du coup la qualité d'un plugin à usage interne ou un fichier développé en interne, à mon avis c'est kif-kif.
Un exemple ? L'importation de tickets dans Jira n'étant pas assez souple, j'ai développé un plugin rapidement répondant au besoin. Les pre/post action dans Jira étant trop limitées, j'ai utilisé le plugin ScriptRunner pour uploader des fichiers implémentant les actions nécessaires.
Dans les deux cas, j'ai codé de la même façon, avec la même qualité. Il y a juste une méthode beaucoup plus fastidieuse que l'autre. Et l'impact sur Atlassian ou le monde extérieur est nul, car c'est uniquement utilisé en interne (si ça casse, c'est notre faute).
Par principe, j'ai l'impression que vous vous positionnez sur ce sujet comme Atlassian qui s'est refusé à implémenter cela en standard (sans doute pour les mêmes raisons). Du coup comme il y a cependant une demande, une entreprise s'est engouffré pour proposer son plugin ScriptRunner (qui semble avoir un certain succès).
C'est un peu dommage je trouve, car être dépendant de fichiers internes c'est quelque chose que l'on peut assumer, mais dépendre d'un plugin dont on ne sait pas vraiment combien de temps il va être maintenu, c'est vraiment rédhibitoire.
Proposer un plugin standard implémentant cette fonctionnalité aurait deux avantages:
- vous pouvez afficher de gros avertissements encadrant l'utilisation de ce plugin.
- les clients potentiels seraient assurés d'avoir au moins un plugin maintenu.
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . Évalué à 1.
Je comprends le problème est, comme je l'ais évoqué plus haut, la solution c'est un "truc" externe qui peut s’exécuter dans une sandbox.
En tant que fournisseur de service (plus uniquement le logiciel cette fois ci), je ne peux pas donner à mes clients un couteau qui n'est formé de d'une lame une lame, sans manche et avec un post-it dessus: "faisez gaffe, ça coupe". Par ce que je sais qu'ils vont se couper et je sais que je vais devoir leur porter assistance parce que ça fait partie du job (je peux t'inviter à venir consulter nos logs de demande de support pour confirmer cela).
Aujourd'hui, ce que tu souhaites faire est déjà mis en place chez nos clients (et probablement dans la communauté aussi) via les mécanismes de webhooks & triggers, ça fonctionne bien, c'est méga stable, ça n'impose aucune contrainte sur le langage à utiliser et ça ne compromet pas le serveur.
[^] # Re: Tuleap
Posté par desktop.ready . Évalué à 1.
Peut-être suis-je trop dans la technique en effet.
Pour moi les fonctionnalités du logiciel ne devraient pas être artificiellement bridées (pour éviter que le client se coupe). Ou en tout cas, on devrait pouvoir le débrider facilement.
La gestion des tickets seraient pour moi un comme la gestion des versions. Git permet de faire à peu près tout, y compris flinguer son dépôt si on s'y prend mal. La responsabilité repose sur l'utilisateur.
Enfin bref c'est une question de philosophie je suppose: par exemple Atlassian est contre et les utilisateurs de ScriptRunner sont pour. Vu que ScriptRunner est facturé $14 000 pour plus de 10 000 utilisateurs, j'imagine qu'il y a un certain nombre d'utilisateurs intéressés (autrement ils ne pourraient pas chiffrer si haut).
Si c'est possible via webhooks & triggers, je serais intéressé par un exemple d'implémentation si on peut trouver cela dans les forums de Tuleap.
Merci !
[^] # Re: Tuleap
Posté par vaceletm (site web personnel) . Évalué à 1.
Voici un exemple sur notre blog https://blog.tuleap.org/how-connect-tuleap-tracker-jenkins-job
# Mantis Bug Tracker, simple, efficace
Posté par jp.fox . Évalué à 2.
En interne, nous utilisons Mantis BT. Facile à installer (PHP/MySQL), simple à paramétrer depuis l'interface d'administration, avec des workflows qui peuvent être différents par projet si on le souhaite. Nous interagissant avec nos clients (pas des informaticiens) avec cet outil sans problème.
[^] # Re: Mantis Bug Tracker, simple, efficace
Posté par desktop.ready . Évalué à 1.
En lisant vite fait la documentation :
The "Manage > Manage Configuration > Workflow Transitions" page allows users with ADMINISTRATOR access level to do the following tasks […]
Comme annoncé dans le journal, je trouve regrettable de devoir solliciter l'administrateur IT pour quelque chose d'aussi simple que mettre à jour un workflow.
D'autant que dans une entreprise, l'administrateur IT n'a pas forcément la connaissance métier et qu'il n'est donc pas forcément capable de construire le workflow.
[^] # Re: Mantis Bug Tracker, simple, efficace
Posté par cimcim . Évalué à 1.
Il me semble que l'"administrator" de mantis est un compte utilisateur interne à mantis, pas l'administrateur du serveur sur lequel il est installé, et donc pas nécessairement l'admin IT de la société. N'importe qui peut être désigné comme admin Mantis et gérer les workflows.
[^] # Re: Mantis Bug Tracker, simple, efficace
Posté par desktop.ready . Évalué à 1.
Oui j'avais bien compris.
L'administrateur est le plus haut niveau de privilège de Mantis :
https://www.mantisbt.org/docs/master/en-US/Admin_Guide/html/admin.user.access.html
Normalement l'administrateur est en charge du logiciel lui-même mais pas responsable des données métier.
Par exemple il peut mettre à jour le logiciel, installer des plugins, faire des opérations de maintenance (import/migration), maintenir les interfaces (LDAP par exemple). Typiquement il est responsable de plusieurs logiciels d'un point de vue IT, mais ce n'est pas un expert métier.
Bien entendu on peut allouer les droits administrateurs à un utilisateur pour contourner le soucis mais ce n'est pas très bien vu (et même interdit là où je travaille car c'est très réglementé).
[^] # Re: Mantis Bug Tracker, simple, efficace
Posté par jp.fox . Évalué à 2.
bah justement, dans Mantis, l'administrateur pour accorder les droits de modification du workflow à un rôle. Les utilisateurs ayant ce rôle (gestionnaire de projet par exemple) peuvent modifier le workflow des projets dont ils sont gestionnaires.
[^] # Re: Mantis Bug Tracker, simple, efficace
Posté par desktop.ready . Évalué à 1.
Tu es sûr ?
La doc dit explicitement que c'est uniquement l'administrateur de Mantis qui peut faire cela.
Si un simple utilisateur peut configurer son propre workflow aux petits oignons (créer des champs personnalisés, pleins d'étapes différentes, des automatismes poussés, etc.) sans embêter les voisins (c'est à dire qu'il ne peut pas modifier le workflow du voisin) cela devient vraiment intéressant !
[^] # Re: Mantis Bug Tracker, simple, efficace
Posté par nico4nicolas . Évalué à 1. Dernière modification le 24 mai 2019 à 17:41.
De mémoire, tu peux configurer qui fait quoi dans Mantis (voir commentaire précédent), il doit être possible de donner le droit à un manager de gérer le workflow. Enfin, sachant, que le workflow c'est le changement de statut, il suffirait de donner le droit à tout le monde de changer tous les statuts et c'est gagné (mais ça peut déboucher sur du grand n'importe quoi).
Je ne comprends pas comment vous travaillez. Est-ce que le workflow change vraiment du tout au tout selon le projet ? Qui devrait gérer le workflow d'après toi ?
[^] # Re: Mantis Bug Tracker, simple, efficace
Posté par desktop.ready . Évalué à 1. Dernière modification le 24 mai 2019 à 21:13.
Oui à partir de quelques centaines d'utilisateurs (voire milliers) éparpillés sur la planète, il va y avoir des besoins vraiment différents (business différent, réglementation différente, usage différent, etc.).
Donc déranger l'administrateur du logiciel à chaque fois pour modifier un workflow ce sera très pénible.
Je vois un peu cela comme un Excel: l'administrateur se limite à faire en sorte que le logiciel tourne.
Ensuite l'utilisateur peut utiliser et configurer Excel à sa guise pour l'adapter à son besoin.
Actuellement ce que je vois, c'est que l'on crée manuellement des formulaires PDF/Word/Excel pour gérer des workflows et ça me fait vraiment mal de voir cela.
Personne n'a jamais eu à remplir un formulaire Word pour une demande de congé ? Ou un formulaire pour se faire rembourser des frais de voyage ?
Vous avez de la chance…
# Deux propositions
Posté par Marotte ⛧ . Évalué à 4. Dernière modification le 24 mai 2019 à 23:24.
Il y a OTRS, version « community » ici, et iTop qui m’avaient semblé pas mal la dernière fois que je m’étais intéressé au sujet.
Sinon il y a aussi GLPI, orienté gestion de parc informatique mais assez versatile au final, me semble-t-il. Et Jira, ce dernier n’étant pas libre.
[^] # Re: Deux propositions
Posté par desktop.ready . Évalué à 1.
Hormis Jira, je n'ai jamais entendu parler de ces logiciels.
Est-ce que l'on peut simplement configurer un workflow et cela sans les droits administrateurs (du logiciel) ?
[^] # Re: Deux propositions
Posté par Marotte ⛧ . Évalué à 3.
Il te faudra les essayer ou trouver quelqu’un qui les connaît mieux que moi pour savoir si c’est possible. Je n’en sais rien.
# OSTicket
Posté par Philippe GRAILLE . Évalué à 1.
Simple à mettre en œuvre et efficace : OS Ticket https://osticket.com/
Est fait pour des tickets de support et le fait bien.
Personnalisable pour des utilisation un peu plus spécifiques.
[^] # Re: OSTicket
Posté par desktop.ready . Évalué à 2.
D'après ce ticket :
https://github.com/osTicket/osTicket/issues/2826
Il n'est pas pour l'instant possible de vraiment personnaliser un workflow…
# Alternatives libres
Posté par Yves (site web personnel) . Évalué à 1.
N’oublions pas :
Bon courage dans ta recherche de la solution idéale…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.