# `MishkaCmsCore.Accounts.Checks.WithinCeiling`
[🔗](https://github.com/mishka-group/mishka_cms_core/blob/v0.0.1/lib/mishka_cms_core/accounts/__checks/within_ceiling.ex#L5)

True when what an action changes holds nothing beyond what the actor holds — the grant ceiling
(`MishkaCmsCore.Accounts.Validations.GrantWithinActorScope`) asked of the account or the row an
action changes, by the same covering rule (`MishkaCmsCore.Accounts.Checks.AccessPermissions.beyond/2`).

  * An account (`MishkaCmsCore.Accounts.User`): every permission it holds, when the action deletes
    it or changes its email, its password, its authenticator or its site — what signing in as it
    takes, and where it belongs. A generic action names the account by its `:id` argument, and deletes it when it is
    given nothing else. Changing only what the account holds is a grant, held to the grant ceiling
    instead; anything else asks nothing.
  * A catalogue row (`MishkaCmsCore.Accounts.Permission`): the name a destroy removes, and both
    names of a rename, which every holder of the row loses and gains. A create names what nobody
    holds yet, and an update that keeps the name changes no name.
  * A grant row (`MishkaCmsCore.Accounts.UserPermission`) written directly: the permission it
    grants. Removing one grants nothing, as `remove_permission` does not.

False for no actor. It only ever narrows a gate: put it beside the checks that authorize, since a
policy passing on it alone would authorize whatever no other policy asks about.

    policy action(:tenant_update) do
      forbid_unless {MishkaCmsCore.Accounts.Checks.AccessPermissions, permissions: ["admin:dashboard:user", "admin:api:user"]}
      forbid_unless MishkaCmsCore.Accounts.Checks.WithinCeiling
      authorize_if expr(site_id == ^actor(:site_id))
    end

# `eager_evaluate?`

# `init`

# `prefer_expanded_description?`

# `requires_original_data?`

# `strict_check`

# `type`

---

*Consult [api-reference.md](api-reference.md) for complete listing*