Consider the case that a user registers to an XNAT site, is approved by the admin, logs in, requests access to a project, is granted access. This is a fairly common use case and should work correctly. In 220.127.116.11, there are all sorts of UI issues, such as the user not being able to add experiments, and getting errors on the project page (and being unable to view the users on the project even if they were granted owner access). There are a variety of ways of triggering this bug (and I found it because everything was buggy after I tried giving my CNDA account access to a project so I could work on another issue), such as the steps described in detail below.
After Mike ran into an issue similar to
XNAT-5922, we were able to come up with some steps that seem reliable to recreate the issue on base XNAT 18.104.22.168:
- As an admin, create a new user.
- Strange, but important: logout as the admin, login as the new user, logout as the new user, and log back in as the admin. If you skip logging in as the user here, the issue doesn't show up.
- Add the new user to a project as an owner via the access tab. The project should have (at least) an MR session.
- Log back out.
- Login as the new user. Do the REST calls to: /xapi/access/displays/browseableCreateable and /xapi/access/displays/browseable. It returns an empty array for both, which is NOT correct (the list should include at least the MR session data type).
- Clear the data access cache for the user (click the username link at the top, then go to "Manage Cached Resources".
- If you repeat the REST calls again, they STILL return empty lists (!!!!)
- If you then create a project as this user, the REST call populates with the expected data types.
Note that the incorrectly cached values will cause (non-exhaustive):
- No data types show up on advanced search.
- New > Experiment list of data types is empty.
- Browse > Data top nav UI element does not display.