Opened 16 years ago
Closed 16 years ago
#7769 closed defect (fixed)
Custom non-required Select fields that are empty cause notification to fail
Reported by: | Owned by: | Remy Blank | |
---|---|---|---|
Priority: | normal | Milestone: | 0.11.3 |
Component: | notification | Version: | 0.11.1 |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Similar to #929, I get the following traceback when making changes to a ticket:
File "/usr/lib/python2.4/site-packages/Trac-0.11.1-py2.4.egg/trac/ticket/web_ui.py", line 992, in _do_save tn.notify(ticket, newticket=False, modtime=now) File "/usr/lib/python2.4/site-packages/Trac-0.11.1-py2.4.egg/trac/ticket/notification.py", line 139, in notify self.data.update({ File "/usr/lib/python2.4/site-packages/Trac-0.11.1-py2.4.egg/trac/ticket/notification.py", line 159, in format_props error(self, u"f is: %s" % str(f)) AttributeError: 'NoneType' object has no attribute 'find'
The field it is erroring on is a custom select that for this specific ticket is blank.
The attached patch fixes it for me, but it seems like this would be more prevalent since that line was changed back in [1832]. I have a number of plugins installed, including agilo.
Attachments (1)
Change History (7)
by , 16 years ago
Attachment: | notification.diff added |
---|
comment:1 by , 16 years ago
comment:2 by , 16 years ago
code is:
if fval.find('\n') != -1
not continue like that traceback says.
comment:3 by , 16 years ago
This has been reported again on trac-users. Jonas has suggested the following patch, which would make sense as a complement to [7463]:
-
model.py
old new 109 109 cursor.execute("SELECT name,value FROM ticket_custom WHERE ticket=%s", 110 110 (tkt_id,)) 111 111 for name, value in cursor: 112 if name in custom_fields :112 if name in custom_fields and value is not None: 113 113 self.values[name] = value 114 114 115 115 def __getitem__(self, name):
However, I cannot reproduce the issue on current 0.11-stable. This might have already been fixed by [7463] (for custom fields, #7465) and [7570] (for core fields, #4061).
OTOH, I cannot reproduce this on 0.11.1 either. I have tried setting core and custom fields to NULL
, but they are invariably set to a non-NULL
value before the notification is triggered.
Do you happen to use a plugin that hides some ticket fields? The only way I could imagine how the custom field could remain NULL
until notification is if the field is absent from the request, meaning that the field is not in the properties form.
comment:4 by , 16 years ago
Keywords: | needinfo added |
---|---|
Owner: | changed from | to
comment:5 by , 16 years ago
Possibly, I would guess agilo does something like that.
Here is our list of plugins:
- AutocompleteUsers 0.3
- BatchModify 0.2.0
- BreadCrumbsNavPlugin 0.1
- TracAccountManager 0.2.1dev-r3857
- TracAddressMacro 0.1
- TracAutoLinks 1.0
- TracDuplicates 0.1
- TracNoAnonymous 2.0
- TracTags 0.6
- TracTocMacro 11.0.0.3
- agilo 0.7
- cc-selector 0.0.2
- ticket-clone r6326
Let me know if you need any more information.
comment:6 by , 16 years ago
Keywords: | needinfo removed |
---|---|
Milestone: | → 0.11.3 |
Resolution: | → fixed |
Status: | new → closed |
I bet on Agilo, as it seems to remove fields from the ticket page. I actually had to disable the validation of ticket fields in Trac to be able to reproduce the issue!
Anyway, it's fixed now in [7720]. Thanks for the bug report.
Sorry, that traceback should be: