1 Reply Latest reply on Jul 13, 2018 8:20 AM by Matt Coles

    TabCmd: Changing User Site Role and Project Group Role

    Melissa Demcsak

      As a standard practice, our production Tableau environment does not allow Report Developers to publish in production.  On a regular basis, we plan to restore a production backup on our QA/Dev environments.  Immediately after the restore we need to perform the tasks below to allow Report Developers to publish in QA/Dev.  Thus far, I've used the user admin tools in the Tableau site, but it would be more productive to have these tasks scripted.  I spent time reviewing TabCmd documentation and playing, but I didn't find a way to script these tasks.  And I even found this idea (https://community.tableau.com/ideas/5933) for voting up.

       

      Has anyone else scripted these tasks?  Any ideas? TIA

       

      Post QA/Dev Restore Tasks

      #1: Change the User Site Role to 'Publisher' for all users in our Report Developers Group

      #2: For every Project that includes our Report Developers Group, change the Project Group Role to 'Publisher'.

       

      Thanks!

      Melissa

        • 1. Re: TabCmd: Changing User Site Role and Project Group Role
          Matt Coles

          #1: You must use tabadmin syncgroup for the Report Developers Group with --role "Publisher". Alternatively, you can use the Server API to change their roles. See Update User.

           

          #2: For this you'll need the Server API. See Query Projects, Query Project Permissions, and the Delete and Add Project Permissions call, too.

           

          If you know Python, there's a great client written for it that makes talking to the REST API pretty easy. Powershell would be fairly nice to work with too, I would think.

           

          All that aside, this is a fairly complex process just for testing. Have you considered using a different method, such as using Sites or Projects to denote test workbooks/data sources--then publish them to the official project / site when cleared? That's how we approach it. That strategy might not be advisable if you are doing load-testing on the new content being developed, but typically that'd be a server-wide QA activity, suitable for something like a major upgrade.