#9494 closed defect (fixed)
[PATCH] $ticket_props doesn't wrap long field values in notification emails
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | high | Milestone: | 0.12.1 |
Component: | notification | Version: | 0.12dev |
Severity: | normal | Keywords: | email ticket_props notification |
Cc: | jun66j5@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
When the value of a text field of a ticket is sufficiently long, the $ticket_props portion of the TracNotification email becomes quite unreadable. The table at the top of the email (which lists all the non-textarea fields) expands in width beyond the 75 char limit. Issues:
- There is no attempt to wrap long fields so that the width of $ticket_props is limited to the 75 chars maximum email width.
- The separator lines (——-+——-) will not extend to the right cell of the table if the left cell is 75 chars or more (but will not limit the extent to which it outlines the left cell).
- There is no symmetry between the table's 2 cells in terms of left and right cellpadding
This is probably most frequently a problem with custom text fields, but even in the default installation a long owner, reporter, or keywords field could cause the formatting issue.
I have attached two images. attachment:ticket_props_formatting_1.png demonstrates the issue with when a text field is only slightly longer could fit within the 75 char table. attachment:ticket_props_formatting_2.png demonstrates the issue with the text field is significantly longer than 75 char. Both images also show how my patch formats the email.
I have attached attachment:ticket_props_formatting.patch which I believe properly sets the cellpadding and correctly wraps long fields. It doesn't wrap long fields without spaces, but with the patch, one continuous value (like a url) will not corrupt the entire table.
Example (note where the separator dashes stop):
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Reporter: anonymous | Owner: somebody Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: component1 | Version: 2.0 Resolution: fixed | Keywords: Text Field: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. | -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
After Patch:
-------------------------------------------------+------------------------- Reporter: anonymous | Owner: somebody Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: component1 | Version: 2.0 Resolution: fixed | Keywords: Text Field: Lorem ipsum dolor sit amet, | consectetur adipisicing elit, sed do eiusmod | tempor incididunt ut labore et dolore magna | aliqua. Ut enim ad minim veniam, quis nostrud | exercitation ullamco laboris nisi ut aliquip | ex ea commodo consequat. Duis aute irure | dolor in reprehenderit in voluptate velit | esse cillum dolore eu fugiat nulla pariatur. | Excepteur sint occaecat cupidatat non | proident, sunt in culpa qui officia deserunt | mollit anim id est laborum. | -------------------------------------------------+-------------------------
Before the patch, in this example the table width is 487 chars wide. After the patch, it is 75.
Attachments (4)
Change History (13)
by , 14 years ago
Attachment: | ticket_props_formatting_1.png added |
---|
by , 14 years ago
Attachment: | ticket_props_formatting_2.png added |
---|
by , 14 years ago
Attachment: | ticket_props_formatting.patch added |
---|
comment:1 by , 14 years ago
Milestone: | → 0.13 |
---|---|
Owner: | set to |
comment:2 by , 14 years ago
Cc: | added |
---|
comment:3 by , 14 years ago
Priority: | normal → high |
---|
comment:4 by , 14 years ago
Milestone: | 0.13 → 0.12.1 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
I don't claim to fully understand what that code does, but it was the same with the previous implementation, and at least this one works :)
Patch applied in [10051]. Thanks!
comment:5 by , 14 years ago
Owner: | changed from | to
---|
follow-up: 7 comment:6 by , 13 years ago
So, I've been digging and digging, and I think this is the change that is causing my emails to be unreadable in my 0.12.1 installation. I have fairly long custom field names and some long possible values in my select list. In my 0.12 installation (i have two installations), even though the text exceeded some (arbitrary?) 75 character limit, the emails looked ok. Now, in 0.12.1, my fields look quite bad in outlook (see attachment:trac_12.1_email.png). Unfortunately, I cant even use the suggested solution here: http://trac.edgewall.org/wiki/TracNotification because the $ticket_props no longer parses properly for me to split on the fields because there are new lines and it's not building the array of values properly:
{% with pv = [(a[0].strip(), a[1].strip()) for a in [b.split(':') for b in [c.strip() for c in ticket_props.replace('|', '\n').splitlines()[1:-1]] if ':' in b]]; sel = ['Reporter', 'Owner', 'Type', 'Status', 'Priority', 'Milestone', 'Component', 'Severity', 'Resolution', 'Keywords'] %}\ ${'\n'.join('%s\t%s' % (format(p[0]+':', ' <12'), p[1]) for p in pv if p[0] in sel)} {% end %}\
Is it possible for someone to update the above code to parse the $ticket_props after this change so that I can format my emails in a way that works? How else can I fix my installation? We used easy_install, and I'm not sure how to patch it when I dont know how to find the source for notification.py.
by , 13 years ago
Attachment: | trac_12.1_email.png added |
---|
trac fields are split into multiple lines and cannot be parsed
follow-up: 9 comment:7 by , 13 years ago
Replying to sue.lueder@…:
Is it possible for someone to update the above code to parse the $ticket_props after this change so that I can format my emails in a way that works? How else can I fix my installation? We used easy_install, and I'm not sure how to patch it when I dont know how to find the source for notification.py.
Sue, the $ticket_props definitely doesn't do the best job formatting when you have custom fields with very long names. As a workaround, you might want to use something like the code snippet below (in place of $ticket_props). I've modified mine to only show a subset of all the ticket's fields. They are fields that we think are worth sending in every email.
--------------------------------------------------------------------------- Reporter: $ticket.reporter #if ticket.owner Owner: $ticket.owner #end #if ticket.resolution Status: $ticket.status ($ticket.resolution) #end #if not ticket.resolution Status: $ticket.status #end Type: $ticket.type Priority: $ticket.priority #if ticket.product Product: $ticket.product #end ---------------------------------------------------------------------------
comment:9 by , 11 years ago
Replying to Andrew C Martin <andrew.c.martin@…>:
As a workaround, you might want to use something like the code snippet below (in place of $ticket_props).
Perfect! I tried the workaround for fixing variable font issues, but lengthy fields were causing problems. This approach is so much better and simpler. Thanks again for sharing.
Thanks for the patch!