Créer des groupes, limiter l’accès aux rubriques et aux articles...

Attention ! Cette contribution modifie des fichiers du noyau de SPIP !

Même si elle a été testée par plusieurs utilisateurs nous ne pouvons garantir qu’il n’y aura pas d’effets secondaires dommageables sur votre SPIP. Conservez toujours les fichiers d’origine pour pouvoir revenir au noyau originel.

De plus, elle n’est compatible qu’avec une version précise de SPIP et sera perdue à la prochaine mise à jour : vous devrez donc recommencer.

Restreindre l’accès aux rubriques, articles, brèves en utilisant des groupes d’auteurs.

Un des besoins fréquent lorsque l’on gère un site sous SPIP est de pouvoir restreindre l’accès à des rubriques afin qu’elles ne soient accessible qu’à certains utilisateurs. De façon complémentaire, pour permettre une gestion de ces accès restreints complète, simple et ergonomique, il s’avère indispensable que les utilisateurs « autorisés » soient gérés par groupes.

Cette contrib répond à ce besoin en offrant le maximum de possibilités tant dans la gestion des utilisateurs autorisés que dans les restrictions d’accès ou dans la création de squelettes.

Attention ! Cette version est compatible SPIP 1.8, pour la version en plugin compatible SPIP 1.9, voir cette contrib.

Les nouveautés de la version 0.7 sont signalées par un : [v0.7]

Cette contrib permet :

  • de créer des groupes d’auteurs : ces groupes peuvent êtres constitués d’utilisateurs, d’autres groupes (sous-groupes) ou de statuts (c’est à dire que tous les utilisateurs d’un statut donné appartiennent à ce groupe). Cette organisation génère elle-même d’autres contraintes techniques à gérer : ainsi il ne doit pas être possible d’inclure le groupe « pére » dans le groupe « fils » puisque celui-ci contient déja « fils » (sinon on risque la boucle infinie lors de la routine de contrôle d’accès).
  • de limiter l’accès à certaines rubriques « rubriques restreintes » aux groupes créés : cette limitation d’accès peut s’appliquer soit dans la partie publique ET dans la partie privée, soit à l’une ou l’autre de ces parties séparément.
  • d’offrir des outils pour la création de squelettes adaptés à l’utilisation de rubriques restreintes.

Les rubriques « à accès restreint » sont gérées automatiquement : dès qu’au moins un groupe est autorisé à accéder à une rubrique (on pourrait dire qu’il contrôle cette rubrique), cette dernière devient alors à « accès restreint » et elle est inaccessible pour les lecteurs n’appartenant pas à ce groupe. Inversement, si aucun groupe ne « contrôle » une rubrique, elle est accessible par tous les internautes.

Le fonctionnement du système de restriction d’accès est conçu de manière à ce que toutes les sous-rubriques d’une rubrique à accès restreint soient elles aussi restreintes (principe « d’héritage des restrictions »).

Un exemple de situation à gérer :

Pour mieux cerner le fonctionnement, voici le cahier des charges auquel cette contrib tente de répondre [1] :

-  un SPIP est installé sur le site d’un établissement scolaire (disons un lycée) pour permettre la publication de contenus élaborés par les profs et/ou les élèves.
-  Ce SPIP comprend une rubrique par discipline (Anglais, Lettres, SVT...), tous les profs d’une discipline sont administrateurs de la rubrique de leur discipline afin qu’il puissent gérer/modérer les publications des élèves dans celle-ci.
Tous les élèves sont rédacteurs dans ce SPIP, les parents peuvent avoir un compte visiteur [2].
-  On souhaite que les profs d’une discipline puissent, s’ils le veulent, créer des sous-rubriques à accès réservé selon leurs besoins. Par exemple une sous-rubrique « travail en cours » dans laquelle ils pourront mettre au point ensemble les sujets de leurs prochains devoirs ou les corrections de ceux-ci. Il semble évident qu’il ne faut PAS que les élèves (comptes auteurs) aient un accès à cette sous-rubrique que ce soit dans la partie publique ou la partie privée !
-  On veut également qu’il soit possible d’avoir des rubriques à accès réservé uniquement aux profs (comptes admins restreints) pour qu’ils puissent publier des infos qui ne concernent pas les élèves (documents administratif, comptes-rendus de réunions syndicales, préparation de projets pluridisciplinaires...).
-  Il doit également être possible d’avoir des rubriques dans lesquelles les profs peuvent préparer des documents (par exemple les comptes-rendus des conseils de classe) qui seront accessibles une fois publiés (donc accès non-restreint dans la partie publique) mais confidentiels tant qu’ils sont en mode « en cours de rédaction » ou « proposé à l’évaluation » (donc accès restreint dans la partie privée).
-  Il faudra aussi une rubrique dont l’accès est réservé à tous les utilisateurs inscrits dans l’établissement (profs = admins restreints + élèves = auteurs + parents = visiteurs) dans laquelle on mettra, par exemple, les emplois du temps qui ne seront donc pas visibles par les « extérieurs » à l’établissement.
-  Enfin, il doit également être possible de créer des rubriques réservées :
— aux élèves d’une classe (un groupe « classe »),
— à plusieurs élèves et quelques profs, par ex le groupe « club informatique »
— aux profs de 2 ou 3 disciplines (par ex« profs de sciences », cad les profs de SVT + Physique/Chimie + Maths). On obtient donc un groupe de groupes
— à tous les élèves d’une classe
— ...
-  Avec comme circonstance aggravante que les admins généraux doient pouvoir « s’inviter » dans n’importe quel groupe pour consulter le contenu des rubriques à accès réservé.

Toute ces situations sont testables sur le spip de démo suivant : http://www.aix-mrs.iufm.fr/formatio...
 : choisir un compte ELEVExx pour un compte auteur ou PROFyy pour un compte administrateur de rubrique.

Fonctionnement obtenu lorsque l’on intègre cette contrib :

  • pour les auteurs : pas de modification par rapport au fonctionnement « normal » de SPIP, toutes les rubriques restreintes (et les articles qu’elles contiennent) sont refusées à l’accès dans la partie publique comme dans la partie privée sauf s’ils sont membres d’un groupe autorisé (ou d’un sous-groupe d’un groupe autorisé, pas de limitation au nombre de sous-groupes imbriqués).
  • pour les administrateurs de rubriques admin restreint ») :
    propriétaire d’un groupe

    idem les auteurs SAUF pour les rubriques dont ils sont administrateurs. Pour ces rubriques, ils ont un accès dans la partie publique et la partie privée MEME s’ils n’appartiennent pas à un groupe autorisé à l’accès. Il paraissait en effet logique qu’un admin de rubrique ait forcément accès aux rubriques dont il à la gestion.
    Il peut également créer des groupes (ou utiliser des groupes existants) pour limiter l’accès aux rubriques qu’il administre et à leurs sous-rubriques. Il ne peut modifier que les groupes et sous-groupes qu’il a créé.

  • pour les administrateurs généraux admin général »), idem les auteurs mais ils peuvent accéder au gestionnaire de groupes pour modifier n’importe quel groupe et donc s’ajouter aux utilisateurs autorisés. Un admin général peut ainsi visiter/modérer une rubrique à accès restreint MAIS il deviendra alors visible dans la liste des utilisateurs autorisés, ce qui permet au « propriétaire » d’une rubrique restreinte (admin restreint) de savoir que l’admin général s’est « invité » dans sa rubrique.

Concernant l’intégration des statuts dans un groupe :

Statuts intégrés dans un groupe

l’idée est la suivante : TOUS les utilisateurs du statut sélectionné sont membres du groupe. Cela implique qu’ils ont donc TOUS accès aux rubriques réservés à ce groupe.

Par exemple si l’admin choisit de faire un groupe « tous les admins restreints » dans lequel il intègre le statut « Administrateurs » et qu’il donne l’accès à ce groupe pour la rubrique « le coin des admins », on aura comme résultat que tous les admins restreints du SPIP peuvent accéder à cette rubrique mais que ni les visiteurs ni les auteurs ne pourront la visiter. Mais si l’administrateur le souhaite, il peut également intégrer l’auteur Toto dans ce groupe afin de lui permettre d’accéder aussi à cette rubrique.

L’interface de gestion :

Interface d’administration


-  Pour rendre les chose plus faciles à apréhender (l’imbrication groupes/sous-groupe peut devenir complexe, les restrictions des rubriques multiples...), l’interface de gestion des groupes (accesgroupes_admin.php3) intègre :
— l’affichage de la liste des groupes et des rubriques qu’ils contrôlent
— l’arborescence des groupes/sous-groupes.

-  [v0.7] Chaque groupe peut être configuré pour permettre aux utilisateurs n’ayant pas le droit d’accès à une rubrique

Paramétrage : « autoriser les inscriptions »

d’envoyer un message au propriétaire du groupe demandant leur intégration dans celui-ci. Ce paramètre permet d’envoyer un formulaire de demande d’inscription dans le groupe lorsque l’utilisateur ne peut accéder à une rubrique. Ce message sera consultable dans la messagerie de l’interface privée, il comporte un lien direct vers l’interface de gestion du groupe concerné. Les auteurs en attente d’intégration sont listés dans cette interface et peuvent être intégrés ou rejetés en un clic.

Auteurs ayant demandé leur intégration en attente



-  [v0.7] Chaque rubrique à accès restreint peut être configurée pour que la restriction porte soit

Configuration de l’accès restreint pour une rubrique

sur la partie privée, soit sur la partie publique, soit sur les 2 (privé + public. Il est possible (pour un admin général) de configurer une restriction d’accès sur une sous-rubrique d’une rubrique elle-même déja restreinte. Néanmoins, le principe « d’héritage des restrictions » d’une rubrique sur ses sous-rubriques impose les règles suivantes :
— rubrique parent restreinte « privé + public » => sous-rubrique restreinte obligatoirement « privé + public »
— rubrique parent restreinte « privé » uniquement => sous-rubrique restreinte « privé » ou « privé + public »
— rubrique parent restreinte « public » uniquement => sous-rubrique restreinte « public » ou « privé + public »

-  Administrateurs restreints : les administrateurs de rubriques ne peuvent modifier QUE les groupes qu’ils ont eux-même créés (= propriétaires). Cela permet de rester cohérent avec le fonctionnement de l’administration des rubriques : ils ne peuvent interdire l’accès qu’a l’intérieur de leurs rubriques. Ils peuvent utiliser des groupes créés par d’autres admins mais ne peuvent les modifier.

Outils à disposition pour les squelettes : [v0.7]

Vous pouvez utiliser les « outils » suivants pour gérer l’affichage des rubriques/articles/brèves restreints dans vos squelettes :

-  [v0.7]Cette contrib fonctionne en définissant une boucle [*ACCESGROUPES*] pour gérer les parties à ne pas afficher dans la partie publique.

Syntaxe générale de cette boucle :

... ici le début de votre squelette : les parties visibles même si l'accès est interdit (en-tête, menu de navigation...)

<!-- A partir d'ici on vérifie les accès en fct des groupes -->
<BOUCLE_ca(ACCESGROUPES)></BOUCLE_ca>
     <INCLURE(page.php3){fond=accesgroupes_interdit} {delais=0} {id_rubrique}>
</B_ca>

... ici la partie de votre squelette qui doit être protégée : contenu de la rubrique, de l'article...

<!-- fin contrôle d'accès -->
<//B_ca>

... ici la fin de votre squelette : partie visible quelque soit l'accès (pied de page...)

Le fichier accesgroupe_interdit.html est donc affiché si l’accès est interdit pour l’internaute qui consulte la page. Il contient le formulaire de demande d’intégration au groupe qui contrôle la rubrique si celui-ci l’autorise. Vous pouvez « customiser » son affichage si nécessaire (partie située après la ligne « //envoi de la page accès interdit » )



-  [v0.7] le filtre * utilisable sur les #BALISEs des boucles ARTICLES, RUBRIQUES ou BREVES, il permet d’ajouter une icone (par défaut cadenas-24.gif) devant la balise si l’élément fait partie d’une rubrique à accès restreint.

Syntaxe de base de ce filtre (exemple sur une balise #TITRE, le paramètre #ID_RUBRIQUE est obligatoire !) :

[(#TITRE|accesgroupes_visualise{#ID_RUBRIQUE})]
Résultat du filtre « accesgroupes_visualise »

Si l’image (cadenas) utilisée ne vous plait pas, ce filtre vous offre la possibilité de choisir un autre fichier image (qui DOIT être placé dans /ecrire/img_pack) en passant le nom de ce fichier en second paramètre du filtre. Exemple pour utiliser le fichier croix-rouge.gif sur une balise #TITRE :

[(#TITRE|accesgroupes_visualise{#ID_RUBRIQUE, croix-rouge.gif})]

-  [v0.7] le critère de boucle [* accesgroupes_invisible *] : ce critère est applicable sur les boucles ARTICLES, RUBRIQUES ou BREVES et permet de rendre invisible les rubriques, articles et brèves auxquels le lecteur n’est pas autorisé. Cela permet d’éviter que les utilisateurs qui n’ont pas accès à un contenu sachent qu’il existe tout en laissant ces contenus visibles pour les utilisateurs autorisés. Ce critère est spécialement utile pour les boucles du menu des rubriques ou le plan du site.

Syntaxe : (exemple sur une boucle RUBRIQUES de plan.html) :

<BOUCLE_rubriques(RUBRIQUES) {id_parent} {par titre} {accesgroupes_invisible}>

Remarque : les rubriques contrôlées par des groupes autorisant les inscriptions par formulaire (paramètre « Autoriser les inscriptions » à OUI) resteront visibles !

Vous trouverez des exemples d’utilisation de ces 2 outils dans le fichier squelettes/plan.html du zip de cette contrib.

Ce que ne fait pas cette contrib

en plus du café... Etant en version beta, et nécessitant encore des tests sur d’autres SPIP, nous ne garantissons pas une sécurité à toute épreuve.
Mais pour l’instant, nous n’avons pas trouvé de faille... si ce n’est le cache de spip... : il est donc utile de vider le cache de votre SPIP si vous déclarez « à accès restreint » une rubrique contenant déja des articles.

Comment installer cette contrib :

Remarque : si vous disposez déja de la version 0.6, les instructions d’installation ci-dessous sont également valides, la mise à jour des tables de la base de données est intégré sous forme d’un « patch » qui sera lancé automatiquement lorsque vous consulterez ecrire/accesgroupes_admin.php3 pour la première fois. Vos groupes existants et les rubriques qu’ils contrôlent seront récupérés à l’identique.

Téléchargez l’archive .zip ci-dessous de la dernière version, décompressez la dans un coin de votre ordi. Vous obtiendrez une arborescence de dossiers correspondant à ceux de votre SPIP à partir desquels vous devrez faire les opérations suivantes.

1) Pour l’interface d’administration des groupes et rubriques restreintes :

Transférer :

a. accesgroupes_admin.php3 et inc_config_accesgroupes.php3 dans le répertoire ecrire/

b. accesgroupes_fr.php3 et accesgroupes_en.php3 dans le répertoire ecrire/lang/

c. les icônes de /img_pack dans /ecrire/img_pack

Cette contrib intègre un installateur automatique pour les 3 tables de la base de données : il suffit de se connecter sur ecrire/accesgroupes_admin.php3 et les tables sont créées si elles n’existaient pas. Leur nom est de la forme : prefixeSPIP_accesgroupes_xxx.

Vous pouvez accéder au gestionnaire de groupe et d’accès restreints en l’appelant depuis votre navigateur http://www.monsitespip.org/ecrire/accesgroupes_admin.php3 ou créer une annonce, un message et faire le lien dans le texte du message :

[ACCES GROUPES->accesgroupes_admin.php3]

Alternativement (si vous ne craignez pas de modifier les fichiers de l’espace privé de SPIP et que vous souhaitez disposer d’une icone dans la barre d’outils), vous pouvez ajouter la ligne suivante

icone_bandeau_principal (_T('accesgroupes:groupes'), "accesgroupes_admin.php3", "groupe-48.png", "groupes", $rubrique, "", "groupes", $sous_rubrique);

juste après

	icone_bandeau_principal (_T('icone_auteurs'), "auteurs.php3", "redacteurs-48.png", "auteurs", $rubrique, "", "redacteurs", $sous_rubrique);

dans le fichier ecrire/inc_presentation.php3 (aux alentours de la ligne 2074 pour une version 1.8.3)

2) Pour la protection des accès dans la partie publique

a. Ajouter dans le fichier ecrire/mes_options.php3, le contenu du fichier mes_options_accesgroupes.php3 (vous pouvez bien sûr également utiliser un include).
Si le fichier mes_options.php3, n’existe pas dans le répertoire ecrire/, renommez mes_options_accesgroupes.php3 en mes_options.php3 et transférez le dans /ecrire.

b. Ajouter la boucle suivante dans vos pages de squelette rubrique, article, breve au début de la zone à ne pas afficher (juste après <div class=« contenu » id=« principal »> pour le squelette par défaut) :

<BOUCLE_ca(ACCESGROUPES)></BOUCLE_ca>
	<INCLURE(page.php3){fond=accesgroupes_interdit} {delais=0} {id_rubrique}>
</B_ca>

et en fin de zone à protéger (si vous utilisez le squelette par défaut, pour article.html et breve.html juste avant <body> , pour rubrique.html juste avant <div> <body>) :

<//B_ca>

c. Ajoutez dans votre dossier de squelette le fichier /squelettes/accesgroupes_interdit.html.

Remarque : si vous utilisez un spip « dist » (sans modifications), vous trouverez dans le dossier /squelettes du zip les pages article.html, rubrique.html et breve.html du squelette par défaut de SPIP 1.8.3 modifiées pour intégrer cette contrib. Dans ce cas vous pouvez directement transférer le dossier /squelettes du .zip dans le répertoire racine de votre SPIP.

d. Ajoutez aux fichiers article.php3, breve.php3 et rubrique.php3 de la racine de votre SPIP la ligne de code suivant qui permet de créer un fichier de cache suivant l’id de l’internaute

if (isset($GLOBALS['auteur_session'])){ $contexte_inclus['auteur_session_id']=$GLOBALS['auteur_session']['login']; }

Remarque : procédez de même pour tous les fichiers xxx.php3 correspondants aux fichiers xxx.html de votre squelette dans lesquels vous utilisez soit la boucle ACCESGROUPES, soit le filtre |accesgroupes_visualise soit le critère accesgroupes_invisible

3) La sécurisation de l’espace privé

Cette sécurisation passe par l’ajout d’une routine de vérification dans les fichiers suivants du répertoire /ecrire :

  • naviguer.php3
  • rubriques_edit.php3
  • articles.php3
  • articles_edit.php3
  • breves_voir.php3
  • breves_edit.php3

Cette vérification nécessite 2 fragments de codes : voici l’exemple pour naviguer.php3

 
// DEBUT ACCESGROUPES : à placer après fin_grand_cadre();

$acces = verif_acces($id_rubrique, 'prive'); 
if ($acces == 1 || $acces == 2) { 
    debut_gauche(); 
    debut_boite_info(); 
    echo "<div align='center'>\n"; 
    echo "<font face='Verdana,Arial,Sans,sans-serif' size='1'><b>"._T('info_numero_article')."</b></font>\n"; 
    echo "<br><font face='Verdana,Arial,Sans,sans-serif' size='6'><b>$id_article</b></font>\n"; 
    echo "</div>\n"; 
    fin_boite_info(); 
    debut_droite(); 
    debut_cadre_relief($ze_logo); 
    echo "\n<table cellpadding=2 cellspacing=0 border=0 width='100%'>"; 
    echo "<tr width='100%'> <td width='100%' valign='top' colspan='2'>"; 
    gros_titre($titre); 
    echo "</td> </tr> <td>".http_img_pack("warning.gif",'', "width='48' height='48'", _T('info_administrer_rubrique')); 
    echo "</td><td>"._T('accesgroupes:bloque_article')."</td></tr>"; 
    echo "</table>\n"; 
    fin_cadre_relief(); 
} else { 

// FIN de la premiere partie d'ACCESGROUPES 
// ACCESGROUPES : à placer avant fin_page(); 
} 
// FIN ACCESGROUPES

Si vous utilisez un spip version 1.8.3, vous pouvez tranférer ces fichiers depuis le dossier /ecrire du zip dans le dossier /ecrire de votre site en écrasant les fichiers existants.

Donc, en résumé, si vous utilisez une version 1.8.3 sans modifications (squelette par défaut), vous pouvez simplement transférer l’ensemble des fichiers fournis dans le zip dans les répertoires correspondant de votre site, renommer ecrire/a_placer_dans_mes_options.php3 en ecrire/mes_options.php3 et ça devrait fonctionner !

Ce qu’il reste à faire

  • Compléter la traduction de accesgroupes_fr.php3 en anglais dans accesgroupes_en.php3 et créer d’autres fichiers de langue si vous avez besoin
  • une icône « groupe » moins crasseuse pour la barre d’outils générale (je suis pas graphiste moi !)
  • Passage en plugin pour la version 1.9 : on y travaille, ne vous impatientez pas...

Téléchargement de la contrib :

3

Les fichiers d’installation... v0.7

Version 0.7 : dernière version stable pour SPIP 1.83

3Archives :3

Les fichiers d’installation... v0.2
Les fichiers d’installation... v0.3
Les fichiers d’installation... v0.5
Les fichiers d’installation... v0.61

Notes

[1cahier des charge tout à fait complémentaire de celui de csv2spip, une autre contrib qui permet de créer et gérer les comptes utilisateurs en masse à partir de fichiers CSV

[2pour fixer les idées on aura donc quelque chose comme 1000 élèves rédacteurs, 80 profs admins restreints dans 15 rubriques disciplinaires plus 4 administrateurs généraux (toutes les rubriques) et un webmestre (le seul qui dispose de l’accès FTP au site)

Historique des versions :

  • V0.1 - 16 juillet 2005
    version initiale avec gestion multilingue
  • v0.2 - 02 août 2005
    maj pour compatibilité avec MySQL 3.23
    la table jpk_auteurs_groupes devient jpk_groupes_auteurs
    correction affichage des titres de rubriques typo()
  • v0.3 - 07 août 2005
    Ajout d’un bouton pour la suppression d’un groupe inactif
    Correction du test d’accès, utilisation du login au lieu de l’id_auteur
  • v0.4 - non diffusée
  • v0.5 - publiée avec un exemple de protection des articles dans l’espace /ecrire/
    Attention, les fichiers ont été renommés !!!
  • v0.61 - intégration des sous-groupes et des status comme membres possibles des groupes, installateur automatique des tables dans la base de donnée de spip, préfixage des tables jpk_, « explorateurs » de groupes dans l’interface de gestion.
  • v0.7 : version finalisée pour SPIP < 1.9 .
    Correction du bogue de la modification / suppression d’un groupe, possibilité de séparation privé / public, possibilité de demande d’inscription dans un groupe par formulaire. Passage en BOUCLE de la restriction de l’espace public + filtre + critère pour configurer les squelettes.

Discussion

36 discussions

  • Alors là, génialissime ! Il ne manquait plus que cette boucle « de protection » ! Bravo à Coyote et cy_altern pour l’une des plus importantes contrib’ pour SPIP.

    Cela fait un petit moment que je teste la version précédente de la contrib’ avec une version 1.8.3 de SPIP et il ne me manquait plus que cette boucle pour gérer mon « usine à gaz ».

    Encore merci à vous 2 !

    P.S. : bon courage pour une migration vers SPIP 1.9 ;-)

    Répondre à ce message

  • 3

    quid de l’évolution de cette contrib vers spip 1.9
    -  suppression des fichiers .php3

    • C’est en cours...

    • Cette contrib est super : bravo ! Je l’ai même testée avec la 1.9 en migrant ma 1.8.2 et ... ça marche sauf le module d’administration accegroupes_admin.php3 !

      J’attends donc impatiemment le plugin parce que le public Accès restreint actuel il est vraiment trop restreint dans ses fonctionnalités : s’il faut être loggé sur l’espace privé pour voir les rubriques protégées de l’espace public, quel intérêt ?

       ;-))

    • C’est en cours ... une estimation de la date peut-être ?
      Courant Juillet serait trop optimiste ?
      Merci et encore bravo.

    Répondre à ce message

  • 1

    Merci d’abord pour cette contrib vraiment pratique
    Je n’ai pas eu de problèmes à la mettre en place, mais il doit y avoir un truc qui m’échappe.
    J’utilise spip 1.8.3 pour gérer un site de département de la Fac, des profs, des lecteurs et des étudiants, à part moi tout le monde a le statut de rédacteur.
    Pour l’instant je ne vois pas beaucoup de différence entre un groupe prof (rédacteurs) par exemple à qui je donne le statut d’admin dans certains groupes, je m’explique, je voudrais qu’ils puissent publier, modifier des contenus dans les rubriques dédiées :
    Mais si je ne donne pas le statut admin spip, ils ne peuvent pas le faire.

    Est-ce que j’ai raté une marche ?

    Sinon j’ai traduit le fichier accesgroupes_de.php3 en allemand comme l’indique le suffixe, je le mettrai bien dispo si on me dit où.

    A part cela j’ai des problèmes plutôt cosmétiques, j’utilise des scelettes bones_kubrick un clone du fameux thème de wordpress, et j’ai beau déplacer le code du contrôle d’accès dans rubrique.html, je n’arrive pas à obtenir la page entière (voir sur le lien du site en cliquant sur la rubrique cours licence 1 par exemple), il n’y a que l’entête et ensuite le fond gris du thème.

    Dans article.html c’est pire, il n’y a que le fond gris et le tableau d’identification tout en haut. (cliquer sur rss articles et prendre le premier venu.

    Mais bon c’est un détail, car l’identification fonctionne quand même.

    Si quelqu’un a une piste, je suis preneur,

    merci

    Martin

    • la version 0.7 est sortie : elle utilise une BOUCLE à la place du php dans les squelettes : ça devrait permettre de résoudre ton problème

    Répondre à ce message

  • 2

    bonjour,
    une possibilité d’amélioration :
    l’utilisation de la variable id_groupe n’est pas judicieuse car il s’agit d’un critère réservé par spip pour l’utilisation de groupes de mots-cles.
    Cela pose des problèmes lorsqu’on veut faire une boucle sur les tables rajoutées pour trouver quels sont les auteurs d’un groupe restreint...
    j’ai pour ma part simplement changé le id_groupe par un id_grpacces (identifiant du groupe d’acces) et ça fonctionne super.
    Cela m’a permis d’avoir un groupe dedié dont je peux lister les membres :-)

    Répondre à ce message

  • 1

    Bonjour,
    Tout d’abord félicitation à l’auteur, cette contrib est vraiment très utile.
    Cependant, un écueil subsiste pour ma part.
    Utilisant BioSPIP 4.0 pour mon site, j’ai bien effectué toutes les modifications préconisées dans le tuto (sauf le paramétrage de l’accès au serveur ftp/mysql dans un des fichiers de config).
    En espérant que l’erreur que je rencontre ne provienne pas de mon oubli cité ci-dessus, voici son libellé exact : « Fatal error : Call to undefined function : verif_acces() ». Elle survient dans tous les fichiers php3 qui ont été modifié et qui l’appelle.
    C’est assez problématique car plus rien n’est possible (navigation, rédaction d’articles, création de rubriques - je n’utilise pas de brèves).
    La fonction est bien présente dans le fichier mes_options-jpk.php3 mais je n’arrive pas à m’expliquer pourquoi son appel ne se réalise pas correctement.

    Merci d’avance de vos réponses éclairées.

    Répondre à ce message

  • Bonjour,

    Je débute sur SPIP (et PHP) et je voudrais créer un site avec accès public restreint.
    Votre contrib semble très interessante, mais il y a apparemment un décalage avec la version 1.9.
    Pouvez-vous m’aider SVP ?

    Merci d’avance.

    Répondre à ce message

  • Superbe contrib.

    Nous sommes en train de repenser le site internet de l’orchestre UT5 et j’essaye de démontrer que SPIP est l’outill contemporain indispensable pour cela. La question des droits d’auteurs et d’éditeurs pour les oeuvres musicales nous empèche de diffuser à tous des enregistrements et des partitions non officiels ou provisoirs. La solution de gestion de groupes proposée ici semble totalement adaptée et apporte une issue extrèmement élégante au problème de l’utilisation restreinte de documents. Je l’ai dors et déjà adoptée pour mon site perso.Merci

    Je découvre le php en même temps que j’essaye d’utiliser SPIP. J’ai adopté une légère variante par rapport à la solution proposée ici. Plutot que d’afficher la balise de refus de connection pour les personnes non enregistrées, je redirige vers un article SPIP dédié. Cela permet une gestion plus souple et mieux controlée des messages d’erreur.

    Encore Bavo

    Répondre à ce message

  • 1

    bonjour et d’abord merci pour cette contrib et tout le travail apporté par elle...mais j’ai ce qui pour moi est un big problème. Sur les rubriques en acces limité mettre une réponse sur le forum n’envoie pas de mail à l’auteur. Cà marche pour un autre site que j’ai avec spip sur le même hébergeur, çà marche sur ce site avec les rubriques publics mais aucun mail ni forum ni en cliquant sur l’auteur avec l’accès limité...avez vous une explication et une solution à me proposer...

    • désolé pour le dérangement, un accent qui trainait dans l’adresse du test...
      Donc merci votre contrib est super, juste si les admin restreints pouvaient ajouter tout seul des auteurs ou des visiteurs dans leur groupe sans voir la page complète, ce serait super.

    Répondre à ce message

  • 1

    j’ai mis en place cette contrib sur mon site et cela marche parfaitement bien.
    C’est le site d’une asso (www.cemea-haute-normandie.org)
    qui gère beaucoup de membres répartis sur une région, avec plusieurs statuts différents et deux espaces(privé et public) sur le site.
    cette contrib m’a sauvé la vie.
    je n’ai aucun bug(pourtant j’ai multiplié les contribs : spip 1.8.3, spip-liste, forum spip...)
    ça change pour une fois quelqu’un qui n’a pas de problème.
    toutefois et c’est l’objet de mon message, j’aimerai savoir s’il serait possible avec cette contrib de gérer les admnistrateurs restreints.
    en effet sur le site j’ai besoins d’avoir des admninistrateurs ne s’occupant que d’une rubrique (pour la validation des articles) mais qui doivent pouvoir accéder en lecture à toute la partie privé(celle de site protégée par mot de passe)
    est-ce possible et comment ?

    • Je l’ai aussi mise en place sans problème majeur (petits problèmes cosmétiques, voir autre message),

      la repartition des groupes est bien lisible,

      par contre je preds sur un autre tableau : dans la rubrique autheurs de l’espace privé les rédacteurs ne voient plus que les admins et pas les autres rédacteurs,

      pour l’instant le statut d’admin n’apporte rien de plus pour la gestion d’une rubrique, ils n’ont même pas accès à l’espace groupe, à moins que je leur donne le statut admin spip (création d’un nouvel auteur), ce qui ne m’avance pas parcequ’à ce moment-là ils peuvent tout faire comme moi :-)

      Peut-être y-a-t-il une astuce, mais j’ai fait plusieurs tests sans trouver la solution.

    Répondre à ce message

  • J’attendais cette contrib depuis longtemps. Elle est super.

    Je souhaiterais néanmoins pouvoir interroger les tables _jpk avec des boucles spip.

    La déclaration classique des tables dans mes_fonctions ne donne pas grand chose.

    Avez-vous une suggestion ?


    // Déclaration des tables JPK

    include (’ecrire/inc_serialbase.php3’) ;
    global $tables_principales ;

    $spip_jpk_groupes_acces = array(
    « id_groupe » => « bigint(21) »,
    « id_rubrique » => « bigint(21) »
    ) ;

    $spip_jpk_groupes_acces_key = array(« PRIMARY KEY » => « id_rubrique ») ;

    $spip_jpk_groupes_auteurs = array(
    « id_groupe » => « bigint(21) NOT NULL »,
    « id_auteur » => « bigint(21) NOT NULL »
    ) ;

    $spip_jpk_groupes_auteurs_key = array(
    « KEY id_groupe » => « id_groupe »,
    « KEY id_auteur » => « id_auteur »
    ) ;

    $tables_principales[’spip_jpk_groupes_acces’] = array(’field’ => &$spip_jpk_groupes_acces, ’key’ => &$spip_jpk_groupes_acces_key) ;
    $tables_principales[’spip_jpk_groupes_auteurs’] = array(’field’ => &$spip_jpk_groupes_auteurs, ’key’ => &$spip_jpk_groupes_auteurs_key) ;

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

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