Аdditional admins

[zlojkashtan]

Someone has ideas about creating additional admin site that will have access to edit only a particular section of content? For example, several editors for the section "news " and a few for "articles" etc.

[apeisa]

You don't actually need additional admin site to achieve this. Just create new roles for these like "News Editors" and "Article editors". Then you have per page setting for roles who can view which pages. And you have to also give those new roles lots of permissions, like (not sure about all of these):

# ProcessHome

# ProcessList

# ProcessLogin

# ProcessLogout

# ProcessPageAdd

# ProcessPageEdit

# ProcessPageEditDelete

# ProcessPageEditImageSelect

# ProcessPageEditLink

# ProcessPageList

# ProcessPageSearch

# ProcessPageSort

# ProcessPageTrash

# ProcessPageView

After this you want them to be able to access admin site also (if you use AdminBar then this is not necessarily needed since they can edit/add pages through front-end). This can be done when editing Admin page, settings tab and there check needed Roles from Roles-section.

After this they can access admin, but not edit any pages (or actually, they might be able to edit admin pages and mess something?). Now you need to give them rights to edit right pages. So go to your News page and edit settings -> Roles and check "News editors" there.

Of course if you want to give them simpler interface then you would need to create additional admin views (or use AdminBar).

And as you notice when editing Roles:

ProcessWire's role based access control system is currently in development. While fully functional, more work, testing and documentation is in progress, so I recommend sticking with the Superuser role for administrative accounts until development is complete.

[zlojkashtan]

Thanks for the quick reply. Half of the necessary capabilities - implemented, but still, the system access distribution has many bugs that let you crap away the main admin.

p.s. sorry for my english.

[ryan]

Half of the necessary capabilities - implemented, but still, the system access distribution has many bugs that let you crap away the main admin.

Superuser is the only role that can actually edit the admin pages, and that is intentional, so that you can add stuff to it as it suits your needs. That part is hard coded, so it doesn't matter what permissions/roles you assign, it's not going to let any role other than superuser modify those pages or even see that they exist (unless you write something to do it from the API). So when you edit the /processwire/ (admin) page to add a role to it, all it's doing is giving them access to use the admin. It might say that they have edit access there, but in this instance they don't.

There aren't any bugs that I'm aware of in the current user/roles system. Though definitely let me know if you found any? The main limitation is just that it's not yet designed for large scale use (i.e. lots of users or data attached to those users), and it's not as refined as other parts of the system in terms of description and messages. However, if you need to setup a role to provide edit access to just another part of the site, then the system should work quite well.

This user system is going to be replaced in the near future by something that is built for lots of users and custom data attached to those users.

[apeisa]

Superuser is the only role that can actually edit the admin pages, and that is intentional, so that you can add stuff to it as it suits your needs. That part is hard coded, so it doesn't matter what permissions/roles you assign, it's not going to let any role other than superuser modify those pages or even see that they exist (unless you write something to do it from the API).

This is good to know! I tested it right away and it works exactly like this.

There aren't any bugs that I'm aware of in the current user/roles system. Though definitely let me know if you found any? The main limitation is just that it's not yet designed for large scale use (i.e. lots of users or data attached to those users), and it's not as refined as other parts of the system in terms of description and messages. However, if you need to setup a role to provide edit access to just another part of the site, then the system should work quite well.

There might be one bug: If you have permissions to login and logout, you cannot actually logout, if you don't give permission to admin site. I see that there is guest role allowed on logout page, but still couldn't logout.

[Adam Kiss]

…If you have permissions to login and logout…

OT: Why do we have separate setting for logout again?

[zlojkashtan]

one of my bugs are - what you must give the possibility to edit "Ноmе" page so that you could edit "News" page.

otherwise we get admin page without a list of all pages.

Also there is a discrepancy in the admin page and AdminBar. If we disable the "ProcessPageList" then in the admin page shows "You don't have permission to execute this Process: ProcessPageList" but AdminBar everything works fine.

The ideal option would be to give the user the authority to work in one section of the site, while other sections to which it does not have access to better make invisible.

I will still describe noticed if you understand my half Google translator language.  ;D

[ryan]

You shouldn't have to give edit access to the homepage in order to give edit access to a page below it. If you have a role that assigns edit access, remove that role from the homepage, and instead add it to the page where you want them to be able to edit.

If you get an admin page without a list of all pages, then what's missing is the ProcessPageList permission. Make sure that is turned on for the role. ProcessPageList does not imply edit (ProcessPageEdit). So you want to give the ProcessPageList permission to all administrative roles.

If a user doesn't have edit access to a page, they will still see it in the admin list (unless they don't have 'view' access), but they won't be able to edit it.

Also wanted to mention that roles can be used in combination. You can assign as many roles to a user as you want, each with different permissions. They will only receive the permissions assigned to that role on pages that are also assigned that same role.  It's powerful in that you have very fine grained control over access. But it's also complex and confusing, which is why I'm changing it.

[ragnarkarlsson]

But it's also complex and confusing, which is why I'm changing it.

Any idea where in the roadmap / timeline user system is Ryan?

[ryan]

Actually this is already started. But multi language support is next on the roadmap followed by the user system. Because they depend on each other some ways, it's likely they will be built together, or close to it.

[ragnarkarlsson]

Cool, look forward to seeing it in action.

[zlojkashtan]

Also wanted to mention that roles can be used in combination. You can assign as many roles to a user as you want, each with different permissions. They will only receive the permissions assigned to that role on pages that are also assigned that same role.  It's powerful in that you have very fine grained control over access.

Hurrah! finally. it works well. Until then, I have never met such use of roles. I'll know. Thank you!

But multi language support is next on the roadmap followed by the user system.

For back- or frontend? My offer of help with translation into Russian is still valid!

[ryan]

Hurrah! finally. it works well. Until then, I have never met such use of roles.

It's basically a full-blown RBAC system:

http://en.wikipedia.org/wiki/Role-based_access_control

Despite writing the system, I still find it confusing to use in my own projects. Roles with different combinations of permissions inheriting through hierarchies are difficult to keep track of. I just want something simpler. The new system will still be role based, but you'll assign roles at the template level, and the "who can do what here" will be unambiguous. Granted the current system may be more powerful in some respects, but simplicity and ease-of-use are more important to this project.

For back- or frontend? My offer of help with translation into Russian is still valid!

This will be for the admin. Although the result will also provide tools that can be useful on the front-end too, but there won't be any translation necessary there (since ProcessWire doesn't output anything at the front end). We definitely appreciate your help! I hope to be in touch about this within the next month or so.

Thanks,

Ryan