فتحات العرب Joomla! • Index page: Access Control List (ACL) in Joomla! 3.x • Re: Edit, Edit state, Edit own -- Edit state own?

Monday, April 20, 2015

Access Control List (ACL) in Joomla! 3.x • Re: Edit, Edit state, Edit own -- Edit state own?

rcarey wrote:

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.


rcarey wrote:

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





rcarey wrote:

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


rcarey wrote:

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



rcarey wrote:

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

Statistics: Posted by Webdongle — Mon Apr 20, 2015 10:03 am




via Joomla! http://ift.tt/1OxAAQE

No comments:

Post a Comment