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