Module Permission Inheritance

Hi team!

We have run into some puzzling App > Module permissions behaviour.

We have an large app which contains a number of modules embedded within.

We ran into an issue where suddenly the app would no longer load for users after embedding a new module to the app (and somehow permissions changed).

I've narrowed the issue down to permissions as once we grant explicit permissions to the modules, it now loads successfully.

What's confusing is that if I:

  1. Create a new app
  2. Add all the same modules to this new app
  3. Add a user to a user permission group with only use permissions granted to the new app (that has the same modules embedded)
  4. The user is able to access the app and it's modules are successfully loaded

I can then:

  1. Remove the access to the new app
  2. Grant access to the older app
  3. The user is unable to load the old app (access denied to the embedded modules)

Some tedious troubleshooting has shown:

  • The user cannot access these modules directly when given access to the old app only, but CAN once also given access to the modules themselves OR the new app (which also embeds the modules in the old app)

  • The initial lookupPage payload includes the embedded module in the new app. It is not fetched after like it is in the old app (I'm assuming this is due to the size of the old app or something?), however;

  • The user is indeed being given access to the linked modules when given use access to the new app ...
    I can see this because I can load the modules themselves directly as that user (by navigating to the modules app 'id')...

This seems to indicate that this is permission based, and not due to some payload related cause

..

Could anyone point me to an explainer on why I'm seeing this differing permission behaviour?

I have only two guesses at why this is happening:

  1. The old app is using an older template version that has different module/permissions behaviour...
  2. The old app is much larger and that is somehow effecting module/permission scoping...

I found one article which went in the right direction: Advanced permissions in Retool: The Fundamentals (Retool for Enterprises) but stops short of speaking to Module related permission behaviour.

For now I will ensure we set explicit use access where required to embedded resources.

Thanks in advance, H

Welcome to the community, @Harry_Martin! Thanks for reaching out. :slightly_smiling_face:

Based on my current understanding and the behavior that you're seeing in a newly created app, the intended pattern is that having any level of access to an app implies Use access to its embedded modules. This implied access can be superseded by explicitly configuring access to the module itself.

I'll reach out to the owning team to see if there was ever a documented shift in the way we handle module permissions that might explain the variation you're seeing. As soon as I have any updates, I'll reach out here. :+1:

In the meantime, you should feel confident that newer apps will properly propagate permissions down to nested modules. It also can't hurt to explicitly assign access, as you mention.

Hi Darren! Thanks for the response!

That is definitely not the behaviour we're experiencing in this case; so it would be great to get some clarification from the dev team :smiley:

Hi Darren, any update on this from the devs?

It's not much, but I've confirmed that Use access to an app's module dependencies should be granted implicitly for any users that have access to the app itself. This is the behavior that you see in newer apps and that I see in my own testing.

I was, however, able to identify a handful of isolated cases in which this access was not being correctly granted for apps that are checked in to source control. The responsible bug was seemingly introduced in version 3.148, as implicit permission inheritance works correctly in 3.114.

Can you let me know whether you're using source control? And, while you're at it, if you're on a cloud or on-prem instance? It seems likely that you are running into the same issue.

Hey @Harry_Martin - I believe the underlying issue causing module permissions in protected apps to not propagate as intended has been fixed! Let me know if you're able to confirm this. :+1: