I’m going to be really honest here and say that the user model could use
some serious love. Its great for what it is currently, but it needs to
grow up. If Radiant is going to see wider use in production from more
developers, the user model needs to be a little more than just
developers and admins. What about content editors or people who just
exclusive access to private parts of the public website? Eh, just
something to think about.
Hi Arik,
I think the current model is actually underutilized as it is, which
signals that even in its rudimentary state it’s got too much going on.
Maybe I haven’t looked through the source code enough, but I really
haven’t found anything that a Developer can do that an Administrator
can’t (and I’m unclear on whether an Admin can do more than a Dev – or
why I would make someone one and not the other or both). I think the
User model as it is is fine for authentication and simple
authorization at most and that’s all it should do out of the box.
I understand that some organizations may have hierarchies and
stratifications of roles, but in the zone Radiant is aiming for I
don’t think this fits the 80/20 rule. The fact that Radiant doesn’t
force me to structure my organization around its idea of who should be
allowed to do what is a major selling point for me (and not to speak
for everyone else, but I think I’m not alone here).
One side-effect to increasing the complexity of the authorization
system would be that extensions would be harder to write. E.g. say
you’re using page_attachments: should anyone be allowed to attach a
file to a page? Should there be a role (asset editor?) for that or
does that fall under a content editor’s purview? I think having to
take these things into account when writing attachments would
seriously hinder sharing them with other users.
IIRC a couple of days ago someone mentioned this extension:
http://saturnflyer.com/svn/radiantP/rbac_base/trunk/
…which may more in line what you’re suggesting without adding the
conceptual overhead to core.
-Andrew
What about publically-accessed user models in extensions? Do we have to
set up a member model or a completely new user model altogether?
Arik J. wrote:
What about publically-accessed user models in extensions? Do we have to
set up a member model or a completely new user model altogether?
In the thread I provided, Casper makes some comments about your
question.
From a UI perspective, you probably don’t want to mix the two classes
of users either. For instance, adding and removing users (those with
access to editing your site’s content) requires an administrator. But
creating members and granting them access to view certain pages might be
a role that even your Basic-level user is given. Users and Members
really, have different applications though their use cases look similar.
-Chris
@Arik
There are actually three user-levels, not two – Administrator,
Developer, and Basic/Writer. Personally, I’d like to see the Users page
show all three with the Basic user checked and disabled (permanently
checked) so that that option would be clearer.
The extension Andrew mentioned can also be found in this thread:
http://www.nabble.com/Role-Based-Access-Control-extension-td15262048.html
@Andrew
I think John’s breakdown is for the Basic and Developer users to offer
two levels of content creation. This is why the Basic user doesn’t have
access to Layouts. And with my soon-to-be-released CSS & JS extension,
I only grant Developers access to these files as well. Now, I’d prefer
the name “Designer” rather than “Developer” for this role – but that’s
just getting picky.
And, of course, Administrator allows tasks like creating users or
selecting extensions which deal more with configuring the admin area and
the site’s operation than with creating content.
-Chris Parish