Admin pages and sections for specific editors

1

Hi all, my first post here.

I’ve used Grav on one of our corporate sites. After evaluating a number of CMS’s, I settled on Grav and recommended it to my boss and the rest of my team. I might now be in trouble!

One of the essential features we need is to allow different content editors access to different pages and content within those pages. For example, our technical team will write and edit blog posts, our marketing guys will add news stories and press releases, our developers will add API functionality etc. etc. When I read about Grav I misunderstood the information about denying content to particular users. I thought this meant administrators, but clearly it doesn’t.

We’ve invested a large number of man-weeks converting one of our sites into Grav. Adding this last bit of functionality would, I thought, be trivial, but it looks like it’s not possible. My boss is not going to be happy with me when I tell him this can’t be done. Eeeek!

Is there a plugin that will do this that I might have overlooked? If not, how difficult would it be to write a plugin that removed areas of the admin pages from the admin plugin for “editor” users? I’m comfortable writing PHP but looking through the Admin plugin files makes me realise I have very little idea of how Grav itself is actually set up.

Lastly, would anyone be willing to write a plugin to do this? Some idea of time/cost would be very useful.

Thanks all…

2

Someone started writing a plugin for this recently. I’m not sure how mature it is yet: https://github.com/weknowinc/grav-plugin-permissions

Also check out Groups and Permissions in the docs, though that seems related to viewing resources only.

If you need the unreleased plugin developed further and the authors can’t be bribed, I’ll be happy to give you a rough quote. I’m certainly interested in this capability myself.

3

Hi hughbris,

thanks for the reply and the links. I’d already looked at that permissions plugin but I have no idea what it does!

Anyway, since posting yesterday, I think I’ve managed to fudge together something that works for me:

Add (or edit) a blocked_access property in the user’s yaml file such as

blocked_access:
  - blogs

In <grav site>/users/accounts/<user name>.yaml

(you may need to logout and login again for this change to show up in the admin panel, or indeed, for it to affect visible pages)

then, in the page or module you want to block, add (or edit) an access_categories attribute to the metadata, such as:

metadata:
  access_categories:
    - blogs

Then edit the code in <grav-site>\user\plugins\admin\themes\grav\templates\pages.html.twig

Around the code block that creates the <li> tags that make up the page links, add

<!-- only show the content if it is not disallowed -->
{% set showContent = true %}
{% set accessCat = p.header.metadata.access_categories %}
{% for ac in accessCat %}
  {% for bc in grav.user.blocked_access %}
    {% if ac == bc %}
      {% set showContent = false %}
    {% endif %}
  {% endfor %}
{% endfor %}
{% if showContent %}
      
  < original code>

{% endfor %}

The original code starts
<li class="page-item" data-nav-id="{{ p.route }}">

That should be it. That user will no longer see that page (or section) in the admin area. Of course, if the editor knows the direct URL to a page in the admin panel, this won’t stop direct access, but the chances of that in my case are extremely slim. And if there is an update to the Admin plugin, this will get overwritten, so I need to keep a safe copy, but I think for now this serves my purpose and my boss need never know!

4

@GeorgeP Don’t forget there is a professional team, ready to help you if you really need to pay for an expertise : https://trilby.media

I totally understand your despair related to the delusion we can all face when discovering, afterward, that a feature isn’t existent in a technology.

You must also keep in mind, to avoid serious disappointments, that GRAV doesn’t work with databases, and that its main asset is to be a top-notch flat-file CMS !

Its main pros are :

  • Fast tree-file deployment
  • Fast configuration throught frontmatters
  • Fully customisable interface and backends features thanks to blueprints files

In a word : it’s fast, when used to it. But things like TWIG or markdown can let you down. Also, despite its facility, GRAV can takes some time to be tamed. It can be difficult to adapt classical web development to such a peculiar framework.

I hope you’ve evaluated all these points. :man_mechanic:

This being said, your need to tweak the admin panel to adapt it, can be fulfilled with already integrated solutions, like the blueprint area authorizes it : https://learn.getgrav.org/admin-panel/extending

It doesn’t require any plugin creation, as far as I know.