Edgewall Software
Modify

Opened 18 years ago

Closed 13 years ago

#2378 closed defect (duplicate)

Format of email notifications

Reported by: Barclay Owned by: Emmanuel Blot
Priority: lowest Milestone:
Component: notification Version: 0.10.2
Severity: minor Keywords: notification email
Cc: lists@…, andrew.c.martin@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

It could be good to modify format of notifications to avoid lines longer than 76 characters. Mail programs wrap lines in plain text messages after 76 or 80 symbols and they looks messy. In general it could be enough to make shorter separating lines for ticket properties as currently when received they look like this:

-----------------------+------------------------------------------------
-----------------------+----
  Reporter:  somebody  |       Owner:  somebody
      Type:  task      |      Status:  closed  
  Priority:  major     |   Milestone:          
 Component:  General   |     Version:          
Resolution:  fixed     |    Keywords:          
-----------------------+------------------------------------------------
-----------------------+----

Attachments (0)

Change History (15)

comment:1 by Emmanuel Blot, 18 years ago

Keywords: notification email added

comment:2 by anonymous, 17 years ago

If the formatting of the e-mail could be controlled through a template or via something like webadmin then it would be a lot easier to manage. Plain text is best, but if needs be then changing to html would be acceptable.

comment:3 by anonymous, 17 years ago

Version: 0.90.10

This is present in version 0.10.

Looking at the it looks like the extra ———————————-+—— line is not there by design.

From source:/tags/trac-0.10/trac/ticket/notification.py#L148

 l = (width[0] + width[1] + 5)
 sep = l * '-' + '+' + (self.COLS - l) * '-'
 txt = sep + CRLF

Here l is the combined width of the largest keyword:value pair in the left column plus 5 and COLS = 75. The width of the second portion (after the '+') should be COLS minus the combined width l. (btw, bad idea to use lower case L as a variable name, is it 1 or l?)

Can't see where the extra line comes from.

comment:4 by Matthew Good, 17 years ago

Milestone: 0.10.1
Priority: normallowest
Severity: normalblocker

comment:5 by anonymous, 17 years ago

Version: 0.100.10.2

This is still present in 0.10.2

comment:6 by Christian Boos, 17 years ago

Severity: blockerminor

in reply to:  4 ; comment:7 by HannesEder, 17 years ago

Replying to mgood:

Looking at the it looks like the extra ———————————-+—— line is not there by design.

Altough it's not there by design I can confirm that it is displayed in the email, at least Outlook 2003 does so. It's is even there when saving the msg as .txt file.

The msg format us utf-8.

It's not there when saving as .msg, nor is it there when you forward or reply to this msg. The seperator line is 75 chars + lf long.

When switching coding to Western, the sperator line is ok, but as expected some other chars look ugly. But: After switching back to UTF-8, the sperator is still ok and the reset looks good.

To me it seems more like a prb. of Outlook, maybe something can be done with the (MIME) encoding of the notification msg.

When using Outlook Express the msg is displayed in a proportional font (arial), looks ugly but correct. When switching to a monospaced font (like courier) it looks perfect.

in reply to:  7 comment:8 by anonymous, 17 years ago

Replying to HannesEder:

When using Outlook Express the msg is displayed in a proportional font (arial), looks ugly but correct. When switching to a monospaced font (like courier) it looks perfect.

Outlook XP (2002) SP3 uses a proportional font too :(

comment:9 by Christian Boos, 17 years ago

Component: ticket systemnotification
Milestone: 0.10.50.12
Owner: changed from Jonas Borgström to Emmanuel Blot

I don't see this being done for 0.10.x, postponing.

comment:10 by DS, 17 years ago

I would recommend using a similar way to how Bugzilla format their e-mails. They appear to have got it right.

comment:12 by Remy Blank, 14 years ago

Milestone: next-major-0.1Xunscheduled

comment:13 by Thijs Triemstra <lists@…>, 13 years ago

Cc: lists@… added

comment:14 by Andrew C Martin <andrew.c.martin@…>, 13 years ago

Cc: andrew.c.martin@… added

this should be fixed with #9494 (resolve as duplicate?)

comment:15 by Christian Boos, 13 years ago

Milestone: unscheduled
Resolution: duplicate
Status: newclosed

Seems so.

Andrew, as you know that code well (i.e. better than us ;-) ), can you also validate the patch proposed by jomae, to verify that it doesn't introduce a regression in your fix? See his latest patch on #4717. Thanks!

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Emmanuel Blot.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Emmanuel Blot to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.