[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.

Bloke · 2015-09-30 19:21:11

Destry wrote #295136:

One of the columns in the default data table on the Users panel is “Privileges”, but should be “Role”

I suspect that’s a gTxt() string. You could raise the issue there.

I don’t see how copy editors should have access to Sections

Good point. I’m up for revoking access if others agree it makes sense.

Freelancer… shouldn’t be seeing articles in the Articles panel listing that are not their own and not “Live” status

We could change this. As it stands, they — like some other roles — can see all articles, but can only edit their own. We could clamp down what ‘edit own’ means so it excludes anything they’ve not authored. Does that have ramifications elsewhere? Not sure.

Why would a designer need Files access at all?

Presumably if there are any files that are needed by the site for it to function. But, in the same vein that we discourage the use of the images directory for site-based (as opposed to content-based) images, the same should be true for files: they’re to support content, not for site design purposes. If they’re used in that manner then anyone with access to the panel could remove or alter the file and potentially screw up the site.

So, yeah, we could remove access to this feature to Designers if everyone agrees it’s sensible to do so.

I’m not sure why they would need Write panel access either. “Designer” is not a content producer role.

Again, true. Anyone any views on this to counter this argument? Or should we revoke access here too?

ruud · 2015-09-30 19:30:25

Bloke wrote #295256:

> Freelancer… shouldn’t be seeing articles in the Articles panel listing that are not their own and not “Live” status

We could change this.

Yes please! I’m using a really ugly workaround for this right now on a site which sometimes has content that is published under an NDA (until a specific date) and guest writers are not allowed to see those articles until they’re live.

Presumably if there are any files that are needed by the site for it to function. But, in the same vein that we discourage the use of the images directory for site-based (as opposed to content-based) images

Never heard that before. To me it doesn’t make sense if you can edit everything through the admin interface, except design purpose images.

Bloke · 2015-09-30 19:54:31

ruud wrote #295257:

Yes please!

I’m up for it if a patch emerges :-)

I wrote #295256:

we discourage the use of the images directory for site-based (as opposed to content-based) images

Sorry, that was clumsy. Firstly, we no longer ship Textpattern with images like the carver in that directory: they’re theme based, because that’s where admin-side site design files reside. Secondly, people are free to use the images directory however they please. What I meant was that site designers probably shouldn’t use the Images panel for storing site design images, because then the images have an ID, get linked in the database and are thus editable by anyone who has access to that panel. As you know, if the images are uploaded via FTP to the images directory, they’re still web-accessible by templates and stylesheets but don’t appear in the back-end and hence can’t be accidentally or maliciously altered by users with content-based roles. This should probably be highlighted in the docs somewhere if it isn’t already.

My badly-made point was that the Files probably fall under the same kind of thing, but with the Files panel there’s an extra hurdle. If, for whatever reason, a designer uploads site-based files via FTP to the files directory, those files can be imported into Textpattern from the Files panel, since any unconnected files appear in the dropdown. So designers shouldn’t be using this directory for anything design-related if they wish it not to be tampered with. Not that I can think of a reason why a designer would be using files in the first place, unless they’re third party PHP scripts that add extra functionality or something. Which kinda backs up Destry’s point that it makes no sense to give designers access to this panel at all.

Textpattern CMS support forum

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