img_assist disregards taxonomy access rules when creating new image nodes

Submit a patch. I only work on img_assist when I have time (it's a hobby, not a job).

Excellent, thanks. I not exactly sure why that's happening, but I suspect it's because I used a custom query to build the list of terms, rather than using an existing taxonomy module function. To fix this I think you'd have to either modify this query or possibly rewrite a few lines of code to make it use an existing taxonomy function.

I'm sorry I haven't been working on img_assist lately. I have so many ideas to make it better, but so little time.

This bug is driving me crazy and i have not nearly enough php knowledge to solve it by myself. I tried commenting out different parts of img_assist module code but did not find "custom query to build the list of terms". Any help will be appreciated.

The custom query to build the list of terms has always been commented out (lines 727-732 of img_assist.module). The problem is that img_assist sets its access settings independently, using the vocabularies specified on the settings page (see function get_image_vocabs).

I just found out that categories get listed acording to Taxonomy Access create or list permissions.

when adding images thru node/add/image:
categories get listed acording to TA create permission as it should be

when adding images thru image_assist:
categories get listed acording to TA list permission (instead of create permission)

i cannot find this bug ....alll i see is that img_assist just calls node_add function

<?php
/**
 * Interface and controller for adding images. It simply calls node_add('image');
 */
function img_assist_upload() {

	if (module_exist('image') && user_access('create images')) {
		$edit = $_POST['edit'];
		$op = $_POST['op'];

		switch ($op) {
			case t('Submit'):
				$output .= img_assist_node_add('image', $op); // use a custom function so we can control the redirect
				break;
			default:
				$output .= node_add('image'); // use default node_add function
		}
		// on other img_assist_pages I've added the javascript using the body onload attribute,
		// but for this page will also need the collapse functions and setting the body onload
		// interferes with this.  To solve this, I'm forced use the addLoadEvent call.  I should
		// probably switch all the pages to this format to be more Drupal friendly, but at the same
		// time I don't know if it really matters.  If a user doesn't have Javascript, they can't
		// use img_assist at all.
		$output .= "\n<script type=\"text/javascript\"><!-- \n";
		$output .= "  if (isJsEnabled()) { \n";
		$output .= "    addLoadEvent(parent.initUpload);\n";
		$output .= "  } \n";
		$output .= "--></script>\n";

	} else {
		if (!module_exist('image')) {
			$output = t('The image module must be enabled to use img_assist.');
		} else {
			$output = t('Your account does not have image uploading privileges.');
		}
	}
	print theme('img_assist_page', $output, array('id'=>'img_assist_upload', 'class'=>'img_assist'));
}
?>

Img_assist uses the default node add form. get_image_vocabs is not related to the image upload form.

Jaka, could you check the output of node_add('image')? I don't use taxonomy access, so can't test. Put the following lines into the body of a story node and set the input format to PHP:

echo node_add('image');

Click preview and see if the correct categories are listed on the resulting form. (The output will be a bit confusing because you're previewing a node add form in a node add form.)

I just noticed this bug, then found this issue page. I tried the test of node_add('image') suggested here. The story displays all of the categories, including the ones disallowed by taxonomy_access module.

I'm a total drupal & php novice, but I'll do what I can to help squash this bug.

I'm still trying to figure this one out. Can anyone recommend a php debugger? I've tried to get Eclipse PDT with the Zend debugger running, but so far it's not working. I can run the project, but it won't stop at breakpoints. I'm using OS X 10.4.

Good news. I gave up (for now) on Eclipse and the Zend debugger, and tried a demo of Komodo. I found the problem. In taxonomy_access.module:

/**
 * Implementation of hook_db_rewrite_sql()
 */
function taxonomy_access_db_rewrite_sql($query, $table, $field) {
  if (!user_access('administer taxonomy') && ($field =='vid' || $field =='tid')) {
    global $user;
    $op = (arg(0) == 'node' && (arg(1) == 'add' || arg(2) == 'edit')) ? 'create' : 'list';
    

As you can see the decision on whether to use "create" or "list" permissions is made based on the url. It's expecting to find /node/add or node/xxx/edit. img_assist is at /img_assist/upload, which tac doesn't recognize, so it defaults to "list" permissions.

I can think of a couple of options:

• reorganize img_assist to use a URL that tac will recognize
• don't use node_add(), instead generate the form some other way
• Add an extra conditional to tac:
  if (arg(0) == 'img_assist' && arg(1) == 'upload') { $op = 'create'; }
  Yuck!

Ideas? Thanks!

p.s. – jferjan, how did you post the php code with the syntax coloring?

Here's a patch the implements option 3 from my previous post. The patch applies to taxonomy_access. This is almost certainly the wrong solution, but it does work, so I'm posting it for the benefit of anyone who wants a quick workaround.

I did try tweaking hook_menu first, setting the paths to node/add/img_assist/[OP], but my first crack at it produced really goofy results. I think this could work, though, I noticed that image_import.module works this way. I'm afraid at present that I don't know enough enough drupal internals to figure this out, so if someone else can pick this up it'd be greatly appreciated.

Does anyone know if this issue exists for Drupal 5 as well?

thanks,
Dylan

Support for 4.7 is discontinued.
Please upgrade to Drupal 5 and latest Image and Image Assist versions.

Feel free to re-open this bug for 5.x, if you still encounter this bug.