Opened 13 years ago
Closed 8 years ago
#9411 closed defect (wontfix)
Exception when formatting html notification when ticket comment is None
Reported by: | anonymous | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | AnnouncerPlugin |
Severity: | minor | Keywords: | ticket TypeError |
Cc: | Trac Release: | 0.12 |
Description
I am using Announcer (v 0.11.1) with agiloForTrac.
When attributes of a ticket are changed in the agilo's backlog view, I get the following exception in the log:
2011-10-25 08:46:55,099 Trac[ticket_email] ERROR: Traceback (most recent call last): File ".../python/lib/python2.6/site-packages/TracAnnouncer-0.11.1-py2.6.egg/announcerplugin/formatters/ticket_email.py", line 192, in _format_html temp = formatter.generate(True) File "build/bdist.linux-i686/egg/trac/wiki/formatter.py", line 1452, in generate escape_newlines) File "build/bdist.linux-i686/egg/trac/wiki/formatter.py", line 1194, in format for line in text: TypeError: 'NoneType' object is not iterable
and the HTML ticket notification reads
Comments: Comment in plain text: None
instead of being empty.
With plain text mails, the same ticket modification produces the expected email showing just the attribute change. Thus, the section "Comments:" is not in the plain text mail (as is desired).
This is most likely a very trivial change, but my python knowledge and available time don't allow me to do it.
Attachments (0)
Change History (3)
comment:1 Changed 12 years ago by
Keywords: | ticket TypeError added |
---|---|
Owner: | changed from Robert Corsaro to Steffen Hoffmann |
comment:2 Changed 8 years ago by
Owner: | Steffen Hoffmann deleted |
---|
comment:3 Changed 8 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Please upgrade to Trac 1.2, which has integrated the core of AnnouncerPlugin. Please raise the issue on the trac:MailingList if you encounter the issue with Trac 1.2.
I don't know, but may I suggest that this could be an issue with Agilo as well? IIRC ticket changes always have a comment (empty at minimum), not None.
Admittedly I've not looked into the code yet. It might still be reasonable to allow for more graceful handling of such unexpected events, sure.