Setting permissions fails with numeric userids

[james@…]

The company where I work has a new policy of using employees file numbers as their windows username. Ie. we now have use '371732' rather than 'doej'.

Our TRAC installation ( 0.11 ) is running through Apache/mod_python, and apache is using the mod_auth_sspi to link to the Windows authentication server. As a result, we now have the odd "371732" user in TRAC.

If you try to assign permissions to these users in the manage permissions screen ( "Add Subject To Group" ), the permission grant fails with "All upper-cased tokens are reserved for permission names".

It seems that the problem is that the permission name uppercase check is done by checking

subject == subject.upper()

which holds true if subject is all numeric.

I've fixed it on my installation by changing the test to

subject == subject.upper() and subject != subject.lower()

which means that numeric userids are okay, but you still can't have an all uppercase text name.

The relevant check is in the function "render_admin_panel" in admin\web_ui.py. The check is now

if subject and subject == subject.upper() and subject != subject.lower() or \

group and group == group.upper():

raise TracError?(_('All upper-cased tokens are reserved for '

'permission names'))

Please can you apply this change to core ?

[osimons]

Makes sense. I'll look at it.

[osimons]

The various upper/lower checking could likely be replaced by Python regular string methods:

u"Wiki_View".isupper()
#[Out]# False
u"WIKI_VIEW".isupper()
#[Out]# True
u"12345".isupper()
#[Out]# False

They seem to provide correct results for our purposes.

[cboos]

Yes, sounds like a good idea. Maybe in time for 0.11.1?

[osimons]

Replying to cboos:

Maybe in time for 0.11.1?

Sure. Committed in [7378] (0.11-stable) and [7379] (merged to trunk).