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)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: mcepl, Unassigned)
Details
Attachments
(1 file)
3.03 KB,
text/plain
|
Details |
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
Reporter | ||
Comment 1•16 years ago
|
||
Comment 2•16 years ago
|
||
(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.
Comment 3•16 years ago
|
||
(In reply to comment #2) > Vanially Bugzilla I guess nobody understood what I meant here. This was supposed to be "vanilla". :)
Comment 4•15 years ago
|
||
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.
Description
•