Le plugin « Autorité »

Ce plugin permet de configurer des « autorisations » différentes de celles par défaut.

Introduction

D’aucuns trouvent le modèle d’autorisations de SPIP trop rigide (voir « psychorigide ») : par exemple, seuls les rédacteurs en qui l’on a confiance (et qu’on a donc promu « administrateurs ») sont autorisés à modifier les articles déjà publiés.

Depuis sa version 1.9.2, SPIP propose toutefois une API (interface de programmation) qui centralise tous les contrôles d’autorisations diverses et variées.

Le plugin « Autorité » est le premier à exploiter cette API pour proposer d’autres modes de fonctionnement hiérarchique. Il utilise (et nécessite) le plugin CFG, ce qui fait que son code reste relativement simple, en tous cas sans superflu.

Fonctionnalités

Dans sa version 0.9, le plugin « Autorité » propose les possibilités suivantes :

Rôle de webmestre

Ce rôle est indispensable pour modifier la configuration du plugin. Le webmestre est, par défaut, l’administrateur id_auteur=1 du site.

Les webmestres ainsi définis ont également le privilège de ne plus être obligés de passer par FTP pour valider les opérations sensibles du site, comme la mise à jour de la base de données ou la restauration d’un dump.

On peut changer la liste des webmestres en allant éditer le fichier config/mes_options.php (à créer le cas échéant), pour y indiquer l’id_auteur des auteurs qui auront les autorisations de webmestre. Par exemple, si les webmestres sont les administrateurs 2, 4 et 11 :

<?php
define ('_ID_WEBMESTRES', '2:4:11');
?>

Droits des auteurs et visiteurs

  • Auteur modifie article : chaque rédacteur (ou visiteur si l’on utilise un plugin tiers type Openpublishing) peut modifier les articles dont il est l’auteur (uniquement via les crayons pour les visiteurs) ;
  • Auteur modère forum : chaque rédacteur peut modérer le forum des articles dont il est l’auteur ;
  • Auteur modère pétition : chaque rédacteur peut modérer la pétition des articles dont il est l’auteur.

À noter : le premier de ces choix valide obligatoirement les deux suivants.

Droits des rédacteurs

  • Rédacteur modifie email : chaque rédacteur peut modifier son email sur sa fiche d’informations personnelles ;
  • Mots-clés : qui peut créer et éditer les mots-clés (administrateurs restreints, rédacteurs...) ;
  • Rédacteur voit stats : les rédacteurs peuvent visualiser les statistiques.

Crayons

  • Editer les forums : par défaut, personne n’est autorisé à modifier les forums ; ce réglage permet de laisser le webmestre (ou les administrateurs) éditer les forums. Mais aussi, si on le souhaite, les auteurs des messages de forum eux-mêmes (à condition qu’ils soient identifiés). Une option (très expérimentale) permet de ne laisser cette dernière autorisation que pour une durée d’une heure ;
  • Editer les signatures : par défaut, personne n’est autorisé à modifier les signatures de pétition. Ce réglage permet d’ouvrir ce droit au webmestre ou aux administrateurs.

Attention : pour ces deux réglages, SPIP n’offre pas d’interface de modification ; il faut utiliser Crayons (ou développer un plugin spécifique).

Espace wiki

Après avoir choisi dans le menu un secteur que l’on veut traiter comme un wiki (c’est-à-dire éditable par tous depuis l’espace public — à condition d’avoir une interface, par exemple les crayons), on indique si l’on souhaite ouvrir le wiki :

  • aux rédacteurs du site ;
  • aux visiteurs enregistrés ;
  • à tous les visiteurs du site.

Configuration du site :

  • interdire la configuration du site aux administrateurs non-« webmestres » ;
  • autoriser les sauvegardes pour les administrateurs restreints / ou les interdire pour tous ;
  • interdire de supprimer les données de la base (s’ajoute à l’authentification FTP) ;
  • interdire la création de nouvelles rubriques à la racine, ou en sous-rubriques.

Configuration des auteurs :

  • À la création d’un auteur, quel est son statut par défaut ?
  • Quels types d’auteurs peut-on associer à des rubriques ?
  • Ignorer la notion d’administrateur restreint

D’autres réglages peuvent s’ajouter à ces idées... N’hésitez pas à faire des propositions et à participer au développement.

Installation & configuration

C’est « plug and play ». Une fois les deux plugins « Autorité » et « CFG » activés, on se rend sur la page ecrire/?exec=cfg&cfg=autorite pour modifier les réglages (si l’on n’indique aucun réglage, les autorisations standards de SPIP s’appliquent).

Ensuite, roule le navire, après un éventuel vidage du cache les nouvelles autorisations sont en place.

L’interface de configuration
Avec le message d’erreur idoine :)

Compatibilité

La quasi-totalité des réglages ne sont opérationnels qu’avec les versions récentes de SPIP (version 2.x ou 3.x) ; seul le réglage auteur modifie article est compatible avec SPIP 1.9.2a. Il faut également une version de CFG supérieure ou égale à 1.0.2.

Structure du code (si vous souhaitez participer au développement)

Le plugin est développé sur SPIP zone, vous pouvez le charger par svn :

svn co svn://zone.spip.org/trac/spip-zone/browser/_plugins_/autorite

Ce plugin comporte quatre fichiers principaux [1] :
-  plugin.xml décrit le plugin ;
-  inc/autoriser.php étend le système d’autorisations et définit les fonctions nécessaires lorsque les autorisations sont différentes des autorisations par défaut ;
-  fonds/cfg_autorite.html définit l’interface de configuration, sous forme d’un simple squelette (ceci grâce au plugin CFG) ;
-  fonds/cfg_autorite_fonctions.php établit la liste des webmestres pour affichage dans le panneau de configuration (Cf. copie d’écran ci-dessous).

Dans inc/autoriser.php on fait bien attention à coder très proprement les fonctions, de manière à toujours pouvoir les redéfinir « de l’extérieur » (dans mes_options.php par exemple) ; le cas échéant, un message adapté signale les conflits dans le panneau de configuration.

Il est recommandé, lors des tests, d’utiliser plusieurs navigateurs connectés sous des profils d’utilisation différents ; et d’activer le debug des autorisations en inscrivant dans mes_options.php la ligne :

define ('_DEBUG_AUTORISER', true);

Notes

[1Les autres fichiers sont les icones, les chaînes de langue et le pipeline qui permet d’ajouter un onglet dans la page de configuration.

Dernière modification de cette page le 14 février 2019

Discussion

126 discussions

  • 3

    Permettre aux rédacteurs de créer de nouveaux rédacteurs ?

    (Je n’ai pas encore eu le temps de voir s’il était possible d’ajouter cette fonctionnalité)

    • Bon, après qcqs essais et errements avec autoriser_exception (’modifier’, ’auteur’, $id, $autoriser=true) ;
      je me suis contenté de :

      ### Autorisation de créer un auteur, on peut n' être que redacteur 
      function autoriser_auteur_creer($faire, $type, $id, $qui, $opt) {
              return ($qui['statut'] == '1comite' OR 'admin');  //
      }

      et modifier le message spip_fr.php ’texte_statut_poubelle’ => ’en attente de validation (ou poubelle)’
      et un admin doit valider la création, nul !
      (comment gérer ça, permettre de modifier le statut à et seulement à la création ???...)

    • je ne comprend rien à vos remarques et questions.

    • je cherche à permettre aux rédacteurs de créer de nouveaux rédacteurs.
      (avec la function autoriser_auteur_creer ci-dessus un redacteur peut créer un redacteur mais avec un statut poubelle. Il faudrait pouvoir permettre de modifier ce statut seulement lors de la création, ?exec=auteur_edit&new=oui . avec $GLOBALS ??

    Répondre à ce message

  • 4

    bonjour,
    trouvant que le plugin Autorité, l’Espace wiki, appelle le plugin révisions,
    je trouvais intéressant de pouvoir signaler les révisions côté public.
    En partant de /plugins/revisions/prive/objets/liste/version.html :

     <BOUCLE_liste_rev(VERSIONS){id_version>1}{objet!=''} 
    {id_auteur?} {id_objet?} {objet?}{where?}{par date} {inverse} {0,10}>
    <tr><td>[(#INFO_STATUT{#OBJET,#ID_OBJET}|puce_statut{#OBJET})]</td>
    <td>[(#OBJET|objet_icone{16})]</td>
    <td><a #SET{titre,#INFO_TITRE{#OBJET,#ID_OBJET}}
    [(#AUTORISER{modifier, #OBJET, #ID_OBJET}|?{
     href="[(#ENV{url_modif,#URL_ECRIRE{revision}}|parametre_url{id_objet,#ID_OBJET} |parametre_url{objet,#OBJET}|parametre_url{id_version,#ID_VERSION})]"
     , href="[(#ENV{url_modif,#URL_PAGE{#OBJET}}|parametre_url{id_#OBJET,#ID_OBJET})]"}
     )]
     title="<:revisions:voir_revisions{objet=#OBJET,id_objet=#ID_OBJET,titre=#GET{titre}}
    |attribut_html:>">
     #GET{titre}</a>[ ((#TITRE_VERSION))] &nbsp;
    </td><td>[(#DATE|date_relative)]</td></tr>
     </BOUCLE_liste_rev>

    (Peut être aussi ainsi possible insérer Historique à la wikipédia ...)

    • tu pourrais proposer cela comme article côté privé (avec un peu plus de détails et de liant) ?

    • Bonjour Maïeul,
      je n’ai malheureusement pas une maîtrise très poussé de tout cela. Cela m’a demandé pas mal de tâtonnement (j’ai vu que d’autres cherchaient aussi dans ce sens) mais ça me parait un peu faible comme contenu pour faire un article, non ?...
      (voir résultat sur http://bleaulib.org/ bas de page)
      Qcq précisions si nécessaire :
      créer un fichier /squelettes/inclure/version.html avec le code ci-dessus, l’inclure par INCLUREfond=inclure/revision , pour avoir les 10 dernières révisions, avec lien sur la page revision de l’espace privé si connecté, sinon sur la page public.
      On peut de même signaler qu’il y a eu révision sur un objet (article, ..) :
      INCLUREfond=inclure/historique, /squelettes/inclure/historique.html :

      <table><tbody>
      <BOUCLE_liste_rev(VERSIONS?){id_version>1}{id_article ?}{id_xxxx ?}{where?}
      {tri #ENV{par,date},#GET{defaut_tri}}{pagination #ENV{nb,10}}>
      <tr><td><a #SET{titre,#INFO_TITRE{#OBJET,#ID_OBJET}}
      [(#AUTORISER{modifier, #OBJET, #ID_OBJET}|oui)
       href="[(#ENV{url_modif,#URL_ECRIRE{revision}}|parametre_url{id_objet,#ID_OBJET}
      |parametre_url{objet,#OBJET}|parametre_url{id_version,#ID_VERSION})]"
      ]>
       <:revisions:voir_revisions
      {objet=#OBJET,id_objet=#ID_OBJET,titre=#GET{titre}}|attribut_html:></a>[ ((#TITRE_VERSION))]</td>
      <td>[<:der_revision:> : (#DATE|date_relative)]</td></tr>
      </BOUCLE_liste_rev>
      </tbody></table>

      (Mais maintenir le filtre |revisions_diff génère une erreur côté public, je ne peux donc montrer l’historique au public, comme sur wikipedia.)

    • si, si ouvre un article. Cela permettra à d’autres de compléter. Là ca va juste être perdu au milieu des messages de forum...

    • Bon, page créée : signaler-les-revisions-cote-public, du coup (après révisions ;-) peut être mettre un lien dans l’article présent sous espace wiki ?

    Répondre à ce message

  • Bonjour,

    Est ce qu’une autorisation pour que les rédacteurs publie leur articles serait utile dans le plugins ?

    Répondre à ce message

  • Bonjour,

    Merci pour ce très utile plugin.

    Je viens d’installer la dernière version (sur SPIP 2.1.26) et je n’ai plus la possibilité d’activer les options « Editer les forums » et « Editer les signatures ».

    Est-ce normal ? Est-ce un choix (il faudrait alors mettre la doc à jour) ? Est-il possible de réactiver ces deux possibilités d’une autre manière ?

    En vous remerciant,

    François

    Répondre à ce message

  • 3

    Bonjour et merci pour ce formidable plugin !

    Je rencontre un petit problème avec SPIP 3.0.11. Les rédacteurs ne peuvent créer de mot-clé alors que l’option est bien cochée dans le menu déroulant d’Autorité.

    Les administrateurs eux, peuvent par contre en ajouter.

    Sauriez-vous vers où je dois orienter mes rechercher pour régler le problème ?

    Merci d’avance !

    • Up.

      Pareil !

    • cf. la réponse ci-dessus : le bug est probablement dans SPIP qui en évoluant aura oublié de vérifier les autorisations nécessaires.

    • jordi bardaji

      Pour moi c’est le même probleme !! Les redacteurs peuvent modifier des mots-clés mais ils ne peuvent pas les ajouter.

      SPIP 3.0.16
      Plugin CFG, autorité et crayons. Les dernières versions.

    Répondre à ce message

  • 1
    lololebo

    Bonjour,

    j’ai un SPIP 3.0.16
    squelette escale
    cfg 3.0.0
    autorité 0.10.0

    et rien, je veux dire par là qu’il m’est impossible d’accéder aux paramétrages d’autorité.
    J’ai vu que d’autres avaient eu ce soucis, mais pas de réponse.

    Est-ce le pb de CFG qui est intégré à spip 3 ?

    • lololebo

      Re,

      Finalement problème réglé en réinstallant une fois de plus après avoir vidé les caches...
      Reste plus qu’à m’amuser avec !

      merci pour ce chouette plugin

    Répondre à ce message

  • 6

    Bonjour,

    Je me permets de republier un message que j’avais posté plus bas dans ce forum, qui n’a pas eu de réponse et dont la problématique subsiste toujours dans la version actuelle du plugin :

    « J’ai coché la case « pour interdire aux administrateurs de créer de nouvelles sous-rubriques dans l’arborescence ». L’icône « Créer une sous-rubrique » ne s’affiche pas, c’est bien.
    Mais il y a des petits malins qui arrivent tout de même à créer des sous-rubriques en créant une rubrique, puis, à l’aide du menu déroulant « À l’intérieur de la rubrique » choisissent de la placer dans une autre rubrique, au lieu de laisser le choix par défaut « Racine du site ».
    C’est ennuyeux, car la structure de ce site n’est pas faite pour gérer les sous-rubriques. Comment faire pour désactiver cette possibilité ? Merci de vos lumières. »

    En espérant que cette fois je me sente moins seul...

    • Quelle version de SPIP ?

    • Oups, alors voici :
      SPIP 3.0.16 [21266]
      + écran de sécurité 1.1.9
      avec zpip_v1
      Plugin Autorité 0.10.0

    • ok alors, vérification faite, il y a en effet des trucs qui ont sauté dans SPIP. Le plugin fonctionne très bien, au sens qu’il définit correctement l’autorisation correspondante. Mais SPIP ne la vérifie plus partout.

      Pour interdire la création d’une rubrique dans une sous-rubrique, tu peux tout de suite appliquer le patch suivant :

      Index: ecrire/action/editer_rubrique.php
      ===================================================================
      --- ecrire/action/editer_rubrique.php        (revision 21369)
      +++ ecrire/action/editer_rubrique.php        (working copy)
      @@ -74,9 +74,14 @@
        *     Identifiant de la rubrique crée
        */
       function rubrique_inserer($id_parent) {
      +
      +        $id_parent = (autoriser('publierdans', 'rubrique', $id_parent)
      +                AND autoriser('creerrubriquedans', 'rubrique', $id_parent)
      +        ) ? intval($id_parent) : 0;
      +
               $champs = array(
                       'titre' => _T('item_nouvelle_rubrique'),
      -                'id_parent' => intval($id_parent),
      +                'id_parent' => $id_parent,
                       'statut' => 'new');
               

      cependant, il restera plusieurs problèmes d’interface :
      — le sélecteur de rubriques devrait tester ces autorisations et ne pas s’afficher si ce n’est pas pertinent
      — le petit bouton de création rapide d’une rubrique ne devrait pas conduire à la page de création d’une rubrique dans la rubrique actuelle, mais simplement à la page de création d’une rubrique tout court (à la racine donc).

      Par ailleurs il faut pouvoir tester tous les autres cas d’autorisation et d’interdiction autour de cette question, histoire de ne pas casser autre chose en réparant ceci.

      Faute de temps pour régler tout ça, je suggère que tu crées un ticket sur core.spip.org pour signaler ce bug, et que tu suives l’affaire.

    • Merci beaucoup.
      Mais euh, comment dire... pour moi c’est du chinois.
      Je ne sais ou appliquer ce patch et n’ai aucune idée de comment créer et gérer un ticket ou juste de comprendre comment ça marche...
      Mais bon, j’ai le temps.

    • le patch ça indique quel fichier modifier, et quelles lignes ajouter (+) et supprimer (-) dans ce fichier.

      bon courage :)

    • Bon, j’ai pu appliquer le patch.
      Le résultat est que le menu déroulant pour choisir racine/rubriques existantes est toujours là, mais il est inopérant. Quoiqu’on choisisse, les nouvelles rubriques se placent toujours à la racine.
      Le but principal est atteint, mais je pense qu’il faut « nettoyer » un peu...

    Répondre à ce message

  • 10
    Insfixx

    Bonjour,

    Je voudrais savoir s’il est possible sur SPIP d’avoir un statut d’auteur sans accès à l’espace privé ?

    • C’est le statut « visiteur ». Cf http://www.spip.net/fr_article3517.html

    • Insfixx

      Oui mais justement mon problème c’est que le statut visiteur ne permet pas d’avoir une page auteur comme avec les rédacteurs ou administrateurs.

      Or j’ai besoin de visiteurs, donc sans accès à l’espace privé, avec leur profil accessible via un lien du type < a href="#URL_AUTEUR">#NOM< /a>

    • a mais si, c’est possible. Il faut « juste » modifier la boucle auteurs de la page auteur.html. Par défaut, une boucle auteur ne boucle que sur les auteurs ayant des articles.

      Mais il y le moyen de contourner cela :
      -  soit en mettant le critère {tout}
      -  soit en précisant que tu veux uniquement les visiteurs : {statut=1comite}.

    • Insfixx

      Même en ajoutant le critère {tout} à la boucle auteur, ça ne marche pas, erreur 404.
      Seuls les liens sur les noms des auteurs avec articles publiés aboutissent à la page auteur.

    • heu, tu peux montre un exemple de ta page auteur.html ?

    • Insfixx

      Voici le code de la page. C’est le squelette auteur de la dist, j’ai juste remanié le body. Bon ce n’est pas encore très propre, je suis en test.

      <BOUCLE_principale(AUTEURS) {id_auteur}{tout}>
      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
      [(#REM) Cf.: http://paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/
      ]<!--[if lt IE 7 ]> <html dir="#LANG_DIR" lang="#LANG" xmlns="http://www.w3.org/1999/xhtml" xml:lang="#LANG" class="[(#LANG_DIR)][ (#LANG)] no-js ie ie6"> <![endif]-->
      <!--[if IE 7 ]> <html dir="#LANG_DIR" lang="#LANG" xmlns="http://www.w3.org/1999/xhtml" xml:lang="#LANG" class="[(#LANG_DIR)][ (#LANG)] no-js ie ie7"> <![endif]-->
      <!--[if IE 8 ]> <html dir="#LANG_DIR" lang="#LANG" xmlns="http://www.w3.org/1999/xhtml" xml:lang="#LANG" class="[(#LANG_DIR)][ (#LANG)] no-js ie ie8"> <![endif]-->
      <!--[if IE 9 ]> <html dir="#LANG_DIR" lang="#LANG" xmlns="http://www.w3.org/1999/xhtml" xml:lang="#LANG" class="[(#LANG_DIR)][ (#LANG)] no-js ie ie9"> <![endif]-->
      <!--[if (gt IE 9)|!(IE)]><!--> <html dir="#LANG_DIR" lang="#LANG" xmlns="http://www.w3.org/1999/xhtml" xml:lang="#LANG" class="[(#LANG_DIR)][ (#LANG)] no-js"> <!--<![endif]-->
      <head>
      <script type='text/javascript'>/*<![CDATA[*/(function(H){H.className=H.className.replace(/\bno-js\b/,'js')})(document.documentElement);/*]]>*/</script>
      <title>[(#NOM|couper{80}|textebrut) - ][(#NOM_SITE_SPIP|textebrut)]</title>
      <INCLURE{fond=inclure/head} ></INCLURE>
      <meta name="robots" content="none" />
      <link rel="alternate" type="application/rss+xml" title="[(#NOM|textebrut)]" href="[(#URL_PAGE{backend}|parametre_url{id_auteur,#ID_AUTEUR})]" />
      </head>
      
      <body class="pas_surlignable page_auteur">
      
      <div class="global">
      
      
      
      
      <div class="bande_logo">
              <h1 id="logo">#NOM_SITE_SPIP [(#LOGO_SITE_SPIP|left)]</h1>
              
              
      </div>
      
      
      
      <div class="corps">
              
              <p class="arbo"><a href="#URL_SITE_SPIP/"><:accueil_site:></a> &gt; <:info_auteurs:>[ &gt; <strong class="on">(#NOM|couper{80})</strong>]</p>
              
              
              <div class="colonne_140">
              
              
              [(#LOGO_AUTEUR|inserer_attribut{class, 'avatar'}|image_reduire{134,*})]
              
              <div class="texte_petit">
              [(#SESSION{id_auteur}|=={#ID_AUTEUR}|oui)#FORMULAIRE_EDITER_AUTEUR{#ENV{id_auteur}}]
              </div>
              
              </div>
              
              
              <div class="colonne_milieu">
              
            <h1 class="#EDIT{qui} fn">#NOM</h1>
            [<div class="#EDIT{bio} texte_moyen">(#BIO)</div>]
                [<p class="#EDIT{hyperlien} hyperlien"><:voir_en_ligne:> : <a href="(#URL_SITE)" class="url org spip_out">[(#NOM_SITE|sinon{[(#URL_SITE|couper{80})]})]</a></p>]
                              
                      [(#REM) / vcard]
              
                              [(#REM) Articles de l'auteur ]
                              <B_articles>
                              <div class="menu">
                                      #ANCRE_PAGINATION
                                      <h2><:articles_auteur:> (#GRAND_TOTAL)</h2>
                                      <ul class="spip">
                                              <BOUCLE_articles(ARTICLES) {id_auteur} {!par popularite} {pagination 10}>
                                              <li><a href="#URL_ARTICLE">#TITRE</a></li>
                                              </BOUCLE_articles>
                                      </ul>
                                      [<p class="pagination">(#PAGINATION)</p>]
                              </div>
                              </B_articles>
                              
                                      [(#REM) Commentaires de l'auteur ]
                              <B_forums_liens>
                      #ANCRE_PAGINATION #GRAND_TOTAL
                                              <BOUCLE_forums_liens(FORUMS?) {id_auteur} {!par date} {pagination 3}>
                                      
                              [(#DATE|affdate)]</td><td><a href="#URL_FORUM"[ title="(#TITRE|attribut_html|couper{80})"]>[(#TEXTE|couper{80})]</a>
                      
                                              </BOUCLE_forums_liens>
                                      [<p class="pagination">(#PAGINATION)</p>]
                              </B_forums_liens>
                              
                              
                              
                              
                              
              </div>
              
                              
              
              
                      <div class="colonne_300">
                      
                      [(#FORMULAIRE_EDITER_LOGO{auteur,#ID_AUTEUR,'',#ENV*})]
                      
      #FORMULAIRE_ECRIRE_AUTEUR
      
      
              
              </div>
              
              
              
              </div>
              
              
      
              
      
              
      </div>
      
      
              
      
      
      </div>
      
      
      
      </body>
      </html>
      </BOUCLE_principale>
    • Insfixx

      J’ai remarqué que même sur spip-contrib lorsqu’on clique sur le nom d’un rédacteur sans article, on aboutit à une page 404.
      Est-ce normal ?

    • oui. du pt de vue de SPIP, un rédacteur n’est visible publiquement que s’il a au moins un article. Sauf si on dit expressement le contraire.

    • Hello

      Dans le plugins tu as un réglage pour fermé l’espace privé au rédacteur.

    • Bonjour je me permet de récupéré ce dernier message.
      _
      La fonction pour bloquer l’accès a l’espace privé aux rédacteurs fonctionne à merveille... même un peu trop !

      En effet, nos rédacteurs dispose d’une page de rédaction coté publique.
      Hors, quand ils choisissent la rubrique dans laquelle ils soumettent leur article, redirection vers un page d’erreur : Accès interdit à l’espace privé.

      On utilise #FORMULAIRE_REDIGER_ARTICLE pour générer ce fameux formulaire de rédaction.

      En espérant que vous pourrez m’apporter de l’aide =)

    Répondre à ce message

  • 1
    Nicolosko

    Bonjour

    ca a vraiment l’air super comme plugin. mais... mais... mais
    l’url ./ecrire/ ?exec=cfg&cfg=autorite => « Fichier cfg introuvable »

    -  Après install de CFG 3.0.0
    -  Autorite 0.10.0
    -  sous SPIP 3.0.14

    Qqlq’un serait-il assez au courant, et serviable, pour me dire comment faire ?
    Merci beaucoup

    Répondre à ce message

  • Bonjour,

    Merci pour ce plugin, toutefois il y a un point que je ne comprends pas bien. J’ai installe la version 0.10 sur SPIP 3.11 et tout semble fonctionner.

    Le dernier champs du formulaire de configuration est celui-ci :

    « Qui peut publier sur le site » (webmestre|administrateurs complets|tous les administrateurs)

    En n’autorisant que les administrateurs complets, mes administrateurs restreints ne peuvent plus editer les articles des autres auteurs. En autorisant TOUS les administrateurs dans ce formulaire alors ils peuvent a nouveau modifier les articles des autres. En me fiant a l’intitule, je pensais que cette option ne correspondait qu’a l’action de publier un article, c’est a dire modifier son statut a « publier ». Or la il semble que toute action d’edition sur un article soit affectee. Je ne vois pas l’interet de cette option de la maniere dont elle fonctionne a l’heure actuelle, ou est-ce que quelque chose m’echappe ?

    Benoit.

    Répondre à ce message

Ajouter un commentaire

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom