# Adminstrator and Developer role clarification **URL:** \ **Category:** Radiant CMS\ **Created:** [June 21, 2008, 10:21pm UTC](https://www.ruby-forum.com/t/adminstrator-and-developer-role-clarification/141087 "2008-06-21T22:21:19Z")\ **Posts on this page:** 5\ **Page:** 2
**Author:** ![squeegy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/dec6dc/32.png) [@squeegy](https://www.ruby-forum.com/u/squeegy)\ **Post date:** [June 23, 2008, 1:01am UTC](https://www.ruby-forum.com/t/adminstrator-and-developer-role-clarification/141087/21 "2008-06-23T01:01:59Z")
Chris P. 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 (|layouts|snippets|users|pages) key ( ie |edit|create|view|destroy| etc) value (true|false|) 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). ---
**Author:** ![squeegy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/dec6dc/32.png) [@squeegy](https://www.ruby-forum.com/u/squeegy)\ **Post date:** [June 23, 2008, 10:52am UTC](https://www.ruby-forum.com/t/adminstrator-and-developer-role-clarification/141087/22 "2008-06-23T10:52:52Z")
Chris P. wrote: > The problem here is that some sites use snippets extensively for content > and writers need to create and edit those in order to create pages. > That’s the beauty of snippets, they’re versatile. But like you noticed, > when snippets hold Layout or other design-level content, it gets hairy > because writers have permissions to those snippets. > > I once suggested that there could be Page Snippets and Layout Snippets > (or Content Snippets and Design Snippets) but you run into the > complication-factor. At some point we’re sliding down the slippery > slope to WordPress or some other massively-featured CMS. > > -Chris True, the last thing we need is an open-source version of Vignette!! We could always tag the Snippets with a simple “content only” or “structural” boolean, and only show those snippets that are appropriate to the user level? Or perhaps, only show the edit controls for those that are tagged (allowing users to see the names of the Snippets available to use in pages)? Jon. ---
**Author:** ![squeegy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/dec6dc/32.png) [@squeegy](https://www.ruby-forum.com/u/squeegy)\ **Post date:** [June 23, 2008, 5:40am UTC](https://www.ruby-forum.com/t/adminstrator-and-developer-role-clarification/141087/23 "2008-06-23T05:40:06Z")
Jonathan McCoy wrote: > Doh! Thanks for the correction. > Whatever happens, and I seem to be banging on about this one, Snippets > should be moved to the same level as Layouts. The problem here is that some sites use snippets extensively for content and writers need to create and edit those in order to create pages. That’s the beauty of snippets, they’re versatile. But like you noticed, when snippets hold Layout or other design-level content, it gets hairy because writers have permissions to those snippets. I once suggested that there could be Page Snippets and Layout Snippets (or Content Snippets and Design Snippets) but you run into the complication-factor. At some point we’re sliding down the slippery slope to WordPress or some other massively-featured CMS. -Chris ---
**Author:** ![squeegy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/dec6dc/32.png) [@squeegy](https://www.ruby-forum.com/u/squeegy)\ **Post date:** [June 23, 2008, 2:46pm UTC](https://www.ruby-forum.com/t/adminstrator-and-developer-role-clarification/141087/24 "2008-06-23T14:46:23Z")
I think we need core extensions that handle these problems. Tools like Drupal and ExpressionEngine of PHP fame handle de-coupled functionality very well. I think RadiantCMS retains a well-defined code base and development platform. With that said, I think focus should be shifted to extension development. Extensions can provide all the granular functionality and control one would need. The Page Group Permissions extension definitely is a great example. > We have core developers for Radiant itself, but I think Radiant could use some core developers for just extensions. I think the community and the promotion of Radiant could benefit greatly from that. What do you guys think? ---
**Author:** ![squeegy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/dec6dc/32.png) [@squeegy](https://www.ruby-forum.com/u/squeegy)\ **Post date:** [June 23, 2008, 3:20pm UTC](https://www.ruby-forum.com/t/adminstrator-and-developer-role-clarification/141087/25 "2008-06-23T15:20:51Z")
Arik J. wrote: > I think we need core extensions that handle these problems. Tools like > Drupal and ExpressionEngine of PHP fame handle de-coupled functionality > very well. I think RadiantCMS retains a well-defined code base and > development platform. With that said, I think focus should be shifted to > extension development. > > Extensions can provide all the granular functionality and control one > would need. The Page Group Permissions extension definitely is a great > example. > > [http://github.com/freels/radiant-extensions/tree/master/page\_group\_permissions/README](http://github.com/freels/radiant-extensions/tree/master/page_group_permissions/README) > > We have core developers for Radiant itself, but I think Radiant could > use some core developers for just extensions. I think the community and > the promotion of Radiant could benefit greatly from that. > > What do you guys think? Good idea. There are still numerous issues I think need to be sorted at the core, but a lot of functionality could come in the form of bolt-ons. My only issue, is the complex setup to ensure everything you need is in one place (unzip some, SVN some more and GIT the rest), and the complexity with updating multiple projects. How about even deploying extensions as gems (still doesn’t solve updates, but one step at a time…) and requiring them in a environment file (like the Rails 2.1 gem handler)? [http://ryandaigle.com/articles/2008/4/1/what-s-new-in-edge-rails-gem-dependencies](http://ryandaigle.com/articles/2008/4/1/what-s-new-in-edge-rails-gem-dependencies) I’ve got a number of useful tool extensions I’ve built, including text manipulation (upcase, downcase etc), truncation, redirection and so forth. Could be persuaded to OS them… Jon. [Previous page](https://www.ruby-forum.com/t/adminstrator-and-developer-role-clarification/141087.md?page=1)