Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Many people use the "Preview pane" feature of their mail client, which shows the first 10-20 lines of an e-mail in your face so you get the jist of what it's about without reading the whole thing.
However, issue e-mails have the information I actually care about (who said what thing) *after* the information I care less about (what the current status of the issue is). So as a result, paging through my infrastructure list e-mails, for example, results in previews like:
Issue status update for
http://drupal.org/node/198873
Post a follow up:
http://drupal.org/comment/reply/198873#comment-form
Project: Drupal.org infrastructure
Version: <none>
Component: Other
Category: tasks
Priority: normal
Assigned to: Anonymous
Reported by: greggles
Updated by: sepeck
Status: active
rather than:
Issue status update for
http://drupal.org/node/198873
d.o. has been slow lately?
sepeck
---
Project: Drupal.org infrastructure
Version: <none>
Component: Other
Category: tasks
Priority: normal
Assigned to: Anonymous
Reported by: greggles
Updated by: sepeck
Status: active
Post a follow up:
http://drupal.org/comment/reply/198873#comment-form
...which I think would be more optimal.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 199178-7.issue-email-content-order.patch | 4.75 KB | dww |
| #6 | minimal.diff | 3.1 KB | moshe weitzman |
Comments
Comment #1
webchickI should clarify. The pertinent information in that status update is mostly what project it came from, but that's found in the subject line: [infrastructure]
Comment #2
dwwwebchick: but if there are diffs to the issue meta data, those are probably at least as interesting as the body of the message, no?
I'm also worried that the issue status will get lost if it's after the body of the comment, especially since there's nothing to clearly distinguish it from the rest of the comments in the thread (which arguably we shouldn't always include at the bottom of each email, but that's a separate issue).
Anyway, I'm torn. This doesn't immediately seem like a clear win, but I won't kill the issue yet, either. ;)
Comment #3
webchickHow about just this then?
Because the subject line is:
[project_issue] [feature] Usability: Re-order contents of project issue emails
I already know it's for the Project Issue Tracking module, and I know it's a feature request. There's definitely little sense in repeating that information again, unless of course it's been modified. So simply include those values that have changed since the last reply, at the top of the message. There are times when there will be enough of these (moving an issue to a totally different project, for example) that the changed statuses will bump the actual content far enough down that it gets lost, but that's pertinent information to know in that case. In all others, the status changes will be minimal, if they exist at all.
Comment #4
dwwMoshe suggested the same over at #886310: Mobile phone friendly emails which I've marked duplicate with both this and #15380: Allow to configure content of issue notification e-mails.
But yeah, we should fix this...
Comment #5
sun- I like the suggestion of only outputting the property changes at the top. Most often, only the status is changed. Even more often, no issue properties changed at all, so you'd see the comment directly at the top.
- I also like the suggestion of outputting all current issue property values below the comment. (but of course, above the full issue history)
- The suggested new diff format of "old » new" is a good one, too, but does not work for all properties. AFAICS, at least issue tags would still have to use the current "unified diff" format.
--- That said, I'd also love to see a change to the issue title.
- I wonder whether this change would have to be user-configurable at all. (don't think so)
Comment #6
moshe weitzman CreditAttribution: moshe weitzman commentedAs per #5, attached patch shows changed metadata at top and full (new) metadata below the body, but above the (optional) issue history.
No change to way we show the diff (unified vs. inline)
Comment #7
dwwSorry, Moshe. Local testing isn't working at all. The metadata changes never appear, nor does the summary of current values. The handling of the $summary variable is totally broken. This whole function is insane. Here's a partial attempt, but it's still not working as expected. I don't have time to keep debugging this and actually getting it working, but if someone wants to build on the changes I've made (or start over with a better approach) cool.
Comment #8
mgiffordI'm assuming this is still needed for D7.
Comment #9
drummThe email notification I got for this issue shows it is fixed.