Roundup Tracker - Issues

Message2224

Author schlatterbeck
Recipients
Date 2006-03-06.15:38:05
Message-id
In-reply-to
I need a class "machine" that can be linked to by other
classes. Since there are *many* machines, I want a
field, not a menu for machines. This doesn't work if
there are machines with names like "12345" consisting
of digits only. If I'm selecting such a machine using
classhelp, I get an error message "machine has no node
12345".

To reproduce with the standard "classic" tracker:
- create a new tracker with postgresql backend
- Add a new priority named "12345"
- edit issue.item.html to make the priority a field
with classhelp:
 <td>
  <span tal:replace="structure context/priority/field"/>
  <span tal:replace="structure python:db.priority.classhelp
       ( 'name,order'
       , property='priority'
       , inputtype='radio'
       , width='600'
       )"/>
 </td>
- Add a new issue and select the priority "12345" by
either using classhelp or manual input
-> error message "Error: priority has no node 12345"

If I'm entering a non-existant priority, I'm getting a
traceback: ERROR:  invalid input syntax for integer: "1
2345a"(see attached file). Here I expect an error
message, e.g., "Error: priority has no node 12345a".

Seems like cgi/actions.py directly hands the
untranslated value '12345' to the backend (if I'm
throwing a different exception in line 1347 of
backends/rdbms_common.py, I'm getting a traceback
indicating that the offending value was passed to the
backend). I think it should do a lookup first --
similar to the new modified lookupIds method in
cgi/templating.py, see also the related bug-report
https://sourceforge.net/tracker/?func=detail&atid=402788&aid=1424550&group_id=31577
"IndexError when copying an issue".

Note that I'm also seeing the untranslated '12345' for
the priority in an auditor!

I currently have no idea where this should be fixed, if
an existing name of a priority is input I'm seeing the
id of the priority in the backend (and the auditor),
not the name, so it looks similar to the bug in the
bug-report mentioned above.
History
Date User Action Args
2009-02-03 14:21:43adminlinkissue1444214 messages
2009-02-03 14:21:43admincreate