desktop.ready a écrit 134 commentaires

Oui exactement. Le problème avec le CSV c'est que cela paraît super simple à priori.
Mais en fait le format est tellement mal spécifié que tu as pleins de cas particuliers.
Combien on lu la RFC 4180 et l'on comprise ?

C'est un peu comme gérer les noms de personnes : la plupart des gens pensent que un champs nom et un champs prénom et c'est plié.
https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/

Le problème c'est surtout que c'est facile de croire que l'on maîtrise le CSV alors que c'est facile de se planter.
Du coup tu te retrouves avec des cahiers de charge écrit vite fait bien fait, avec genre "et la livraison devra être faite en CSV".
Si tu as de la chance, il sera peut-être précisé le caractère de délimitation et c'est tout.

programme-tv.net:
- 27 ad tracker
- 74 third party cookies
- This website could be monitoring your keystrokes and mouse clicks.
- When you visit this site, it tells Facebook.
- This site allows Google Analytics to follow you across the internet.
- 16 Partenaires (dont Criteo !)

Salut,

J'ai testé avec deux boîtiers différents et deux alimentations différentes.
De plus les boîtiers marchent très bien avec d'autres disques durs 2.5" (seagate, western digital…).

Je n'ai pas souhaité tester plus en avant et j'ai retourné les disques…

Ce disque est sorti il y a presque 3 ans et le rapport de bogue sur un soucis similaire (j'ai donné le lien plus haut) date d'environ 5 ans.
Donc je doute qu'il soit corrigé rapidement.

C'est juste que ce n'est pas une priorité et que donc personne n'a prévu d'y regarder. Si le constructeur ne fait aucun effort, tant pis pour lui: il y a d'autres marques de disque dur…

Apparemment cela arrive avec les SSHD:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1318218/comments/21

J'ai démarré avec l'OS sur un autre disque.
Le processus de Boot est bloqué (bien après GRUB) avec les messages d'erreurs (ci-dessus) qui s'affichent en boucle.

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 !

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…

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.

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.

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) ?

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.).

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 ?

Tu as un peu péché par omission :)

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.

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

Je te renvoie aussi à la note à la fin de mon journal ;-)

Les projets sont-ils indépendants ou as-tu besoin de coordination entre eux (Gestion de portfolio) ?

Projets indépendants

Es-tu ouvert à des solutions fermées ou uniquement open-source ?

De préférence open-source, mais je ne suis pas fermé aux logiciels fermés.

Quelle est la taille de ton entreprise ?

Plusieurs centaines voire milliers d'utilisateurs.

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 !

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…

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 !

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 ?)

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).

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.

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é).

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.

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

Le problème, c'est que le tambour photoconducteur à une durée de vie bien plus grande que celle des cartouches, alors c'est très con de le changer en même temps que les cartouches.

Oui c'est pas bien pour l'environnement (pour le prix, je n'ai pas vu de différence sensible sur les toners avec ou sans tambours).
Mais d'un autre côté j'ai lu qu'il était facile de flinguer son tambour avec des toners compatibles de mauvaise qualité.
Donc au moins quand le toner intègre le tambour, j'ai moins de scrupule à tenter la route des toners compatibles.