[development] Suggestion for User Permissions

Simon Roberts lyricnz at gmail.com
Thu Nov 29 20:42:43 UTC 2007

Agree. If someone really wants an "admin role" they can use (ta-da)


> Date: Thu, 29 Nov 2007 09:45:53 -0800
> From: "Steven Peck" <sepeck at gmail.com>
> Subject: Re: [development] Suggestion for User Permissions
> To: development at drupal.org
> Message-ID:
>         <a151b5a00711290945y37f9f5acsc3ff989a4104365d at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> When creating a site admin role, there are several items I do not turn
> on for the users, nor do I want them on for those sites.
> Creating roles is generally a one time deal per role.  It is something
> that 'even it is a 'pain' or 'inconvenient' should not be 'globally
> allowed turn on'.  This comes to a security issue in that you should
> determine your permission model.  It is not an 'OMFG usability issue'.
>  It is a security issue.  I have always liked the default 'everything
> is off' model because I then have to turn on things.
> It may be inconvenient but it doesn't seem to be something to go into
> hysterics over or claim usability as an overarching trump card.
> If we are going to do this, then allowing it only once per role 'at
> time of creation' seems the least harmful approach to easily allowing
> people to shoot themselves in the foot to solve some users
> 'inconvenience'.
> Steven Peck :: www.blkmtn.org
> On Nov 29, 2007 5:14 AM, Earnie Boyd <earnie at users.sourceforge.net> wrote:
> > Quoting Darren Oh <darrenoh at sidepotsinternational.com>:
> >
> > > Giving a permission to the authenticated user and the anonymous users
> > >  gives it to all roles. If you are speaking of giving a single role
> > > all permissions, I would be careful. It would be better for modules
> > > to set defaults for their permissions and then change each permission
> > >  individually.
> > >
> >
> > IMO, the set/unset all function should be applied to created roles at
> > the time of creation only.  This solves the issues being discussed.

More information about the development mailing list