Uploaded image for project: 'XNAT'
  1. XNAT
  2. XNAT-5925

Improper caching of data access when user added to project

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.7.5.1
    • Fix Version/s: 1.7.5.2
    • Component/s: None
    • Sprint:
      1.7.5.2 Point release
    • Rank:
      0|ii1nlz:
    • Sprint:
      1.7.5.2 Point release

      Description

      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 1.7.5.1, 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 1.7.5.1:

      1. As an admin, create a new user.
      2. 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.
      3. Add the new user to a project as an owner via the access tab. The project should have (at least) an MR session.
      4. Log back out.
      5. 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).
      6. Clear the data access cache for the user (click the username link at the top, then go to "Manage Cached Resources".
      7. If you repeat the REST calls again, they STILL return empty lists (!!!!)
      8. 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):

      1. No data types show up on advanced search.
      2. New > Experiment list of data types is empty.
      3. Browse > Data top nav UI element does not display.

        Issue Links

          Activity

          Hide
          gkgurney@wustl.edu Jenny Gurney added a comment -

          This may have all been caused by the corrupt hash indexes. Please retry on a fresh CNDA VM. Thanks!

          Show
          gkgurney@wustl.edu Jenny Gurney added a comment - This may have all been caused by the corrupt hash indexes. Please retry on a fresh CNDA VM. Thanks!
          Hide
          mfmckay@wustl.edu Mike McKay added a comment -

          Just to note in case it was unclear, we had already recreated this issue on non-CNDA 1.7.5.1 XNATs, so I see no reason to think it would now work on a fresh CNDA VM. Not that we can't test, but I wouldn't be comfortable setting this one aside until the core XNAT issue is fixed.

          Show
          mfmckay@wustl.edu Mike McKay added a comment - Just to note in case it was unclear, we had already recreated this issue on non-CNDA 1.7.5.1 XNATs, so I see no reason to think it would now work on a fresh CNDA VM. Not that we can't test, but I wouldn't be comfortable setting this one aside until the core XNAT issue is fixed.
          Hide
          jrherrick@wustl.edu Rick Herrick added a comment -

          Added more info to group update events. Now the cache clears and regenerates user cache entries when group memberships are updated.

          Show
          jrherrick@wustl.edu Rick Herrick added a comment - Added more info to group update events. Now the cache clears and regenerates user cache entries when group memberships are updated.

            People

            • Assignee:
              moore.c@wustl.edu Charlie Moore
              Reporter:
              moore.c@wustl.edu Charlie Moore
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 3 hours
                3h

                  Agile