Adminstrator and Developer role clarification

Is the Adminstrator role considered to be the all powerful role? And
developer has less priveleges? Or is it the other way around?

I see 2 main roles in my use of Radiant so far.

  • Site setup person. Layouts, css, taking care of where page parts go,
    everything you need to have a functional radiant framework for your
    site.
  • Content person. Once the layout is in place, this person would create
    and manage pages of content.

Given the names “administrator” and “developer” I would assume that
developer means they have access close to the code level. Which, by
process of eleimination, means admiistrator has less access to content
only.

Are my assumptions right? I just want to be sure that in my public
extensions I am exposing the right sections to the right users.

Thanks.

On Jun 21, 2008, at 4:21 PM, Alex W. wrote:

Are my assumptions right? I just want to be sure that in my public
extensions I am exposing the right sections to the right users.

Nope.

An administrator is a superuser. A developer can do everything, but
create and edit other users. The two roles are really more akin to
“root” and “designer”.


John L.
http://wiseheartdesign.com

John, have you ever considered changing the name “developer” to
“designer”? I think it’d be more clear.

Also, I’d think clarity could be further improved by:

* Showing that there is a Basic user privilege level that is applied
  when Administrator and Developer are not checked.  It's not always
  clear that you still get something when all the options are
  unchecked and it's certainly not clear what that "something" is
  permitted to do. (Perhaps a name like "Writer" or "Author" would
  help).

* Currently, Radiant's permission structure has 3 permission levels
  -- each with progressively more authority (i.e. Developer = Basic
  User + Unique Developer Powers and Administrator = Developer +
  Unique Admin Powers).  So checking Administrator *and* Developer
  makes no sense -- yet today this is an option.  That's really
  where this thread's question comes from.

  I can think of several ways to prevent this confusion to users but
  first the decision needs to be made whether this progression of
  powers is the best approach or whether roles should only consist
  of their unique capabilities (i.e. Admin just includes permissions
  to edit Users and Extension not any Developer stuff -- to get
  those privileges, you'd need to add the Developer role to your
  user).  I'm used to the former since that's what we have today but
  I can think of cases where I'd have an Admin who doesn't have
  Developer privileges.  The latter method is also more extensible
  since others may add roles that don't fit the subset/superset
  approach.

-Chris

Chris P. said the following on 21/06/08 11:51 PM:

John, have you ever considered changing the name “developer” to
“designer”? I think it’d be more clear.

Why?

A ‘developer’ is someone who develops content.
This is obvious to anyone except a programmer.

Chris P. wrote:

John, have you ever considered changing the name “developer” to
“designer”? I think it’d be more clear.

Also, I’d think clarity could be further improved by:

Well said. In my mind, it should work one of two ways.

  1. Have a 3 tier permission system where each tier has more rights than
    the one before. Perhaps Administrator, Designer, and Author. This
    seems close to the current radiant approach, but the UI needs to a drop
    down box with a little documentation about what each setting means.
    Having checkboxes makes this confusing since options with more
    previliges are inclusive of the other options.

  2. Have a component based permission system where each user can have any
    number of roles. Each role give them access to something else. In this
    case the permissions should be labeled by what that allows them to do.
    Perhaps “User Management”, “Development”, “Authoring”. Any user may
    have any combination of these. This allows someone to manage users and
    post content, but not be allowed to mess with the layout or other more
    technical aspects defined in extenstions, for instance. This method
    works well with using checkboxes for each permission type.

Option 2 seems more flexible, as Chris noted. And perhaps those aren’t
the best permission names or levels. But if you guys can decide on an
official approach, I would be happy to submit a well specced patch
implementing it.

If, of course, enough people feel this needs attention at all.

-Alex

On Jun 22, 2008, at 4:45 AM, Anton A. wrote:

Chris P. said the following on 21/06/08 11:51 PM:

John, have you ever considered changing the name “developer” to
“designer”? I think it’d be more clear.

Why?

A ‘developer’ is someone who develops content.
This is obvious to anyone except a programmer.

Ironic, but true.

If you look at the mockups repo and in the ‘blade’ directory, you’ll see
there is a ‘Design’ tab in the interface. I imagine that role will be
changing names as we implement that UI.

Sean

Hi,

I raised the role issue in response to a question regarding SCM’ing
templates a week or so back…

Layouts, snippets and site assets on the file system? - Radiant CMS - Ruby-Forum

Anyway, to repost a few relevant points. My first thought was to keep
the the 3-tier (renaming Developer for Designer) - but juggling some of
the privileges about. A couple of days later, nearing delivery of a
site, I actually countered it with a need for 4-tiers (and still
juggling privileges about).

Jonathan McCoy wrote:


In keeping designs and code DRY, we find ourselves using snippets to
contain more than user-editable content, and use them heavily for
fragments of design logic. As such, we want to keep day-to-day users far
away from anything that can cause damage to the site.

Standard (Pages) → Designer (+ Snippets) → Administrator (+ Layouts, Users, etc)

Jonathan McCoy later wrote:

I’ve monkey-patched a frozen version of Radiant (0.6.7) with some of the
functionality I lusted for above. No testing or a “designer” flag (just
put snippets on the Admin/Dev level). I’d be more inclined to assemble
patches and tests (to the spec above) if anybody else was interested in
it being pushed into the trunk?

Would be nice to review the user levels available - or if we’re all
feeling code-happy, granular access control. I can foresee the need for
the following roles at least:

  1. Content Monkey (pages + preferences)
  2. Designer (+ layouts + snippets)
  3. Developer (+ extensions)
  4. Administrator (+ user management)


I’d keep the developer flag for the
benefit of extensions/plugins that need technical setup. Another
question, is whether flags are more desirable than a user-level number
(ie 1 to 4) or even a class-name, which can be mapped out to a role
name. A popup list with userlevels can be used instead. It removes the
uncertainty of having admin flagged, but developer unflagged → what
rights does the user have?!

Jon.

Jonathan McCoy wrote:

I think it’s fairly useful to define the difference between a Content
If you’re designing a site to be managed by an in-house team, you’ll
need to segregate the design (layouts and snippets) from the
copywriters. Likewise, it’s a fair idea to keep management of extensions
and site setup from designers - leaving it with the technical support
team. And of course leaving user management to the project manager.

Jon.

Jon, that’s a very good explanation! We should use that in the new
‘Summer Reboot’ documentation [1] as a discussion on roles in Radiant :slight_smile:

Cheers,
Mohit.
6/23/2008 | 1:09 AM.

[1] http://wiki.radiantcms.org/Summer_Reboot

Anton A. wrote:

Chris P. said the following on 21/06/08 11:51 PM:

A ‘developer’ is someone who develops content.
This is obvious to anyone except a programmer.

Huh??

I think it’s fairly useful to define the difference between a Content
Manager, Designer and Developer - because frankly there’s a big
difference.

Developer = Web D. = RoR[etc]/DB/XML/XHTML/CSS
Designer = Web Designer = HTML/CSS
Content Manager = Idiot = Copywriter/Editor

“Developers open TextMate, Designers open DreamWeaver and Content
Managers can’t switch on their computer.” - Pretty much says it all.

If you’re designing a site to be managed by an in-house team, you’ll
need to segregate the design (layouts and snippets) from the
copywriters. Likewise, it’s a fair idea to keep management of extensions
and site setup from designers - leaving it with the technical support
team. And of course leaving user management to the project manager.

Jon.

Jonathan McCoy said the following on 22/06/08 12:59 PM:

difference.

Developer = Web D. = RoR[etc]/DB/XML/XHTML/CSS
Designer = Web Designer = HTML/CSS
Content Manager = Idiot = Copywriter/Editor

“Developers open TextMate, Designers open DreamWeaver and Content
Managers can’t switch on their computer.” - Pretty much says it all.

Why are you being insulting?

The whole point is to have content.
Without content a web site is just an academic exercise in programming.


The quality, not the longevity, of one’s life is what is important.
–Dr. Martin Luther King Jr

Mohit S. wrote:

Jonathan McCoy wrote:

I think it’s fairly useful to define the difference between a Content
If you’re designing a site to be managed by an in-house team, you’ll
need to segregate the design (layouts and snippets) from the
copywriters. Likewise, it’s a fair idea to keep management of extensions
and site setup from designers - leaving it with the technical support
team. And of course leaving user management to the project manager.

Jon.

Jon, that’s a very good explanation! We should use that in the new
‘Summer Reboot’ documentation [1] as a discussion on roles in Radiant :slight_smile:

Cheers,
Mohit.
6/23/2008 | 1:09 AM.

[1] http://wiki.radiantcms.org/Summer_Reboot

Thanks… (I’ll write a more coherent version for the docs!!)

There’s a few holes in the documentation I’d like to fix, so I’ll would
be interested in taking part in the reboot.

Cheers,
Jon.

Anton A. wrote:

The whole point is to have content.
Without content a web site is just an academic exercise in programming.

That theory is great, when one person designs, builds and manages a
site.

But as soon as you have more than one person involved in the management
of a site, as with any business function, tasks and responsibilities are
delegated to the appropriately trained and graded staff. Security,
authorization/editorial and responsibility becomes even more important,
the larger the team becomes.

Role based access has nothing to do with “Design Versus Content”, but
the logical separation of discrete roles.

Jon.

Anton A. wrote:

blah

Whatever. Nice argument. Sadly it fell apart shortly after “For most
businesses…”. The reality is quite different, and I can assure you
that the ability to write copy, doesn’t provide you with the competence
to make design or technical decisions. While you’re theory is sound for
a utopian future, we’re trying to solve a real tangible problem in the
here/now.

Can we get back to the original discussion now?

Jonathan McCoy said the following on 22/06/08 03:12 PM:

Anton A. wrote:

blah

Whatever. Nice argument. Sadly it fell apart shortly after “For most
businesses…”. The reality is quite different, and I can assure you
that the ability to write copy, doesn’t provide you with the competence
to make design or technical decisions.

I never said it did.
I wasn’t denigrating those roles.

Unlike you I wasn’t denigrating any roles.
All have to play their part.

Calling the people involved in content development “Idiots” as you did
is insulting.


As a goatherd learns his trade by goat, so a writer learns his trade by
wrote.

Um, this thread’s starting to deteriorate a bit.

@Alex - As you mentioned, I’m starting to like the component-ized
approach as it makes it possible for extension builders to integrate new
roles without breaking the UI (which oddly enough uses checkboxes =
component mentality).

@ Anton - My choice of wording certainly is certainly objective but I
chose it with the goal of conveying information to a lay user or small
business owner to help them understand what the roles offer and what
their boundaries are. Again, it’s debatable but I think you would have
more folks give you an answer closer to what we mean here if you asked,
“what does your website designer do” vs. “what does your website
developer do?”

I think that part of this stems from the fact that the word “developer”
is generally only used in the context of:

* Software Developer
* Land/Subdivision Developer

This is one of those cases, where “designer” leads the new user to the
right conclusion but, once you know what the role already means,
“developer” is probably more technically accurate.

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.

In any case, I’m not stuck on one particular name. I was only trying to
find a term that someone from outside of the web world could look at and
make a fairly close guess at the scope of that role.

-Chris

Jonathan McCoy said the following on 22/06/08 02:38 PM:

authorization/editorial and responsibility becomes even more important,
the larger the team becomes.

Role based access has nothing to do with “Design Versus Content”, but
the logical separation of discrete roles.

Indeed.
That’s not the point I’m arguing about.
For most businesses the business value of the site is reflected by the
content. The infrastructure (and those roles) is essential to the
delivery of the content, but without the content - why bother?

Calling the people who manage the content, the writers and editors
“Idiots” as you did is insulting, just as insulting as calling people
like John L., Sean C. and Chris parish “coding jerks”.

In fact the case can be made that the content is ‘ongoing’ whereas code
can be ‘frozen’.

Chris P. said the following on 22/06/08 06:22 PM:

@ Anton - My choice of wording certainly is certainly objective but I
chose it with the goal of conveying information to a lay user or small
business owner to help them understand what the roles offer and what
their boundaries are.

I don’t object to the clarification, I don’t object to a better
definition of the roles.

I do object to people being called “Idiots”.

That’s all.


All national institutions of churches, whether Jewish, Christian, or
Turkish, appear to me no other than human inventions, set up to terrify
and enslave mankind, and monopolize power and profit.
–Thomas Paine

Chris P. wrote:

Um, this thread’s starting to deteriorate a bit.

@Alex - As you mentioned, I’m starting to like the component-ized
approach as it makes it possible for extension builders to integrate
new roles without breaking the UI (which oddly enough uses checkboxes
= component mentality).
You guys should look at Matt Freels’ branch from a while back. He
factored out roles into a separate entity (model, etc). I thought the
code quality was good but Radiant wasn’t ready for it. I feel we should
let the UI changes drive that kind of change.

Sean

Sean C. wrote:

I feel we should let the UI changes drive that kind of change.

I originally posted to record my thoughts and possibly help others
understand what Radiant was “thinking” with it’s roles. I
wholeheartedly agree with you here Sean. I see much of this already
coming.

-Chris