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 desktop.ready . En réponse au journal Gestion des tickets/workflows. É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.