Formulaire editer_liens affiché inutilement dans certains cas #3245

Closed
opened 9 years ago by tcharlss · 6 comments
tcharlss commented 9 years ago
Owner

Reproduire le comportement

Pour observer le problème, je propose d'utiliser les mots-clés, qui se servent du formulaire « editer_liens ». Donc :

    1. Avoir au préalable des articles avec des mots-clés, et d'autres sans.
    1. Désactiver l'ajout de mots-clés aux articles pour tous les groupes de mots-clé.

Résultat :

  • Les articles possédant des mots-clés comportent toujours le formulaire. Là, ça me semble normal.
  • Les articles ne possédant pas de mot-clé affichent eux aussi le formulaire. Là, ça me paraît erroné : il devrait être caché. Il n'a aucune utilité, et on a "désactivé" l'utilisation des mots-clés pour les articles, ça veut dire qu'on en veut pas.

Continuons.

    1. Retirer tous les mots-clés liés aux articles.

Résultat :

  • Maintenant, le formulaire n'est plus affiché, car plus aucun article ne possède de mot clé : on retrouve le comportement normal.

Problème

Le problème vient d'un test effectué dans charger : http://core.spip.org/projects/spip/repository/entry/spip/prive/formulaires/editer_liens.php#L94

Le raisonnement actuel est le suivant : quand le formulaire n'est pas éditable, il est caché s'il n'existe aucun lien pour le type d'objet.
Ou pour reprendre l'exemple des mots, plus parlant : le formulaire est caché s'il n'existe aucun mot lié à un article (n'importe quel article).
Or je pense qu'il devrait être caché s'il n'existe aucun mot lié à l'article en cours.

Donc, en remplaçant :

objet_trouver_liens(array($objet_lien=>'*'),array(($objet_lien==$objet_source?$objet:$objet_source)=>'*'))

par :

objet_trouver_liens(array($objet_lien=>'*'),array(($objet_lien==$objet_source?$objet:$objet_source)=>$id_objet))

On retrouve le comportement qui me semble "normal".

## Reproduire le comportement Pour observer le problème, je propose d'utiliser les mots-clés, qui se servent du formulaire « editer_liens ». Donc : * 1) Avoir au préalable des articles avec des mots-clés, et d'autres sans. * 2) Désactiver l'ajout de mots-clés aux articles pour tous les groupes de mots-clé. Résultat : * Les articles possédant des mots-clés comportent toujours le formulaire. Là, ça me semble normal. * Les articles ne possédant pas de mot-clé affichent eux aussi le formulaire. Là, ça me paraît erroné : il devrait être caché. Il n'a aucune utilité, et on a "désactivé" l'utilisation des mots-clés pour les articles, ça veut dire qu'on en veut pas. Continuons. * 3) Retirer *tous* les mots-clés liés aux articles. Résultat : * Maintenant, le formulaire n'est plus affiché, car plus aucun article ne possède de mot clé : on retrouve le comportement normal. ## Problème Le problème vient d'un test effectué dans charger : http://core.spip.org/projects/spip/repository/entry/spip/prive/formulaires/editer_liens.php#L94 Le raisonnement actuel est le suivant : quand le formulaire n'est pas éditable, il est caché s'il n'existe aucun lien pour le type d'objet. Ou pour reprendre l'exemple des mots, plus parlant : le formulaire est caché s'il n'existe aucun mot lié à un article (n'importe quel article). Or je pense qu'il devrait être caché s'il n'existe aucun mot lié à *l'article en cours*. Donc, en remplaçant : <pre>objet_trouver_liens(array($objet_lien=>'*'),array(($objet_lien==$objet_source?$objet:$objet_source)=>'*'))</pre> par : <pre>objet_trouver_liens(array($objet_lien=>'*'),array(($objet_lien==$objet_source?$objet:$objet_source)=>$id_objet))</pre> On retrouve le comportement qui me semble "normal".
b_b commented 9 years ago
Owner

Salut, ta proposition me semble correcte. Si tu veux, tu peux envoyer une pull request sur github, ainsi tu seras crédité dans le commit. Sinon, on peut le commiter pour toi. Quelle est ta préférence ?

Salut, ta proposition me semble correcte. Si tu veux, tu peux envoyer une pull request sur github, ainsi tu seras crédité dans le commit. Sinon, on peut le commiter pour toi. Quelle est ta préférence ?
b_b commented 9 years ago
Owner

Heu, petite question tout de même : il y a bien une vérification de la configuration "permettre d'associer des mots clés aux articles" en plus du test cité ici ? Sans ça, je ne suis pas certain que le patch règle le problème correctement.

Heu, petite question tout de même : il y a bien une vérification de la configuration "permettre d'associer des mots clés aux articles" en plus du test cité ici ? Sans ça, je ne suis pas certain que le patch règle le problème correctement.
Poster
Owner

Oui, on vérifie l'autorisation à associer l'objet source à l'objet et à modifier l'objet : http://core.spip.org/projects/spip/repository/entry/spip/prive/formulaires/editer_liens.php#L92
Cela dit, ça concerne l'éditabilité du formulaire, et non pas son affichage.
Ce dernier est seulement influencé par la présence de lien ou non.

Alors je suis pas très au fait de git / github, donc je te laisse commiter le temps de me mettre à la page :p

Oui, on vérifie l'autorisation à associer l'objet source à l'objet et à modifier l'objet : http://core.spip.org/projects/spip/repository/entry/spip/prive/formulaires/editer_liens.php#L92 Cela dit, ça concerne l'éditabilité du formulaire, et non pas son affichage. Ce dernier est seulement influencé par la présence de lien ou non. Alors je suis pas très au fait de git / github, donc je te laisse commiter le temps de me mettre à la page :p
Owner

ah oui, tu as raison, l'autorisation de base dans le charger semble incorrecte car ne testant pas l'article en cours… Bien vu.

ah oui, tu as raison, l'autorisation de base dans le charger semble incorrecte car ne testant pas l'article en cours… Bien vu.
Owner

Appliqué par commit r21689.
Statut changé à Fermé

Appliqué par commit r21689. **Statut changé à Fermé**
Owner

C'était un tout petit peu plus compliqué a cause de la reversibilité du formulaire (liens à gauche ou à droite)
Version cible mise à 3.1

C'était un tout petit peu plus compliqué a cause de la reversibilité du formulaire (liens à gauche ou à droite) **Version cible mise à 3.1**
Sign in to join this conversation.
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.