Role management questions

I have some questions related to the Manager/Role management/Create or edit role settings:

1. Does the permission to Create documents imply the permissions to edit, save and change the created documents?
2. Does the permission to Edit a document imply the permission to Save it?
3. I am missing one very crucial permission here: the permission to publish/unpublish documents! And maybe the permission to change published documents.
4. How does MODx manages ownership of documents?
(i.e. the privileges of the user who created it: how are they defined by default? I would like to permit users to create/edit/save documents, but NOT to change published content, but to require a specific approval from a "Super-Manager" (ususally named "admin").

I think the answer to the first two questions should be "yes" - but is it so?
The third and fourth question are highly relevant for workflow-issues. Content-management does also mean "responsibility-management", and the latter is directly related to the act of publishing, not of creating or editing, as long as the results are not published.

And for the third question: the option to create "dynamic" document groups, based on their published status could be of great help, without changing the current permission-policies. (Which means, that MODx could create automatically document groups for published, unpublished and deleted docs.)

Another useful feature could be to implement user-related document-groups (provided by default) like:
- documents I have created
- documents I have edited
(a bit similar to the way these forums work)

If MODx wants to compete with CMSes like Joomla (or even the small/french SPIP, which I find quite nice and to be very aware of workflow-issues, which may be due to their history of making previously printed magazines web-ready) it should address those aspects. MODx seems to be focused mainly on how to create the most flexible and powerful front-end experience - which is usually the main aspect for smaller projects, admined by just one person. But for more bigger, corporate-related projects MODx should be more aware of all that workflow/responsibility-related issues.

EDIT:
addition to first paragraph:
- documents I have published
- documents I have unpublished/deleted

Quote from: ppaul at Jul 29, 2006, 04:42 PM

I have some questions related to the Manager/Role management/Create or edit role settings:

1. Does the permission to Create documents imply the permissions to edit, save and change the created documents?

No, except for the save part.

2. Does the permission to Edit a document imply the permission to Save it?

I’d think so... kinda be difficult to make the changes stick otherwise.

3. I am missing one very crucial permission here: the permission to publish/unpublish documents! And maybe the permission to change published documents.

Perhaps. There are no publish permissions currently, although if you create them and make it work we’d gladly include it!

4. How does MODx manages ownership of documents?
(i.e. the privileges of the user who created it: how are they defined by default? I would like to permit users to create/edit/save documents, but NOT to change published content, but to require a specific approval from a "Super-Manager" (ususally named "admin").

The permissions system is currently not that granular. It’s purely groups based. If you want to emulate that granular of permissions, you’d need to create separate groups per user. Although that’s a hackish work around.

I think the answer to the first two questions should be "yes" - but is it so?
The third and fourth question are highly relevant for workflow-issues. Content-management does also mean "responsibility-management", and the latter is directly related to the act of publishing, not of creating or editing, as long as the results are not published.

MODx in its current state is not a good "workflow" platform. You can get creative and work around some bits, but we’re a ways off.

And for the third question: the option to create "dynamic" document groups, based on their published status could be of great help, without changing the current permission-policies. (Which means, that MODx could create automatically document groups for published, unpublished and deleted docs.)

I don’t see a question there, but it’s a good suggestion.

Quote from: ppaul at Jul 29, 2006, 05:29 PM

Another useful feature could be to implement user-related document-groups (provided by default) like:
- documents I have created
- documents I have edited
(a bit similar to the way these forums work)

Great idea indeed! Although that begs the question of versioning as well, since what happens when someone edits a doc after I edited it. Current DB structure only dictaes the creator, publisher and last editor. There coudl be many edit occurences between the first two and the last one. And these are all issues of which we’re very well aware.

If MODx wants to compete with CMSes like Joomla (or even the small/french SPIP, which I find quite nice and to be very aware of workflow-issues, which may be due to their history of making previously printed magazines web-ready) it should address those aspects.

Joomla! is not really our benchmark. I think that honestly is a totally diffenent application. If you were to ask someone who only cares about creating CSS sites, they’d probably say that if Joomla! wants to compete with MODx...

MODx seems to be focused mainly on how to create the most flexible and powerful front-end experience - which is usually the main aspect for smaller projects, admined by just one person.

Then you clearly don’t have enough seat time, as far more complex applications are possible. Ask Adam who has over 200 editors of 2500 pages. Or Jared with similar numbers. Or Jason and me and Victor with totally custom applications built that support thousands of users in non-native DB tables.

But for more bigger, corporate-related projects MODx should be more aware of all that workflow/responsibility-related issues.

It all depends on what type of "big" corporate projects you mean.

In all fairness, MODx is not tailored to big corporate projects right now. You honestly probably need to be on larger multi-tiered, multi-server implementations in a JSP environment with a full time dev and support team. I’m not saying we won’t get there and that releases in the near future won’t be a major step in that direction, but today, we’re not. We’re more than aware of the current limitations and we don’t pretend to make MODx something it’s not

Thanks for your reply, Ryan!
I guess this "auto-doc-group" thing (on published-state and on a per-user basis) would be worth to be investigated.
I will give it a try, and come back to this topic after then. I fear this type of functionality can not be put into a module, but must be placed in the core.
And the versioning-problem, I think this is not so relevant, since the doc-groups serve to provide editing-permissions. [EDIT: i.e. not to manage different versions of a doc] The only functionality required would be to move a doc from one "user-auto-group" to another (by assigning a different user-ID for the edited-by value). I have a "self-made" CMS working which handles it like that. Runs fine, works well.
And for the "publish"-control: Most of the requirements which lead to need such a feature are covered already by the "auto-groups" I guess. For the rest it would be necessary to know, where to intercept the "publish/unpublish" event, like the "save" event. (could you point me to the right place in the manager’s code?
BTW: in my opinion "publishing" is also "editing" (not the content, but the state of a doc).
Can I publish a doc that I am not allowed to edit in 0.9.2.1 ?

Joomla: J! has the greatest share in the "What have you used before MODx?" poll. So I argue that there is a kind of competition though. And when you or Jason or others who know MODx from the inside create big projects, using MODx more as a framework than a CMS, than this might not be very representative for the user-community as a whole.

You are right, that the issue of workflow is not directly related to the size of the project, but to the type of the client. Some clients have to care very much for legal issues and are steered by responsibilities and policies. And then they require an approval-step. (Most of my clients require this, so my first real MODx-site will be my own. )

I really look forward to seeing what you come up with Paul. We’re definitely not against including code in the core that makes it better. FYI, we’ll also have a public beta in the coming week or so of the next release and I hope you can help us get some things sorted there as well. I hope you’ll like what you see.

I’ve spent some more hours with that User/Role/Document stuff.
I could write down here my findings in all detail, but its far easier and more concise to put them as an example:

I have a DocA and a UserB.
I want to make that DocA editable only for UserB, but viewable for all others.

So what have I done?
1. created a DocumentGroupX
(since this is the only option to manage the access for docs )
and a DocumentGroupY (why? see step 8 )
2. created a UserRoleC, which can edit
3. created a UserRoleD, which can NOT edit, but view
4. edited UserB to have the role of UserRoleC
5. set all other users to UserRoleD
(otherwise, DocA would become unviewable because of ->step 8 ).
6. defined a UserGroupE
(since this is the only option to manage access for docs based on users ))
7. set the access permissions of UserA to UserGroupE
8. assigned DocumentGroups X and Y from step 1 to DocA, one for editing, one for viewing.
9. created User/Document-links for UserGroupD/DocumentGroupX and
10. UserGroupE/DocumentGroupY

If that is really the only way it works - I do not think I’d have to comment on that...

My guess is that at least one of the four present concepts: role, usergroup, user-access-permissions, docgroup is redundant but creates interferences which make dealing with doc-based-permissions ... almost impossible. (I think that could be put in a very stringent logical argument, but right now I’m too confused by that stuff. )

My first suspicion:
Maybe it’s the docgroup AND usergroup which creates all this mess.
I am used to set the rights for a doc in a set of different permission-types, like view, edit, delete, publish and provide one or more roles (or groups) a user has to have to get that specific permission. EDIT: and a value for who is the actual owner of the doc. He can edit anyway.
Then let copies of docs inherit that settings, provide (only) the creator of a doc with editing and viewing-rights for his creation by default and you’re done.
No need for all that trouble then, and MODx would be not only more functional but also more straightforward to use and to program.


But maybe I’m just too dump to catch on.

BTW: the right to EDIT does indeed NOT imply the right to SAVE!
You can edit a doc as long as you wish, but when you click "SAVE" you will be told that you don’t have the permission to do that! >:(

Just another reply to self:
The concept of "cross-tabling" doc-groups and user-groups is apparently devoted to maximum flexibility. But the outcome is maximum confusion. Too many lists, too many values to set, too many forms, too much at all.
Since I think that most members of the MODx-devteam do not care about permissions so much this must be an etomite-legacy-issue.
(I remember some visualisations on role-management at the etomite-site: and I frankly admit that I didn’t understood one of them )
My purpose here is not to critizise MODx, but to make it "business-ready". Don’t know of what kind the amazing 100+ users sites (mentioned by rthrash) are, but for my projects: they are mostly for big companies and as such subject to their approach of managing "permissions".

Quote from: ppaul at Jul 31, 2006, 03:49 PM

Since I think that most members of the MODx-devteam do not care about permissions so much this must be an etomite-legacy-issue.
(I remember some visualisations on role-management at the etomite-site: and I frankly admit that I didn’t understood one of them )
My purpose here is not to critizise MODx, but to make it "business-ready". Don’t know of what kind the amazing 100+ users sites (mentioned by rthrash) are, but for my projects: they are mostly for big companies and as such subject to their approach of managing "permissions".

Do not care about permissions???!!! Wow, I would not argue that the etomite legacy permissions approach is quite pathetic, but you are coming across as quite abrasive at times, I must say. I think I better stop this reply before it goes too far.