v0.8.0
Which objects each person sees, decided on the datasource
A datasource may now carry objects: rules of match (a name pattern) and roles (the same principal vocabulary as roles). With no rule nothing changes. With any, a person sees exactly the objects some rule they hold matches, and may name only those in a statement. An administrator always sees everything.
- Patterns. Matched against the object's dotted path (
public.orders,apim-2026.*) with*for any run and?for one character, case-insensitively; a pattern with no dot matches the relation's own name in any schema, the natural spelling on a search cluster. A matched object covers what nests under it. - Visibility. Applied on the provider every object route reads through: the tree, the counts, the autocomplete, the schema diff and the agent's grounding show the same thing. A hidden object's detail is "not found", and the rules are never sent to the browser.
- Enforcement. Every statement on
/api/db/query,multi-query,transaction,maintenance,export(route and worker),profile, the bot's/api/v1/executions, an alert's run and the agent's statement runner is scanned for the relations it names; the first one outside the scope is refused with 403 and auditedobject_forbidden, with the fix: qualify the name, spell out the wildcard, or write a statement whose reach can be read (CALL,COPY,SYSare refused as unreadable rather than guessed at). MongoDB and Redis get visibility only. - Admin form. A rule list on the datasource sheet, pattern and principals per row. A virtual datasource can neither carry rules nor include a member that has any.
- Agent. The persisted actor records the session's groups and named roles, so a drive judges the rules as the person who opened the run.
Limits, stated: the rules are the portal's; the datasource's credential still sees the whole engine, and monitoring's table statistics are not filtered yet. See docs/CONTEXT.md §4.56 and docs/SEED_CONNECTIONS.md "Object rules".
Image: ghcr.io/klinux/dbportal:0.8.0 · chart 0.1.32.