Edit, Edit state, Edit own -- Edit state own?

[waarnemer]

I am struggling with the following;

I have author group allowed to "edit" and "edit state"..
I also have an author group allowed to "edit own".. and I would want them to allow "edit state own" too...

I can only set "edit state" to the last group, but then they are allowed to publish or unpublish articles of others as well... is there a way to set "edit state own" in some way? workarounds?

Or is it supposed to work like I want but does not?(facing a bug maybe?)

Tx,

[goldengravel]

Why don't add the users to both groups?

[waarnemer]

The point is that I DON'T want the users to edit the state other then their own.....

[Webdongle]

Why don't add the users to both groups?

Best to have each user only in Registered and only one other user group.

In Global config >>> Permissions ... you can change the 'Edit State' to 'Allow' for Author and Editor.

Or you could set your 2 new user groups to have Author as 'Parent' ... then have every setting (except 'Edit State') as 'Inherit' ... then Allow 'Edit State'

[waarnemer]

"allow" - "Edit state" also allows them to edit the state of articles from others.
I am looking for a way to have "Edit state own".

[Webdongle]

"allow" - "Edit state" also allows them to edit the state of articles from others....

'Edit State' only allows a user edit Articles that they are able to edit.

Group A
Create ........ Inherited ... Allowed
Edit ............ Inherited ... Not Allowed
Edit State .... Inherited ... Allowed
Edit Own .... Inherited ... Allowed
Can only edit the publishing state of their own Articles because they can only see the edit screen of their own Articles !!!

Group B
Create ........ Inherited ... Allowed
Edit ............ Inherited ... Allowed
Edit State .... Inherited ... Allowed
Edit Own .... Inherited ... Allowed
Can edit the publishing state of all Articles because they can see the edit screen of all Articles.

[waarnemer]

I wish that was true as in my 3.4.1 a user can still publish/unpublish articles of others..
even when Edit is not allowed....

[Webdongle]

It is true ... Either you have not set the permissions correctly or you have a 3rd party extension that is overriding the Joomla ACL

Addendum
A badly written override of a custom Template can ignore the ACL settings

[waarnemer]

That is front end ok.. but when I do the same with back end it doesn't work that way.

The publish and featured icon are still click and changeable in backend article manager..

[Webdongle]

Yep that looks like a bug. Did you start the tracker http://issues.joomla.org/tracker/joomla-cms/6801

[waarnemer]

yep... as it occurred to me after few days going up and down all ACL settings it must be a bug

[rcarey]

As I understand your discussion, I do not see this as a bug. The action of changing an article's state is independent from the action of editing that article. In other words, the ability of a user to change the state of any given article has no connection with that user's ability to edit the article.

A user who can view the list of articles but cannot edit them will still see the articles he/she cannot edit. Because Joomla's core ACL provides an all-or-none permission on changing an article's state, the user will be able to change the state either on all articles or none of the articles - even if the list contains articles that the user cannot edit.

It is possible, and rather easy, to control on which articles a user can change state from the list view within the backend. Here is how...

[1] Override the template file administrator/components/com_content/views/articles/tmpl/default.php
[2] Around line 120 you will see the line of code that defines the variable $canChange. Below this line add a new line of code that is true only if the user should be able to change the state of the item being added to the list. Here is code that should work for you

Code: Select all

$canChangeState  = $user->authorise('core.edit.state', 'com_content.article.'.$item->id) && ($item->created_by == $userId || $user->authorise('core.admin', 'com_content.article.'.$item->id));

What this does is require the user have permission to change state and either is the owner of the article or an admin of com_content or of the particular article.
[3] Now go to around line 148 where the code references 'jgrid.published'. Within that line of code change the variable from $canChange to your newly created variable $canChangeState.

That should be it... at least for the list view.

[a] If you need to allow a user to edit other articles but not change the article's state, then you will need to override some code for the article view (in addition to the list view as coded here).
This approach keeps honest people honest, but a malicious user who is very tech savvy could find a way around this override and change the state of an article for which he/she should not be allowed to edit. A simple plugin could be written to provide that deeper level of security to prevent this, but I'm assuming you will not be needing that.

[Webdongle]

As I understand your discussion, I do not see this as a bug. The action of changing an article's state is independent from the action of editing that article. In other words, the ability of a user to change the state of any given article has no connection with that user's ability to edit the article.....

It comes down to the definition of Edit. Some would take the stance that 'Edit' meant to change the text ... but imho changing if an Article is displayed or not is an 'Edit' of the Article. For someone to unpublish or trash an Article that they can't edit makes no sense because it has the same result as them deleting all the text. Allowing a user (who is not able to delete the text of an Article to edit the publishing state of an Article ... or trash it ... is a security risk. If someone does not have the security level to change the wording of an Article then they should not be allowed to remove it from view or trash it.

[rcarey]

I can imagine editorial workflows where one role is able to publish/unpublish articles (or whatever item the component is) without being able to edit the content. For instance, a department might be the only ones qualified to write the domain-specific content that belongs to its category, but the webmaster or other gatekeeper has the ability to display or hide an item. Or if the site is multilingual, perhaps a rule is that only someone who knows the language well can edit an article that is written in that language, while some gatekeeper still has the ability to control what is displayed and what is not.

But putting our own perspectives aside, it is clear from the code of the core components that the state permission is independent from the edit/edit.own permissions. It seems to be how the core team intended it to be.

Consider further that the action state applies to feature, ordering, and category assignment as well as to published. It is conceivable that an organization will want to have someone control one or more of these settings without being able to change the text.

I see a bigger security dilema - that out-of-the-box we are forced to choose between all-or-nothing when it comes to state. If the site integrator does not know how to inject special logic, then he/she if forced to escalate a usergroup's permissions to more than that group needs just to get the slice of what more it does needs. That is the problem that waarnemer was facing - having to allow a usergroup permission to publish/unpublish any article when all that is needed is for the user to publish just his/her own articles. I posted a solution to demonstrate to waarnemer and others that Joomla allows us to refine access control beyond what we get out-of-the-box.

[waarnemer]

@rcarey: if you state that edit/edit own is independent from edit state then I cannot conclude other than this is a feature forgotten to implement as it makes absolutely no sense that a user who can only edit own would be allowed to edit state of all.
I can be clear from code, but a clear code is not the same as clear functionality.

I am gonna put your lines of code to the test.. but a feature plugin or more refined core solution would be more welcome.

I'll let you know how this works.. Tx

[Webdongle]

I can imagine editorial workflows where one role is able to publish/unpublish articles (or whatever item the component is) without being able to edit the content. For instance, a department might be the only ones qualified to write the domain-specific content that belongs to its category, but the webmaster or other gatekeeper has the ability to display or hide an item. ...

Giving the 'webmaster or other gatekeeper' the 'ability to display or hide an item' that they are not qualified to write is ludicrous. Because they would not be able to evaluate the accuracy of the Article and therefore would not be competent enough to asses if it met the criteria for publication.

... Or if the site is multilingual, perhaps a rule is that only someone who knows the language well can edit an article that is written in that language, while some gatekeeper still has the ability to control what is displayed and what is not.

Giving the 'gatekeeper ... the ability to control' the display of Articles that are written in a language they do not understand is also ludicrous. Because they would not be able to evaluate the accuracy of the Article and therefore would not be competent enough to asses if it met the criteria for publication.

...
But putting our own perspectives aside, it is clear from the code of the core components that the state permission is independent from the edit/edit.own permissions. ...

There have been several instances where 'it is clear from the code of the core components that the' code is intended but later had to be altered. An example of that is when a visitor receives a copy of a message they sent to a contact. Originally the reply address was that of the contact ... which was obviously a bug. Because the contact may not want the visitor to know their email address. Therefore the 'intended' code was altered so the visitor could not use the copy of their message to email the contact directly.

...
Consider further that the action state applies to feature, ordering, and category assignment as well as to published. It is conceivable that an organization will want to have someone control one or more of these settings without being able to change the text....

Again it is ludicrous to give control one or more of these settings' to someone who is not qualified to edit the text. Because they would not be able to evaluate the accuracy of the Article and therefore would not be competent enough to asses if it met the criteria for publication.

...
I see a bigger security dilema - that out-of-the-box we are forced to choose between all-or-nothing when it comes to state. If the site integrator does not know how to inject special logic, then he/she if forced to escalate a usergroup's permissions to more than that group needs just to get the slice of what more it does needs. That is the problem that waarnemer was facing - having to allow a usergroup permission to publish/unpublish any article when all that is needed is for the user to publish just his/her own articles. ...

That is exactly why it is a bug ... a user in a user group who should only be allowed to edit state (or otherwise manipulate) their own. Because they would not be able to evaluate the accuracy of Articles that were created by other departments and therefore would not be competent enough to asses if it met the criteria for publication.

[waarnemer]

Well bug or gap in the feature.. to me it is the same and it needs fixed.. it ain't working as expected.
Also I cannot imagine why one would not be able to edit some he can delete, change and/or move.. just makes no sense at all... I cannot imagine it is meant that way.

Anyway:

@rcarey at least pointed me into the right direction to solve things for now.
Though there is much more to change than the few lines he mentioned.. without the hint I would have never thought of the override.. a big thanks for that.
I had to adapt some of the code as it messed with the ACL when users other then admin where allowed to edit and change all.. Did not quit work ok. I needed a switch for edit and edit own stuff and also needed to make more changes (checkbox disable, dropdown status disable as these remained available.
Only thing I am not able to tackle yet is the sort order move around thingy...)

In the attached file is what I added to: administrator/templates/isis/html/com_content/articles/default.php

overrides.zip

Edit: made a tiny correction and added categories and featured overrides

[rcarey]

I'm glad this led to your solution.

I qualified step [2] to explain the condition I chose to implement. Each site that has a need to restrict the state permission might have different business rules for how that restriction should be applied. So it is up to the site integrator to code the condition desired (as I see you did in your file).

As for the ordering issue you are now facing... I see that your variable in line 115 is missing the dollar sign. That will affect the ordering column.

[waarnemer]

I corrected that one already. It was in my reedited attachment.. But that only greys it out.. functionality remains.. there is something else missing in my "philosophy" there....

anyway if you have a sort order set "by date" in the component parameters in the front end, it is not that important. It only is functional when the sort order in the pages view is based on that manual order.