Chris Parrish wrote:
> Interestingly, in one of your later posts, you define "Developer" and
> "Designer" separately where "Developer" was working outside of the
> Radiant UI (including RoR and DB tasks). And where Developer got into
> (x)html or css, the role overlapped with your definition of "Designer"
> It kind of made my point.
Actually, that was my post ;)
Anyway, I'd be inclined to keep such a delineation - leaving the lowest
level being content-only. Having a tier for content, a tier for design
and a tier for configuring plugins/extensions (and dipping into Radiant)
- and a root tier for user management (and any fundamentals that may
crop up in the future UI).
I'd be quite keen to see a moved from the checkboxes, to a hierarchical
approach. Keeping the potential for extensions to insert new roles, a
weighted inheritance index could be a simple solution:
1 Content
25 Designer
50 Developer
100 Admin/Root
Or, just go granular. A checkbox for every function, with extensions
inserting their own granular function control. Implementation fairly
simple, with a key/value table:
access:
user_id
module (<extension>|layouts|snippets|users|pages)
key (<function> ie |edit|create|view|destroy| etc)
value (true|false|<string>)
Whatever happens, and I seem to be banging on about this one, Snippets
should be moved to the same level as Layouts. The lowest level (akin to
Content-only) then needs to be feature-stripped further, even perhaps
down to specific CRUD functions.*
Jon.
* I've already had problems this week - a customer project manager is
having trouble with content management staff making changes to the
snippets (which I fixed with a patch) and with deleting/renaming pages
and page-parts (which I'm lacking a solution for).
--
Posted via http://www.ruby-forum.com/.
_______________________________________________
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
