Permission dropdown in `Role Edit Form` fails to echo names of bound permissions

[TeCHiScy]

Bug description

1. Have superset 6.1.0rc3 installed
2. Go to Settings -> List Roles
3. Edit a Role such as Public, the Role must have some permission bound
4. Open the Permission dropdown, there's a toast saying There was an error loading permissions. At the same time, you will find the UI fails to echo names of some permissions already bound

---

I've digged into this problem, and found that when Permission dropdown is opened, a request to /api/v1/security/permissions-resources/?q=(page:0,page_size:100) is generated. However, with page_size = 100 set, it can not ensure the bound permissions to be returned in the first page, which causes the UI fails to echo permission names. After all pages are loaded (by scrolling to the bottom of the dropdown), names shows.

Meanwhile, I found that, when I open the Role Edit Form on a role with some permissions bound, a request to /api/v1/security/permissions-resources/?q=(filters:!((col:id,opr:in,value:!(7,15,236,72,73,75,109))),page:0,page_size:100) is generated. However, this api call returns HTTP 400 with body {"message":"Filter column: id not allowed to filter"}. If I understand correctly, this API call is to fetch permission names for bound permissions. Since this call fails, there's no way to map permission id to names unless all permission data was fetched through successive paging requests.

I also found that if I perform a search in the permission dropdown, a request to /api/v1/security/permissions-resources/?q=(filters:!((col:view_menu.name,opr:ct,value:ca)),page:0,page_size:1000) is generated, but also with HTTP 400 and body {"message":"Filter column: view_menu.name not allowed to filter"} or {"message":"Filter column: permission.name not allowed to filter"} returned. This leads to the issue that users can not search the appropriate permission, such as can explore json on Superset.

Based on the aforesaid findings, it should be concluded that the Permission dropdown in role edit form is buggy and not able to use. If one want to review the bound permissions, or to search and add some new permissions, he has to first scroll down to the bottom of the dropdown, to get all pages of permissions detail fetched.

Screenshots/recordings

2026-05-08.21.28.39.mov

Superset version

6.0.0

Python version

Not applicable

Node version

16

Browser

Chrome

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[TeCHiScy]

Continue digging the root cause, I found that the api /api/v1/security/permissions-resources is provided by upstream dependency named Flask-AppBuilder.

In file:

https://github.com/dpgaspar/Flask-AppBuilder/blob/master/flask_appbuilder/security/sqla/apis/permission_view_menu/api.py#L6

It can be seen that no search_columns were defined, which leads to id, permission.name, view_menu.name not searchable.

Currently, my workaround is to build a custom superset docker image which patches this file by:

FILTERS=$(find /app/.venv -path "*/flask_appbuilder/models/filters.py") && \
sed -i 's/self._search_filters\[k\] += v/self._search_filters.setdefault(k, [])\n                self._search_filters[k] += v/' $FILTERS && \
API=$(find /app/.venv -path "*/flask_appbuilder/security/sqla/apis/permission_view_menu/api.py") && \
sed -i '1i\from flask_appbuilder.models.sqla.filters import FilterContains, FilterEqual, FilterNotEqual, FilterStartsWith, FilterIn' $API && \
echo '    search_columns = [ "id", "permission.name", "view_menu.name" ]' >> $API && \
echo '    search_filters = { "permission.name": [ FilterContains, FilterEqual, FilterNotEqual, FilterStartsWith, FilterIn ], "view_menu.name": [ FilterContains, FilterEqual, FilterNotEqual, FilterStartsWith, FilterIn ] }' >> $API

If the aforesaid solution is acceptable, I'm happy to draft a PR.

[mapledan]

We hit the same two filter errors on 6.1.0rc3 while working on the Role Edit Form's permission dropdown, and wanted to share what we found in case it helps narrow down the root cause.

Reproduction matches the report:

GET /api/v1/security/permissions-resources/?q=... with a filter on id returns 400 Filter column: id not allowed to filter.
Same call filtering by view_menu.name (or permission.name) returns 400 Filter column: view_menu.name not allowed to filter.
Root cause we observed (FAB side, not Superset):
The endpoint is served by FAB's built-in PermissionViewMenuApi, which does not declare search_columns for id or the dot-notation related columns. Even when you subclass it and set

search_columns = ["id", "permission.name", "view_menu.name"]

the request still fails. The reason is in flask_appbuilder.models.filters.Filters.init: when it merges search_filters, it does effectively self._search_filters[k] += v, which requires the key to already exist in the dict. _init_properties only auto-populates entries for columns it can resolve on the local model — dot-notation related columns (permission.name, view_menu.name) are never auto-detected, so the key is missing and the filter is rejected as "not allowed".

Workaround that worked for us:
Override PermissionViewMenuApi and inject the filter instances manually after _init_properties runs:

from flask_appbuilder.models.sqla.filters import FilterContains
from flask_appbuilder.security.sqla.apis import PermissionViewMenuApi

class SupersetPermissionViewMenuApi(PermissionViewMenuApi):
    search_columns = ["id", "permission.name", "view_menu.name"]

    def _init_properties(self) -> None:
        super()._init_properties()
        for col in ["permission.name", "view_menu.name"]:
            self._filters._search_filters[col] = [
                FilterContains(col, self.datamodel)
            ]

and wire it via SupersetSecurityManager.permission_view_menu_api = SupersetPermissionViewMenuApi. After this, both the id-based hydration call and the user-typed search call return 200, and the bound permission names render without the "scroll to load all pages" workaround.

Sharing for reference — this was an AI-generated workaround we applied locally to unblock ourselves, not a proper fix.

[sadpandajoe]

@dosubot has this been fixed as part of 6.1.0?

[dosubot]

Based on my research, this issue is only partially addressed in the Superset codebase:

PR #38387 (merged March 6, 2026) converted the permissions/groups dropdowns to AsyncSelect with server-side search, which assumes FAB's /api/v1/security/permissions-resources/ endpoint supports filtering by id, view_menu.name, and permission.name [1]. That PR should be included in a 6.1.0 release given the merge date.

However, as the issue reporter identified, the root cause lives upstream in Flask-AppBuilder — the PermissionViewMenuApi class doesn't define search_columns, meaning those filters return HTTP 400. Superset currently pins FAB to >=4.7.0, <5.0.0 [2], and I could not find evidence that any FAB 4.x release has added search_columns to that API class.

So the situation appears to be:

• The frontend (PR fix(roles): convert permissions/groups dropdowns to AsyncSelect with server-side search #38387) correctly tries to use server-side search/filtering ✅
• The backend (Flask-AppBuilder) still doesn't allow those filters ❌

Unless FAB was patched upstream or Superset added an override to the FAB API class, this bug likely still exists in 6.1.0. The reporter's workaround of patching the FAB source to add search_columns = ["id", "permission.name", "view_menu.name"] remains the fix. A proper resolution would require either an upstream FAB PR or a Superset-side override of the PermissionViewMenuApi.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[venkatamandavilli-code]

Thanks for reporting this issue and including the stack trace. The behavior seems related to datasource permission validation rather than the dataset itself actually being deleted.

From the logs, it looks like Superset is failing during the datasource permission check (check_datasource_perms) and then returning the generic “dataset no longer exists” message afterward. In some cases, this can happen when the chart metadata, datasource ID, or security context becomes inconsistent after chart updates or datasource changes.

It may help to verify:

• whether the datasource ID referenced by the chart still matches the active dataset
• whether role permissions were updated recently
• whether cached chart metadata is referencing an older datasource state
• whether the same issue occurs with admin-level access

The 403 response during explore_json also suggests there may be a permission or security validation issue happening before the chart render completes.

Thanks again for documenting the logs and reproduction steps clearly.