This is not a complete patch.  I've worked on it for
the rdbms section but nothing else.  In our tracker, we
wanted the user's realname to show when possible.  So
we added a labelprop to the realname.  That seemed to
work fine at first.  The problem is that the user is a
Multilink in the nosy list.  So when the nosy list is
being displayed it is showing the realnames.  That in
itself is ok, but if you make any changes, it tries to
find the realnames.  What I did was create a new
function that is similar to lookup but uses the
labelprop instead of a key.  This new function I called
llookup.  I added a stub function in hyperdb.py and the
good function in rdbms_common.py.  I then modified the
KeyError in hyperdb.py to see if there is a labelprop.
 If there is, I call the llookup to find the row based
on the labelprop.  If it can't find it or there isn't a
labelprop, it then gives the KeyError.

As stated before, I did not make the necessary changes
anywhere but in the rdbms_common.py and hyperdb.py. 
back_anydbm.py and back_metakit.py would still need to
be changed.

My email is:
David.Byrne@cambridge-na.com

Thanks,
David Byrne

Logged In: YES 
user_id=6405

Perhaps label props shouldn't be used in the actual 
editing fields. Perhaps those fields should only use the 
key prop.

Logged In: YES 
user_id=53454

Our client uses a special number for identifiers in their
applications.  This number has no special meaning as far as
being recognized immediately by anybody (they call them 'A'
numbers -- its the letter 'A' followed by a 5 digit number).
 These identifiers are usually only known by the user.  So
we want to reuse these 'A' numbers for login purposes.  But
so that users can see who submitted the issue, we use the
real names for the labelprop.  As I stated originally, the
problem comes in with multi-links.  Roundup is putting the
label version in the field when it is displaying it.  When
the issue is committed (even without changes to the nosy
list), it still validates the nosy list.  Without my patch,
it errors off the label values that it placed in there.

This is a feature interaction. It's generally not a good idea to assign
a labelprop (different from the key) to something already having a key
property. I think there is no good way the resulting problems can be
resolved. So don't do that :-)

Better modify the html templates to display the additional label where
necessary.