Retool permission groups, spaces, and source control: “Groups that can run this query” are stripped

[sgodoshian]

Questions

1. What is the recommended way to configure and manage query-level access controls (“Groups that can run this query”) so they remain portable across spaces when using Source Control?
2. Is there a supported way to share or map permission groups across spaces for orgs using a gitflow branching strategy?

Context

Our enviroment

We recently switched over to an enterprise plan and are adopting spaces and source control, and following a gitflow branching strategy. We have our main/organization space on the main branch, and out uat space on the uat branch. We will create branches off of uat, merge into uat, get approval, then cherry-pick into main. We want to enforce backend resource query access restrictions, by leveraging the Groups that can run this query access controls.

Problem

When I protect an app in main and sync it into uat, any Groups that can run this query access controls set on resource queries are removed in uat after I create a branch and make unrelated edits. This appears to happen because permission group IDs are different between spaces, so Retool can't resolve them.

Steps to Reproduce

1. In main space (main branch), set Groups that can run this query for several queries in an app.
   • 
2. Protect the app and sync it to uat space (uat branch).
3. In uat, create a feature branch and make a small change (not touching the queries).
4. Observe that:
   1. the query-level group restrictions are now unset in uat
   2. the Retool generated schema changes... auto commit reflects the removals.
   • 
   • 

What we’ve already tried

• Ensured all corresponding permission group names exist in uat
  • Verified that only the permission group IDs differ
• Confirmed the removals are introduced by the Retool generated schema changes... commit, not by our manual edits
• Tried toggling these Source Control settings in uat, and making a new branch an PR, but it made no difference
  • Disable auto catch up commits
  • Force UUID mapping

[sgodoshian]

Here's screenshots showing that the permission groups I shared in my example exist in both spaces with the same names, but the IDs differ:

uat space permissions

main space permissions

[Darren]

Hey @sgodoshian! In talking to the team, it sounds like permission groups are expected to sync via name when using source control, so the behavior you're seeing is definitely unexpected.

I've done a fair bit of testing and initially suspected that capital letters and/or special characters in the group names might be causing an issue, but I'm unable to reproduce it. One point of clarification - how are you syncing the changes from main to uat? Through a PR in Azure, I assume?

[sgodoshian]

Hi @Darren ! Thank you for checking in on this.

@Erin_Masatsugu worked with us on this and it turns out that the problem was because the permission groups weren't created in our uat space prior to syncing the protected apps from main into uat.

Our workaround is to unprotect the apps in main, sync to uat, then re-protect the apps in main and sync to uat. Going forward, we'll make sure that permission groups are created in our spaces before we sync the code into those spaces.

[sgodoshian]

For reference and so others know this isn't a problem, the allowedGroupIds will still be updated, but the allowedGroups will remain unchanged. Screenshot of our PR for example:

[Darren]

Thanks for providing an update, @sgodoshian! Glad to hear this was resolved.