En attribuant le droit d'accès à un pprofile/groupe on obtient une
véritable gestion des droits d'accès par groupe.

Il faudrait remplacer la requête SQL lors d'une tentative d'accès à un
objet géré par accès restreint. Actuellement c'est sans doute une
vérification si l'id_auteur est listé dans la table de connexion d'accès
restreint. Quand on vérifie si l'auteur qui essaie d'accéder à un objet
(id_rubrique etc.) appartient à un groupe (id_profile) autorisé est un
petit peu plus compliqué mais cela doit être faisable même pour un
boulet comme moi ;-)

Je pense qu'il y a pas mal de travail quand on se met à modifier
l'interface d'accès restreint pour qu'il permette de gérer les profils
en plus des auteurs individuels, mais le code SQL nécessaire ne doit pas
être trop compliqué.

Ce qu'il ne faudrait pas faire c'est introduire des interdictions. On se
retrouverait avec des cas comme "l'auteur n'y a plus accès car il y a
droit indiviuellement mais un certain groupe dont il fait partie est
interdit d'accès". C'est le genre de bêtise qui te gâche la vie quand tu
vis dans le monde parano de chez MS. Tant qu'on n'attribue que des
autorisations positives il n'y a pas de problème, on n'aura jamais des
logiques contradictoires.

A la limite, si on veut éviter que des autorisations survivent par
inattention, il faudrait prévenir lors de la suppression d'un groupe que
certains auteurs du groupe gardent leur droit d'accès à cause d'une
autorisation individuelle.

Ou alors est-ce que je n'ai pas bien compris un truc ?

:-)k++



On 12.02.2018 10:39, RastaPopoulos wrote:
> Le 12/02/2018 à 10:23, klaus++ a écrit :
>> Génial - on aura enfin les groupes / profils d'utilisateurs
>> indispensables pour une utilisation "professionnelle" du plugin accès
>> restreint.
>>
>> Merci Rastapopoulos!
> 
> Je ne sais pas si c'est pareil et utile pour ce besoin, car le concept
> de Profil, c'est qu'on ne peut avoir qu'un seul profil pour un même
> compte. Alors que le concept de groupe d'utilisateurs dans tous les
> autres systèmes informatiques (notamment CMS mais pas que) ça a toujours
> été multiples : une même personne peut faire partie de plusieurs
> groupes. Ce n'est donc pas pareil que des "rôles" multiples (par ex dans
> Redmine, dans un projet on peut être "Manager" et "Développeur" et
> "Rapporteur" et ensuite ça cumule les droits).
> 
_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à  spip-...@rezo.net

Archives : https://www.mail-archive.com/spip@rezo.net/maillist.html

Infos : http://listes.rezo.net/mailman/listinfo/spip

Documentation de SPIP : http://www.spip.net/

Irc : de l'aide à toute heure : http://spip.net/irc

Répondre à