Image_attach granular permissions

marking http://drupal.org/node/146214 as a duplicate

http://drupal.org/node/210402 is a duplicate.

Here's my comments from there:

My suggestion would be:

- 'attach images' for whether the user can pick an image node to attach or change the attached image
- use the 'create image content' to determine whether a user may upload a new image

Is a distinction needed between picking an image node to attach and changing an existing attachment?

Sorry for double posting this but I'm not sure what post to add this to since there are several that reference each other as duplicates.

All of the links to "Dupe" items don't have a solution either.

I need to have it so that 1 user (with role A) can create a node and then user 2 (with role B) can add images to it. But unregistered and other roles will only be able to see it and not make updates.

Is this possible?

We mark issues as duplicates to keep the issue list sane -- duplicates are identical or nearly and can be ignored.

There's no solution yet because this is a request for a new feature, and someone needs to do the coding.

In your case, can role B edit the node? If so, what's requested here will work for you. If you want role B to be unable to edit node content, you'll need even finer granularity.

marked #243276: Image attach permissions as a duplicate

I need this too.

http://drupal.org/node/506974 as duplicate.

#3: "Is a distinction needed between picking an image node to attach and changing an existing attachment?"

Yes, that would definetely be preferable on some sites.

Here is a patch.
Actually, it does a lot more, correcting some bugs when "Attach existing images" is disabled:
* impossible to attach more than one image
* the image is created but not attached at all

Just as a note (principally for me):
if !user_access('attach images') : display nothing
else: if user_access('create images') OR attach_existing_images : display the form

if attach_existing_images: the select list should contain all image nodes
else: it should only contain already attached nodes

That's all for me at the drupalcon sprint code, but I'll try to help comitting this one (and more), if needed. :)

Regards,
David

Committed with minor comment tweaks and with this bit removed from the patch:

-      unset($node->iids[0]);
+      //unset($node->iids[0]);

Thanks for all your help at the image code sprint today! We've managed to get so much done :)

To which branch was this committed? I can't find it in the latest beta.

I see it right here in CVS HEAD.
Unless the beta has very badly misrolled, it should be in there too. (If that's the case file a critical please!)

sorry, was on coffee withdrawal. :p

I see the patch in this thread was committed, but it's not the feature I was expecting. With a subject "Image_attach granular permissions", I expected to see a change to permissions -- admin/user/permissions -- e.g. at the very least a "attach existing images". But alas, it's still only a globally configurable setting. In other words the question from #3 and #9 was never addressed:

"Is a distinction needed between picking an image node to attach and changing an existing attachment?" My answer is yes, and the attach patch provides the fix.

In this patch:

• New permission: "attach existing images". In addition to the global "Enable Attach Existing" setting, this permission must be for each role that should be able to attach existing images.
• hook_update for backwards compatibility: Since there was previously no distinction between "attach images" and "attach existing images", this hook_update adds "attach existing images" permission to every role that already has "attach images". This will create an uninterrupted update experience for image_attach users.

Apologies if I was not supposed to reopen this issue, but i thought it was pertinent.
Please let me know if i should put this in a new request.

Hmmm... seems reasonable, but this should be in a new issue -- can you file one please?

OK, opened #820660: Add (role-based) permission for "attach existing images" re comment #16