[doc] User roles and privileges

Destry · 2015-09-17 23:32:52

ToC
- Administration
  - Users
    - User roles and privileges

I’m trying to improve the info design of the old user roles and privs doc, which has always been a bit cryptic. I mean it could certainly be better. For example, think about a Publisher vs. a Freelancer role and their rights on the Users panel. A publisher can access and do everything, while the Freelancer can access but only do unto himself. There are limitations.

So for every role type, we could define one of three panel access conditions:

Full (panel access and full functionality)
Limited (panel access but limited functionality)
None (no panel access)

As it turns out, we have the same colors available for docs use as defined for use in Diagnostics: green, yellow, red, (and blue). I’ve been finding uses for these color classes on certain things, such as for Diagnostics, of course, but in this case too. In User roles and privileges, I’ve started a “visual” table for Roles vs. Panels, where, once filled, it will be easy to see at a glance what scope of panel access each role has:

Full (green)
Limited (yellow)
None (red)

This is rather convenient because full/green obviously means everything, so one will only need to look at the doc for that panel to see what the full suite of functionality is. None/red is nothing so immediately understood without further action. Limited/yellow is the only one that needs further specification on the doc page about what elements are accessible in each case.

Further, the yellow specs lists offer an enhancement. The old lists specify what roles can do (e.g., “can create, edit, publish and delete own articles”), whereas the new yellow/limited lists will specify what relevant roles can do by the associated controls they can see, which is less cryptic by being more specific.

So it would be feasible to use the easy-scan table and replace the old “Roles in terms of privileges” lists with just the yellow specification lists.

Make sense? Or am I overlooking something about how this new info design communicates panel privs per role?

If I’m on the right track, then what I could use some help with is filling in the Full, Limited, and None values in the table. I.e., just pick a panel row and list them off left to right.

When the table’s complete I can more easily try and specify the “limited” ones.

etc · 2015-09-18 10:28:53

Security-wise, most of these restrictions are ridiculous. For example, “Designer can only modify article until is published”. As every person with “form” access, a designer can make himself admin and totally fubar the site. Keep it in mind when asking help from an unknown ~~txp~~ Textpattern wizard. :)

Destry · 2015-09-18 10:46:12

Interesting. That sounds like something that needs resolved in core. Or at least a re-think on who gets access to forms. But mostly likely the onus is on the site administrator to pick people of integrity to work on the site at all.

GugUser · 2015-09-18 12:07:15

Destry wrote #294957:

Interesting. That sounds like something that needs resolved in core.

It seems to me te same.

jpdupont · 2015-09-18 17:36:44

+ 100 with etc.

Actually, I’m in the process to create a site with big importance on users roles and user privileges (one user may edit one section and not an other). The user (the redactor) is not able to modify my work (pages, form, style, sections … ) and I don’t understand how proceed with TXP.

The interface must give me fine settings on users privileges. The end user (Content management !) must be able to modify : articles, categories, images, links, files.

ruud · 2015-09-18 18:11:30

etc wrote #294956:

Security-wise, most of these restrictions are ridiculous. For example, “Designer can only modify article until is published”. As every person with “form” access, a designer can make himself admin and totally fubar the site.

Unless you disable the preference that allows the use of the <txp:php> tag.

Bloke · 2015-09-18 18:35:40

jpdupont wrote #294967:

The interface must give me fine settings on users privileges.

smd_user_manager might give you a leg up here. You can make a bunch of new groups, specify which groups can see which panels and assign your users to them however makes senses for your application. You can even make new privileges if you like and use the plugin’s built-in tag — possibly coupled with smd_tabber — to write a completely different admin-side workflow.

Destry · 2015-09-19 07:39:37

Great discussion! This intel will make its way into the doc.

Destry · 2015-09-25 16:13:53

Update so far… I used smd_faux_role to help me explore the admin side with the different default roles and against different user accounts having various content contributions. I think I got most of it right, but please verify the table and with associated “Limited access” clarification sections underneath.

One thing I’m unsure about because I can’t replicate the scenario against two different user accounts, is for Copy Editor on the Files panel. Would that be full access or limited? It’s currently marked as limited, but it seems to be it would be full if it’s full for all the other content types.

Note I also tried to provide some context with these roles, both with respect to account types and with editorial roles in the working world in general. In the latter respect it’s not an exact science, but I“m just working with what we have here, and I think if anyone coming from editorial were to see this, it would make a lot more sense now that it ever did before.

I also have some general observations about default role definitions and whatnot for core change consideration:

One of the columns in the default data table on the Users panel is “Privileges”, but should be “Role”, because that’s what it’s actually showing, the role titles. Privs are things the role can do, which is not being shown in the table. Privs are what this doc is detailing in the bottom sections.
Copy Editor: I don’t see how copy editors should have access to Sections since there’s no content there to edit. Sections are structure/presentation thing, so they should belong to the big shots or the Designer, not writers or editors. Forms and Pages, sure, there’s potentially copy there that needs editing.
Freelancer: Since they are external to the editorial team (typically speaking) they shouldn’t be seeing articles in the Articles panel listing that are not their own and not “Live” status. I.e., articles by other roles having draft, pending, sticky, or hidden status should not be seen by Freelancers. Only the Live articles, which they could otherwise see on the public side anyway.
Designer: Why would a designer need Files access at all? Seems like that panel should be blocked by default. I’m not sure why they would need Write panel access either. “Designer” is not a content producer role.

I still need to make some passes on copy and I want to expand on the extension topic a bit more, but let me know if there’s glaring faults somewhere. It was a tedious chore.

Destry · 2015-09-25 19:10:56

Sorry. Forgot to sync changes to the repo. My post should make better sense now.

Destry · 2015-09-30 13:00:08

ruud wrote #294968:

Unless you disable the preference that allows the use of the <txp:php> tag.

I need some clarification here, please. Anyone.

I see two preferences related to PHP:

“Allow PHP in pages?”
“Allow PHP in articles?”

The info pop-up for the “pages” pref says:

“When enabled, this setting allows PHP code within page and form templates.”

I’m guessing that’s the one you were referring to, Ruud, but could a Designer, for example, give himself “admin” rights by using PHP in articles too?

Attention Textpack controllers, that preference should read: “Allow PHP in pages and forms?”. It might as well be clear right on the surface. There’s plenty of room.

Another question…

The info pop-up for the “articles” pref reads:

“When enabled, this setting will allow use of PHP within articles. The author must have sufficient privileges to do so (by default, only Publishers and Managing Editors can).”

I don’t think this is communicating what it’s trying to. The first sentence is okay but the second sentence, as written, is basically saying in relation to the first: only Publishers and Managing Editors can add PHP to articles. The message is a little mixed up. This is better:

“When enabled, any role with privileges to draft articles can add PHP in the article body.”

You don’t need to say more than that because only people with the rights to enable the preference will see the information.

If I’ve interpreted that second info message incorrectly, and indeed only Publishers and Managing Editors can add PHP to articles, then it could say this instead, again more direct and clear:

“When enabled, Publishers and Managing Editors can add PHP in the article body.”

Last edited by Destry (2015-09-30 13:26:37)

ruud · 2015-09-30 17:59:59

“Allow PHP in pages?”

This allows the <txp:php> tag to function outside article body context, so that’s typically in pages and forms.

“Allow PHP in articles?”

This affects how the <txp:php> tag is handled in an article body. Any author can add that tag, but it only works if that author has sufficient privileges: by default only publishers/managing authors have the article.php privilege. If a lower privileged author adds a <txp:php> tag to the article body, it’ll trigger a php_code_forbidden_user error.

Textpattern CMS

Textpattern CMS support forum

#1 2015-09-17 23:32:52