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

anon77445132 · October 28, 2019, 4:36pm

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).

piaaaac · October 28, 2019, 5:37pm

Thanks @anon77445132, 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

texnixe · October 28, 2019, 9:18pm

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.

piaaaac · October 29, 2019, 11:06am

@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. ! The page “options” cannot be found).

texnixe · October 29, 2019, 11:14am

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.

anon77445132 · October 29, 2019, 11:30am

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.

piaaaac · October 29, 2019, 2:07pm

@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

texnixe · October 29, 2019, 2:09pm

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

piaaaac · October 29, 2019, 2:09pm

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…

piaaaac · October 29, 2019, 2:12pm

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

options:
  create:
    admin: true
    editor: false

texnixe · October 29, 2019, 2:13pm

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.

piaaaac · October 29, 2019, 2:18pm

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

texnixe · October 29, 2019, 2:21pm

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.

piaaaac · October 29, 2019, 2:44pm

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 )

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.

texnixe · October 29, 2019, 2:47pm

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.

piaaaac · October 29, 2019, 3:08pm

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.

texnixe · October 29, 2019, 3:09pm

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.

piaaaac · October 29, 2019, 3:17pm

ok didn’t get that! It works perfectly then, thank you.

I confirm that it works.

anon77445132 · October 29, 2019, 5:15pm

My way to restrict a role

I run XAMPP Version: 7.2.15, PHP/7.2.15, on Win10 64Bit as my development system.

What I have done to test:

I installed a new starterkit 3.2.5.
I updated to Kirby 3.3.0-rc.2 (I could not download the newer rc-version).
I changed the content of the existing file \index.php to:

<?php
require __DIR__ . '/kirby/bootstrap.php';
$kirby = new Kirby();
$user  = $kirby->user();
if ($user && $user->role() == 'editor') {
   $kirby = new Kirby([
       'roots' => [
           'blueprints' => __DIR__ . '/site/blueprints/bp_role_editor',
       ],
   ]);
};
echo $kirby->render();

I created a new directory \site\blueprints\bp_role_editor and then a new directory \site\blueprints\bp_role_editor\users.
I added a new file \site\blueprints\bp_role_editor\site.yml that looks like:

title: Website for Editor role
### site\blueprints\bp_role_editor\site.yml
columns:
  - width: 1/3
    sections:
      parts:
        headline: Pages for Editor role
        type: pages
        templates:
          - notes     # only this template-type is shown for this role at this menu level
        create: false # avoid new pages at this menu level
        delete: false
  - width: 2/3
    fields:
      infofield:
        type: info
        label: Info for Editor role
        text: |
          This is the panel start page for the role "editor".

I added a new file \site\blueprints\bp_role_editor\users\editor.yml that looks like:

title: Editor with Editor role
description: The Editor uses the panel to edit only the notes page and note pages as well as his own user fields.
permissions: # for this role, may be you want to make changes here!!!
  access:
    users: false
    settings: false
  site:
    update: false
  pages:
    delete: false
  user:
    changeRole: false
    changeName: false
    delete: false
sections: # user fields for this role itself
  meta:
    type: fields
    headline: User data
    fields:
      phone:
        label: Phone [bp_role_editor\users\editor]
        type: text
        width: 1/2
      mobile:
        label: mobile Phone
        type: text
        width: 1/2

I created a new directory \site\blueprints\bp_role_editor\pages and then I copied the file \site\blueprints\pages\notes.yml to \site\blueprints\bp_role_editor\pages\notes.yml and the file \site\blueprints\pages\note.yml to \site\blueprints\bp_role_editor\pages\note.yml.
We can add user permissions for this role in these new files.
I created a new directory \site\blueprints\bp_role_editor\sections and then I copied the file\site\blueprints\sections\notes.yml to \site\blueprints\bp_role_editor\sections\notes.yml.
I copied the file\site\blueprints\bp_role_editor\users\editor.yml to \site\blueprints\users\editor.yml.
This new file is for the admins in the panel! To show this, you can make some changes (e.g. text) in the file \site\blueprints\users\editor.yml. So only in the file copy I deleted every text bp_role_editor\.
I addded an admin (for me !) in the panel and then as admin I added a new user with the role editor as my test user.
Now I can test this new user with the role editor and his permissions.

Notes:

I don’t need any routes for this.
Yes, I know that I have some files, I copied, for each role a second time. But the setup is simple. Maybe we can work with symbolic links for the directories in the steps 7 to 8. But that depends on the installation and its OS. Or may be we can use routes or config options for this???
I don’t know…

Good luck!

pixelijn · May 20, 2020, 1:11pm

So that nobody gets confused: The solution described by @anon77445132 is basically the same that originated from @gillesvauvarin and described here: Custom blueprint for different roles

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

Option A - Using a standard pages section

Option B - Using a field of type pages

My way to restrict a role

Option A - Using a standard `pages` section

Option B - Using a field of type `pages`