RE: [PEAR-DEV] Re: permissions managment

From: Date: Tue, 13 Aug 2002 11:21:50 +0000
Subject: RE: [PEAR-DEV] Re: permissions managment
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-8359@lists.php.net to get a copy of this message
> 4. authorization priorities > > We might want to introduce priorities (maybe there's a better name for > that?) > of authorization. For example, a logged in user belongs to the group > 'administrator' and thus he is granted access to most parts of our Website, > but the super admin denied him access to a certain page. Then the user > specific authorization overrules the group specific authorization. This > priority scheme should again be as flexible as possible. There should be > no > hardcoded behaviours, instead a method should be provided to define such > priority rules dynamically. > I dont see why this is necessary. It will only create an administrative nightmare because people will not understand why they cannot access a section even though "all" admins should. If you get a special title which you have associated certain rights to, then the only way to revoke those rights is to take away that special title: For example you have following hierarchy: Superadmin Admin Moduladmin The Superadmin can do everything. The Admins can do everything except creating new Admins or modify the Superadmin The Moduladmin can do everything in the modules he has been assigned rights to use. If you don't want an admin to admin a certain module you will have to reduce him to Moduladmin status and give him the rights to admin all the module he may use. Obviously this is not as flexible but creates much less confusion. If you add another module then you will manually have to hand this right to all affected Moduladmins. A solution to this would be to define masks of user rights. Then you could just add the rights to the new module to that template and automatically all Moduladmins that are associated with that mask will gain access to that module. Regards, Lukas

« previous php.pear.dev (#8359) next »