Granting a licence bundle — and why it doesn't switch anything on by itself
A commercial licence grant gates whether a module pack is even allowed to install, but granting one to an already-installed, disabled module changes nothing on its own.
A TenantLicenseGrant is the entitlement check a module pack's required licence bundle asks for before its installation is ever allowed to switch on. It fails closed by construction: no grant means no enable, never "enable and warn."
What a grant actually does, and doesn't, do
Granting a bundle here makes future installs of anything requiring it possible. It does not reach back and flip on a module pack that's already sitting installed-but-disabled because its bundle wasn't granted at the time — the install-time check only runs once, at seeding, not continuously against the current grant set. If a pack stayed dark because of a missing licence, granting the licence afterward leaves it exactly as dark as it was; someone still has to re-run the module install or enable flow separately.
This is the single easiest thing to get wrong on this screen: granting a bundle and expecting a disabled module to visibly change is a reasonable guess, and it's wrong. If nothing on screen moves after a grant, that's not a bug — check whether the module actually needs re-installing or re-enabling on top of it.
The screen itself
It's short on purpose: a note stating the retroactive-enable caveat above, a form to grant a new bundle by slug (plus an optional note for your own records), and a table of what's currently granted — bundle slug, when it was granted, and that note. If you hold only the read permission, you see the table with no form and no revoke controls; granting and revoking a commercial entitlement is gated on registry.license.administer specifically, separate from the broader catalogue-read permission that lets someone merely see what's granted.
Ambient to whichever tenant you're working in
Neither the read nor either write mutation on this screen takes a tenant argument explicitly — the currently selected tenant resolves server-side from the workspace context, the same pattern the rest of the city-scoped catalogue screens use. Switch tenants in the workspace switcher and come back to this same URL, and you're looking at that city's own grants, not the one you were just on.
Revoking a bundle here is exactly as immediate and exactly as non-retroactive as granting one — it stops future installs from being allowed, it doesn't reach into an already-enabled module and turn it off. Treat a revoke as closing a door, not as pulling a plug.