# `PhoenixKit.API.Access`
[🔗](https://github.com/BeamLabEU/phoenix_kit/blob/v3.5.0/lib/phoenix_kit/api/access.ex#L1)

The rights of a person behind an admin page, read again from the database.

A LiveView captures the person's `Scope` at mount; a role may change after that, and
core's PubSub refresh of the page is asynchronous and can be missed. An event that
changes something (a key, a setting, an approval) must not act with rights the person
no longer has, so it calls `fresh_scope/1`: the user is loaded again and must still be
active, and both the scope captured at mount (which may be narrowed to one active role)
and a scope built now from **all** held roles (the way the API computes rights) must
hold `api`. The fresh scope is the one to hand to `PhoenixKit.API.Keys`,
`PhoenixKit.API.ServiceUsers` and `PhoenixKit.API.Approvals`, which check again on
their own.

`fresh_scope/2` is the same check for a page that any one of several permissions
opens: "My API keys" (`["api_personal_keys", "api"]`).

# `fresh_scope`

```elixir
@spec fresh_scope(PhoenixKit.Users.Auth.Scope.t() | nil) ::
  {:ok, PhoenixKit.Users.Auth.Scope.t()} | :error
```

`{:ok, fresh_scope}` while the person may still manage the API, else `:error`.

# `fresh_scope`

```elixir
@spec fresh_scope(PhoenixKit.Users.Auth.Scope.t() | nil, [String.t()]) ::
  {:ok, PhoenixKit.Users.Auth.Scope.t()} | :error
```

`{:ok, fresh_scope}` while both the scope captured at mount and a full scope built now
(`narrow: false`) hold at least one of `permissions` (`Scope.can?/2`) and the person is
still active, else `:error`. An empty list opens nothing.

---

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