Upgrading to v6.1.x: everything you need to know

Last updated: October 23, 2026

This page lists the changes in v6.1.x that may need action from you when your workspace moves from v6.0 to v6.1.x. It only covers changes you need to prepare for. For all other changes, see the Preset changelog.

We update this page as new v6.1.x releases ship, and remove entries once they no longer need action. Each entry shows the v6.1.x release we verified it on. To see which version your workspace runs, open Settings in the top-right menu and scroll to the bottom of the list: the version appears under About (for example, "Version: 6.1.0.13").

Summary

"Owners" is now "Editors"

What changed

Owners are now called editors. An editor has the same rights an owner had on the asset.

In the app:

• Dashboard and chart properties show an Editors field instead of Owners.
• Dashboard, chart and alert lists have an Editor filter and an Editors column.
• Alerts and reports use the same Editors field.

In the API:

• Dashboards, charts, datasets and alerts/reports have an editors field. It holds subject IDs, not user IDs.
• Every user has a subject ID, and it is usually a different number from their user ID. Look it up with GET /api/v1/security/subject/, filtering on user_id:
  GET /api/v1/security/subject/?q=(filters:!((col:user_id,opr:eq,value:<user_id>)))
• To list the subjects you can assign, use GET /api/v1/dashboard/related/editors (or /chart/, /report/).
• To change editors, send editors with subject IDs, for example PUT /api/v1/dashboard/<id> with {"editors": [<subject_id>, ...]}.

The owners field still works, but is deprecated

The legacy owners field (user IDs) and related/owners still work on dashboards, charts, datasets and alerts/reports, so existing scripts keep working. They are deprecated: move to editors, which is the standard going forward.

• There is no removal date. owners stays supported until a new version of the API is available, and for a while after that.
• Send either owners or editors, not both. Sending both in one request returns 400 "Use either owners (user IDs) or editors (subject IDs)."
• An unknown user ID in owners returns 422 "One or more users do not exist."

Important: don't send user IDs in editors.
If a script renames owners to editors but keeps sending user IDs, the request succeeds (HTTP 200) with no warning, and:

• the editors become whoever holds those subject IDs, which can be different people, and
• the whole editors list is replaced, so the previous editors lose edit rights.

Convert user IDs to subject IDs before sending them in editors. Until a script has been migrated, keep it sending user IDs in owners.

MCP

• MCP responses don't include owners or editors. This is by design, for privacy.
• The editor filter in MCP list tools takes a user ID (you can find one with the find_users tool), while the API's editors field and filter take a subject ID. They are different IDs, so the same number can mean different people. Don't reuse IDs between the two.

Who is affected: anyone with scripts, integrations or MCP workflows that read or set owners.

What to do before upgrading

1. Find scripts and integrations that read or set owners, including any that use owners or related/owners.
2. Move them to editors, converting user IDs to subject IDs.
3. Check that nothing sends user IDs in editors.

Status: Permanent change. owners remains available as a deprecated field.

Draft dashboards open only for their editors

What changed

In v6.0, a user with access to a dashboard's data could open a Draft dashboard through a direct link, even if they were not an owner and it didn't appear in their dashboard list.

In v6.1.x, a user who isn't an editor of a Draft dashboard gets a "Page not found" (404) page when opening its link, even if they have access to its data. Editors open it as before.

Dashboard links now use the format /dashboard/<id>/. Older links in the format /superset/dashboard/<id>/ redirect to the new format, so they keep working, and the same rule applies to them.

Who is affected: teams who share links to Draft dashboards, for example with users in the Dashboard Viewer role.

What to do

• Publish dashboards that other people need to open.
• Or add those people as editors of the Draft dashboard. What being an editor allows depends on the user's workspace role:
  • Viewer, Dashboard Viewer and Dashboard Interactor: they can open the dashboard, but they still can't edit it.
  • Other workspace roles: they can open the dashboard and edit it.

Status: Expected behavior in v6.1.x.