Closed Bug 467331 Opened 16 years ago Closed 15 years ago

Layout of email reports makes them hard to use

Categories

(Bugzilla :: Email Notifications, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: mcepl, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; cs-CZ; rv:1.9.0.4) Gecko/2008111217 Fedora/3.0.4-1.fc10 Firefox/3.0.4
Build Identifier: 3.1.4+

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?).

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).

Reproducible: Always

Steps to Reproduce:
1.just let bugzilla sent you email
2.
3.
Actual Results:  
very confusing layout which covers half of my email client with nothing, but doesn't cotain useful information; I don't know even what is the current status of the bug.

Expected Results:  
something better -- message should be self-containing and allow maintainer of the package to decide at least basic decision what to do even without going to bugzilla itself
(In reply to comment #0)
> 1) should really developers be reminded that they shouldn't reply by email (on
> two lines nonetheless)?

This lines have been added by the maintainer of your installation. Vanially Bugzilla doesn't have these lines.


> 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 :-).

That's bug 73330.


> 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.

I disagree. Having to scroll down to see bug changes is a pain. In the same way we display bug attributes first in the web UI, we should display bug changes first in bugmail, IMO.


> 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).

Wrong, all bugmail have X-Bugzilla-Status and many other such fields to let you display them in the header in e.g. Thunderbird.


> Actual Results:  
> very confusing layout which covers half of my email client with nothing, but
> doesn't cotain useful information

Depends what you are looking for. All the interesting information is displayed at once for me.
(In reply to comment #2)
> Vanially Bugzilla

I guess nobody understood what I meant here. This was supposed to be "vanilla". :)
I think everybody is pretty happy with the current layout, and this RFE got no traction at all in the last 3 months -> WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: