mapledan commented on issue #39967:
URL: https://github.com/apache/superset/issues/39967#issuecomment-4436558712
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
```python
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:
```python
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
