Adding issue tags without a comment or change in other metadata does not work

Duplicate of #367419: Editing issue follow-up comments broken.

Also, if I try and just add a tag on an issue but leave the comment body field empty, I get an "You must either add a comment, upload a file, or change something about this issue." error.

I just tested this and adding only a tag to an issue but not changing anything else gives an error. Adding as a 6.x-1.x blocker.

subscribe

Uhh, I don't think this can both be a "blocker" and "minor". ;) aclight, what's up with #6?

Sorry about the last priority change--I just wanted to see if that worked, and it obviously did.

As I stated in comment #4, adding a tag to an issue but otherwise not changing anything does not work on d.o. However, on a local installation of the drupal.org testing profile, with versions of project, project_issue, and comment_alter_taxonomy updated to today's HEAD versions, I can't reproduce this behavior. So I wonder if there is something else on d.o, or perhaps some kind of caching or something, that's causing the problem.

I'm changing the issue title to reflect the fact that the problem seems to be exculsive to adding (and possibly removing) tags.

Issue tag: I've noticed the required comment happen when I tag one issue without comment which works fine and then go to a second issue to do the same thing then I'm forced to add a comment.

Other metadata: Today I had a comment go missing when attaching a file. I uploaded the file first before entering the comment.

@earnie: First point is indeed this issue here, and yes, it does seem inconsistent. Previewing issue tags is all whacky, too, and I think that's related to the bug described here:
#367922: Term changes in issue not being properly displayed in emails

The other issue has nothing to do with project_issue, it's a comment_upload bug:
#379470: Change in the issue description is discarded after clicking on the attach button

I was able to reproduce this issue and will start working on a fix.

Just wanted to provide an update here. While working on this today I think I narrowed the issue down to
includes/comment.inc:
project_issue_form_comment_validate() which is the extra validate function
for the project_issue_form_comment_form_alter (overriding the form_comment)
form. The issue is with line 309:
if (!empty($form_state['rebuild'])) {
return;
}
I am not sure where this is getting set, but I will keep looking into it. I am thinking maybe this is an issue with the #ahah code.

Curious: The comment_alter_taxonomy module is what enables this feature on d.o, but is there a use case that would make it so that we should be checking for a change in taxonomy even if this module is not installed? For now I am assuming that the comment_alter_taxonomy module is a requirement for checking for changes in taxonomy.

On closer look it appears that the $form_state variable is not being passed on correctly (maybe just not including the altered taxonomy) when a project_issue is submitted for preview. I have verified that this is not a bug in comment_alter_taxonomy as it works fine in non-project_issue node comments.

This looks like it is an issue that deals with forcing the rebuild of the comment_form on preview. This is done in project_issue_form_comment_form_alter() by setting the the preview button to #type submit, and again if the pid changed from underneath us in project_issue_form_comment_validate().