This Bug Report affects these Traffic Control components:

• Traffic Ops

Current behavior:

/user/current validates the role field and will reject requests that specify a new Role with greater Permissions (or in old version PrivLevel) than the user's current Role - but even if that validation passes, it's not possible to use this endpoint to change Role. The request will succeed, but even in the response to that request, the user's Role remains unchanged.

/user/current GET requests also always show gid and uid as null, even when they aren't. Curiously, it does allow the user to change these fields, and the responses to PUT requests that do so will show the correct values. Subsequent GET requests will show null.

Expected behavior:

/user/current shouldn't show the wrong value for fields, and if it's intended to be able to change a user's Role using it then that should work. If that's not intended, then the field should be ignored, not validated, and removed from the request documentation.

Steps to reproduce:

PUT to /user/current changing your Role to anything you have permission to change it to. Observe that it didn't happen.

PUT to /user/current changing your uid and gid to anything non-null. Observe that both still appear to be null in GET responses.

It is unknown if this is a regression or if this has just been broken forever, since uid and gid have no known use and changing a user's own Role is rare and generally not very advisable because they can only be taking permissions away from themselves - so it's possible this never worked and nobody noticed because nobody needed it to work.