So currently there are several WTF's surrounding the new wiki/issue summary business.
1) To quote merlinofchaos "In fact, I bet there's a WTF right now that because issue updates can change the title, you can see in the comments how the title changes but if someone edits an issue and changes the title, you'll lose that tracking and have no idea where it changed."
2) Updates are not consistently passed to "Your Issues" and other dashboard widgets.
3) History of the summary is not consistently presented to the user. This is seen in the title weirdness but this applies to any edits because from a user perspective the comments are the timeline of the issue resolution.

I think the simple solution to this is to automatically create a comment for each edit providing as much revision modification information as makes sense. Project issues already provides a simple function to help automate this used for creating the autoclose comments: project_issue_add_followup()

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

neclimdul’s picture

Thinking about it further, there's probably another WTF if you edited the summary but didn't comment and issues that show up in your issues. I don't know if this was addressed already or not but this would probably simplify any logic around that.

klonos’s picture

...subscribing.

ccardea’s picture

Playing around with this. Added this code to the drupalorg project_issue module:

drupalorg_project_nodeapi(&$node, $op = 'view', $teaser = FALSE, $page = FALSE) 
 if ($op == 'update') {
    if ($node->type == 'project_issue') {
      $changes = array(
        'nid' => $node->nid,
        'comment' => t('Issue Summary updated'),
       );
      project_issue_add_followup($changes);
//    dpm('Issue Summary Updated');
    }
  }

It seems that calling project_issue_add_followup() from within this hook executes 6257 queries and adds 215 comments to the node. I don't see anything in the code that could cause that to happen. Running the dpm outputs once.

By the way, very cool that you can link to a line number in the repository..

neclimdul’s picture

Did the page timeout or anything when you tested it? I'd be a nickel the " comment_invoke_comment($comment, 'insert');" toward the end of project_issue_add_followup is going back in and working its way around to calling drupalorg_project_nodeapi(). It then recurses until the something somehow stopped it. The dpm's didn't show up for you because all the subsequent calls to nodeapi where handled impersonating the follow up user.

Thanks a ton for hashing out the basics of the patch ccardea!

ccardea’s picture

Creating a comment array and calling comment_save() does the same thing, and in addition, does not update the number of replies. I'm at a loss on this one.

ccardea’s picture

I'm not getting any error message saying that the page timed out, but it doesn't complete. At the end I get a page showing all of the queries and I have to go back a page to get to the node.

ccardea’s picture

I'd be a nickel the " comment_invoke_comment($comment, 'insert');" toward the end of project_issue_add_followup is going back in and working its way around to calling drupalorg_project_nodeapi().

You got that right. Taking it out stops the recursion.

ccardea’s picture

OK, heres the patch. I haven't tested the mail notification. I haven't found any code that specifically updates the issue notifications, so I'm not sure if that will happen either.

ccardea’s picture

Status: Active » Needs review
ccardea’s picture

This needs to be changed to insert the comment number as the subject.

ccardea’s picture

The patch also needs to insert an entry into the project_comments table.

ccardea’s picture

This patch adds an entry to the project_issue_comment table and adds the comment number to the subject.

dww’s picture

Cool that y'all are trying to work this out via a patch, thanks!

One thing about the original report... Re: point 1) There's no WTF there. If you edit an issue, none of the fields you can edit with a comment are available, including the title. The only thing you can really change is the body (aka the summary). This is *itself* a WTF as I pointed out over at #1036132-81: Provide a mechanism for issue summaries (point g), but that's another story. Point being, if you want to change the summary, you have to use the edit tab. If you want to use anything else, you have to use a new comment. So WTF #1 in the original issue here is an imaginary problem.

Anyway, stepping back, I'm not sure we actually want this behavior. ;) Do we really want to spam everyone with notification emails on every summary edit? I kinda like how it is now that I can go in and fix typos in a summary without spamming everyone, but if I do a major overhaul of a summary, I can consciously choose to add a comment to that effect. Basically, the current behavior lets the end user decide how it should behave. I can see how that's itself a bug given that not everyone is going to Do The Right Thing(tm) in every case.

I'd personally rather see the edits to the summary interwoven with the comments as I also proposed at #1036132-81: Provide a mechanism for issue summaries (point d). Basically, you'd see an "activity steam" for the issue with comments, summary edits, eventually Git commits, etc. I think that'd be better than actually posting comments whenever someone edits the summary or makes a commit.

In conclusion, I'd love to see more discussion about if we actually want this behavior before anyone spends more time trying to get the patches working, reviewed, tested, etc.

Thanks again!
-Derek

ccardea’s picture

I actually did this in response to http://drupal.org/node/1217286#comment-4829106. There was a complaint that there were no notifications sent when the issue summary was updated, and no updates on the dashboard. I think it only sends the email if you're subscribed to the issue. I believe the intention is to keep a clear trail of what changes have been made, notify people who want to be notified, and make sure the update is reflected on the dashboard.

I haven't yet read the proposal you link to above.

ccardea’s picture

d) Part of why I think 'Log message' should be required is that I think it'd be nice when viewing an issue to see markers that user foo edited the summary interspersed with the comments at the times that those edits took place. the markers could have a link to the diff, etc. That definitely shouldn't delay initial deployment here, but I think it'd be great to spin that off into another follow-up/related issue here. Thoughts?

That's been implemented. If there is a revision to the issue summary, the Revision information line on the node links to the diff, where you can see the changes and who made them. Good idea. By the way the issue summary on that issue mentions concerns about lacking comment stream integration, so it looks like the current issue also addresses those concerns.

ccardea’s picture

I guess we could also put a link to the diff in the comment.

ccardea’s picture

I just want to acknowledge neclimdul for getting the ball rolling on this. The job would have been a lot harder without the pointer to project_issue_add_followup(). I also appreciate the help in debugging.

webchick’s picture

subscribe.

mgifford’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
Issue summary: View changes
Status: Needs review » Closed (works as designed)

I think this is fixed now thanks to some recent work on the issue queue.