User Roles

Hi folks,

Can someone explain to me the differences between the user roles?

Cheers, Joannou.

The Good Lord has changed water into wine, so how can drinking beer
be a sin. - Sign near a Belgian monastery

Joannou Ng wrote:

Can someone explain to me the differences between the user roles?

admin - has access to everything, can create accounts, etc…
developer - can create pages, snippets, and layouts
default - can create pages and snippets


John L.
http://wiseheartdesign.com

These roles are not really useful IMHO.
Admin and developer are too close in purpose. User has too much access.
I’d like to have individual users with access to certain parts of the
site… and an Admin user(s) for control of this.

Just my opinion of course. I’m not trying to start a flame war.

Cheers,
Adam

It isn’t too bad considering the intended userbase for the CMS. It is
intended to be a system for small and trusted groups of users and not a
mass of people. It is definitely not for everyone and that is a good
thing to me since it isn’t trying to be everything to everyone. It then
has a better focus.

One must also consider that we are still sitting at .52 for a stable
release and it is still growing in terms of its functionality and
feature set; one of those being the reworking of the plug-in system. So
even if the core does not natively support it, maybe there is a chance
for a plug-in to step in. As long as it has a solid API for extension,
it can be a lot of things. For now, it is still a work in progress.

Of course, John is the man with the plan on this. The system seems to be
working for what I need and that is what counts for me.

Why not have a “role group” which has predefined access to a page
(which is inherited by sub-pages)
Then you could make your own groups and allocate “normal” users as
you saw fit.
The only users able to change these role groups would be Developers
and Admin.

I don’t want users changing the “file not found” pages or the styles
pages etc, but the rest are ok.

Adam
Ps I appreciate that:
a) it’s only .52 version
b) it’s intended for small groups
But I don’t see how planning for growth is a bad thing… I’m using
Radiant as well because it best fits my purposes of all the CMS I’ve
tried, but that doesn’t mean it can’t be improved. On a similar note:
another lack for Radius is unfortunately handling forms, but I see
the new extensions in mental branch as taking care of this…

Adam,

I concur with much of what you say here. I think user/group
permission/management is one of the weaker, if not the weakest points
of Radiant at this point in time. I strongly believe it should be part
of the core and not handled by a third party plug-in. Permissions
should always be internal to the system, well encapsulated and with
proper access right.

For now Radiant works for me, but starting this spring I’m going to
have my hands full as about 10 people will need some form of access to
the back end and we’ll make 3-4 groups each of which SHOULD have their
permission set. Instead, we’re gonna have to rely on personal
principles and honesty. At any rate, I still think Radiant holds much
more promise than Drupal or Typo3 in so far as simplicity and
no-nonsense is concerned.

Just thinking further on these lines…
Why not have a “role” group which has access to a page (which is
inherited by sub-pages)
Then you could make your own groups and allocate “normal” users as
you saw fit.
The only users able to change these role groups would be Developers
and Admin.

Adam
Ps I appreciate that:
a) it’s only .52 version
b) it’s intended for small groups
But I don’t see how planning for growth is a bad thing… I’m using
Radiant as well because it best fits my purposes of all the CMS I’ve
tried, but that doesn’t mean it can’t be improved. On a similar note:
another lack for Radius is unfortunately handling forms, but I see
the new extensions in mental branch as taking care of this…

Not a bad idea to have a “contributor” role – edit but not add or
delete pages, change status from draft to published, perhaps add
snippets – hmmm. Maybe.

  • Clayton