Redirect user of specific role from panel home to specific panel page

I need to restrict editors to edit one page only.
The easiest way to do that would be redirecting from panel home to the page (if role == 'editor').

No idea how to do that. I tried:

  • using a route, but can’t intercept panel pages with a pattern.
  • with hooks, but did not find a hook that triggers on panel login. Also, I’d like to trigger the redirect whenever an editor tries accessing the panel homepage, not only after login.

Kirby 3.3.0 has a new user.login.after hook, you could try that, but not sure if you can achieve that with a hook.

Thaks @texnixe.
As mentioned earlier, I’d need to trigger the redirect every time an editor tries accessing the panel homepage, not only after login. This is because he/she might click on the site name in the panel breadcrumb.

Can anyone think of a way to do this with a route or some other sort of redirect?
:pray:

May be https://forum.getkirby.com/t/access-only-user-specific-or-template-specific-pages-in-panel/12263/8 can help you, if you can change your way to restrict the access to the panel for (a) particular role(s).

Thanks @HeinerEF, it’s a bit redundant and complicated to set up, but it could work.

Would still find it a lot easier if I could use routes within panel pages :confused:

I thought it could be done with a route.before hook, but that only works when reloading the page, not when clicking a link.

What you could try instead is log in the user from the frontend, reroute to the allowed page and use permissions and access hooks to prevent access to other parts of the Panel.

@texnixe,
I’m already using permissions to prevent access to some panel pages, and will probably end up using this approach.
The outcome is a bit dirtier since the user is prompted an error message when trying to access the forbidden page (e.g. :small_red_triangle:! The page “options” cannot be found).

Do you also get that if you set options in blueprints like this:

Title: Page hidden for editors
options:
  read:
    editor: false

This should actually hide all pages not available to editors even in the Dashboard. The extra site.yml is still the better alternative on top, because you can then create a nicer layout for this special use case.

If you implement the above hints from @texnixe with my link, you can use the default.yml file in the editor blueprint path to create a special error message. The prerequisite would be that for all pages, that the editor should edit, there is a separate *.yml file in his blueprint path.
The file site.yml is his start page in the panel, which can look completely different than e.g. for admins.
You can also hide unwanted entries in the top left menu for the editor, depending on your requirements.

@texnixe I tried that but the outcome didn’t seem consistent. I’ll try to explain better.
My site.yml has a single list of pages that should be accessible to editors

# site.yml
    ...
    sections:
      stories:
        type: pages
        parent: site.find('map')
        template: story

Till here all is good.
Then there needs to be an index of the pages of the site, visible only to admins. I tried two ways to obtain this.

Option A - Using a standard pages section

The pages are actually hidden to editors (by setting read to false for editors in the pages’ blueprints), but they can still see an empty list and can still create new pages.

# site.yml continues (A)
    ...
    sections:
    ...
      index:
        type: pages

I know I can use user blueprints to avoid creation, but then editors can’t create the only kind of pages they’re supposed to (new stories, that are children of page map).

Option B - Using a field of type pages

I manually added the pages to this field to create the index but they are still visible to editors even if in their blueprint I set read to false for editors.

# site.yml continues (B)
    ...
    sections:
    ...
      section:
        type: fields
        fields:
          index:
            type: pages
            disabled: true # this is to create a static, non editable list

Should not be possible if you set create to false as well for editors in the relevant blueprints (the same where read is false).

I tried to use the solution you linked but it led me to other problems:

  • an error that had something to do with routes when logged as admin
  • an undesired redirect when logged as editor

so i gave up…

The problem is at top level, even if at the beginning of site.yml I placed:

options:
  create:
    admin: true
    editor: false

Hm, I have to look into that. That setting shouldn’t be in site.yml, though, but in the blueprints for the parent pages where the user is not allowed to create subpages. Or do you mean, prevent the editors to create first level pages? But that should be solvable by creating different site.yml blueprints for editors and admins.

Exactly what I meant. But to use two different site.yml blueprints I need to use the approach @HeinerEF linked earlier, right?

Or this one: User blueprints and panel permissions

Note that you have to remove the site.yml blueprint from /site/blueprints to make this work.

Oh this would be perfect!
Can you clarify what role the plugin plays in this, or where I should place this code? (I thought in index.php but I’m not sure anymore :sweat_smile:)

Also, I’d rather do something like:

<?php
if(($user = kirby()->user()) && $user->role() == 'admin') {
    $dir = __DIR__. '/blueprints/site_admin.yml';
} else {
    $dir = __DIR__ . '/blueprints/site_editor.yml';
}

without using subfolders, if that works.

Create a new folder in /site/plugins and put an index.php into it.

I don’t know if your solution will work or not, you have to test it.

The solution @gillesvauvarin first came up with is fine if you create custom blueprint folders per user roles. If you only want to change single blueprints, the plugin approach is the better solution.

It doesn’t.
[EDIT] It does, I was doin it wrong

I tried (A) using two different folders (/site/blueprints/admin/site.yml and /site/blueprints/editor/site.yml) but it gives me an error: Call to a member function options() on null.

If (B) I leave the original /site/blueprints/site.yml (intended for editors) and just change the setting for admin roles to /site/blueprints/admin/site.yml, the original one overwrites the admin one as you predicted.

The folders must be in the plugin folder, not in the main blueprint folder.

And then your suggestion should work as well, at least it did in my quick test.

23