Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: [doc] User roles and privileges
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?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
Re: [doc] User roles and privileges
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
imagesdirectory 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.
Offline
Re: [doc] User roles and privileges
ruud wrote #295257:
Yes please!
I’m up for it if a patch emerges :-)
I wrote #295256:
we discourage the use of the
imagesdirectory 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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
Re: [doc] User roles and privileges
ruud wrote #295257:
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.
Exactly. Freelancers are external to the ‘company’. They have no business seeing the intellectual material of the publishing house (or that of other freelancers) that is not already public.
Offline
Offline
Re: [doc] User roles and privileges
etc wrote #295268:
A designer could have some difficulties to test his work if he can not write a “test” article. Just my 2 kopecks.
In a collaborative situation, a designer wouldn’t need to produce content, since it’s not their responsibility. The content would already be there for them (because it’s first in the design process when done right), whether a test article for the purpose or an existing article. And if one didn’t exist, the designer simply asks the publisher to create one based on what new element(s) might need testing, because collaborative. No designer should be working in a bubble, or beyond their scope.
2 cockles.
Last edited by Destry (2015-09-30 21:20:21)
Offline
Re: [doc] User roles and privileges
Bloke wrote #295256:
I suspect that’s a
gTxt()string. You could raise the issue there.
I will.
[Copy Editor|Sections, blocked] Good point. I’m up for revoking access if others agree it makes sense.
As a working professional in editorial, I thank you for the vote of confidence. As you know, members of the equine committee usually (there are fine exceptions) don’t pipe up unless they have a contrary opinion (as opposed to an informed perspective based on industry convention). Silence from the majority could be taken as agreeing with the logic, or not caring one way or the other. So would no response to the contrary also favor changing it?
I’m only asking because I’d like to put a blue marker on it in the table to show it’s going to change (if it is) in the next release, for example.
And yes, I’m tugging your chain a bit, because, you know, you’ve got so much time on your hands. ;)
[Freelancer|Articles, limited=own material and “live” only] 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.
As implied already, giving outsiders read access to unpublished intellectual material isn’t what happens in the real world. A situation taken pretty seriously, in fact.
[Designer|Files, blocked] in the same vein that we discourage the use of the
imagesdirectory for site-based (as opposed to content-based) images, the same should be true for files … So, yeah, we could remove access to this feature to Designers if everyone agrees it’s sensible to do so.
Right. The situation with putting theme/presentation images on the server (not in the database), which I know Phil is adamant about, is partly where my inquiry comes from. But also, most people think of “files” as .pdf, .docx, .txt, whatever, so 99.9% of the time that’s what kind of files will go there, because in the business world “files” basically means text content or data files. Based on that observation of what happens in the macrocosm, it doesn’t seem like Designers need access there; it’s out of their scope in terms of the admin-side because they’re not content producers (they shouldn’t be). They always have the front-side access to files, which for their purposes is enough.
I realize Designers may produce files like mockups from Photoshop, for example, which can rightly be argued as non-text or data files. But this context loops back to the initial logic of how a real collaborative web design process would actually go down, and where those kinds of artifacts would be shared and stored. Probably not in the system that is under design and development, but in a collaborative repo elsewhere.
[Designer|Write, blocked] Again, true. Anyone any views on this to counter this argument? Or should we revoke access here too?
I don’t want to beat a dead horse… Ba-da-boom! But you know my position. Actually, see my next post.
I know it’s tough being in the judges chair, but as the District Attorney (docs editor) I’m trying to give you responses based on logic and convention (the evidence), to make your decisions easy. Ultimately I abide by your ruling. ;)
Last edited by Destry (2015-10-01 08:12:28)
Offline
Re: [doc] User roles and privileges
Hmm…
Regarding a Designers rights to the Write panel… I’ve been arguing to block them from there under the perspective that they currently have the right to create a draft, and that they are, somewhat, of an outsider role (similar to Freelancer). But they can’t create a draft. They can only see full articles in the panel. In that case, maybe it’s fine as is. Unlike a Freelancer, who’s outside of the ‘org’, a Designer might be considered as inside the org, thus just seeing articles would be fine; presumably their already under the orgs NDA. (Again, if they need to create a test article, they should have someone with higher rights do it for them according to spec, fit to the logic of the role’s scope and the collaborative process.)
The hanging question then, would be: Is a “designer” always considered inside the org? In the outside world, designers are often consultants, so it could be factored either way here. If considered outside, then the logic as applied to Freelancers would make more sense… they shouldn’t have access to what they don’t need to see.
Maybe the middle ground is Designers have read access to only articles having one of the non-published statuses: Draft, Pending, or Hidden. Nope, that wouldn’t work from an NDA perspective if they were contractors. Though other status are already a little confused in terms of specific use so using one of them might just add to their confusion.
Maybe this is a time to create a “Test” or “Concept” status specifically scoped to the Designer’s privileges for presentational purposes only. In that case, a Designer could create a ‘test’ article, and would only see their test articles in the Articles panel.
On the other hand, it still wouldn’t hurt to just block Designers from the Write (thus Articles) panel. It’s easier to do, I suspect, than code up a new status, and it solves both contexts of inside/outside relationship.
Sorry to be a pain. When you dive into functionality to write docs about it (technical writing), you start seeing and thinking about the logic of things deeper than you would otherwise, and should raise flags when oddities are found. That’s what’s going on here and will likely go on as the deep dive editing continues.
Last edited by Destry (2015-10-01 09:16:12)
Offline
Re: [doc] User roles and privileges
Different issue… As I look at the privileges table, the redundancy between the Publisher and Managing Editor seems obvious and too much, no? The only difference is that ME’s have slightly less control on user accounts. I’m not sure that justifies the ME role at all. The Managing Editor should probably not have so much rights as the Publisher, otherwise what’s the point? I don’t have suggestions off hand about what additional restrictions they should have, I’ll have to research that a bit, but it doesn’t seem logical as is.
This makes me wonder about the many times I’ve collaborated with people who tell me they need “Publisher” role to help with all the content and design stuff, I never thought twice about it, but in fact they don’t. A Managing Editor role, as core is currently setup, would be sufficient. This has never been obvious to me before without this cool, new table. Already paying off. ;)
EDIT: Just remembered that ME’s don’t have read access on the Extensions panels. That’s not in the table because it’s not exactly core, but I think it should be in this case — in the table, I mean. I’ll add it. Still, is that enough yet to distinguish Publisher and ME roles?
Last edited by Destry (2015-10-01 12:02:33)
Offline
Re: [doc] User roles and privileges
Destry wrote #295286:
would no response to the contrary also favor changing it?
Sure. I’ll give it a day or two and if nobody complains, it’s fair game.
The only difference is that ME’s have slightly less control on user accounts
Yes. They can’t create or edit users, which minimises misuse from what is otherwise an identical feature set as Publisher. Oh, and they don’t have as much detailed debugging info available to them on the admin side when the production status is cranked up. They do have full access to the extensions panel, but what they see there is up to plugin authors.
As you noticed, having the differentiation of user account control gives you a nice way to delegate the site’s day-to-day management to your colleague without burdening them with hiring and firing user accounts. It also allows you to limit your attack scope by only having one Publisher account per domain. If your otherwise trusted colleague chooses a crappy password, someone else could screw your site up, but at least they can’t (easily) make themselves a user account and cause more havoc. PHP in Pages/Forms notwithstanding.
When you dive into functionality to write docs about it (technical writing), you start seeing and thinking about the logic of things deeper than you would otherwise
That’s absolutely fine. Keep it up. It drives change and helps keep the core cruft free as we uncover stuff that’s outdated or plain doesn’t make sense.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
Re: [doc] User roles and privileges
Bloke wrote #295295:
Oh, and they don’t have as much detailed debugging info available to them on the admin side when the production status is cranked up.
Ah, good to know. Hmm… I guess that one will be a footnote.
They do have full access to the extensions panel, but what they see there is up to plugin authors.
Also good to know. Thanks.
It also allows you to limit your attack scope by only having one Publisher account per domain. If your otherwise trusted colleague chooses a crappy password, someone else could screw your site up, but at least they can’t (easily) make themselves a user account and cause more havoc. PHP in Pages/Forms notwithstanding.
I like that. I’m going to use some of that in the Publisher role description. ;)
Offline
Re: [doc] User roles and privileges
Managing Editors…
Bloke wrote #295295:
they don’t have as much detailed debugging info available to them on the admin side when the production status is cranked up.
What do you mean by “when the production status is cranked up”? I need to put this into user doc terms.
Offline