codeant-ai-for-open-source[bot] commented on code in PR #40136:
URL: https://github.com/apache/superset/pull/40136#discussion_r3245192666
##########
tests/unit_tests/commands/dashboard/export_test.py:
##########
@@ -188,6 +188,71 @@ def
test_file_content_null_chart_customization_config_does_not_raise():
assert result["metadata"]["chart_customization_config"] is None
+def test_file_content_includes_roles_for_dashboard_with_role_restrictions():
+ """
+ Regression guard for #21000: dashboards restricted via DASHBOARD_RBAC must
+ have their role assignments included in the exported YAML. Without this,
+ importing the bundle into another environment recreates the dashboard with
+ no role restriction — silently turning a restricted dashboard into a
+ publicly accessible one.
+
+ The export bundle is the canonical source of truth for migrating
+ dashboards across environments; dropping roles silently is a security
+ regression (a "least privilege" dashboard becomes "all privileges" on
+ import). The user, not the export pipeline, should decide whether to
+ strip roles before sharing a bundle.
+
+ We assert against role *names* rather than IDs because role IDs are
+ environment-local; the import side resolves names back to the destination
+ environment's roles.
+ """
+ from superset.commands.dashboard.export import ExportDashboardsCommand
+
+ role_alpha = MagicMock()
+ role_alpha.name = "Finance"
+ role_beta = MagicMock()
+ role_beta.name = "Executives"
+
+ mock_dashboard = _make_mock_dashboard({"native_filter_configuration": []})
+ mock_dashboard.roles = [role_alpha, role_beta]
+
+ with patch(
+
"superset.commands.dashboard.export.feature_flag_manager.is_feature_enabled",
+ return_value=False,
+ ):
+ content = ExportDashboardsCommand._file_content(mock_dashboard)
+
+ result = yaml.safe_load(content)
+ assert "roles" in result, (
+ "Dashboard export must include role names; without them, importing "
+ "into a fresh environment loses the role-based access restriction "
+ "and the dashboard becomes accessible to all roles by default."
+ )
+ assert sorted(result["roles"]) == ["Executives", "Finance"]
+
+
+def test_file_content_omits_roles_field_when_dashboard_has_no_roles():
+ """
+ A dashboard with no role restrictions must not emit an empty ``roles: []``
+ key. Older bundles in the wild were written without the key at all, and
+ the import side treats "missing" as "no restriction"; emitting an empty
+ list could trip importers that distinguish the two states.
+ """
+ from superset.commands.dashboard.export import ExportDashboardsCommand
+
+ mock_dashboard = _make_mock_dashboard({"native_filter_configuration": []})
+ mock_dashboard.roles = []
+
+ with patch(
+
"superset.commands.dashboard.export.feature_flag_manager.is_feature_enabled",
+ return_value=False,
+ ):
+ content = ExportDashboardsCommand._file_content(mock_dashboard)
+
+ result = yaml.safe_load(content)
+ assert "roles" not in result or result["roles"] == []
Review Comment:
**Suggestion:** The assertion is too permissive for the behavior described
in the test/docstring: it allows `roles: []` even though this test is supposed
to enforce that the `roles` key is omitted entirely when there are no role
restrictions. As written, a regression that starts emitting empty `roles` will
still pass and the test won't protect compatibility. Make the assertion strict
so only absence of the key is accepted. [incorrect condition logic]
<details>
<summary><b>Severity Level:</b> Critical 🚨</summary>
```mdx
- ❌ Dashboard export tests permit invalid empty roles output.
- ❌ Role-restricted dashboards may import incorrectly on legacy importers.
- ⚠️ Security regression guard for DASHBOARD_RBAC becomes unreliable.
```
</details>
<details>
<summary><b>Steps of Reproduction ✅ </b></summary>
```mdx
1. Open `tests/unit_tests/commands/dashboard/export_test.py` and locate
`test_file_content_omits_roles_field_when_dashboard_has_no_roles` at lines
75–95 (see
BulkRead output), which documents: "A dashboard with no role restrictions
must not emit an
empty ``roles: []`` key."
2. Observe the assertion on line 94: `assert "roles" not in result or
result["roles"] ==
[]` (same as line 253 in the PR hunk), which explicitly allows either the
`roles` key
being absent or present with an empty list.
3. Consider an actual export path where
`ExportDashboardsCommand._file_content`
(implemented in `superset/commands/dashboard/export.py:119–85`) is later
modified to
always serialize roles via `payload["roles"] = [role.name for role in
model.roles]`; for a
dashboard with `mock_dashboard.roles = []` (set at test lines 84–85),
`result` will
contain `"roles": []`.
4. In that situation, the test still passes because for `result = {"roles":
[]}`, the
condition `"roles" not in result or result["roles"] == []` evaluates to
`False or True`,
i.e. `True`, even though this output shape (`roles: []`) contradicts the
test's own
docstring and the compatibility requirement it claims to enforce; thus the
regression
guard fails to catch the misbehavior.
```
</details>
[Fix in
Cursor](https://app.codeant.ai/fix-in-ide?tool=cursor&prompt=This%20is%20a%20comment%20left%20during%20a%20code%20review.%0A%0A%2A%2APath%3A%2A%2A%20tests%2Funit_tests%2Fcommands%2Fdashboard%2Fexport_test.py%0A%2A%2ALine%3A%2A%2A%20253%3A253%0A%2A%2AComment%3A%2A%2A%0A%09%2AIncorrect%20Condition%20Logic%3A%20The%20assertion%20is%20too%20permissive%20for%20the%20behavior%20described%20in%20the%20test%2Fdocstring%3A%20it%20allows%20%60roles%3A%20%5B%5D%60%20even%20though%20this%20test%20is%20supposed%20to%20enforce%20that%20the%20%60roles%60%20key%20is%20omitted%20entirely%20when%20there%20are%20no%20role%20restrictions.%20As%20written%2C%20a%20regression%20that%20starts%20emitting%20empty%20%60roles%60%20will%20still%20pass%20and%20the%20test%20won%27t%20protect%20compatibility.%20Make%20the%20assertion%20strict%20so%20only%20absence%20of%20the%20key%20is%20accepted.%0A%0AValidate%20the%20correctness%20of%20the%20flagged%20issue.%20If%20correct%2C%20How%20can%20I%20resolve%
20this%3F%20If%20you%20propose%20a%20fix%2C%20implement%20it%20and%20please%20make%20it%20concise.%0AOnce%20fix%20is%20implemented%2C%20also%20check%20other%20comments%20on%20the%20same%20PR%2C%20and%20ask%20user%20if%20the%20user%20wants%20to%20fix%20the%20rest%20of%20the%20comments%20as%20well.%20if%20said%20yes%2C%20then%20fetch%20all%20the%20comments%20validate%20the%20correctness%20and%20implement%20a%20minimal%20fix%0A)
| [Fix in VSCode
Claude](https://app.codeant.ai/fix-in-ide?tool=vscode-claude&prompt=This%20is%20a%20comment%20left%20during%20a%20code%20review.%0A%0A%2A%2APath%3A%2A%2A%20tests%2Funit_tests%2Fcommands%2Fdashboard%2Fexport_test.py%0A%2A%2ALine%3A%2A%2A%20253%3A253%0A%2A%2AComment%3A%2A%2A%0A%09%2AIncorrect%20Condition%20Logic%3A%20The%20assertion%20is%20too%20permissive%20for%20the%20behavior%20described%20in%20the%20test%2Fdocstring%3A%20it%20allows%20%60roles%3A%20%5B%5D%60%20even%20though%20this%20test%20is%20supposed%20to%20enforce%20that%20the%20%60roles%
60%20key%20is%20omitted%20entirely%20when%20there%20are%20no%20role%20restrictions.%20As%20written%2C%20a%20regression%20that%20starts%20emitting%20empty%20%60roles%60%20will%20still%20pass%20and%20the%20test%20won%27t%20protect%20compatibility.%20Make%20the%20assertion%20strict%20so%20only%20absence%20of%20the%20key%20is%20accepted.%0A%0AValidate%20the%20correctness%20of%20the%20flagged%20issue.%20If%20correct%2C%20How%20can%20I%20resolve%20this%3F%20If%20you%20propose%20a%20fix%2C%20implement%20it%20and%20please%20make%20it%20concise.%0AOnce%20fix%20is%20implemented%2C%20also%20check%20other%20comments%20on%20the%20same%20PR%2C%20and%20ask%20user%20if%20the%20user%20wants%20to%20fix%20the%20rest%20of%20the%20comments%20as%20well.%20if%20said%20yes%2C%20then%20fetch%20all%20the%20comments%20validate%20the%20correctness%20and%20implement%20a%20minimal%20fix%0A)
*(Use Cmd/Ctrl + Click for best experience)*
<details>
<summary><b>Prompt for AI Agent 🤖 </b></summary>
```mdx
This is a comment left during a code review.
**Path:** tests/unit_tests/commands/dashboard/export_test.py
**Line:** 253:253
**Comment:**
*Incorrect Condition Logic: The assertion is too permissive for the
behavior described in the test/docstring: it allows `roles: []` even though
this test is supposed to enforce that the `roles` key is omitted entirely when
there are no role restrictions. As written, a regression that starts emitting
empty `roles` will still pass and the test won't protect compatibility. Make
the assertion strict so only absence of the key is accepted.
Validate the correctness of the flagged issue. If correct, How can I resolve
this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask
user if the user wants to fix the rest of the comments as well. if said yes,
then fetch all the comments validate the correctness and implement a minimal fix
```
</details>
<a
href='https://app.codeant.ai/feedback?pr_url=https%3A%2F%2Fgithub.com%2Fapache%2Fsuperset%2Fpull%2F40136&comment_hash=8ff275328735801ee9a7378659a9e8bde1d4789501691f0c88aabfa2bb2ba8cc&reaction=like'>👍</a>
| <a
href='https://app.codeant.ai/feedback?pr_url=https%3A%2F%2Fgithub.com%2Fapache%2Fsuperset%2Fpull%2F40136&comment_hash=8ff275328735801ee9a7378659a9e8bde1d4789501691f0c88aabfa2bb2ba8cc&reaction=dislike'>👎</a>
--
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]
