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.

I don't have a solution for this but I think this is another victim of "ids are strings and not ints". We force Link and Multilink values to be strings and then we need to determine whether that string is an id or a key during the creation. Currently we assume it is an id if it matches a number regexp and a key otherwise. This breaks down when the keys are also integers.

might a solution like that in:

  issue2550748

which captures the exception from looking up the number as an id
and forces it to be considered a name work?

This would probably not do what was intended if the machine name
just happened to be a valid id 8-(.

I have implemented this some time ago:
In the schema-definition of links or multilinks to something that can
have numeric names, you define the option "try_id_parsing='no'".
This will change the parsing algorithm whenever numbers are entered in
fields for this Link/Multilink. The default for this attribute is "yes"
to preserve the standard behaviour. When set to "no", numbers will not
be interpreted as object ids.

Now we might argue that this is sub-optimal because it really should be
a parameter of the roundup item, not the link/multilink to it.

And there should be some more documentation on this.

But this is in production for some time now and works as expected.

Example schema definition:

    customer_agreement = Class \
        ( db
        , ''"customer_agreement"
        , customer         = Link      ("customer")
        , product          = Link      ("product", try_id_parsing='no')
        , description      = String    ()
        )
    customer_agreement.setlabelprop ("customer")
    customer_agreement.setorderprop ("description")

Another note: When parsing link values as IDs the traceback documented
in the attachment is not the major problem. The main problem is when
this works and an item exists in the database with the given ID: In that
case the item with the ID is linked, not the item with the (numeric)
name. Which -- in most cases -- is not what the user expects.

Just pushed the missing documentation.
Closing.