image_attach creates unpublished image nodes

did previous version create published images?

Set image content type to be published by default?
But I agree it should be done at create time by image_attach, if it's currently failing to do so.

the reason i was asking if it did something different in a previous version is because i think it's working the way it's designed. i think it's a stupid way of operating, but it is working correctly. so here's a patch that lists all image nodes rather than a only published ones.

Well, I think that not listing unpublished images is the correct behaviour.

Plus, that patch is affecting the possible images that show up in the edit/select box - not the node display, which is where the issue is.

The problem noted in the OP is that that unpublished images are showing, when the system really shouldn't be allowing that. The image is visible when embedded, but denied when viewed on its own.

However, on a totally fresh test site, I found that my images ARE getting published on create, so this problem doesn't exist unless I manually unpublish the image. In which case it DOES still show up embedded (and probably shouldn't) and it automatically gets linked to a denied URL.
(I don't normally allow that link to the stand-alone file, so it's not an issue for me but I see the irregularity)

Auto-attached images should be published when they are created (check)
This results in them showing on the embeeded page (check)
With a link to a full-view page (check for me, but this apparently fails for ricmadeira)
Thus, unable to replicate, and I suspect some other node-acces type issue at rics end :-/

If an admin deliberately unpublishes an image at a later date, or otherwise resticts access, I'd expect that that image should no longer be available even if called from the context of a node that attached it.
This is not the current behaviour.

I'd say that image attach needs to check node_access('view', $node) just before rendering it.
Patch attached.
This patch makes a change to the default theme function, so it can be over-ridden by choice later, such as to display thumbs to everyone, but not show the whole image except to registered users ...

I realize this is the opposite to a solution to the original problem - but as I'm unable to replicate that, I think this is a more consistant change. If a user is going to get access denied looking for the image, they should NOT have seen it as a clickable attachment in the first case.

i'm into dman's solution but i'd like some other feedback.

The out-of-the-box behaviour I saw was the new image came out published.

Although looking at the code it doesn't explicitly do so (by setting the status) for the new node, it must be getting assumed somewhere (for me) yet not for you.

Tracing the code, the key point seems to be in the middle of
node.module: node_submit($node)
where, in preparation for making a new node, the default values, including 'status' are set.

// Process the workflow options and provide defaults. If the user
// can not administer nodes, ignore the form and either use the
// saved values if the node exists, or force the defaults.

As this works for me, I don't know what's going wrong for you.

My system also created unpublished image nodes. I alterd image_attach.module and added $image->status = 1; on line 194 (in the case 'prepare' in the image_attach_nodeapi function).

here's a re-roll of dman's patch that steals a little code to set the proper defaults for the image node. i'd love to get some feedback.

@drewish: your patch works, but only with a few major modifications.

You copied the block below from comment.module, but it looks like you forgot to rename the variables! $node should be $image in each case below:

+      // Set the node's defaults... (copied this from node and comment.module)
+      $node_options = variable_get('node_options_image', array('status', 'promote'));
+      $node->status = in_array('status', $node_options);
+      $node->promote = in_array('promote', $node_options);
+      if (module_exists('comment')) {
+        $node->comment = variable_get('comment_image', COMMENT_NODE_READ_WRITE);
+      }

You also had some syntax errors:

Missing a trailing } here:

+    if (!node_access('view', $image)) 

and missing an opening ( and trailing } here:

+    if !node_access('view', $image))

I've rerolled your patch against the most recent dev version of the image module.

I tested attaching an image to a node using both an administrative account and a normal authenticated user. I have image nodes set to be published by default. In both cases this patch fixes the problem in the original post (images not being published when they should be) but also fixes the inconsistency where the thumbnail is published and visible when the original sized image is unpublished.

This looks RTBC to me but I'll hold off on marking it as such since I did make some code changes.

thanks, the changes look good to me. committed to HEAD and DRUPAL-5.

I can confirm that image attach used to publish the image nodes, and since 1.3 attaches the image, but unpublished - This causes a user to not see the attached image in the list when editing the node and un-attaches the images upon submit.

Upgrade to 1.4 did not fix the problem. Patch works - thanks :)

AE@uberellis.com, you can download the -dev release with the fix already applied.