[oleksandr-nc]

Since Nextcloud 29 every request loads the non-lazy app config values of every app, so an app should keep non-lazy only what it reads on requests that have nothing to do with it.

Every value was loaded on every request

All values were read and written through the deprecated IConfig::getAppValue() and setAppValue(), and setAppValue() always stores a key as non-lazy. The OAuth client credentials, the default link token and the admin switches were therefore loaded on every request of every user, although only dashboard_enabled and issue_notifications_enabled are read there, in Application::register().

Only the two registration switches stay non-lazy

Every read and write of an app config key now goes through the typed methods of IAppConfig, and every delete through its deleteAppValue(): the app-scoped IAppConfig in the app's code, and OCP\IAppConfig in the two migrations, Version030010Date20241002015812, which encrypted the stored credentials, and the new one. No getAppValue() or setAppValue() call is left. The lazy keys pass lazy: true on every read and write, because a read without it can return the default once the key is lazy, and a write without it makes the key non-lazy again.

Lazy, read only by the app's own settings, dashboard widget, OAuth flow, reference providers and GitHub requests:

• client_id, client_secret: the OAuth app, read by both settings pages, the dashboard widget, the OAuth redirect and the token revocation
• default_link_token, allow_default_link_token_to_anonymous, allow_default_link_token_to_guests: read by the admin settings and by SecretService::getAccessToken()
• user_name, user_displayname: the GitHub account of the default token, written when the token is saved or when the admin settings find them missing, and shown there
• use_popup: read by both settings pages, the dashboard widget and the OAuth redirect
• link_preview_enabled: read by the two reference providers whenever a link is resolved, and by the admin settings

Non-lazy:

• dashboard_enabled: decides in Application::register() whether the dashboard widget is registered, and is also read by the admin settings
• issue_notifications_enabled: decides in Application::register() whether the notifier is registered, and is also read by the notification job and both settings pages

Stored values keep their format ('1' and '0' strings), and the client credentials and the default token stay encrypted with ICrypto.

The admin endpoints only write the settings they are for

Besides the three secrets, setAdminConfig() and setSensitiveAdminConfig() wrote any key the request carried. Written lazily, a key the server owns would break the app: a lazy enabled row is not found by the app manager, and the app looks disabled. setAdminConfig() now accepts only the six switches of the admin settings, setSensitiveAdminConfig() only client_id, client_secret and default_link_token, both only as strings, and both answer 400 without writing anything otherwise. The admin settings page sends nothing else.

Existing installs mark the keys lazy on upgrade

Version030301Date20261021102507 calls IAppConfig::updateLazy() for each lazy key, which leaves keys that were never set alone. It runs with the next version bump. Until then, for example on a checkout of main, reads with lazy: true still find the values stored non-lazy, and the next write of a key stores it lazy.

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI