externaliser la gestion des docs avec les plugin ad’hoc
passer les chaines de trad sous Salvatore
externaliser les notifications (plugin notification) – en option –
implémenter la vérification par email (y’a un bout de plugin qui avait commencé ça)
revoir les pipelines (actuellement, lorsqu’on vide le cache depuis l’interface privé, le cache des pipelines est mal recalculé – ceux de Publication Ouverte sont appelés deux fois)
Revoir la gestion des droits (passer par accès restreint me semble pas mal pour cette partie)
Revoir l’interface de configuration en partie privée
Bref, le plugin actuel va complètement exploser.
C’est bien pour cela que j’ai préparé une branche de développement spécifique qui sera tout sauf stable dans un premier temps
(contrairement à la branche « stable » que je ne touche pas)
Si tu bosses sur publication ouverte pour 2.1, je me demandais l’intérêt de repartir du plugin plutôt que des simples editer_article.html/php du /prive ? Suffit de mettre ça dans ton /squelettes/formulaires et tu as une publication ouverte (en définissant le statut à prop plutôt qu’à prep).
Je suppose qu’à porter en plugin avec les quelques ajouts nécessaires ça sera mille fois moins lourd que d’adapter le publication ouverte ?
Enfin, je me gourre peut être, mais je trouvais ça bizarre que publication ouverte réécrive les fonctions d’ajout d’articles plutôt que d’utiliser celles existantes.
externaliser la gestion des docs avec les plugin ad’hoc
passer les chaines de trad sous Salvatore
externaliser les notifications (plugin notification) – en option –
implémenter la vérification par email (y’a un bout de plugin qui avait commencé ça)
revoir les pipelines (actuellement, lorsqu’on vide le cache depuis l’interface privé, le cache des pipelines est mal recalculé – ceux de Publication Ouverte sont appelés deux fois)
Revoir la gestion des droits (passer par accès restreint me semble pas mal pour cette partie)
Pourquoi le plugin Accès restreint et pas le plugin Autorité ? Ou l’API (?) autoriser() de SPIP ?
Revoir l’interface de configuration en partie privée
Bref, le plugin actuel va complètement exploser.
C’est bien pour cela que j’ai préparé une branche de développement spécifique qui sera tout sauf stable dans un premier temps
(contrairement à la branche « stable » que je ne touche pas)
Si tu bosses sur publication ouverte pour 2.1, je me demandais l’intérêt de repartir du plugin plutôt que des simples editer_article.html/php du /prive ? Suffit de mettre ça dans ton /squelettes/formulaires et tu as une publication ouverte (en définissant le statut à prop plutôt qu’à prep).
Je suppose qu’à porter en plugin avec les quelques ajouts nécessaires ça sera mille fois moins lourd que d’adapter le publication ouverte ?
Enfin, je me gourre peut être, mais je trouvais ça bizarre que publication ouverte réécrive les fonctions d’ajout d’articles plutôt que d’utiliser celles existantes.
Revoir la gestion des droits (passer par accès restreint me semble pas mal pour cette partie)
Pourquoi le plugin Accès restreint et pas le plugin Autorité ? Ou l’API (?) autoriser() de SPIP ?
Le plugin de publication publique permet de ne permettre à un auteur anonyme de ne publier que dans certaines rubriques bien précises : c’est exactement ce que gère le plugin Accès_restreint.
Il passe actuellement par un auteur spécifique qui n’a pas de mot de passe – ça me semble être une restriction assez importante surtout si à terme on ajoute la création automatique de comptes auteur_sans_accès_a_l_espace_privé (et je ne pense pas utiliser des 6visiteur pour cela car c’est incompatible avec toutes les autorisations existantes)
Le plugin de publication publique permet de ne permettre à un auteur
anonyme de ne publier que dans certaines rubriques bien précises : c'est
exactement ce que gère le plugin Accès_restreint.
Aucun rapport : le plugin Accès restreint gère la *visibilité* des éléments. Si on a pas accès à telle ou telle partie, ce n'est pas juste qu'on ne peut pas publier : on ne voit rien du tout !
C'est donc une trop grosse artillerie pour juste restreindre la publication à une liste de rubrique.
Pour cela il vaudrait mieux une page de configuration (avec CFG par ex) permettant dans choisir une ou plusieurs rubriques dans lesquelles la publication ouverte sera autorisée.
Il passe actuellement par un auteur spécifique qui n'a pas de mot de
passe -- ça me semble être une restriction assez importante surtout si à
terme on ajoute la création automatique de comptes
auteur_sans_accès_a_l_espace_privé (et je ne pense pas utiliser des
6visiteur pour cela car c'est incompatible avec toutes les autorisations
existantes)
Le but de l'API autoriser() ce n'est pas juste de pouvoir redéfinir les autorisations existantes, mais surtout de pouvoir en créer de nouvelles (qui, elles, pourront être surchargées pour personnaliser). Il n'est pas donc farfelu d'imaginer des autorisations spécifiques à la publication ouverte.
Je vois deux choix :
- soit faire des autorisations spécifiques
- soit surcharger l'autorisation "rubrique_publierdans" qui existe afin de modifier le comportement lorsque la rubrique est (ou fait partie de la branche qui est) dans la liste configurée dont je parle précédemment.