Grav-plugin-admin: Autorisations pour modifier et supprimer des pages

Créé le 21 avr. 2016  ·  16Commentaires  ·  Source: getgrav/grav-plugin-admin

Ce serait formidable si nous pouvions verrouiller certaines pages afin que les utilisateurs ne puissent modifier que des pages spécifiques, et non l'ensemble du site. Peut-être quelque chose en plus des groupes d'utilisateurs ?

Par exemple, il pourrait y avoir des autorisations par défaut, peut-être dans user/config/admin/admin.yaml (ou peut-être que cela aurait plus de sens dans les plans, ce qui permet de définir cette configuration en fonction du modèle) :

# Only admins can delete pages
permissions:
  pages:
    write: [admin, editor]
    delete: [admin]

Et la configuration YAML de chaque page pourrait écraser ces paramètres par défaut :

---
title: Awesome page
permissions:
  write: [admin] # Limit changes to the admin group in the admin plugin
  delete: [] # Protect this page from deletion from the admin plugin

---

Cas d'utilisation pour verrouiller une page

  • Si la structure de votre site repose sur quelques pages « conteneurs » (blog, section1, section2…) et que vous souhaitez éviter les suppressions inconsidérées de _tout le contenu_ d'une section en verrouillant les pages de niveau 1.
  • Si vous souhaitez protéger la page d'erreur ou d'autres pages "techniques".
  • Un site Web de communication d'entreprise où un éditeur ou un groupe d'éditeurs devrait pouvoir créer de nouveaux articles de blog, peut-être modifier la page racine "blog" mais PAS la supprimer, et ne devrait pas pouvoir modifier (et encore moins supprimer) d'autres pages dans d'autres sections (ou la page d'accueil).

    Types d'autorisation

Je pense qu'une implémentation simple pourrait être limitée à 2 autorisations :

  • écrivez
  • effacer

En excluant ces autres types d'autorisation courants (moins utiles ou plus difficiles à gérer) :

  • lire (le besoin de cacher le contenu aux utilisateurs administrateurs semble faible)
  • propriété de la page (écrire/supprimer vos "propres" pages) -> ajoute un grand niveau de complexité
  • addchild (contrôle si un groupe d'utilisateurs peut ajouter une page enfant à l'intérieur d'une page) -> ajoute également un peu de complexité
1.10 enhancement fixed in repo

Commentaire le plus utile

Quelques bonnes idées ici. En fait, j'avais déjà une note avec quelques idées sur la façon d'améliorer les autorisations. Je veillerai à ce que ce ticket soit également pris en compte. Merci!

Tous les 16 commentaires

Quelques bonnes idées ici. En fait, j'avais déjà une note avec quelques idées sur la façon d'améliorer les autorisations. Je veillerai à ce que ce ticket soit également pris en compte. Merci!

@rhukster Hey, je voulais juste savoir s'il y avait des progrès sur ce sujet que j'ai manqué ?

Pour un projet spécifique, j'ai besoin d'autorisations d'édition basées sur un groupe pour certaines pages ou pages d'un dossier. C'est la seule exigence qui pourrait potentiellement nous empêcher d'utiliser Grav 😞

Ce serait vraiment utile, si vous pouviez pointer dans la bonne direction, en faisant des recherches là-dessus.
Merci beaucoup d'avance pour votre aide.

Fonctionnalité la plus recherchée !

cogner

J'ai des élèves qui veulent travailler sur le site Web de notre école. En ce moment, ils ne font que me transmettre les informations à publier sur le blog ; il serait utile de pouvoir leur donner accès à des pages spécifiques afin que je n'aie pas à m'inquiéter qu'un étudiant modifie accidentellement ou délibérément la page d'accueil ou quelque chose d'autre d'important.

Merci - j'espère que des progrès sont réalisés sur cette fonctionnalité !!

Quand pouvons-nous aspect cette fonctionnalité. J'espère donc que ce sera dans la prochaine version. :-))

@brianjschott Vous pouvez consulter le plug- in Editable with SimpleMDE et tester s'il convient ou non à votre objectif. La dernière version prend en charge les autorisations basées sur les pages à l'aide du système d'utilisateurs et de rôles Grav. Ainsi, vous pouvez également créer des groupes. L'édition est limitée aux pages et à l'interface uniquement.

Je dois donner un accès éditorial à des utilisateurs non techniques, cela m'aiderait certainement à dormir la nuit ! :+1:

Des progrès à ce sujet? Fonctionnalité la plus recherchée.

Je travaille actuellement sur le support Flex Pages et j'ai déjà des autorisations pour supprimer des pages (bien que pour le moment sans support propriétaire).

Quelques bonnes idées ici. En fait, j'avais déjà une note avec quelques idées sur la façon d'améliorer les autorisations. Je veillerai à ce que ce ticket soit également pris en compte. Merci!

@rhukster plus de 3 ans se sont écoulés depuis votre commentaire. Certains de mes clients veulent vraiment cette fonctionnalité, mais nous, en tant que développeurs passionnés de Grav, n'avons toujours aucune information à ce sujet.

@mahagr Qu'est-ce que les pages flexibles ? C'est à propos de CSS Flexbox ou quelque chose de différent ? Merci de donner plus d'infos 😉

Les pages flexibles sont basées sur Grav Flex Objects, qui est juste un nom sympa pour les classes (vous pouvez les trouver dans Grav\Framework\Flex . :)

En bref, Flex Objects remplacera le plug-in Flex Directory ; les classes de base sont dans Grav lui-même, mais pour CRUD, vous aurez besoin du plugin Flex Objects, qui fournira des vues de liste et d'édition qui fonctionneront à la fois dans l'administration et dans le frontend. l'édition frontale ou si vous avez besoin de faire des classes/routages personnalisés pour le faire fonctionner. Quoi qu'il en soit, ce plugin n'est nécessaire que pour les tâches d'administration, Flex lui-même s'exécute sans lui.

Flex Pages en implémentation des Grav Pages actuelles, mais basées sur ces nouvelles classes Flex. L'utilisation de Flex présente quelques avantages par rapport à l'ancienne solution :

  • il conserve un index de tous les objets et sait quels objets ont été mis à jour et quand
  • à cause de l'index, les objets ne sont chargés qu'à la demande
  • il a une mise en cache intégrée pour les recherches de collection, les appels de méthode et même le rendu
  • la mise en cache est basée sur les objets, donc la mise à jour d'un seul élément n'invalide pas le cache des autres
  • les collections sont bien plus puissantes qu'avec les anciennes pages ; vous pouvez rechercher presque n'importe quoi
  • FlexPage est autonome et beaucoup plus facile à utiliser que Page
  • Flex vous permet de personnaliser facilement les pages selon vos besoins
  • Il vous permet de créer votre propre section d'administration, par exemple pour les articles de blog - séparée des autres pages
  • ...

Il y a encore plus d'avantages, mais nous les utilisons déjà dans certains de nos projets et tout le monde est tellement excité à ce sujet. On obtient facilement des performances 10 fois meilleures sur un site de 4000 pages. Nous pouvons créer des types personnalisés, même des pages qui sont stockées séparément des pages normales et qui se trouvent dans une section distincte de l'administration. Les utilisateurs peuvent créer leurs propres pages en remplissant des formulaires simples etc...

Merci beaucoup d'avoir partagé cette information @mahagr 👍 De tout ce que vous mentionnez (tout semble génial !), des collections de pages plus avancées, la personnalisation de page et une section d'administration distincte pour différents types de page m'intéressent le plus. Veuillez ajouter mon vote pour des autorisations de page plus fines, ce serait super précieux dans les scénarios éducatifs avec Grav !

Suite à ce post. J'en ai vraiment besoin en ce moment.

60153027-8420fb80-9815-11e9-831b-7a32f4f48f7b

J'apprécierais également cette fonction. Lié à ce problème d'amélioration ouvert .

Cela a déjà été implémenté dans Grav 1.7 / Admin 1.10

Cette page vous a été utile?
0 / 5 - 0 notes