Having more than one group with the same permissions is no problem at all.
In fact, it's kind of the purpose of role-based authentication.
I have a web site that features different classes of users who need access
to pages. Some groups can access every single page in the site (e.g.
'root' user) while others can access only a tiny subset. The key is to
make the permissions granular enough. If a secretary has permission for
some kinds of reports but not others, there needs to be a permission to
handle that subset of reports so it can be added to the secretary group.
Here is the code I use to build permissions when the database is being
initialized. Other permissions and groups can be added through web
actions, but his list populates the basic site. This code runs in a
"module" which is why It uses the thread-safe "settings" variable.
from gluon import *
class UserRole():
@staticmethod
def permissions():
T,settings = current.T,current.settings
return [
('club_page', T('View club information page'), '', 0),
('lsc_page', T('View LSC information page'), '', 0),
('support_page', T('View %(title) support page', settings), '',
0),
('admin_page', T('View %(title) admin page', settings), '', 0),
('root_page', T('View special root-access page'), '', 0),
('impersonate', T('Impersonate other users'), 'auth_user', 0),
]
@staticmethod
def roles():
T,settings = current.T,current.settings
return [
('root', T('Superuser access to all'),
('club_page','lsc_page','support_page','admin_page','root_page','impersonate')),
('ss_admin', T('%(title) administration', settings),
('club_page','lsc_page','support_page','admin_page','impersonate')),
('ss_support', T('%(title) support', settings),
('club_page','lsc_page','support_page','impersonate')),
('lsc_admin', T('LSC staff'), ('lsc_page',)),
('club_admin', T('Club staff'), ('club_page',)),
('coach', T('Swim coach '), ('club_page',)),
('user', T('Parent or swimmer'), tuple()),
('vendor', T('Vendor or advertiser'), tuple()),
('impersonate',T('Impersonate other users'), ('impersonate',))
]
@classmethod
def define_roles(cls):
auth = current.auth
perms = {nam:(nam,obj,col) for nam,dsc,obj,col in cls.permissions()}
for ea in cls.roles():
grp,descr,plist = ea
gid = auth.add_group(grp, descr)
for p in plist:
auth.add_permission(gid,*(perms[p]))
On Thursday, July 16, 2020 at 5:30:47 PM UTC-5, Paul Ellis wrote:
>
> the situation is that I have permissions associated with auth_groups.
>
> eg. user, team leader, business leader, oversight
>
> now I need a "secretary" or "accounts" group which has access to some
> business leader features i.e reports.
> Some team leader features ie. price maintainence.
> But does not have access to the basic features of normal users.
>
> I can't see how to make an auth_group which has permissions which are
> already associated with another group.
>
> I am hoping for a solution which does not involve hard coding access to
> these features using @auth.has_membership('accounts') as I don't expect
> this to be last case of overlapping permissions.
>
> Ideally I can make an interface where business leaders can make a custom
> permission group and assign it to their employees. Without creating a
> situation where each new employee needs to have a permission allocated for
> every little thing.
> i.e. customer maintenence, customer delete, product related permissions,
> product permissions where special knowledge is required...
>
> Is this possible with the Web2py Auth System?
>
>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to web2py+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/web2py/ab7d164b-4a24-47b0-b846-0a5858ee4144o%40googlegroups.com.
