Cédric (92de6ddd) at 25 Jul 12:08
fix: compatible SPIP 4.2
Cédric (dde6583e) at 27 Apr 17:10
icono svg pour le plugin
Cédric (3184070f) at 26 Apr 17:35
Paginations compat spip 4
Cédric (6075ca5e) at 26 Apr 14:06
Compat SPIP 4.1 aussi
charles razack (5862f367) at 08 Dec 14:25
Traduction anglaise
charles razack (87feba97) at 08 Dec 09:35
Bon faudrait pas changer le n° de version dans une PR, mais voilà.
charles razack (1f84e76f) at 08 Dec 09:35
Merge branch 'issue_2_commentaire' into 'master'
... and 1 more commit
Bon faudrait pas changer le n° de version dans une PR, mais voilà.
charles razack (87feba97) at 08 Dec 09:28
Ticket #2 : ajout d'un champ commentaire
Oui je voulais aussi aborder la question du wording, mais cela dépend effectivement du sens que l'on donne à ces actions et du workflow. Je ferais un ticket séparé pour ça du coup.
Je vais faire une PR rapido pour les commentaires donc, ça reste valable dans tous les cas.
Bonne idée pour l’ajout de commentaire.
Ceci dit, entre "valide / invalide" et "traité / ignoré", il me semble que le sens est différend. Que c’est une indication différente.
Ie: si je "marque comme valide" la proposition, ça ne veut pas dire que je l’ai appliqué, prise en compte, traitée ensuite ou aussitôt sur l’objet concerné.
Du coup, il me semble que a minima c’est un statut intermédiaire entre 'prop' et 'publie' (la proposition arrive en statut ’proposé’… > on passe valide > on passe traité.).
Non ?
charles razack (87fe79ea) at 08 Dec 08:29
Issue #1 : ajout d'une colonne id_auteur afin de pouvoir identifier les auteurs des modifs, et les filtrer en conséquence
Du coup en complément j'ai changé la signature de la fonction d'api : on peut passer l'id_auteur à la fin :
function inc_proposer_modifications_dist(string $objet, int $id_objet, string $source, $data, int $id_auteur = 0)
Au début je pensais que la fonction pourrait récupérer automatiquement celui de l'auteur connecté, mais en fait je me suis dis que c'était pas forcément toujours souhaitable et que ça devait rester à la charge de l'appelant. Par exemple si events envoie une proposition de modif à idc, il faudrait pas que ça mette le numéro de l'auteur d'events.
Dans le formulaire d'ajout par contre, là ça prend l'auteur connecté.
charles razack (cd3de74d) at 08 Dec 08:29
Merge branch 'issue1_id_auteur' into 'master'
... and 2 more commits
Proposition : ajout d'un champ commentaire
Le contexte : sur un projet, les propositions de modifications sont effectuées par un prestataire externe.
Nos admins valident ou invalident ces propositions (on a modifié les chaînes de langue dans ce sens : "marquer comme valide / invalide", plutôt que "traité" ou "ignoré").
On aurait besoin que les admins puissent laisser un commentaire expliquant leur décision : « invalide parce que bla bla bla », et donc d'ajouter un champ sur le table.
Je pensais l'ajouter dans le cadre du projet, mais je me dis que le besoin est suffisemment générique pour être direct dans le plugin.
Merci, du coup PR !1 (merged)
Issue #1 : ajout d'une colonne id_auteur afin de pouvoir identifier les auteurs des modifs, et les filtrer en conséquence
Du coup en complément j'ai changé la signature de la fonction d'api : on peut passer l'id_auteur à la fin :
function inc_proposer_modifications_dist(string $objet, int $id_objet, string $source, $data, int $id_auteur = 0)
Au début je pensais que la fonction pourrait récupérer automatiquement celui de l'auteur connecté, mais en fait je me suis dis que c'était pas forcément toujours souhaitable et que ça devait rester à la charge de l'appelant. Par exemple si events envoie une proposition de modif à idc, il faudrait pas que ça mette le numéro de l'auteur d'events.
Dans le formulaire d'ajout par contre, là ça prend l'auteur connecté.
charles razack (87fe79ea) at 24 Nov 15:06
Issue #1 : complément de la signature de la fonction d'API pour ind...
... and 1 more commit