Package-level declarations

Finds the preferences and the wording a command is for: their ids are derived from what they are for (ScopedIds), as the 9.x preferences and wording routes derived them, so a request names none and one that names an id is sent to the derived one all the same: nobody takes another owner's or application's id. Without the application the command names no id, and the aggregate refuses it (view-store.app-required).

The shared dashboards that reference a view, from the view snapshots: every shared dashboard of the tenant and the application, a keyset page of PAGE at a time, each read only for its id, its title and its config (the schema projects nothing deeper in it), whose panels' references are then matched here (no dashboard past a bound is missed, and a claim holds one page of configs in memory, never every dashboard's). 9.x matched the panels in the query; the query protocol has no element match into a free-form config, so the panels are read instead.

The view reads of the view store's routes: the system views from systemViews, the saved views from the view snapshots. The snapshots are read as trusted code, the view store's own, which no access policy restricts, so each read keeps to its application here as the views' access policy does for a caller's query (ViewStoreConfiguration). A node whose backend serves no snapshot query reads no saved view.

The view store's reserved owners behind another resolver, CoSec's or the host's development callers' (roadmap P.15): a caller whose Wow-Scope names the owner (shared), or the tenant (platform) with the owner (system), acts as that owner (ViewStoreRoles.reservedTarget), as 9.x had it from the path …/owner/(shared)/…. Every authenticated caller reads there; the ViewStoreAuthorizer decides who writes, by the roles decorated gave it. Any other Wow-Scope is left to decorated and admission: a user does not act as another one.

Keeps the view store's reads to an application: a read by a caller without one, a query of any model, a state read or a trace, is refused as malformed (wow.query.malformed, 400) before anything is read, as the view store's commands refuse it (APP_REQUIRED). Who is reading has no application: the request's CoSec scope names none. Which application's views, preferences and wordings a caller then reads is the access policies' (ViewStoreConfiguration): each aggregate records its application, appId, as an access attribute. Trusted in-process code, which reads with no caller, is not asked.

Who writes what in the view store, the 9.x gateway's write rules:

The view store's beans: its callers, its write rules, its derived ids, its access policies and the application its reads need, the board lookup, the system views and the handlers of its own routes.

The view store's roles, which a caller lists in its attribute ROLES_ATTRIBUTE (from the identity the CoSec gateway forwards, or the Wow-Roles header in development), and its reserved owners, which a caller acts as by naming them in Wow-Scope (ReservedScopeCallers).

The view store service on the Wow host: the host finds the view store's models and saga through view-store-domain's binding index, serves their routes on the public port and the cluster on the internal one. It runs on the memory backend, or on PostgreSQL with the postgres profile (spring.datasource.*).

Finds the wording a ClearDatasetWording is for, as PreferencesTarget finds preferences.

Finds the wording a SetDatasetWording is for, as PreferencesTarget finds preferences.