The
ACL rules you are looking for are more refined than what 2.5 offers out-of the
box:
- You have to set "Edit
State" to "allow" to grant permission to publish/unpublish,
but this permission does not distinguish based upon author.
- You have to set
"Create" to "allow" to grant permission to create
articles, but the permission to create includes new subcategories as well.
ACL is enforced at the code level, so if one needs
additional permissions or finer control of permissions, then this logic needs
to be added at the code level. (I don't think
you are going to find a solution to your needs through some configuration of
permission settings.)
The logic you need can be created with just a few lines of code and inserted
into select view files - files that can be overridden so the changes are safe
from upgrades. Here is an approach that will accomplish what you are looking
for:
If a user is have the ability to publish/unpublish articles, you will need to
allow the permission "Edit State" upon the respective component,
categories, or objects. Then you need to edit the view files that display the
publish/unpublish option and add the logic that will hide or show this option
based upon the current user. For instance, the following line will evaluate to
true if the user is the same as the article's author.
Code:
$item->created_by == $userId
...but you will probably want to grant
admins, super admins, and perhaps other groups the ability to publish/unpublish
any article and not just their own, so you might be using some code like this:
Code:
$groups =
$user->get('groups');
$canEditOthers = in_array(7,$groups) || in_array(8,$groups) ;
if($canEditOthers || $item->created_by == $userId){
// code that displays the publish/unpublish option.
}
Here are the view files that display this option (which need to be overridden
with you logic added):
• /administrator/components/com_content/views/articles/tmpl/default.php (shows
the list of articles with the publish/unpublish icon)
• /administrator/components/com_content/views/article/tmpl/edit.php
("article" is singular - the form for editing an article)
Remember, you should be overriding this file - if you hack it, all your
changes will be lost with an upgrade to a new Joomla version.
You can follow a similar approach in order to limit a user's ability to create
categories. Ideally, we'd like to suppress the "new" option, but this
is not that easy. So I suggest adding logic to the category edit screen that
will not display unless the user has additional credentials (whatever you want
them to be).
Override the following file
• /administrator/components/com_categories/views/category/tmpl/edit.php
In overriding this file, you should add you logic before the form is being
built. If your added logic says the current user does not have the right to
edit/create a category, then execute "return;" which will break out
of the file before the form is displayed - rendering this edit screen
inoperable for any edits or saving as anew category.
Here is the sample logic that will allow only admins and super admins to
proceed:
Code:
$groups =
$user->get('groups');
$canProceed = in_array(7,$groups) || in_array(8,$groups); // in
group admin, or super admin
if(!$canProceed){
return; // break out of this file so that the edit form is
not built
}
Sometimes we
desire more specific rules than what ACL gives us out-of-the-box. As we grant
the permissions we need, those permissions might extend beyond the scope we
want. If we can live with this, we do. That finer-grain control is attained at
the code level. Fortunately for us, we often can attained what we need by
overriding one or more view files.
Comments
Post a Comment