Intégrer les deux fonctions génériques logo_dupliquer() et objet_dupliquer() #45

Open
rastapopoulos wants to merge 7 commits from issue_4101 into master
Owner

Intégrer les deux fonctions génériques logo_dupliquer() et objet_dupliquer() dans les deux API afférentes editer_logo et editer_objet.

objet_dupliquer() a été développée dans le plugin Duplicator le temps de la tester et être sûr que ça couvre tous les cas mais elle a été pensée dès le départ pour être totalement générique et pour être intégrée au noyau directement.

En effet, le plugin Duplicator c'est de l'interface, de la configuration complexe suivant plein d'objets et d'enfants etc. Là il s'agit uniquement d'une fonction générique qui est autosuffisante.

D'autres besoins nécessitent de dupliquer des objets, sans aucun rapport avec l'interface de Duplicator, et c'est bête de devoir tout recoder à chaque fois (ex dupliquer une adresse d'un utilisateur pour la mettre sur une commande, sans que ce soit la même ensuite).

Là aussi ça ferait une amélioration substentielle de l'API des objets pour la 3.3, sans rien casser vu que ajout uniquement.

Par contre il y a besoin de l'API de parenté, donc à intégrer seulement après la PR #44

Intégrer les deux fonctions génériques logo_dupliquer() et objet_dupliquer() dans les deux API afférentes editer_logo et editer_objet. objet_dupliquer() a été développée dans le plugin Duplicator le temps de la tester et être sûr que ça couvre tous les cas mais elle a été pensée dès le départ pour être totalement générique et pour être intégrée au noyau directement. En effet, le plugin Duplicator c'est de l'interface, de la configuration complexe suivant plein d'objets et d'enfants etc. Là il s'agit uniquement d'une fonction générique qui est autosuffisante. D'autres besoins nécessitent de dupliquer des objets, sans aucun rapport avec l'interface de Duplicator, et c'est bête de devoir tout recoder à chaque fois (ex dupliquer une adresse d'un utilisateur pour la mettre sur une commande, sans que ce soit la même ensuite). Là aussi ça ferait une amélioration substentielle de l'API des objets pour la 3.3, sans rien casser vu que ajout uniquement. Par contre il y a besoin de l'API de parenté, donc à intégrer seulement après la PR https://git.spip.net/spip/spip/pulls/44
Owner

Y a un truc qui me chiffone sur ces fonctions.
Enfin surtout logo_dupliquer()… pourquoi ça indique seulement un $id de destination, et pas un $objet de destination aussi ?

Y a un truc qui me chiffone sur ces fonctions. Enfin surtout logo_dupliquer()… pourquoi ça indique seulement un $id de destination, et pas un $objet de destination aussi ?
Owner

En plus ça appelle le "pipeline('duplicator', ...)" qui n’est pas déclaré.

En plus ça appelle le "pipeline('duplicator', ...)" qui n’est pas déclaré.
b_b reviewed 11 months ago
* @param $options
* Tableau d'options :
* - champs : liste des champs à dupliquer, sinon * par défaut
* - ajout_titre : ajouter une chaine à la fin du titre
b_b commented 11 months ago
Poster
Owner

nomenkaltura alternative, suffixe_titre car le terme ajout ne mentionne pas implicitement si c'est au début ou à la fin

nomenkaltura alternative, suffixe_titre car le terme ajout ne mentionne pas implicitement si c'est au début ou à la fin
b_b reviewed 11 months ago
* - champs : liste des champs à dupliquer, sinon * par défaut
* - ajout_titre : ajouter une chaine à la fin du titre
* - dupliquer_liens : booléen précisant si on duplique les liens ou pas, par défaut oui
* - liens : liste d'objets liables dont on veut dupliquer les liens
b_b commented 11 months ago
Poster
Owner

si cette option est renseignée, je suppose que duppliquer_liens n'a plus d'effet, dans ce cas le préciser dans le commentaire

si cette option est renseignée, je suppose que duppliquer_liens n'a plus d'effet, dans ce cas le préciser dans le commentaire
Owner

Commenté en ligne pour quelques détails, sinon je ne comprends pas pourquoi tu as collé les commits de l'API de parenté dans cette PR.

Commenté en ligne pour quelques détails, sinon je ne comprends pas pourquoi tu as collé les commits de l'API de parenté dans cette PR.
tcharlss reviewed 11 months ago
* @return
* Retourne le chemin du nouveau logo si tout s'est déroulé correctement
*/
function logo_dupliquer($objet, $id_source, $id_cible, $etat='on') {
Poster
Owner

À suffixer en _dist peut-être ?

À suffixer en _dist peut-être ?
Poster
Owner

@marcimat :

  • tout duplication est toujours pour UN objet, on duplique les infos de l'id 123 vers l'id 456 de tel objet, ça vaut pour le logo aussi, c'est art123 qui est copié en art456
  • éventuellement on pourrait rajouter l'objet pour le logo, même si ça me parait pas méga utile, enfin c'est surtout une sous-fonction de l'autre
  • pour le pipeline c'est une scorie du plugin ça, je vais l'enlever, c'est un autre pipeline qui est appelé maintenant (et bien déclaré)

@b_b :

  • ok pour suffixe_titre (ou titre_suffixe), à changer
  • non "liens" c'est quels liens on veut dupliquer, par défaut tous. Et "liens_exclus" permet inversement d'en exclure
  • il y a l'API de parenté car cette PR en dépend, comme bien expliqué dans la description. J'ai donc créé la branche pour ajouter cette API en partant de la branche contenant déjà la parenté, puisqu'il la faut. Enfin ça me paraissait logique quoi. Mais fallait peut-être pas faire ça…

@tcharlss :

  • aucune fonction d'API d'édition des objets n'est surchargeable, donc je vois pas pourquoi tout d'un coup l'une le serait… je sais que normalement il faudrait que Rôles de documents puisse la surcharger, mais au niveau cohérence, je vois pas pourquoi tout d'un coup l'une de ces fonctions passerait en "dist" alors qu'aucune des autres
  • en revanche le truc manquant c'est que toutes les fonctions de l'API doivent permettre patate_XXX s'il existe, plutôt que la fonction générique (mais ça n'aiderait en rien pour Rôles de documents ok)
@marcimat : - tout duplication est toujours pour UN objet, on duplique les infos de l'id 123 vers l'id 456 de tel objet, ça vaut pour le logo aussi, c'est art123 qui est copié en art456 - éventuellement on pourrait rajouter l'objet pour le logo, même si ça me parait pas méga utile, enfin c'est surtout une sous-fonction de l'autre - pour le pipeline c'est une scorie du plugin ça, je vais l'enlever, c'est un autre pipeline qui est appelé maintenant (et bien déclaré) @b_b : - ok pour suffixe_titre (ou titre_suffixe), à changer - non "liens" c'est *quels* liens on veut dupliquer, par défaut *tous*. Et "liens_exclus" permet inversement d'en exclure - il y a l'API de parenté car cette PR *en dépend*, comme bien expliqué dans la description. J'ai donc créé la branche pour ajouter cette API en partant de la branche contenant déjà la parenté, puisqu'il la faut. Enfin ça me paraissait logique quoi. Mais fallait peut-être pas faire ça… @tcharlss : - aucune fonction d'API d'édition des objets n'est surchargeable, donc je vois pas pourquoi tout d'un coup l'une le serait… je sais que normalement il faudrait que Rôles de documents puisse la surcharger, mais au niveau cohérence, je vois pas pourquoi tout d'un coup l'une de ces fonctions passerait en "dist" alors qu'aucune des autres - en revanche le truc manquant c'est que toutes les fonctions de l'API doivent permettre `patate_XXX` s'il existe, plutôt que la fonction générique (mais ça n'aiderait en rien pour Rôles de documents ok)
Owner

@b_b :

  • ok pour suffixe_titre (ou titre_suffixe), à changer

cool

  • non "liens" c'est quels liens on veut dupliquer, par défaut tous. Et "liens_exclus" permet inversement d'en exclure

'k

  • il y a l'API de parenté car cette PR en dépend, comme bien expliqué dans la description. J'ai donc créé la branche pour ajouter cette API en partant de la branche contenant déjà la parenté, puisqu'il la faut. Enfin ça me paraissait logique quoi. Mais fallait peut-être pas faire ça…

Hmmm, j'arrive à comprendre ta démarche, c'est pas bien grave de toute façon, un squash meger permettra de n'avoir qu'un commit, et les diffs de l'api parent "ne seront pas appliqués" si !44 est mergé avant. Par contre, si ça bouge dans !44 tu vas te retrouver avec du conflit lors du merge de la présente PR.

> @b_b : > - ok pour suffixe_titre (ou titre_suffixe), à changer cool > - non "liens" c'est *quels* liens on veut dupliquer, par défaut *tous*. Et "liens_exclus" permet inversement d'en exclure 'k > - il y a l'API de parenté car cette PR *en dépend*, comme bien expliqué dans la description. J'ai donc créé la branche pour ajouter cette API en partant de la branche contenant déjà la parenté, puisqu'il la faut. Enfin ça me paraissait logique quoi. Mais fallait peut-être pas faire ça… > Hmmm, j'arrive à comprendre ta démarche, c'est pas bien grave de toute façon, un squash meger permettra de n'avoir qu'un commit, et les diffs de l'api parent "ne seront pas appliqués" si !44 est mergé avant. Par contre, si ça bouge dans !44 tu vas te retrouver avec du conflit lors du merge de la présente PR.
Owner

éventuellement on pourrait rajouter l'objet pour le logo, même si ça me parait pas méga utile, enfin c'est surtout une sous-fonction de l'autre

Bah soit tu considères que ta fonction logo_dupliquer ne concerne que les vieux logos (et encore même) (et serait donc quasi dépréciée en 3.3), soit tu considères le présent qui est que ça utilise concrètement une table de liens, et donc ça devrait plus ressembler à la signature de objet_dupliquer_liens(). Enfin je vois aucune raison de brider au même objet la duplication du logo. Non ?

Note en passant : je viens de m’auto-perturber en voyant que les logos déclarent un mode='logoon' ou 'logooff' dans spip_documents, et pas un role idoine dans spip_documents_liens... :)

> éventuellement on pourrait rajouter l'objet pour le logo, même si ça me parait pas méga utile, enfin c'est surtout une sous-fonction de l'autre Bah soit tu considères que ta fonction logo_dupliquer ne concerne que les vieux logos (et encore même) (et serait donc quasi dépréciée en 3.3), soit tu considères le présent qui est que ça utilise concrètement une table de liens, et donc ça devrait plus ressembler à la signature de `objet_dupliquer_liens()`. Enfin je vois aucune raison de brider au même objet la duplication du logo. Non ? Note en passant : je viens de m’auto-perturber en voyant que les logos déclarent un mode='logoon' ou 'logooff' dans spip_documents, et pas un role idoine dans spip_documents_liens... :)
Owner

Une petite question : si dans un objet j'utilise un identifiant chaine en plus de l'id, est-ce que l'on peut préciser qu'il ne faut pas le dupliquer tel quel ou pas car sinon on va créer des doublons qu'on ne veut pas justement ?

Une petite question : si dans un objet j'utilise un identifiant chaine en plus de l'id, est-ce que l'on peut préciser qu'il ne faut pas le dupliquer tel quel ou pas car sinon on va créer des doublons qu'on ne veut pas justement ?
Poster
Owner

J'ai modifié logo_dupliquer() @marcimat et mis titre_suffixe @b_b

@Eric oui c'est dans le param "modifications", tu peux alors vider la valeur pour tel ou tel champ, ou déjà le pré remplir avec autre chose que t'aurais généré

Du coup après ces modifs, ça semble bon pour le merge mais… il faut faire le merge de la parenté d'abord, qui est encore en débat

J'ai modifié logo_dupliquer() @marcimat et mis titre_suffixe @b_b @Eric oui c'est dans le param "modifications", tu peux alors vider la valeur pour tel ou tel champ, ou déjà le pré remplir avec autre chose que t'aurais généré Du coup après ces modifs, ça semble bon pour le merge mais… il faut faire le merge de la parenté d'abord, qui est encore en débat
Owner

Nickel, j'ai plussoyé !

Nickel, j'ai plussoyé !
Owner

Yep, ça me parait mieux :)

Yep, ça me parait mieux :)
Owner

Les fonctions de parentés sont à jour dans cette PR ?
On dirait que non !

Les fonctions de parentés sont à jour dans cette PR ? On dirait que non !

Coucou
J'ai pas suivi les détails du débat et peut être cette intervention est bruiteuse plus qu'utile, vous jugerez par vous même, mais j'ai été confronté plusieurs fois à à des pénibilités dans le comportement de duplicator. La situation en gros c'est ça :

  • je veux dupliquer un article de news pour en proposer un nouveau, actualisé ; la dernière news (un article) sert donc de modèle ; ces articles ont tous un logo ; lorsque je duplique le dernier article, et que je supprime le logo (l'ancien logo, dupliqué... ou pas ?) sur le nouvel article pour mettre un nouveau logo sur cette nouvelle news, eh ben l'ancien article (celui d'origine) perd son logo aussi...
  • C'est arrivé plusieurs fois. Je sais pas si ça arrive toujours car du coup j'ai arrêté de me servir de duplicator.
  • C'est sur un SPIP 3.3.0-dev [24422] (donc avec les logos à l'ancienne mode) et avec duplicator 2.0.8 SVN [119662].
Coucou J'ai pas suivi les détails du débat et peut être cette intervention est bruiteuse plus qu'utile, vous jugerez par vous même, mais j'ai été confronté plusieurs fois à à des pénibilités dans le comportement de duplicator. La situation en gros c'est ça : * je veux dupliquer un article de news pour en proposer un nouveau, actualisé ; la dernière news (un article) sert donc de modèle ; ces articles ont tous un logo ; lorsque je duplique le dernier article, et que je supprime le logo (l'ancien logo, dupliqué... ou pas ?) sur le nouvel article pour mettre un nouveau logo sur cette nouvelle news, eh ben l'ancien article (celui d'origine) perd son logo aussi... * C'est arrivé plusieurs fois. Je sais pas si ça arrive toujours car du coup j'ai arrêté de me servir de duplicator. * C'est sur un SPIP 3.3.0-dev [24422] (donc avec les logos à l'ancienne mode) et avec duplicator 2.0.8 SVN [119662].
Poster
Owner

En SPIP 3.3 ce ne sont justement pas les logos à l'ancienne mode, mais un entre-deux, où les logos sont quand même bien mémorisés dans spip_documents et non pas juste par un fichier avec le nom de l'objet (patate123.jpg) à la racine.

Quand c'était ce dernier cas, de fait, un même fichier ne pouvait jamais servrir à plusieurs contenus à la fois puisqu'à chaque fois ça copie dans un fichier avec un nom différent (patate456.jpg pour être une autre patate). Alors que là dans le nouveau système un même fichier peut servir plusieurs fois et donc si tu le supprimes à un endroit bah oui ça le supprime ailleurs.

Mais sauf que dans l'interface 3.3 comme c'est un entre deux, ça ne permet pas de réutiliser un fichier existant et donc je suppute que ça propose la possibilité de "supprimer" à tout moment sans vérifier que la même image (le même id_document) est peut-être utilisé à plusieurs endroits à la fois.

Bref ça m'a l'air vraiment d'un truc propre à la 3.3.

En SPIP 3.3 ce ne sont justement **pas** les logos à l'ancienne mode, mais un entre-deux, où les logos sont quand même bien mémorisés dans spip_documents et non pas juste par un fichier avec le nom de l'objet (patate123.jpg) à la racine. Quand c'était ce dernier cas, de fait, un même fichier ne pouvait jamais servrir à plusieurs contenus à la fois puisqu'à chaque fois ça copie dans un fichier avec un nom différent (patate456.jpg pour être une autre patate). Alors que là dans le nouveau système un même fichier peut servir plusieurs fois et donc si tu le supprimes à un endroit bah oui ça le supprime ailleurs. Mais sauf que dans l'interface 3.3 comme c'est un entre deux, ça ne permet pas de réutiliser un fichier existant et donc je suppute que ça propose la possibilité de "supprimer" à tout moment **sans** vérifier que la même image (le même id_document) est peut-être utilisé à plusieurs endroits à la fois. Bref ça m'a l'air vraiment d'un truc propre à la 3.3.
Poster
Owner

Mais donc vu que cette PR est pour intégré à la 3.3, oui il faut résoudre ça, si ça merdouille avec la manière dont sont fait les logos actuellement.

En théorie ça fait pas ça avec Rôles de documents (en 3.2 il est) car lui c'est pas un entre-deux : quand on dit qu'un logo utilise un truc de la médiathèque et qu'il est utilisé en plusieurs endroits, ça ne propose pas de le supprimer si jamais il est utilisé plusieurs fois. On ne peut que le détacher, comme pour les autres docs.

Mais donc vu que cette PR est pour intégré à la 3.3, oui il faut résoudre ça, si ça merdouille avec la manière dont sont fait les logos actuellement. En théorie ça fait pas ça avec Rôles de documents (en 3.2 il est) car lui c'est pas un entre-deux : quand on dit qu'un logo utilise un truc de la médiathèque et qu'il est utilisé en plusieurs endroits, ça ne propose **pas** de le supprimer si jamais il est utilisé plusieurs fois. On ne peut que le détacher, comme pour les autres docs.

@rasta la version 3.3.0-dev [24422] que j'utilise date d'il y a assez longtemps (plus d'1 an je dirais) et date donc d'avant le changement de fonctionnement des logos (qui n'a pas été fait immédiatement à la création de la 3.3, mais s'est étalé sur plusieurs semaines ou mois assez récemment, il y a environ 6 mois je dirais)

@rasta la version 3.3.0-dev [24422] que j'utilise date d'il y a assez longtemps (plus d'1 an je dirais) et date donc d'avant le changement de fonctionnement des logos (qui n'a pas été fait immédiatement à la création de la 3.3, mais s'est étalé sur plusieurs semaines ou mois assez récemment, il y a environ 6 mois je dirais)
Poster
Owner

Bon alors peut-être bien qu'il y a tel ou tel problème mais pour le coup effectivement c'est pas super pratique de rapporter un problème qui serait sur une vieille version de dev jamais utilisée, entre deux situations. Soit ya un bug sur la dernière stable 3.2, soit vraiment sur la version de dev à jour.

Bon alors peut-être bien qu'il y a tel ou tel problème mais pour le coup effectivement c'est pas super pratique de rapporter un problème qui serait sur une vieille version de dev jamais utilisée, entre deux situations. Soit ya un bug sur la dernière stable 3.2, soit vraiment sur la version de dev à jour.

En effet. En l'état ça n'est pas une déclaration de bug, mais ça motive un scenario à tester pour validation avant plus large diffusion.

En effet. En l'état ça n'est pas une déclaration de bug, mais ça motive un scenario à tester pour validation avant plus large diffusion.
This pull request has changes conflicting with the target branch.
ecrire/paquet.xml
ecrire/base/objets.php
ecrire/inc/filtres.php
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
6 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.