`Admin` permission does not satisfy individual permission checks (Status, Settings, etc.) after upgrade

The problem

Title: Admin permission does not satisfy individual permission checks (Status, Settings, etc.) after upgrade

OctoPrint version: 2.0.0rc (also present on 1.11.8 prior to upgrade)
OS: OctoPi 1.1.0 on Raspberry Pi 3 Model B Plus, Python 3.11.2
Browser: Chrome

Summary

An existing user account with the Admin (Dangerous) permission checked in
Settings → Access Control was found to be missing several individual
operational permissions — confirmed missing at minimum Status and
Settings, likely others. This produced two concrete, reproducible symptoms:

1. GET /api/printer and GET /api/job returned 403 Forbidden on every
   single request, permanently, across a 4-day log capture (over 260,000
   requests each, zero successes) — both endpoints require the Status
   permission per the REST API docs.
2. GET /api/settings returned null for backend-only plugin configuration
   blocks (e.g. a third-party plugin's entire settings object), consistent
   with the documented 2.0.0 behavior change where SETTINGS_READ alone
   only returns frontend-related settings and full Settings permission is
   required for backend config to be returned non-null.

Meanwhile, permissions the account did have explicitly listed — Plugin
Manager, Backup & Restore, Software Update, Logging, Achievements,
Announcements — all worked correctly. This narrows the issue specifically to
Status and Settings (and possibly other core operational permissions)
not being satisfied by the Admin permission, even though Admin was
checked.

Steps to reproduce

1. On an existing instance with an admin-level user account, open
   Settings → Access Control and inspect that account's permission list.
2. Note whether Status, Settings, Connection, Control, Print,
   Files, Webcam, System, and Terminal are present, independent of
   whether Admin (Dangerous) is checked.
3. If any of the above are absent while Admin is present, test:
   curl -H "X-Api-Key: <key>" http://<host>/api/printer → returns 403
   despite the account being flagged admin.
4. Manually check the missing individual permissions (or add the account to
   the Administrators group directly, rather than relying on the standalone
   Admin permission) → both symptoms above resolve immediately.

Expected

An account with Admin (Dangerous) granted should have that permission
satisfy checks for all other permissions, consistent with how "admin" is
generally understood to work, and consistent with pre-2.0.0 behavior where
admin_permission served as a blanket check.

Actual

Admin is checked, but Status/Settings (and likely others) are not
independently satisfied by it, leaving admin-labeled accounts unable to
access core printer status or read/write plugin settings until those
specific permissions are also manually granted or the account is added to
the Administrators group.

Notes

This is likely to affect anyone upgrading an existing instance rather than
doing a fresh install, since it's easy to assume an account already marked
admin carries full access forward. Worth surfacing prominently in the
2.0.0 migration/release notes if confirmed as expected (rather than
accidental) behavior, since right now it presents as a silent, unexplained
loss of core functionality with no error pointing at the cause.

Did the issue persist even in safe mode?

Yes, it did persist

If you could not test in safe mode, please state why ("currently printing" is NOT an excuse!)

No response

Version of OctoPrint

OctoPrint 2.0.0rc

Operating system running OctoPrint

Python 3.11.2 OctoPi* 1.1.0 (build 2025.09.09.113029 on Pi 3 B Plus

Browser and version of browser, operating system running browser

Chrome 151.0.7922.76 Mac mini M4 26.5.1

Printer model & used firmware incl. version

Ender-3 V2 SE

Systeminfo Bundle

octoprint-systeminfo-20260810204859.zip[^bundle1]

Checklist of files to include below

• Contents of the JavaScript browser console (always include in cases of issues with the user interface)
• Screenshots and/or videos showing the problem (always include in case of issues with the user interface)
• GCODE file with which to reproduce (always include in case of issues with GCODE analysis or printing behaviour)

Additional information & file uploads

No response

[^bundle1]: octoprint-systeminfo-20260810204859.zip (bundleviewer) (download)
OctoPrint: 2.0.0rc4
Python: 3.11.2
OS: Linux-6.6.51+rpt-rpi-v7-armv7l-with-glibc2.36
RPi: Raspberry Pi 3 Model B Plus Rev 1.3
OctoPi: 1.1.0 (build 2025.09.09.113029)
Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36

Start with the Access Control permission handling and the checks behind GET /api/printer, GET /api/job, and GET /api/settings. Trace how the standalone Admin permission is evaluated versus individual permissions and the Administrators group. Done means an account with Admin receives the expected Status and Settings access, including backend plugin settings, without manually granting each permission; add or update regression coverage if the relevant tests are found.