Bug 215484

Summary: Layout of email reports makes them hard to use
Product: [Community] Bugzilla Reporter: Matěj Cepl <mcepl>
Component: Bugzilla GeneralAssignee: PnT DevOps Devs <hss-ied-bugs>
Status: CLOSED UPSTREAM QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.2Keywords: FutureFeature
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-12-01 10:09:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
presentation of message in Evolution informing about new comment in BZ
none
Presentation of the "new bug" message in Evolution
none
Example of message from Trac none

Description Matěj Cepl 2006-11-14 10:49:26 UTC 
Description of problem:
Layout of messages send by bugzilla provides so little information without
scrolling window of MUA that I usually rather click on the link and open bug in
browser. Cannot we make something like "developers layout" for emails -- with
120 unread emails in my bugzilla folder it becomes really bothersome?

Some specifical gripes:
1) should really developers be reminded that they shouldn't reply by email (on
two lines nonetheless)?
2) then there are four (or how many) empty lines after the previous reminder
which eliminate even the last remainders of useful information visible in the
message :-).
3) three lines message about status change is too big and could be in the bottom
of the message rather than on the top -- when the status change is the only
change to the bug, than it would be visible, otherwise user's comment is more
interesting than that and I would like to read it first.
4) Report about new bug filed into Bugzilla -- after duplicate summary of bug
(which is in the Subject of message as well), there are all those informations
about platform, version, processor, etc., EACH ON SEPARATE LINE. They could be
very well on the bottom of the message as well, so that the user could read in
email what is the description of the problem.

Couldn't it be possible at least to make some user customization of these
messages (like CSS stylesheet applied before filtering into text/plain or
something?).

Version-Release number of selected component (if applicable):
current version of Bugzilla

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Matěj Cepl 2006-11-14 10:49:26 UTC 
Created attachment 141145 [details]
presentation of message in Evolution informing about new comment in BZ
Comment 2 Matěj Cepl 2006-11-14 10:51:28 UTC 
Created attachment 141146 [details]
Presentation of the "new bug" message in Evolution
Comment 3 David Lawrence 2008-09-16 16:54:59 UTC 
Red Hat Bugzilla is now using version 3.2 of the Bugzilla codebase and therefore this bug will need to be re-verified against the new release. With the updated code this bug may no longer be relevant or may have been fixed in the new code.
Updating bug version to 3.2.
Comment 4 Matěj Cepl 2008-11-30 19:39:19 UTC 
Created attachment 325138 [details]
Example of message from Trac

I actually much prefer what I get from trac. It looks in my Thunderbrid like this:

#4521: traceback in on_roster_treeview_row_expanded of roster_window.py
--------------------+-------------------------------------------------------
 Reporter:  mcepl   |        Owner:     
     Type:  defect  |       Status:  new
 Priority:  normal  |    Milestone:     
Component:  None    |      Version:  svn
 Severity:  normal  |   Resolution:     
 Keywords:          |           Os:  All
--------------------+-------------------------------------------------------

Comment(by asterix):

 see #4034, it's the same traceback. But it's impossible that iter is wrong
 as GTK gives it to us. does this package contain some patches? Are you
 able to reproduce? how? Which GTK / PyGTK version?

---------------------------------------------------

Just a few lines, but I get all interesting information about the current state of the bug. With our bugmails I for example don't know what state the bug is in (as in NEW, ASSIGNED, or something else).
Comment 5 David Lawrence 2008-11-30 22:33:46 UTC 
(In reply to comment #4)
> Created an attachment (id=325138) [details]
> Example of message from Trac
> 
> I actually much prefer what I get from trac. It looks in my Thunderbrid like
> this:
> 
> #4521: traceback in on_roster_treeview_row_expanded of roster_window.py
> --------------------+-------------------------------------------------------
>  Reporter:  mcepl   |        Owner:     
>      Type:  defect  |       Status:  new
>  Priority:  normal  |    Milestone:     
> Component:  None    |      Version:  svn
>  Severity:  normal  |   Resolution:     
>  Keywords:          |           Os:  All
> --------------------+-------------------------------------------------------
> 
> Comment(by asterix):
> 
>  see #4034, it's the same traceback. But it's impossible that iter is wrong
>  as GTK gives it to us. does this package contain some patches? Are you
>  able to reproduce? how? Which GTK / PyGTK version?
> 
> ---------------------------------------------------
> 
> Just a few lines, but I get all interesting information about the current state
> of the bug. With our bugmails I for example don't know what state the bug is in
> (as in NEW, ASSIGNED, or something else).

Most of the current information about the bug is in the headers unfortunately and not printed in the message body itself. I am not against putting more info in the body, but I feel this is best worked upstream. Possibly file a bug there and let it be hashed out in a cooperative manner. The email message is basically a template that has most of the bug information available to the template, so layout is just a matter of preference.

What do you think?

Dave
Comment 6 Matěj Cepl 2008-12-01 10:09:45 UTC 
I filed this bug in the upstream database (https://bugzilla.mozilla.org/show_bug.cgi?id=467331). Closing as UPSTREAM