#2192 closed defect (fixed)
"big" fields useless and mess with formatting in email notification
Reported by: | Owned by: | Christopher Lenz | |
---|---|---|---|
Priority: | low | Milestone: | 0.9 |
Component: | ticket system | Version: | 0.9b1 |
Severity: | normal | Keywords: | |
Cc: | m.kooijman@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
There is a small error with formatting of email notifications.
"big" fields were counted for determining even/odd (left column/right column) of a field, even though they were not displayed.
in Notify.py, i
is used for determining if "left" or "right" formatting should be used and if there should be an extra newline in the end.
If any "big" fields are present, these big fields are counted in i
, but they are not actually displayed, which messes up the formatting.
To fix this, one could decrement i
after deciding a field is "big". Or, nicer, one could
manually increment i
after displaying a normal field, instead of letting the for loop do that.
Also, it seems this issue can only be reproduced by having newlines in a non-textarea custom field, which I could only produce by changing the type of a textarea to text after putting in a value with newlines. This is because textarea fields are filtered out a little earlier, so textarea fields don't even stand a chance of becoming big fields.
I think initializing big with a list of all textarea fields would also make sure that they are properly displayed in notify emails (they aren't at all right now).
I would have made patch, if I would know list handling in python a little better, and it wasn't 4 am already ;-)
Tested with 0.9b1, but there are no relevant changes in b2 or trunk which affect this.
Attachments (0)
Change History (4)
comment:1 by , 19 years ago
Cc: | added |
---|
comment:2 by , 19 years ago
Milestone: | → 0.9 |
---|---|
Owner: | changed from | to
Priority: | normal → low |
Status: | new → assigned |
comment:3 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Should be fixed in [2331], [2332], [2333].