3 Replies Latest reply on Jul 19, 2016 7:32 AM by Travis Boyle

    Server 9.2 and above permissions

    Travis Boyle

      Prior to 9.2, we used to be able to parse the next_gen_permissions table and be able to determine the permissions set at the project level, and compare them against the permissions set on the individual workbooks.  9.2 added the ability to lock permissions to the permissions set at the project level.  Unfortunately in attempting to audit permissions prior to making that change, I found that the next_gen_permissions table no longer maintains the permissions set at the project level for more than just the View, Save, and Project Leader permissions. 


      Has anyone found where / how the workbook permissions (Download, Add Comments, Filter, etc.) set at the project level are now stored, so that they can be compared against the individual workbook permissions?


      I've attached the permission audit workbook that I had been able to use previously.  Hopefully I can get all of my project owners to re-standardize their permissions and I'll be able to lock all permissions to the project level, and this will all be moot soon.  Until then, I'm going to keep poking away at trying to sort out these permissions.

        • 1. Re: Server 9.2 and above permissions
          Justin D'Cruze

          I'm not sure on this one.....but based on the table structure I think it's permissions_templates that contains the extended permissions.


          I'm sure someone can correct me if that's wrong

          • 2. Re: Server 9.2 and above permissions
            Jeff Strauss

            Our experience has been that when we started locking permissions at the project level, then permissions at the workbook level were invalid within the next_gen_permissions table.  So we arrived at having to query the projects table attribute "controlled_permissions_enabled", if it's true this indicates that permissions are locked and you need to look at permissions at the project level.  See the attached for SQL that we tested.

            1 of 1 people found this helpful
            • 3. Re: Server 9.2 and above permissions
              Travis Boyle

              Thanks Jeff.


              I've hit the point now where the time required to try to fix my audit workbook just isn't going to be worth it.  Instead we've identified all projects with workbooks that don't match the project level permissions, notified the project owners, and let them know that permissions will be reset.  It is up to the project owners to either request new projects if the need a new permission set, request additional project permissions, or accept that permissions will be reset to the project default.


              Surely not an ideal route, but one that seems unavoidable at this point.  Had I known there was such a major change in the schema, I'd have recorded the permissions audit prior to updating from 9.1.