Using roles or just 'guest' and front-end editing capabilities?

[celfred]

Hello there,

I'm struggling again with a new site I'm trying to implement for fun. First, for personal use, but now I'd like to make it a 'member available' site.

The site is just an invitation management site : who came over? What did they eat? What ere the recipes? And so on...

Here's my problem :

I'm trying tp use Fredi (the module) to allow members to edit their recipes, their hosts, their profile. Actually, I wanted to use Fredi so I didn't have to really care about anything front-end. Fredi would take care of it. I added a 'member' role (with page-edit access) to each member. It works fine this way, but the worry I'm facing is that if a member manually adds '/processwire' in the address bar, he will have access to all the members list and invitations and I wish I could hide all of this.

Actually, they can't 'View' or 'Edit' anything, so I guess the probability of them fiddling with all these information is close to zero, but I do'nt like it anyway. I wish they could have access ONLY to their stuff. In my tree, this means everything under '/invitations/user-id', 'guests/user-id/', and '/dish/user-id'. And I'm unable to find out how to do this... Hence my post

The other way I imagined : leaving all members with 'guest' role (if they type 'processwire' in the address bar, they won't see anything (which is good), and implementing front-end editing solutions for the members. It could work, but I feel like I'll never use the user/roles PW capabilities if I start working this way

Am I misunderstanding something? If anybody could give me a clue about how to handle this issue, I'd appreciate

[SiNNuT]

On the subject of limiting the default PW admin user interface to only show users their own content in some way i can't help you. Maybe others have solutions.

But this does sound like you might indeed want to make a 'front-end' system, where a member can login and manage and create their content. You can still use all the power of the PW api, to store the content (pages), users etc.

Creating a member role and giving it only the page-view permission will keep them out of the PW backend but this will allow you to use the API to do stuff with roles. You can add as many roles and (custom) permissions to that roles, that you might need for your frontend system. On this subject i once wrote a simple example http://processwire.com/talk/topic/2937-creating-a-front-end-admin/?p=28954 This might help some. Of course, making you own admin basically, will require work, coding skills and a good understanding of (the) PW (api).

More knowledgable users will be able to answer more specific questions on this subject.

[celfred]

Thanks a lot SiNNuT for this answer.

I guess I'll pull up my sleeves and try to code some basic front-end editing tools and keep my members out of the PW back-end... Actually that's what I started doing, but when I saw Fredi's possibilities, I thought "Well, I'll never be able to do as good as this in terms of sanitizing data, so let's use it!" and that's when I got stuck with the page-edit permission needed for Fredi's access and page-edit permission giving too much 'view' power in the PW back-end.

Again, if someone can try to explain to me why giving page-edit permission to a role allows full access to the website tree in the PW back-end and not just access to the branches where the page-edit permission applies (I tried to use the Page Edit Per User module to limit), I feel like I would understand things better, because I'm a little lost on that

I have a feeling I should interpret things this way : "By default, only the 'Superuser' has access to the PW back-end. If another user is given access, this user can see ALL of it (from /, and all branches)  but actions will be limited according to his permissions (the buttons 'view', 'edit', 'move', 'delete'... will be there or not. If the user has no permission on a page, no buttons are shown, but the page title is there anyway. And it works this way because ... [and that's what I'd like to understand;)]". To be as clear as possible, on my screenshot, I'm logged in as 'celfred' having the 'member' role : I have the 'edit' permission on my branch : cool. But as you can see, I also can see the other members and see how many invitations they have and the dates). Since I have no permissions in those branches, I feel like they should be hidden...

I've read many posts in the forums about roles and permissions and I have a little question : when you have a huge website (as some of you do) with thousands of pages and you have multiple roles. Do the users have access to hte thousands of pages anyway (even though they can't edit them)? Let's say for example on the Blog profile site. If a user can edit articles in 1 category only, does he have access to all categories? If all other categories could be hidden, I could imagine 'very basic' admin back-end for certain users and 'more complex' back-end for higher-level users...

Anyway, for the moment, I'll go ahead and leave the users with just the 'guest' and code something in the front-end, as SiNNuT mentionned above

Sorry if you feel like I misunderstanding things about the PW back-end access... I'm trying my best to make sense out of this so I can have a correct approach. Maybe those 'roles' and 'permissions' issues are for bigger sites, not really useful for my amateur very small sites

[SteveB]

Celfred, I had some of the same thoughts about Fredi and access. In that thread SiNNut mentioned above there was a simple module to hide the backend admin from certain users. By modifying it slightly I'm using Fredi without letting frontend editors see admin pages.

1. Create a role called frontend-editor and give it page-view, page-edit, page-edit-recent permissions.

2. Create a user (or several) with that role.

3. For each template they need access to, use template's access tab to grant 'edit pages' access to that role.

4. Setup HideBackend this way (a little different from Adrian's version, maybe rename it) to keep them out of backend...

class HideBackend extends WireData implements Module {

     public static function getModuleInfo() {
          return array(
               'title' => 'Hide Backend',
               'summary' => 'Redirect frontend-editor user from backend admin back to site\'s homepage.',
               'href' => '',
               'version' => 1,
               'permanent' => false,
               'autoload' => 'template=admin',
               'singular' => true,
          );
     }

     public function init() {
          if($this->user->isLoggedin() && $this->user->hasRole("frontend-editor")) {
               $this->addHookAfter('Page::render', $this, 'redirect');
          }
     }

     public function redirect(HookEvent $event) {

          if($this->page->template == "admin")    {
               $this->session->redirect("/");
          }
     }
}

I think I'll have it redirect to some kind of welcome page instead of "/" but this does seem to be working. The user can use the admin login page to login. Once they succeed they are immediately redirected away and Fredi edit links should become visible.

Edit: Wait! - Had it working yesterday (thanks to a typo) but there's a problem with this method.

The crux of it is that if we redirect in HideBackend we break fredi's uses of the admin pages too. I can't totally prevent a frontend-editor user from going into admin pages but I'm testing a workaround to reduce the likelihood of that happening. This may not be the final answer but in HideBackend's init function I'm saving the current time to a session variable each time an obvious fredi request comes in (opening the modal). Other requests are allowed if previous fredi request was not too long ago, otherwise the redirect hook is set.