Ticket #2378 (closed defect: duplicate)
Opened 7 years ago
Last modified 19 months ago
Format of email notifications
| Reported by: | Barclay | Owned by: | eblot |
|---|---|---|---|
| Priority: | lowest | Milestone: | |
| Component: | notification | Version: | 0.10.2 |
| Severity: | minor | Keywords: | notification email |
| Cc: | lists@…, andrew.c.martin@… | ||
| Release Notes: | |||
| API 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
Change History
comment:1 Changed 7 years ago by eblot
- Keywords notification email added
comment:2 Changed 6 years ago by anonymous
comment:3 Changed 6 years ago by anonymous
- Version changed from 0.9 to 0.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 follow-up: ↓ 7 Changed 6 years ago by mgood
- Milestone set to 0.10.1
- Priority changed from normal to lowest
- Severity changed from normal to blocker
comment:5 Changed 5 years ago by anonymous
- Version changed from 0.10 to 0.10.2
This is still present in 0.10.2
comment:6 Changed 5 years ago by cboos
- Severity changed from blocker to minor
comment:7 in reply to: ↑ 4 ; follow-up: ↓ 8 Changed 5 years ago by HannesEder
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.
comment:8 in reply to: ↑ 7 Changed 5 years ago by anonymous
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 Changed 5 years ago by cboos
- Component changed from ticket system to notification
- Milestone changed from 0.10.5 to 0.12
- Owner changed from jonas to eblot
I don't see this being done for 0.10.x, postponing.
comment:10 Changed 5 years ago by DS
I would recommend using a similar way to how Bugzilla format their e-mails. They appear to have got it right.
comment:11 Changed 4 years ago by anonymous
comment:12 Changed 2 years ago by rblank
- Milestone changed from next-major-0.1X to unscheduled
comment:13 Changed 20 months ago by Thijs Triemstra <lists@…>
- Cc lists@… added
comment:14 Changed 19 months ago by Andrew C Martin <andrew.c.martin@…>
- Cc andrew.c.martin@… added
this should be fixed with #9494 (resolve as duplicate?)
comment:15 Changed 19 months ago by cboos
- Milestone unscheduled deleted
- Resolution set to duplicate
- Status changed from new to closed
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!



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.