| Project: | Taxonomy Access Control Lite |
| Version: | 6.x-1.4 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
Hello,
I am using TAC_Lite to provide access control for an Intranet/Extranet project.
- I use NAT to automatically create a term in the taxonomy for every new customer node I create.
- All document nodes for each customer are then associated to the customer taxonomy term.
- Then I use TAC_Lite to restrict access for the customer user to his documents only.
This works really well. The issue comes when I want to have a role (Secretary) that has access to all customers, and hence to all taxonomy terms.
TAC_Lite provides for a way to give access for a role to all existing terms by manually selecting them all, but when I create new customers, and new terms are added, they are not automatically added to the TAC_Lite list for the Secretary role.
Is there a way for a role to be asssociated by default to all (existing/new) terms in a vocabulary? So that the Secretary role is automatically given access to new terms in this vocabulary.
Comments
#1
The quick solution is to grant Secretary the administer_tac_lite permission. Then that role will not be restricted by tac_lite in any way. But also they will be able to change tac_lite settings, which may not be good.
Other than that, I have no good suggestion. I don't know of a clean way to support what you're asking for. I'll think about it.
#2
The quick solution is to grant Secretary the administer_tac_lite permission. Then that role will not be restricted by tac_lite in any way. But also they will be able to change tac_lite settings, which may not be good.
Other than that, I have no good suggestion. I don't know of a clean way to support what you're asking for. I'll think about it.
#3
Thanks a lot Dave. That is a good quick fix for this case, and I can proceed with this project, but it would be great to have that functionality in TAC_Lite.
Please consider my suggestion to improve this fantastic module.
#4
From an interface standpoint, I think the logical way to implement this would be to have an < all > option on the page for access control by taxonomy.
I'm not saying that implementing that would be easy, but to me, that would be the logical way to add it.
+1 for this feature, I'd find it useful too.
#5
I have a similar issue where I have sites
Site A
-- Site A1
-- Site A2
---- Site A2a
-- Site A3
Site B
-- Site B1
Where the sites constantly change. I would like to be able to set a user to see site A and everything underneath it. So if a Site A2b was added, they would have access to it.
I was thinking the easiest way might be to add an permissions option "can view/edit/delete term children" -- certain roles could then automatically see nodes tagged with terms that had been added underneath a site they already have access to view.
Great Module!
#6
That sounds rather complicated for tac_lite. But if you provide a patch I'll look it over.
You might be better off with a module which automatically tags a node with parent terms whenever it is tagged with a child term. That is, if someone selects Site A2a, the node is also tagged as Site A2 and Site A. This would lead to the behavior you want in access control, and probably what you want when viewing nodes by taxonomy and other taxonomy-related behaviors. I don't know of a module that does this, but I think it would be useful and perhaps it already exists.
Another option to consider is adding another vocabulary with terms like "Site administrators" or "Site A Administrators" and configure tac_lite to grant permission based on those terms. You could even use hook_form_alter to hide such a taxonomy from end users.
#7
#5 is not quite a similar issue. Probably better related to:
#213267: Allow access on children items
But maybe the "All" option feature request I've just opened for surge_martin's #4 suggestion might solve Digital Deployment's problem too:
#333320: "All" option per vocab for by default access to All terms (and new ones automatically).
#8
This doesn't seem to work for me. The user, even with administer_tac_lite, still doesn't see any of the content. Any suggestions?
#9
For the time being I did this patch...
function tac_lite_taxonomy($op, $type, $array = NULL){
global $user;
if ($op == "insert" && $type == "term")
{
$schemes_number = variable_get('tac_lite_schemes', NULL);
for ($i = 1; $i <= $schemes_number; $i++)
{
$terms_restricted = variable_get('tac_lite_grants_scheme_'.$i, NULL);
$tid = $array['tid'];
$user_roles = array_keys($user->roles);
foreach ($user_roles as $rid)
$terms_restricted[$rid][1][$tid] = "$tid";
variable_set('tac_lite_grants_scheme_'.$i, $terms_restricted);
}
}
}
#10
It is more correct patch that I did.
#11
The hook_taxonomy code looks pretty good. If I understand correctly, it only pays attention to roles, not individual users, and only to update, not view or delete. Right?
If it were made configurable (i.e. a checkbox on each scheme) and worked with users and all privileges, I'd probably add it to the module. As is, it may be a useful patch for those who want it to work that way, but not a candidate to be in the module itself.
#12
Thank you for reviewing.
I did it this way because for our requests it's enough. But I will finish it in way you are suggesting this week, I think for some users it will be useful.
#13
So now I did this patch configurable (it has checkbox on every scheme) and this works with per-user permissions and all privileges. Also I noticed that some things were not correct in my previous version.
But when I thought carefully how it can work and don't damage existing permissions I found only this way: when user create new term it will has the same permissions that its parent has until administrator will review it and maybe change.
But if new term has no parents, it means that it is top term on vocabulary, we have no any arguments to give it some default permissions because we don't know what permissions to give (view, update or delete) and according to which scheme... Maybe the best way is to leave it for administrator because we should keep on mind security of the site. If you suggest something about this it will be cool.
#14
Good points. I generally try to avoid this kind of complexity.
I could see, maybe, instead of a checkbox on each scheme a select of vocabularies. So it would prompt, "automatically add new terms from these vocabularies to this scheme."
But more important, I don't like the loop over all users. I understand why it's there, but many sites will have too many users for that code to work well. Can't call user_save() potentially thousands of times every time a term is added.
#15
Using this but as stated in that post, I'd prefer to use a solution in the module rather than resorting to a clever workaround. A select option or a checkbox for each vocabulary like Dave stated above would be ideal.
Subbed.
#16
I used Content Access to set global view and edit permission for a role on the content type. This works if you only need to give access on the content type level and not the vocab level. This worked fine for my situation were I only have one vocab on a specific content type that is using TacLite and I only need a admin role to have access to all node of that type regardless of TacLite permissions. All other uses that do not have the admin role require the correct TacLite term permissions to access the content.
The only downside to this is that this solution does require two access control modules.