API Objet - Lacunes ou évolutions détectées par le plugin Archivage de Contenus

Équipes fonctionnel
#1

Le concept d’archivage mis en place par le plugin Archivage de Contenus implique de ranger des objets SPIP dans une zone de stockage virtuelle pour les extraire de la publication (espace public) voire des différents affichages standard de l’espace privé.

Gérer une telle zone nécessite de changer le comportements naturels des objets concernés d’une manière générique. Création, modification, changement de statut et déplacement d’un objet sont les actions qui devraient être impactées par l’archivage.

Deux principaux types de changement sont envisageables pour les objets concernés par l’archivage:

  1. Interdire les actions qui pourraient engendrer des incohérences avec l’archivage
  2. Ajouter des traitements liés à l’archivage suite au déclenchement de l’une des actions précitées

Mais au préalable, il semble que l’api objet de SPIP ne distingue pas clairement les actions, en particulier, pour le déplacement et le changement de statut qui sont toutes deux incluses dans instituer. Et d’ailleurs il n’y a pas de suppression car on utilise le changement de statut pour cela.
Je me demande si on aurait pas intérêt à mieux clarifier les actions de base sur les objets (un peu comme un CRUD étendu ou modifié).

Ensuite, pour le point 1, la façon évidente d’interdire une action sur un objet est d’utiliser l’api d’autorisation. Le problème c’est que l’on ne sait pas reconnaitre l’autorisation de création ou de modification voire de déplacement : ni par une déclaration ni par le nom.
Une déclaration incluse dans celle des objets spip serait une réponse mais il faudrait pour cela connaitre la liste et l’identifiant des actions sur les objets.

Pour le point 2, c’est les pipelines pre_edition et post_edition qui devraient être utilisés mais il faudrait pour cela vérifier qu’ils sont bien appelés systématiquement pour chaque action précitée et dans un contexte cohérent pour chaque type d’objet.

L’idée de ce fil c’est de discuter de ces sujets pour voir si il y aurait un intérêt de créer un ou plusieurs tickets à inclure dans une prochaine roadmap de spip.

2 « J'aime »
#2

Sur ce point, on a pas mal d’autorisations creer, tu penses qu’il en maque ? Idem pour modifier. Concernant le déplacement si ma relecture rapide est bonne, on passer par « instituer » qui renvoie sur modifier avec pas mal de cas spécifiques pour les articles. On pourrait améliorer en sortant les autorisations de changement de parent de la « modification » afin que « institue » appelle celles-ci et que tout cela soit bien raccord/branché avec l’API de gestion de parenté.

#3

Non, je ne dis pas qu’il en manque pour certains objets, je dis juste que je ne suis pas sur que l’autorisation de création de chaque type d’objet s’appelle toujours de la même façon et pas parfois ajouter ou autre. Donc en fait, si on ne veut pas imposer une norme de nommage il faudrait déclarer le nom de l’autorisation dans l’api objet pour chaque action : d’où l’intérêt de connaitre la liste des actions.

1 « J'aime »
Objets éditoriaux ?
#4

N’étant pas encore suffisamment dispo pour le moment, je n’ai que parcouru en diagonale les liens mentionné sur le ticket que j’ai ouvert au sujet de l’API objet : Objets éditoriaux ?

Cependant, bien que dans le silence depuis, j’arrive à peu près à suivre les échanges. Si j’avais eu suffisamment de temps dispo, j’aurais déjà fait des propositions.

Je pense de même que @Eric_tonton :

Joyeux soleil,
à bientôt.

#5

Je viens de transférer ce fil sur l’api objet dans l’équipe « fonctionnel ».

#6

Il me semblait que les autorisations de base ça c’était bien normé puisque l’échafaudage générique d’admin et l’api objet, appellent toujours autoriser('creer', $objet, …) ou autoriser('modifier', $objet, …)

#7

Oui mais par exemple si tu veux créer un article dans une rubrique c’est un peu spécial et donc si tu veux étendre ça à des nouveaux objets c’est pas générique. J’aurais bien vu une déclaration des autorisations par rapport à une liste d’actions données quitte à aussi définir un nom normalisé qui serait utilisé de préférence.