Item5773: SEARCH on topicinfo.author is near-impossible if cUID contains high-bit (or worse) chars

Two things fail in TWiki 4.2 if login names are different from wiki names:

• %SEARCH{"whatever" order="editby"}% sorts according to login names, which looks like "random" fixed in Item5443
• %SEARCH{"TOPICINFO.*author= .%WIKINAME%." type="regex"}% should return all pages edited by the current user, but fails if there are login names which are different from wiki names.
  • The (anyway ugly) workaround %SEARCH{"TOPICINFO.*author= .%USERNAME%." type="regex"}% fails in our case where we have special characters in our login names

Both seem to be related to the fact that with 4.2, the "internal" user name as derived from the login name is being used for TWiki's system actions.

-- TWiki:Main/HaraldJoerg - 14 Mar 2008

From Cairo/4.0 to 4.1 the spec changed so instead of login ID the wikiname was stored in the TOPICINFO author field.

And in 4.2 we again changed to using canonical user ID (cUID)

There is no fix to this problem. This was a non backwards compatible change. We have learned now that changing was seems to be a harmless internal format has a consequence because TWiki apps dig information out of the META content - because there is no other alternative.

For 4.2.1 we probably change the cUID a little to address another issue. We have no alternative to this. So in order to resolve this we probably have to add an additional wikiname or displayname field to the META that people can search for. This requires an update of peoples META searches. And it requires an update scriptof some kind which people only have to use if they need this specific feature.

This may be possible in the scope of 4.2.1. But it can be deferred to 5.0 thus the Normal priority.

Better to delay the fix and get a proper fix than to rush things through.

To those that need a work around for 4.2.0 - change your search so it searches for BOTH the wikiname and the login name. That will work for most. If you use non A-Za-z0-9 login names you may have to find another way to search or to make an advanved piece of TML to create a cUID from the login name.

-- KennethLavrsen - 13 Jul 2008

I've re-titled this bug address the problem that remains: you can now QuerySearch quite reliably, but only if the cUID does not contain any characters which will be escaped using our dum_b e_s_caping format.

I'm not sure how to solve that: it seems we need to teach QuerySearch how to understand the cUID escaping for TOPICINFO.author ?

Same goes for CREATEINFO.author

-- PaulHarvey - 06 Jul 2011