Cannot create node in taxonomy term without create permission for parent term

I have a same problem: if I uncheck Create checkbox in parrent caterogy, then users see only blank combobox in add node page (although there are checked Create checkboxes for this user).

Is there any solution?

I run Drupal 5.1 and mysql 5.0.x.

why not create multiple taxonomies..or get rid of the offending holding containers? "solid" doesnt provide so much information, does it? especially since this is so granular?

I have the same problem, no terms show up in the Taxonomy window if I want to create a new page and "create" for the partent taxonomy term ist unchecked.
I run Drupal 5.1, PHP 4, MYSQL 4.1.22.
Is there any solution?

OK, I will provide details about my needs.

I have one vocabulary with hierarchy and I need for user to choose one term in his scope (it means where he has priviledges).
Structure is following:
-Department IT
--Clients
--Servers
--Mail system
--Others

So I want to have pages in 2nd level and also in 1st level (in Department IT).
And I need to provide privilegdes for managers for Department IT, and for chief of Clients, Servers, ... ONLY to their categories, but not to top level "Department IT".

So, is there any way how to do this?

This is very tricky solution. I don't want ot do it this way. I just need to allow user to add node when he has permision for it, althrough he hasn't create permision of parent term.

I think it looks logical that in company is manager allowed to do anything and employees can do only part but not everything. So in this logic, I have:

Company
-Department1
--Section1.1
--Section1.2
-Department2
--Section2.1
--Section2.2

and I want some user to create nodes only in Section2.1, but not anywhere else (not in Department2, not in Company).

Is there any help for this?

I run Drupal 5.1, mysql5, taxonomy_access 5.x-1.1 and tried 5.x-2.x (everywhere it is the same).

This is very tricky solution. I don't want ot do it this way. I just need to allow user to add node when he has permision for it, althrough he hasn't create permision of parent term.

I think it looks logical that in company is manager allowed to do anything and employees can do only part but not everything. So in this logic, I have:

Company
-Department1
--Section1.1
--Section1.2
-Department2
--Section2.1
--Section2.2

and I want some user to create nodes only in Section2.1, but not anywhere else (not in Department2, not in Company).

Is there any help for this?

I run Drupal 5.1, mysql5, taxonomy_access 5.x-1.1 and tried 5.x-2.x (everywhere it is the same).

I've confirmed that if you don't have create for a term, you won't be able to create in any descendant. I had not been aware of this behavior. Presumably it is a bug, not a feature?

I've been planning to change the mechanism for limiting available terms from hook_db_rewrite_sql (which limits the terms before they are passed to taxonomy module) to hook_form_alter (alter the taxonomy select form after taxonomy is done with it). This would fix the parent problem.

I have the same problem in 6.x-1.0

Has there been any progress on this in the past two years?

I traced this to taxonomy_get_tree() in the core taxonomy module.
The db_rewrite_sql hook of taxonomy_access does what it's supposed to do and only returns the terms the user has permissons for. But this destroys the term hierarchy/tree if the user has no permisson for the parent term.

I came up with this patch for the core taxonomy module. Terms with parent terms that were not returned by the database query (no permisson) get displayed as first level terms.

In file modules/taxonomy/taxonomy.module, function taxonomy_get_tree(), before:

$max_depth = (is_null($max_depth)) ? count($children[$vid]) : $max_depth;

Insert:

  foreach ($terms[$vid] as $ttid => $tterm) {
    $parent_visible = false;

    // Check if at least one parent term was returned by the db query
    foreach ($parents[$vid][$ttid] as $ptid) {
      if ($ptid == '0' || !empty($terms[$vid][$ptid])) {
        $parent_visible = true;
        break;
      }
    }

    // If the db query didn't return a parent term for the current term,
    // the parent is set to '0' (= this term becomes a first level term)
    if (!$parent_visible) {
      $parents[$vid][$ttid] = array('0');
      $children[$vid][0][] = $ttid;
    }
  }

Confirming #14 works, is there a way to do this in TAC rather than core, or can this be submitted as a patch to core?

It's also worth noting that the heirachy can get really messed up for the end user with this fix if you have items from separate 2nd or 3rd depths in the tree.

Marked #719656: Different permission inheritance system. as duplicate of this issue.

I got the warning about wrong argument to foreach so I've change the first line in #14 to:

  if ($terms[$vid]) foreach ($terms[$vid] as $ttid => $tterm) {

It seems it works fine.

Thank you!

I agree with #15 that it would be best to provide this functionality from within TAC without a core patch; the patch to core in #14 and #17 is an interim workaround for this issue but introduces other problems in my case.

Any suggestions on a sufficiently drupalish way to resolve this issue? Could we add to hook_db_rewrite_sql()?

#48715: Cannot see children terms when parent term is not enabled seems like it might be related.
Edit: marked that one as duplicate.

Marked #162667: need help configuring as duplicate of this issue.

See also http://drupal.org/node/38221#comment-357025.

Hello xjm and others,
seems like nobody on Drupal side is working on patch in core at least for D7.

I'd also suggest to fix it in TAC module if possible.

Has anybody here idea how to do it in the any (best) way?
I've pure knowledge about Drupal modules and patches, but like to have this solved in official way.

Moving this issue to the 6.x branch. This (and several other issues related to Create/List) might require some major refactoring.

I have developed a solution that does not hack core taxonomy (which does not always work w/ nested terms). I inserted this code into taxonomy_access.module @ line 370 (after the taxonomy_access_nodeapi delete case).

case 'validate':
	global $user;
	foreach ($user->roles as $rid => $role_name) {
		foreach(taxonomy_access_get_grants($rid) as $term => $value) {
			if ($term == $arg['taxonomy'][1]['#value'] && ($value['update'] == 2 && $value['delete'] == 2)) {
				form_set_error('taxonomy[1]', t("You cannot use %tax, please select another section.", 
						array('%tax' => taxonomy_get_term($arg['taxonomy'][1]['#value'])->name)));
			}
		}
	}
	break;

To use, you have to grant 'create' access to the parent of your term, but then set 'delete' and 'update' to D. This will allow your terms to show up on your edit form, but if the user selects the parent, on the form submit the validate function above return the form with an error message telling the user to select a different term.

NOTE: The vocabulary used to control TAC was 1 (['taxonomy'][1]), which might have to be changed to match your site.

I have been testing this for a little while w/o and issues. I do welcome feedback on issues of ways to improve the above code.

Another solution would be to create a new permission and check that, but I did not want to rewrite the module that much, so I used what already existed.

I hope this helps.
Scott

thanks seworthi, works fine but not with multiple choice vocabulary

here is my version of your patch :

	case 'validate':
		global $user;
		if (is_array($arg['taxonomy'][1]['#value'])) $categories = $arg['taxonomy'][1]['#value'];
		else $categories = array($arg['taxonomy'][1]['#value']);
		foreach ($user->roles as $rid => $role_name) {
			foreach(taxonomy_access_get_grants($rid) as $term_id => $value) {
				if (in_array($term_id, $categories) && $value['update'] == 2 && $value['delete'] == 2) {
					form_set_error('taxonomy[1]', t("You cannot use %tax, please select another section.",
						array('%tax' => taxonomy_get_term($term_id)->name)));
				}
			}
		}
		break;

A proper patch for #25, please test and mark RTBC

subscrib

subscribe

subscribing

Marked #856716: Grant permission only to children, not to parent as duplicate. Subscribers: If you want this feature, please test the patch and post your results.

Marked #872584: Cannot assign permissions to sub-term as duplicate.

Note that some configurations might currently rely on the parent denying create to the children. This would only be the case when the global or vocabulary default has create permission, but a parent term does not, and its children are not controlled.

So, if/when this patch is ready provide a hook_update_n to add all records that would be affected by this change, as follows.

For each controlled role
Include vocabularies with create permissions in the vocab default configuration
If the global default has create permissions, include vocabs with no default set

For each of these vocabulary/role combinations
For each term controlled by TAC that does not have create permission
For each of that term's children not controlled by TAC
Get values for V/U/D and List from the vocab default, or global default if no vocab default is set
Set create to 0
Write the record

For those who might have missed it above, here are seworthi's instructions on using the patch in #26.

To use, you have to grant 'create' access to the parent of your term, but then set 'delete' and 'update' to D. This will allow your terms to show up on your edit form, but if the user selects the parent, on the form submit the validate function above return the form with an error message telling the user to select a different term.
NOTE: The vocabulary used to control TAC was 1 (['taxonomy'][1]), which might have to be changed to match your site.

I have been testing this for a little while w/o and issues. I do welcome feedback on issues of ways to improve the above code.

Another solution would be to create a new permission and check that, but I did not want to rewrite the module that much, so I used what already existed.

sewothi, soju, and realityloop: Thank you for your work on this. After thinking about this solution awhile, here are a few notes:

1. There are cases where someone might want to allow update or delete nodes under the parent term, yet not create, but still wish to allow create for its children. It's probably a much rarer case than the original (where "solid" and "liquid" are pseudo-terms used for categorization of the taxonomy terms themselves), but we should not discount it in our solution.
2. It would be best not to rely on users needing to remember a specific configuration to get their child terms working. Rather, TAC should handle the logic of whether create is available or not, and allow the user access to create (or not) based on that.
3. It would be better to have some indicator that the option is not available without the user having to submit and fail validation, by disabling the option in the term selection box. (IE 6 users would still have to fall through to the validation case, but that's graceful degradation.)

This all ties into the larger question of how TAC handles the create op in general. Currently, it is controlled in hook_db_rewrite_sql(), which has caused a number of other issues because of the broad impact of this hook:
#818212: Critical bug with node_revisions - vid as revision id versus vocab id
#660668: TAC + revisioning: Empty taxonomy term select list on node/add for regular users
#785060: Bug with List and Create permissions at admin/ paths

Two additional helper functions protect terms that the user does not have access to change. There are to-do notes in the module code dating back to at least the 5.x-2.x branch to move control of the create op into hook_form_alter() instead. This would need to be complemented by checks in both the validate and presave cases of hook_nodeapi().

I think that these changes to the create op would allow us to safely resolve this issue as well. So, I am marking postponed pending that change (which I hope to implement within the next month, if I have time). If everything checks out, I will re-use the logic behind this solution to implement this feature after that.

In the meanwhile, consider the patch in #26 to get this functionality. It is a useful interim solution. Just make sure to follow the instructions I have quoted above.

This issue about the forums is related to the usability question I raise above: #12089: Better method of showing forum containers in form

Forum containers would be equivalent to the non-creatable parent terms in our case here.

EDIT: updated to link to a new issue since I reverted the scope of the other one.

The basics of this are be fixed by: #903522: Move control of create into hook_form_alter() and hook_nodeapi() to prevent numerous problems. Please test the patch in that issue if at all possible. Direct link: http://drupal.org/files/issues/tac_903522.patch

There's still some fine-tuning to be done--specifically, the parent terms without create aren't displayed, but the display of their children is unchanged from what it would be if all the terms were displayed. This makes the form indentation a little wonky. E.g., in the example from the original post, we'd see:

--milk
--bread
--butter
--water
--wine
--beer

That's not so bad, but it gets pretty confusing with more complicated hierarchies.

This is actually a bug in core; we are using the API function _taxonomy_term_select() to render the fieldset, and it provides the option to exclude a list of terms but does not alter the presentation. However, we could probably override the field manually to help, possibly using optgroups or something (see #12089: Better method of showing forum containers in form).

#37 is working well for me with a 2 level hierarchy