Merci pour les propositions.
Je suis d'accord pour passer tous les attributs "jalon", "composant",
"versions", etc. en mots-clés. En effet, tout le monde n'en a pas
besoin, ou on peut vouloir exprimer les mêmes notions avec d'autres
termes. Mieux vaut donc que ces attributs soient éditables, plutôt
qu'"imposés" et bloqués dans le code du plugin.
De même, libérer le code de ces notions dédiées au développement
informatique permet d'utiliser le système de tickets dans d'autres
environnements de collaboration. Il s'agit avant tout de permettre à une
équipe d'organiser le travail en commun, pas nécessairement pour des
développeuses/rs.
On peut modifier le code pour proposer une vue/crayon (et dans le
formulaire d'édition : un champ d'édition) par groupe de mots-clés.
C'est facile à faire, grâce à Marcimat
(Crayon de mots pour un article - La graine de Marcimat). Dans
l'implémentation actuelle, tous les mots-clés sont proposés dans le même
"select", avec un "optgroup" par groupe de mots-clés autorisés (on
n'affiche que si l'association avec les "tickets" est cochée dans la
page d'un groupe de mots-clés, comme pointé par Rastapopoulos).
Pour la migration, comment faire ? Il s'agit de créer programmatiquement
les groupes de mots-clés (jalon, version, composants, etc.) et les
relier aux tickets selon ce qui est présent dans la base au moment de
l'actualisation ? Et que proposer à l'installation du plugin ?
Sylvain
El 14/02/14 19:38, Eric escribió:
Hello,
L'idée de lier des mots-clés me parait sympa d'un point de générique
mais je trouve que l'implémentation actuelle n'est pas adaptée à cet objet.
En effet, un ticket n'est pas un objet éditorial comme un article, la
preuve en est qu'il n'est pas proposé dans le menu édition. De ce fait,
lier un mot-clé quelconque à un ticket n'a de sens que par rapport au
type d'information que cette association apporte.
De ce fait, le groupe de mots-clés est dans le cas du ticket aussi
important le que le mot-clé lui-même car il porte une grande partie de
la sémantique de l'association.
Par exemple, si l'on veut ajouter à des tickets du core de SPIP des
mots-clés 'autorisation', 'pipeline', 'SQL'... on pourrait les
regrouperait dans un type 'composant'. L'opération d'association aurait
donc le but d'identifier sur quel(s) composant(s) porte le ticket.
De fait, je pense qu'il faudrait plutôt :
1) autoriser explicitement dans la configuration Tickets les groupes de
mots-clés pouvant être associés à un tickets.
2) utiliser le nom du groupe de mots-clés pour définir le type
d'association (composant, jalon, versions...)
3) présenter ces associations dans le formulaire d'édition non pas en
utilisant le formulaire générique des mots-clés mais comme des select
(cf gravité) en utilisant le nom du groupe comme label.
4) virer les attributs jalon, version, composant, projet et leur
configuration pour justement les remplacer par ce mécanisme de mot-clé.
C'est d'ailleurs ce qui avait été envisagé à la création du plugin mais
qui n'avait pas été mis en place car à l'époque les api SPIP n'étaient
pas aussi souples qu'aujourd'hui.
5) créer une fonction de migration des attributs supprimés vers des
groupes et leurs mots-clés
A votre avis ?
++
Eric
2014-02-14 16:09 GMT+01:00 <severo@rednegra.net
<mailto:severo@rednegra.net>>:
Author: severo@rednegra.net <mailto:severo@rednegra.net>
Date: 2014-02-14 16:09:32 +0100 (Fri, 14 Feb 2014)
New Revision: 80692
Removed:
_plugins_/tickets/trunk/inclure/mots_ticket.html
Modified:
_plugins_/tickets/trunk/lang/tickets_fr.php
Log:
tickets - fichiers inusités
Details: Connexion · GitLab
_______________________________________________
Spip-zone-commit@rezo.net <mailto:Spip-zone-commit@rezo.net> -
http://listes.rezo.net/mailman/listinfo/spip-zone-commit
----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone