Historique
Ce plugin reprend la contrib Créer des groupes, limiter l’accès aux rubriques et aux articles... (version 0.7 réservée aux versions 1.8 de spip) dont il constitue la version 1.0. Ce plugin est compatible avec la version 1.9.2 de spip. Il n’a pas été complètement testé avec la version SVN de spip 1.9.3. (Une version compatible spip 1.9.1 est disponible également mais elle n’est plus maintenue).
[Mises à jour]
- la version [1.0.1] remplace la version 1.0 pour permettre d’assurer le filtrage des articles en mode « révision ». Voir ce forum pour plus de détails.
Il est vivement conseillé de procéder à la mise à niveau des plugins v1.0, la mise à jour des fichiers n’entraînera pas de modification de vos groupes et restrictions existant. - passage à la version [1.0.2] qui permet l’utilisation du critère tout_voir et du filtre accesgroupes_visualise pour permettre l’affichage d’une liste de toutes les rubriques/articles/brèves y compris les restreintes.
- passage à la version [1.0.3] compatible spip 1.9.2.
- passage à la version [1.0.31] qui corrige un certain nombre de bogues.
But :
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 essayant d’offrir le maximum de possibilités tant dans la gestion des utilisateurs autorisés que dans les restrictions d’accès, le tout sans avoir à intervenir sur les squelettes utilisés.
Pour permettre de réaliser des contenus totalement protégés, les restrictions d’accès doivent pouvoir s’appliquer aussi bien à l’espace privé qu’à l’espace public.
Pour les utilisateurs de la contrib (v0.7 ou v0.61), les nouveautés de cette version 1.0 (plugin) sont signalées par un : [v1.0]
Ce plugin 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 » si 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.
Les rubriques « à accès restreint » sont gérées automatiquement : dès qu’au moins un groupe contrôle une 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 ».
[v1.0] Ce plugin permet également qu’un admin général puisse créer des groupes en ayant la possibilité d’en « déléguer » ensuite la gestion à un admin restreint, ce qui correspond à une sorte de « changement de propriétaire » d’un groupe.
Un exemple de situation à gérer :
Pour mieux cerner le fonctionnement, voici le cahier des charges auquel cette contrib tente de répondre :
- 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.
- 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
- ...
- l’administrateur général du spip doit également pouvoir créer des groupes dont il déléguera ensuite la gestion aux admins de rubriques
- 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é.
Installation du plugin acces groupes :
[v1.0] Comme tous les plugins : récupérez le dernier zip à jour de cette contrib sur https://plugins.spip.net/accesgroup... ou sur le miroir http://miroirspip.ventre.name/build..., décompactez le et placez le dossier « acces_groupes » obtenu dans votre répertoire /plugins (à créer à la racine de votre spip si nécessaire), rendez vous sur l’interface de gestion des plugins (menu Configuration > Gestion des plugins), cochez le plugin « acces_groupes » et validez.
Vous devriez voir apparaître une icone supplémentaire dans le menu « auteur » pour les administrateurs (de rubriques et généraux) (merci à Litteul Kevin pour son icone nettement plus « classe » que mes pauvres bidouillages...)
Du point de vue de la base de données, ce plugin installe 3 tables supplémentaires : spip_accesgroupes_auteurs, spip_accesgroupes_acces et spip_accesgroupes_groupes, sachant que grâce au nouveau système de gestion des requètes MySQL par le core de spip 1.9 (« SPIP est grand et ses codeurs sont mes prophètes ! »), le préfixe ’spip’ sera automatiquement remplacé par le préfixe des tables que vous avez défini dans votre fichier /ecrire/mes_options.php (variable $table_prefix) si vous gérez plusieurs spip avec une seule base de données.
[*ATTENTION !!!*]
- ce plugin n’est PAS compatible avec le plugin « acces restreint » puisqu’il surcharge les mêmes fonctions que lui pour le filtrage des BOUCLES (affichage de l’espace public) : si celui-ci est actif, vous devez d’ABORD le désactiver (la vérification n’est pas gérée par le plugin) !!!
- Si vous procédez à une mise à jour depuis une version antérieure dans le cas ou votre spip serait passé de la version 1.8 (où vous utilisiez la version 0.7 ou 0.61 de la contrib originale) à la 1.9, vous devez d’ABORD procéder à la mise à jour des tables utilisées. Pour cela connectez vous sur le script /plugins/acces_groupes/maj_tables.php qui permet de « patcher » les tables à partir de celles de la version 0.7 ou 0.61. Ce script est extrèmement sommaire [1] et vous demandera de saisir les paramètres de connexion à votre base de données MySQL pour éviter que n’importe qui puisse le lancer. Une fois ce script joué, vous pouvez effacer le fichier maj_tables.php.
4. Fonctionnement obtenu lorsque l’on intègre ce plugin :
- pour un internaute qui n’est pas authentifié toutes les rubriques restreintes (ce qui inclus les sous rubriques, les articles, les brèves, les liens ...) seront [v1.0] invisibles à ce visiteur dans la partie publique.
-
pour un visiteur authentifié, seules les rubriques restreintes auxquelles il n’a pas accès (via son appartenance à un groupe ou son statut) seront invisibles.
-
pour les auteurs authentifié : idem les visiteurs pour la partie publique,
Message obtenu lors de l’accès à une rubrique restreinte dans l’espace privéen revanche pour la partie privée, les rubriques à accès restreint sont (pour l’instant !) visibles mais non accessibles.
-
pour les administrateurs de rubriques (« admin restreint ») : 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éé (= dont il est le « propriétaire »).
-
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 :
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 un 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 du SPIP (restreints ou généraux) 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 des groupes et des rubriques restreintes :
- 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 (exec=accesgroupes_admin) intègre :
- l’affichage de la liste des groupes et des rubriques qu’ils contrôlent
- l’arborescence des groupes/sous-groupes.
-
Configuration de l’accès restreint pour une rubriqueChaque rubrique à accès restreint peut être configurée pour que la restriction porte soit 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 ou pour un admin de rubrique dans une rubrique qu’il administre) 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 »
-
Un groupe dont l’admin restreint est « propriétaire »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.
-
Changer de propriétaire un groupe[v1.0] Pour simplifier la vie des admins de rubriques, un admin général peut créer un groupe, lui attribuer des rubriques en accès restreint puis transférer la « propriété » de ce groupe à un admin de rubrique : celui-ci pourra alors gérer ce groupe comme s’il l’avait créé lui même.
-
Configurer la possibilité d’une demande d’intégration au groupeChaque groupe peut être configuré pour permettre aux utilisateurs n’ayant pas le droit d’accès à une rubrique d’envoyer un message au propriétaire du groupe demandant leur intégration dans celui-ci. Cette situation va se rencontrer principalement dans l’espace privé (les rubriques restreintes étant visibles dans les listes de rubriques/sous-rubriques) mais également dans l’espace public pour un utilisateur qui suivrait un lien vers une rubrique protégée (si le squelette le prévoit, cf « Type de filtrage et squelette » ci-dessous).
Le formulaire de demande d’inscription à un groupeCe paramètre permet d’afficher un formulaire de demande d’inscription dans le groupe lorsque l’utilisateur ne peut accéder à une rubrique. Ce message sera consultable par le propriétaire du groupe (si c’est un admin de rubrique) ou par n’importe quel admin général (si le groupe est créé par un admin général) dans la messagerie de l’interface privée, il comporte un lien direct vers l’interface de gestion du groupe concerné.
Un auteur ayant demandé à être intégré à un groupeLes auteurs en attente d’intégration sont listés dans cette interface et peuvent être intégrés ou rejetés en un clic.
[v1.0] Lorsque le propriétaire du groupe aura rejeté ou accepté la demande d’inscription de l’auteur, le message de demande sera automatiquement effacé.
Type de filtrage et squelette :
[v1.0] Etant donné que ce plugin filtre directement les BOUCLES qui génèrent le contenu de l’espace public rendant invisibles celles qui sont restreintes pour un utilisateur non-authentifié, vous avez le choix entre 2 types de filtrages :
- Un filtrage fort : pas d’indication qu’un contenu existe mais qu’il n’est pas accessible (page 404 si un utilisateur non-autorisé essaye d’accéder directement au contenu d’une rubrique restreinte, par ex en suivant un lien ou un signet de son bookmark). Si vous ne souhaitez pas modifier votre squelette, c’est cette solution qui sera retenue par défaut.
Pour rendre les choses plus ergonomiques, vous devriez donc avoir un lien ’S’identifier’ générique sur tout le site, qui permet aux personnes habilitées de se connecter pour accéder au contenu. Pour cela utilisez par exemple la balise #LOGIN_PUBLIC (cf cet article de spip-contrib pour plus d’infos).
-
Formulaire d’identificationUn filtrage avec information : si l’internaute essaye d’accéder au contenu d’une rubrique restreinte alors il se retrouve sur une page l’informant qu’il est nécessaire de s’identifier pour accéder au contenu. Si une fois connecté il ne fait pas partie des utilisateurs autorisés, alors il aura éventuellement le formulaire de demande d’intégration au groupe (selon la config du groupe, cf paragraphe précédent).
formulaire de demande d’inscription (partie publique)Pour obtenir ce fonctionnement vous disposez des filtres « accesgroupes_article_restreint », « accesgroupes_rubrique_restreinte » et « accesgroupes_breve_restreinte » qui vous permettent d’intégrer dans vos squelettes des pages « article.html », « rubrique.html » ou « breve.html » le formulaire de #LOGIN_PUBLIC (si l’utilisateur n’est pas connecté) ou (selon config) le formulaire de demande d’accés.
Pour réaliser cette intégration dans ces pages, il vous suffit de rajouter aux BOUCLES principales de ces pages le code suivant (exemple pour la page article.html) :
<!-- fin du fichier = fin de la boucle générale de la page -- >
</BOUCLE_article_principal>
<!-- code à rajouter -- >
[(#ID_ARTICLE|accesgroupes_article_restreint|?{' ',''})<INCLURE{fond=inc_accesgroupes_login}{skel=#CHEMIN{inc_accesgroupes_login}}>]
<//B_article_principal>Comme le montre le code ci-dessus, vous ajoutez donc à la BOUCLE_article_principal (celle qui englobe TOUTE la page) une condition en cas de retour vide (cad en principe affichage de la page 404 : « page non trouvée ») qui permet d’INCLURE le fichier inc_accesgroupes_login.html (situé à la racine du répertoire /plugins/acces_groupes) dans le cas où l’absence de page est due à une restriction d’accès et non pas à une page vraiment absente.
La page inc_accesgroupes_login.html livrée avec le plugin est (volontairement) dépouillée, ce qui vous laisse la possibilité de la « customiser » selon vos goûts et votre charte graphique.
Fonctionnement du plugin :
Les filtrages des parties publiques et privée reposent sur 2 principes différents (pour l(instant !) :
- Pour la partie privée, peu de modifications par rapport aux versions précédentes de cette contrib : on vérifie dans les pages de gestion des articles (exec=articles et exec=articles_edit) , rubriques (exec=naviguer et exec=rubriques_edit) et breves (exec=breves_voir et exec=breves_edit) si l’élément dont on affiche la page id_article=xxx par ex) fait partie d’une rubrique à accès restreint (en fonction de l’id_auteur et de son appartenance aux groupes/statuts) et si c’est le cas on envoie le message de restriction d’accès : jusque là rien de bien compliqué...
- [v1.0] Pour la partie publique les choses se compliquent puisqu’il faut gérer le cache... Et pour « rendre à César ce qui appartient à César » il me faut ici remercier Cedric Morin pour son système de filtrage mis au point pour le plugin « accès retreint » qui permet de surcharger directement les requêtes SQL des BOUCLES de spip. Cela permet donc d’exclure des résultats renvoyés par la base de données tous les éléments appartenant à une rubrique à laquelle l’utilisateur n’a pas accès (soit il n’est pas connecté, soit il ne fait pas partie d’un groupe autorisé). Ce code est bien évidemment adapté au fonctionnement par groupe (alors que le plugin "accès restreint fonctionne par zones) mais reste le même dans son principe de filtrage. Je cite donc textuellement l’explication donnée par l’inventeur de ce système cf doc du plugin Accès restreint :
« L’intérêt de cette démarche, c’est qu’elle fonctionne sur toutes les boucles, donc tout le site se trouve instantanément sécurisé sans aucune modification de squelette. Il n’y a pas de risque d’oublier un morceau.
Ce plugin nous garantie l’absence de fuite liée a de nouvelles fonctionnalités de SPIP (comme les modèles de 1.9.1 qui seraient une belle faille pour ceux qui sécuriseraient du contenu au moyen des squelettes).
Le principe même de fonctionnement du plugin acces-restreint est de ’supprimer’ du résultat des boucles tout ce que le visiteur n’a pas le droit de voir. Ainsi les zones à accès réservées sont invisibles pour qui n’y est pas habilité.
N’ayez donc aucune crainte en ce qui concerne les robots, les moteurs de recherche, ou les fichiers de backend. Le filtre est infaillible.
Ce principe de fonctionnement permet au plugin de filtrer le contenu publié sans modification du squelette. Cela permet aussi d’avoir des menus (liste de rubriques) cohérents avec le contenu effectivement accessible. Bref c’est un parti pris, qui fait son efficacité même. »
Donc vous pouvez dormir sur vos deux oreilles : pas de fuites possibles !
Du point de vue du cache, pour minimiser son volume tout en obligeant le recalcul des pages selon les droits de l’utilisateur, (et en utilisant un principe toujours pompé sur le plugin accès restreint !), il sera créé un fichier de cache par combinaison de rubriques interdites : donc si un utilisateur affiche une page, celle-ci sera tirée du cache correspondant au groupe de rubriques auxquelles il a accès, ainsi là également, pas de risque d’indiscrétions.
Outils à disposition pour les squelettes :
[v1.0.2]Selon le type de site utilisant ce plugin il peut apparaître le besoin de vouloir afficher une liste intégrale des rubriques (ou articles, brèves) c’est à dire y compris les éléments à accès restreint qui sont normalement invisibles. La version [1.0.2] intègre donc le critère tout_voir qui permet de réaliser cela [2].
De façon complémentaire, si on utilise ce critère il est utile de pouvoir « marquer » par une icone les titres des éléments à accès restreints : le filtre |accesgroupes_visualise, utilisable sur les #BALISEs des boucles ARTICLES, RUBRIQUES ou BREVES, 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.
Exemple typique d’utilisation de ce critère et du filtre : modification du fichier inc-rubriques.html qui fait le menu latéral des rubrique de la dist :
<B_rubriques>
<div class="rubriques">
<h2 class="menu-titre"><:rubriques:></h2>
<ul>
<BOUCLE_rubriques(RUBRIQUES) {racine} {par num titre, titre}{tout_voir}>
<li>
<a href="#URL_RUBRIQUE"[ class="(#EXPOSE)"]>[(#TITRE|couper{80}|accesgroupes_visualise{#ID_RUBRIQUE})]</a>
<B_sous_rubriques>
<ul>
<BOUCLE_sous_rubriques(RUBRIQUES) {id_parent} {par num titre, titre}{tout_voir}>
<BOUCLE_test_expose(RUBRIQUES) {id_enfant}{tout_voir}>#EXPOSE{' '}</BOUCLE_test_expose_total>
<li><a href="#URL_RUBRIQUE"[ class="(#EXPOSE)"]>[(#TITRE|couper{80}|accesgroupes_visualise{#ID_RUBRIQUE})]</a>
<BOUCLE_re(BOUCLE_sous_rubriques){tout_voir}></BOUCLE_re>
</li>
</B_test_expose>
</BOUCLE_sous_rubriques>
</ul>
</B_sous_rubriques>
</li>
</BOUCLE_rubriques>
</ul>
</div>
</B_rubriques>Remarque : le paramètre #ID_RUBRIQUE du filtre accesgroupes_visualise est obligatoire !
Si l’image (cadenas) utilisée ne vous plait pas, ce filtre vous offre la possibilité de choisir un autre fichier image en passant le nom de ce fichier en second paramètre du filtre. Exemple pour utiliser le fichier cadenas-petit.png placée dans le répertoire /img de votre dossier de squelette :
[(#TITRE|couper{80}|accesgroupes_visualise{#ID_RUBRIQUE, #CHEMIN{img/cadenas-petit.png}})]Ce qu’il reste à faire :
- Ainsi que je le mentionne par 2 fois plus haut, l’idée pour la suite des développements est de réaliser un filtrage complet de l’espace privé afin que, comme pour l’espace public, un utilisateur ne voit que les rubriques auxquelles il à accès. Cela concernerait donc la liste des rubriques affichées dans la page d’accueil de /ecrire, les sous-rubriques affichées dans /exec=naviguer, les rubriques et articles affichés dans /exec=articles_tous, le navigateur rapide de rubriques du bandeau et surtout le mini-navigateur ajax de choix de la rubrique lors de la création d’un article ou d’une sous-rubrique (afin d’empécher un auteur de créer un article dans une rubrique à laquelle il n’a pas accès, ce qui, dans cette version, l’empèche ensuite d’y accéder dès qu’il l’a enregistré une fois).
- comme suggéré dans ce message du forum, la prochaine version devrait intégrer des groupes basés sur l’adresse IP du poste connecté (groupe = plages d’adresses IP)
Cela permettra de gérer des restrictions d’accès différents selon que l’accès au spip se fait depuis l’intranet ou internet ou selon le sous-réseaux de l’intranet etc...
Pour cette partie, soyez patients : on y travaille !
- comme suggéré par le forum public de la version précédente de cette contrib on pourrait aussi imaginer :
- que les restrictions d’accès puissent s’appliquer au niveau des articles (et pas seulement au niveau des rubriques)
- que les groupes puissent êtres récupérés à partir d’un LDAP
Pour ces 2 points, on y travaille PAS mais toutes les bonnes volontées sont les bienvenues... et comme pour beaucoup d’autres plugins, afin de faciliter le developpement collaboratif, vous trouverez l’ensemble des fichiers en cours sur le SVN de spip-zone !
- et, bien sûr, toutes les traductions du fichier de langue sont également les bienvenues (le fichier accesgroupes_en.php livré avec cette version est super incomplet...)
Discussions par date d’activité
146 discussions
Bonjour,
Le plugin marche bien ... mais
pour les groupes de statut « visiteur » dès que l’un a un accès, tous les autres l’on aussi sans qu’il aie un groupe les regroupant.
J’ai installé la version 1.0.31 avec SPIP 1.9.2
Merci de votre aide.
Kos
Répondre à ce message
Bonjour
J’ai bien installé le plugin et il est fonctionnel.
Mon souci : je ne vois pas lien pour s’inscrire à gauche.
Mon squelette est sarka spip.
J’ai pourtant coché les cases comme il faut.
Quel peut-être le souci ?
Mon site :
http://snec.cftc.acnantes.free.fr
Répondre à ce message
Bonjour,
J’ai un pb quand j’installe le plugin acces restreints par groupe.
Des erreurs apparaissent dans le fichier mysql.log lors de son installation du
Vous trouverez ci-dessous une copie de ce fichier.
Le pb disparait dès que je désactive ce plugin...
Je suis en 1.9.2d et j’utilise le squelette biospip
Voici la liste des autres plugins installés :
article_pdf
barre_typo_rubriques
barre_typo_v2
boutons_admin_supp
boutonstexte
cfg
couteau_suisse
dw2
enluminures_typographiques_v2
enviar_email
gestion_documents
icone_prive
imprimir_documento
outils_article
panoramas
pdf
sauver_config
sitemap
spip-listes
statistiques_publication
thickbox2
widget_calendar
A noter que ces erreurs apparaissent sans même qu’il y ait de visite
dans la partie public du site.
Merci pour votre aide
Boby
Jul 01 14:12:33 82.229.204.186 (pid 19833) GET
/spip/spip.php ?action=cron
Jul 01 14:12:33 82.229.204.186 (pid 19833) - SELECT count(*) AS nb_acces
FROM
eco2scop.spip_accesgroupes_accesLEFT JOIN
eco2scop.spip_accesgroupes_groupesON
eco2scop.spip_accesgroupes_acces.id_grpacces =eco2scop.spip_accesgroupes_groupes.id_grpaccesWHERE id_rubrique = 4
AND actif = 1 AND prive_public != 1
Jul 01 14:12:33 82.229.204.186 (pid 19833) 1146 Table
’eco2scop.spip_accesgroupes_acces’ doesn’t exist
Jul 01 14:12:33 82.229.204.186 (pid 19833) GET
/spip/spip.php ?action=cron
Jul 01 14:12:33 82.229.204.186 (pid 19833) - SELECT count(*) AS nb_acces
FROM
eco2scop.spip_accesgroupes_accesLEFT JOIN
eco2scop.spip_accesgroupes_groupesON
eco2scop.spip_accesgroupes_acces.id_grpacces =eco2scop.spip_accesgroupes_groupes.id_grpaccesWHERE id_rubrique = 6
AND actif = 1 AND prive_public != 1
Jul 01 14:12:33 82.229.204.186 (pid 19833) 1146 Table
’eco2scop.spip_accesgroupes_acces’ doesn’t exist
Jul 01 14:12:33 82.229.204.186 (pid 19833) GET
/spip/spip.php ?action=cron
Jul 01 14:12:33 82.229.204.186 (pid 19833) - SELECT count(*) AS nb_acces
FROM
eco2scop.spip_accesgroupes_accesLEFT JOIN
eco2scop.spip_accesgroupes_groupesON
eco2scop.spip_accesgroupes_acces.id_grpacces =eco2scop.spip_accesgroupes_groupes.id_grpaccesWHERE id_rubrique = 4
AND actif = 1 AND prive_public != 1
Jul 01 14:12:33 82.229.204.186 (pid 19833) 1146 Table
’eco2scop.spip_accesgroupes_acces’ doesn’t exist
Jul 01 14:12:33 82.229.204.186 (pid 19833) GET
/spip/spip.php ?action=cron
Jul 01 14:12:33 82.229.204.186 (pid 19833) - SELECT count(*) AS nb_acces
FROM
eco2scop.spip_accesgroupes_accesLEFT JOIN
eco2scop.spip_accesgroupes_groupesON
eco2scop.spip_accesgroupes_acces.id_grpacces =eco2scop.spip_accesgroupes_groupes.id_grpaccesWHERE id_rubrique = 6
AND actif = 1 AND prive_public != 1
Jul 01 14:12:33 82.229.204.186 (pid 19833) 1146 Table
’eco2scop.spip_accesgroupes_acces’ doesn’t exist
Jul 01 14:12:33 82.229.204.186 (pid 19833) GET
/spip/spip.php ?action=cron
Jul 01 14:12:33 82.229.204.186 (pid 19833) - SELECT count(*) AS nb_acces
FROM
eco2scop.spip_accesgroupes_accesLEFT JOIN
eco2scop.spip_accesgroupes_groupesON
eco2scop.spip_accesgroupes_acces.id_grpacces =eco2scop.spip_accesgroupes_groupes.id_grpaccesWHERE id_rubrique = 4
AND actif = 1 AND prive_public != 1
Jul 01 14:12:33 82.229.204.186 (pid 19833) 1146 Table
’eco2scop.spip_accesgroupes_acces’ doesn’t exist
Jul 01 14:12:33 82.229.204.186 (pid 19833) GET
/spip/spip.php ?action=cron
Jul 01 14:12:33 82.229.204.186 (pid 19833) - SELECT count(*) AS nb_acces
FROM
eco2scop.spip_accesgroupes_accesLEFT JOIN
eco2scop.spip_accesgroupes_groupesON
eco2scop.spip_accesgroupes_acces.id_grpacces =eco2scop.spip_accesgroupes_groupes.id_grpaccesWHERE id_rubrique = 7
AND actif = 1 AND prive_public != 1
Jul 01 14:12:33 82.229.204.186 (pid 19833) 1146 Table
’eco2scop.spip_accesgroupes_acces’ doesn’t exist
Jul 01 14:12:33 82.229.204.186 (pid 19833) GET
/spip/spip.php ?action=cron
Jul 01 14:12:33 82.229.204.186 (pid 19833) - SELECT count(*) AS nb_acces
FROM
eco2scop.spip_accesgroupes_accesLEFT JOIN
eco2scop.spip_accesgroupes_groupesON
eco2scop.spip_accesgroupes_acces.id_grpacces =eco2scop.spip_accesgroupes_groupes.id_grpaccesWHERE id_rubrique = 7
AND actif = 1 AND prive_public != 1
Jul 01 14:12:33 82.229.204.186 (pid 19833) 1146 Table
’eco2scop.spip_accesgroupes_acces’ doesn’t exist
Jul 01 14:12:33 82.229.204.186 (pid 19833) GET
/spip/spip.php ?action=cron
Jul 01 14:12:33 82.229.204.186 (pid 19833) - SELECT count(*) AS nb_acces
FROM
eco2scop.spip_accesgroupes_accesLEFT JOIN
eco2scop.spip_accesgroupes_groupesON
eco2scop.spip_accesgroupes_acces.id_grpacces =eco2scop.spip_accesgroupes_groupes.id_grpaccesWHERE id_rubrique = 10
AND actif = 1 AND prive_public != 1
Jul 01 14:12:33 82.229.204.186 (pid 19833) 1146 Table
’eco2scop.spip_accesgroupes_acces’ doesn’t exist
Jul 01 14:12:33 82.229.204.186 (pid 19833) GET
/spip/spip.php ?action=cron
Jul 01 14:12:33 82.229.204.186 (pid 19833) - SELECT count(*) AS nb_acces
FROM
eco2scop.spip_accesgroupes_accesLEFT JOIN
eco2scop.spip_accesgroupes_groupesON
eco2scop.spip_accesgroupes_acces.id_grpacces =eco2scop.spip_accesgroupes_groupes.id_grpaccesWHERE id_rubrique = 4
AND actif = 1 AND prive_public != 1
Jul 01 14:12:33 82.229.204.186 (pid 19833) 1146 Table
’eco2scop.spip_accesgroupes_acces’ doesn’t exist
Jul 01 14:12:33 82.229.204.186 (pid 19833) GET
/spip/spip.php ?action=cron
Jul 01 14:12:33 82.229.204.186 (pid 19833) - SELECT count(*) AS nb_acces
FROM
eco2scop.spip_accesgroupes_accesLEFT JOIN
eco2scop.spip_accesgroupes_groupesON
eco2scop.spip_accesgroupes_acces.id_grpacces =eco2scop.spip_accesgroupes_groupes.id_grpaccesWHERE id_rubrique = 10
AND actif = 1 AND prive_public != 1
Jul 01 14:12:33 82.229.204.186 (pid 19833) 1146 Table
’eco2scop.spip_accesgroupes_acces’ doesn’t exist
effectivement je me rend compte que j’ai le même genre d’erreurs dans le mysql.log de mon site de test !
Je vais donc regarder de quoi il s’agit et essayer de trouver où se situe le bogue...
merci pour la détection du problème, je te préviendrais via ce forum lorsqu’il y aura du nouveau
Répondre à ce message
Bonjour
Bravo, travail très interessant : mise en place immédiate et facile, avec la documentation des articles de référence bien commodes.
J’ai eu juste un souci, ce qui fait AMHA que le plugin n’est pas encore utilisable sauf « plug and pray » ;-)
De façon un peu bestiale, j’avais encadré tous mes squelettes (article, rubrique,etc..) par une boucle contextuelle.
Quelle ne fut pas ma surprise de tomber sur des pages magnifiquement blanches lors des tests en utilisateur « normal » (c-a-d non connecté) !!
- Bon, j’ai rapidement tourné la difficulté en rajoutant un lien vers le sommaire dans la partie optionnelle de la boucle (recopié ci-dessous pour la fin d’une page Rubrique).
Mais -idée- ce serait peut-etre plus facile d’apporter un lien automatique vers une 404 quand Spip ne rend rien dans la boucle.....
@suivre
Y
PS une petite remarque (j’étais connecté en Rédacteur sur spip-contrib ), il me semble aujourd’hui que le formulaire de réponse ait un pb. pour la description des champs (texte affiché à « Null » dans les champs au-dessus du titre et du texte).?...
Ca n’est pas normal : ta page blanche correspond à une erreur php quelque part dans ton squelette / fichier(s) d’options/fonctions...
C’est effectivement *déja* le comportement par défaut de ce plugin, donc ce que tu devrais obtenir si ton squelette ne faisait pas planter le truc !
Houps, effectivement, une erreur sur l’orthographe de la balise ’obligatoire’ #INSERT_HEAD
Merci de m’avoir donné -si rapidement repondu- et l’occasion de le voir...
Répondre à ce message
Bonsoir,
Je viens d’installer ce super plugin qui me sera très utile et je salue le développement qui as dut être bien complexe.
J’ai vu dans votre roadmap que vous ne travaillez pas sur la restriction niveau articles, hors cela m’intéresse énormément, je voudrais savoir si vous l’avez intégrer dans votre développement futur ou si ce n’était toujours pas d’actualité et si c’est le cas est ce difficile de le mettre en oeuvre ?
Je veux bien m’en occuper mais n’ayant qu’une connaissance limitée du PHP, de MySQL mais surtout du système SPIP (encore un peu flou pour ma part) j’ai peur de ne pas y arriver si cela est trop complexe !
Merci d’avance.
Pour l’instant on en est pas du tout là : voir le point sur la situation fait dans ce forum : http://www.spip-contrib.net/Acces-r....
Le problème est que si tu bosse sur la version actuelle, il y a tellement de truc qui vont changer que ça risque d’être à refaire...
Ceci dit, si tu es malgré tout motivé, la zone est ouverte à tous : si tu fais une version qui intègre cette fonctionnalité sans régression des autres, ça sera toujours un point de départ pour l’intégrer dans la fusion accès_restreint/accès_groupes.
Merci de ta réponse.
Je vais essayer de m’y coller car j’en ai vraiment besoin, et j’ai pas envie de faire un fouillis impossible à créer des rubriques pour chaque article que je veux protéger.
Allez soyons fou je vais tenter de mettre les mains dans le cambouis...
;)
Re,
J’ai essayer de modifier la contrib’ et c’est pas gagné je crois que mes connaissances sont trop limitées pour pouvoir ajouter la restriction aux articles...
Désolé, mais ça dépasse mes compétences :(
Répondre à ce message
Bonjour et merci d’avance à ceux qui voudront bien m’aider ;)
Alors voilà je vous expose mon problème :
J’ai installé spip 1.9.2d (avec un squelette, le durzy 0.8.3.9 qui semble compatible) et avec les plugins suivants :
acces restreint par goupe (version 1.0.2)
activité du jour (version 1.55)
agenda pour spip 1.9.2 (version 0.14)
cfg : moteur de configuration (version 1.3.8)
le couteau suisse (version 1.7.16.12)
crayons (version 0.9)
deplier-replier blocks (version 0.2)
dw2 (version 2.14)
ratelier (version 0.1)
squelette par mot clef (version 0.1)
widget calendrier (version 0.11)
Tout se passe bien dans la partie publique, mais c’est dans la partie privée que se pose le problème.
J’affiche l’arborescence du site dans le but de créer une nouvelle rubrique ou un nouvel article. Et quand je clique sur « Racine du site », j’ai le message d’erreur suivant :
Fatal error : Call to undefined function : acces_rubrique() in /racine du site/plugins/acces_groupes/inc/accesgroupes_prive.php on line 991
Et voici ce qu’il y a à la ligne 991 de ce fichier php.
$flag_editable = ($connect_statut == ’0minirezo’ AND (acces_rubrique($id_parent) OR acces_rubrique($id_rubrique))) ; // id_parent necessaire en cas de creation de sous-rubrique
Si vous avez déjà eu le cas et que vous connaissez la réponse, merci infiniment de me la communiquer.
JP
Je fais comme tout le monde : je me réponds à moi-même puique j’ai trouvé la solution moi-même ;))
J’ai tout simplement remplacé le plugin acces restreint par sa version plus récente à savoir la version 1.0.31
et... ça marche
Répondre à ce message
Bonjour,
Comment faire pour que les articles en zone à accès restreint par groupe ne se retrouvent pas dans la liste des nouveautés du site gérée par SPIP et envoyée régulièrement ?
J’utilise le plug in avec beespip. L’utilisation du mot clef « exclu actualité » ne résoud pas le problème. Un paliatif consiste à changer la date de l’article (l’année par exemple) mais cela n’est pas très propre...
De quelle liste des nouveautés parles-tu ? De la liste des derniers articles publiés lorsque tu as l’option « Annonce des nouveautés » activée dans la page « Interactivité » de la configuration du site ?
Si c’est le cas, cette fonctionnalité n’est effectivement pas prise en compte dans le fonctionnement du plugin.
Alors soit tu code l’ajout de cette fontionnalité, soit tu continue à bidouiller avec les dates : la zone est ouverte à tous, c’est toi qui choisit la solution que tu préfère !
Oui c’est bien de cette liste dont je parle.
Je prends bonne note des deux solutions proposées :-).
J’en ai une troisième : je pense que je vais m’envoyer à moi rien qu’à moi la liste des nouveautés et que je la forwarderai après filtrage « manuel » sur une liste de diffusion de type newsletter...
dans le même ordre d’idée, j’imagine qu’il doit être possible de faire un « patron » avec le plugin spip_liste qui permettrait d’envoyer la liste des nouveautés en prenant en compte ce problème d’autorisations et ce de façon automatisée (sans intervention manuelle ni bidouilles de dates).
Répondre à ce message
Je n’arrive pas à supprimer un sous-groupes inclus dans un groupe.
quand je clique sur « Retirer le sous-groupe »,
J’ai message « Vous devez choisir un groupe ».
Je suis sous SPIP 192 est acces rectreint par groupe 103.
Merci de votre aide
Kos
OK, c’était un micro-bogue dans l’URL du lien de suppression. Corrigé par la version 1.0.31.
si tu veux éviter de mettre à jour tout le plugin, il te suffit de mettre à jour uniquement les fichiers plugin.xml et /exec/accesgroupes_admin.php
Merci pour la remontée de bogue !
Merci beaucoup, vous êtes des seigneurs. J’ai juste recopié tout le repertoire acces_groupes (annule et remplace) pour prendre en compte les éventuelles révision de la version 1.0.3. Je n’ai pas refait une instal normale via l’espace privé, Est-ce sans danger ?
Répondre à ce message
bonjour Voici mon problème
Il y a des rubriques dans le portail. Dès lors qu’on s’authentifie, on a accès à certains rubriques et pas à d’autres. Le problème est que malgré les bonnes declarations, les nouveaux users ne voient pas une rubrique. Donc à comparer leur profil avec ceux qui ont bien accès, je me suis rendu compte qu’il y a un champ ( attribut) ldap qui leur manquait. Si je leur ajoute cette dernière, ils ont accès à la rubrique. Mais le problème, c’est que mon responsable ne veut plus de ce champ car il ne doit plus exister. Donc je deduis donc qu’il y forcement un test sur ce champ. Moi je souhaiterais orienter le test sur un autre champ. Je crois que mon prédécesseur à supprimer le champ dans le formulaire de déclaration des users sans modifier son code.
Pouvez vous m’aider ??
Merci d’avance
de ce que je comprend de ta « description » du problème (qui reste assez incomplète/peu claire), il semblerait que ton système de contrôle d’accès ne soit pas basé sur ce plugin, ou sur une version modifiée pour gérer LDAP.
Peux tu vérifier dans le gestionnaire de plugins de ton spip (.../ecrire/ ?exec=admin_plugin) que le plugin accès_groupes est installé et activé ?
Si oui, précise l’organisation des groupes et des rubriques qu’ils contrôlent pour qu’on ait plus d’infos sur la nature du problème.
Bonjour,
Merci de me repondre.
Je confirme que le plugin est bien installé et activé.
Dans la partie rubrique gérées par les groupes de l’espace privé, j’ai Projet -> 3 espace equipe. et d’autres....
La rubrique qui pose problème c’est « Espace equipe ».
Ma question : Comment permettre aux user de voir cette rubrique ???.
Car auparavant mon responsable m’a dit que tout marchais bien. C’est à dire que les user declaré en tant qu’appartenant au groupe « TMA » inclut dans projet doivent voir la rubrique « espace equipe »
Je reste à votre dispo pour apporter toutes autres précision
il faut donc que tu vérifie :
Si ces vérifications sont OK, il te faut savoir aussi que lorsque tu viens d’ajouter des utilisateurs à un groupe, les modifications d’affichage pour leur compte nécessitent que les pages soient recalculées (sinon, spip te sert les pages du cache c’est à dire avant que les modifications aient été faites...).
Un moyen simple pour vérifier que ce n’est pas ce problème que tu rencontre consiste à vider le cache via l’interface d’administration chaque fois que tu as modifié les groupes.
Enfin si le problème persiste et qu’il est résolu via une modification du LDAP cela veut dire que tu as une version « bidouillée » de ce plugin pour assurer le support du LDAP et dans ce cas je ne peux rien pour toi (si ce n’est te demander de m’envoyer ta version pour une éventuelle intégration de cette fonctionnalité dans une prochaine version du plugin...)
Bonjour,
*) Dans la partie privée : « Arborescence des sous groupes », j’ai bien le groupe TMA et le groupe projet.
Pour le groupe projet, j’ai bien le Groupe TMA qui y appartient.
*) Dans « Rubrique gérées par groupes », « Espace equipe » appartient bien au groupe « projet » et j’ai « Management » qui appartient à « TMA ».
Or « Management » est la première sous rubrique de la rubrique « Espace equipe »
Est ce normal ???
*) C’est dans le formulaire d’ajout de nouvel user qu’on sélectionne l’entité dans laquelle appartient l’user.
Apparement, autrefois, en plus de sélectionner l’entité auquel appartient l’user, il y avait un champ « pôle ». Si la valeur est « TMA », alors l’user à accès à la rubrique « espace equipe ». une fois le formulaire validé, il ecrit dans la base ldap et dans les tables spip
Mon prédécesseur à supprimer ce champ car il y a une certaine redondance de l’information. je m’explique : Certaines entités auxquels appartient un user sont tous inclus dans TMA.
Il a donc supprimé le champ « pole » dans le formulaire et a oublié de mettre à jour son programme. D’où quand on déclare les users il ne voient pas la rubrique « espace equipe » malgré leur appartenance aux bonnes entités.
Comment puis procéder pour corriger ???
Merci d’avance pour votre aide
C’est possible, « normal » ça dépend de ce que tu veux avoir comme niveaux d’accès aux rubriques. Cette configuration groupes/rubriques signifie que :
Ce plugin n’a jamais eu de champ « pôle » : ta version est « bidouillé » => sur cette fonctionnalité, tu dois te débrouiller avec l’auteur de la bidouille...
Ca c’est obligatoirement le cas vu ton architecture : tout utilisateur du groupe « TMA » fait partie du groupe « Projet » (puisque « TMA » est inclu dans « Projet ») et à accès à l’ensemble de la rubrique « Espace équipe ».
Non, ce plugin n’a jamais proposé de fonctionnalité de modification de LDAP... Idem : si ta version le propose, tu dois te débrouiller avec l’auteur de cette « bidouille » (et par la même occasion lui demander si il ne veut pas la proposer sur spip-zone que d’autres puissent en profiter...)
Répondre à ce message
Bonsoir,
Je vous décrit ce qui m’arrive avec ce plugin et un spip 192b avec lequel je fais des tests pour développer un site communautaire.
J’ai une rubrique secteur qui a 6 rubriques enfants. La rubrique parent(secteur) et donc les 6 enfants sont en accès restreint, par héritage, par un groupe composé d’un administrateur.
L’une des 6 enfants est en accès restreint par un groupe composé d’un rédacteur. Celui ci, lors de la rédaction d’article, ne peut pas choisir de rubrique dans laquelle mettre l’article car le champ destiné à cela est totalement vide. Pas même la rubrique que son groupe contrôle. Après, lors de l’enregistrement, on sort de l’administration et on est renvoyé à la page d’accueil.
Est ce un bug ou simplement une mauvaise utilisation de ma part du plugin ?
merci d’avance pour vos retours !
Bonjour, j’ai aussi le même type de problème ( c.a.d. qu’un rédacteur pourtant déclaré dans un groupe ne peut pas rédiger un article car le nom de la rubrique, sous « Nouvel Article », dans laquelle il est autorisé à rédiger n’apparaît pas ) mais uniquement chez mon hébergeur (Free) car en local ça marche très bien !?!?!?
Please help me :)
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 :
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.
Suivre les commentaires :
|
