Details

    • Sprint:
      1.7.6 - 01
    • Rank:
      0|ii1mva:
    • Sprint:
      1.7.6 - 01

      Description

      To recreate:

      1. Administer > Data Types > xnat:subjectData
      2. Edit the data type. Add a new Listing Action with these parameters:

        Name: BulkDeleteAction
        Display Name: Bulk Delete
        

      3. Submit.
      4. Go to a project with subject data.
      5. In the Subjects data listing in the project, click the "Options" menu option in the table.
      6. The Bulk Delete action will not present like it would be in 1.7.4.

        Activity

        Hide
        mfmckay@wustl.edu Mike McKay (Inactive) added a comment -

        It looks like this is because actions are not being included in browseableElements. I think the fix will require changes to the caching code and Rick would be best situated to fix it.

        Show
        mfmckay@wustl.edu Mike McKay (Inactive) added a comment - It looks like this is because actions are not being included in browseableElements. I think the fix will require changes to the caching code and Rick would be best situated to fix it.
        Hide
        jrherrick@wustl.edu Rick Herrick added a comment -

        There are a couple of things happening. The immediate cause was a problem in the Javascript in dataTableSearch.js, where the code checked the length of the actions associated with a data type. This doesn't actually work, as length is not a defined property, so that was always false. I modified this to just iterate the map. This results in listing actions appearing for users that don't have browseable, browseableCreateable, etc. elements already cached. Which gets to the second issue, which is that those caches were not updated for users that do have those cached already. I added an event trigger that fires when element securities are updated (the listing actions are actually on the security element for the data type).

        Lastly, there was an unrelated issue on the data type admin page where the action that handles changes to data types redirect to a report page using an absolute path but not qualified by the site URL. When the front-end proxy handles SSL, Tomcat sees the page as http and redirects to http://site/xxx rather than https://site/xxx, which results in a security error in the browser. I changed this so that the paths are qualified by the site URL.

        Show
        jrherrick@wustl.edu Rick Herrick added a comment - There are a couple of things happening. The immediate cause was a problem in the Javascript in dataTableSearch.js, where the code checked the length of the actions associated with a data type. This doesn't actually work, as length is not a defined property, so that was always false. I modified this to just iterate the map. This results in listing actions appearing for users that don't have browseable, browseableCreateable, etc. elements already cached . Which gets to the second issue, which is that those caches were not updated for users that do have those cached already. I added an event trigger that fires when element securities are updated (the listing actions are actually on the security element for the data type). Lastly, there was an unrelated issue on the data type admin page where the action that handles changes to data types redirect to a report page using an absolute path but not qualified by the site URL. When the front-end proxy handles SSL, Tomcat sees the page as http and redirects to http://site/xxx rather than https://site/xxx , which results in a security error in the browser. I changed this so that the paths are qualified by the site URL.
        Hide
        moore.stephen.m@wustl.edu Steve Moore added a comment -

        Sprint nonsense

        Show
        moore.stephen.m@wustl.edu Steve Moore added a comment - Sprint nonsense
        Hide
        moore.stephen.m@wustl.edu Steve Moore added a comment -

        Had to assign to me to open for sprint management.

        Show
        moore.stephen.m@wustl.edu Steve Moore added a comment - Had to assign to me to open for sprint management.
        Hide
        moore.c@wustl.edu Charlie Moore added a comment -

        Sorry, false alarm.

        Show
        moore.c@wustl.edu Charlie Moore added a comment - Sorry, false alarm.

          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 - 1 day, 4 hours
              1d 4h

                Agile