dengc367 commented on PR #14239:
URL: https://github.com/apache/gravitino/pull/14239#issuecomment-6502659447
One addition from reading the Databricks reference directly, since Pages is
the closest thing to a term and
its documentation is explicit about the permission model. This extends my
earlier comment on where term
privileges should live.
**Fields are close.** Domain ↔ term domain, Owner ↔ owner, Synonyms ↔
synonyms, Description ↔ definition,
Related assets ↔ bindings, Sources ↔ source reference. Two things a Page has
that this design does not:
- **A rich-text body.** A Page is a document — the structured fields are
followed by Definition, Business
use and Examples sections with links, images and tables. A `definition`
string cannot hold that, and
`properties` has no structure for it, so a long-form term loses content
rather than degrading gracefully.
- **No approval step.** Pages have Draft/Published only, and a consumer can
create *and* publish directly.
The `DRAFT` / `APPROVED` / `DEPRECATED` lifecycle here is stricter than
the reference, which is a choice
worth making explicitly rather than by default.
**The permission model is the part worth re-reading.** From the Pages
documentation:
> You don't grant permissions on a Page directly. A Page inherits access
from the domain or subdomain it
> belongs to.
Three personas, and all of them are expressed in domain terms rather than in
page-level grants: a consumer
with domain access can create and publish Pages, the page owner edits their
own, and a curator holds
`MANAGE` on the domain and can edit any Page in it.
That is the same shape as the suggestion in my earlier comment — define the
term privileges on the metalake
and let the domain leg reuse the existing `USE_DOMAIN` / `MANAGE_DOMAIN` —
rather than mounting a second
privilege family on the same domain objects.
**One more divergence to settle deliberately.** A Page must belong to a
domain: "Every Page is attached to
a domain or subdomain", and you need a domain before you can create one.
This design allows a term in zero
domains. Supporting cross-domain terms is a reasonable requirement, but it
should be stated as a deliberate
divergence, because a domainless term is invisible from every domain's page
and inherits no domain grant.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
