Skip to main content

permission_where

Function permission_where 

Source
pub fn permission_where(
    filter: &Value,
    session: &HashMap<String, String>,
    names: &NameOverrides,
    schema: &str,
    table: &str,
) -> Result<Option<Value>, String>
Expand description

Turn a permission’s row filter into the boolean expression a where argument would have been.

The two are the same language. Hasura’s filter is written in the same shape a client writes where in, so there is no second predicate compiler here and no second set of operators to keep in step – the filter is rewritten into a <table>_bool_exp and handed to the one that already exists. Everything it can express, a permission can express, including a predicate over a relationship.

Three things metadata spells differently, and they are all this does:

  • {"author_id": 1} is _eq written without saying so. Metadata omits the operator where it is equality; a where argument never does.
  • $and, $or and $not are the older spellings of _and, _or and _not, and the corpus uses both – sometimes in one file.
  • "X-Hasura-User-Id" is not a string to compare against but the name of a session variable to compare against the value of. This is the half that makes a permission about the caller rather than about the table.

Ok(None) means the filter restricts nothing, which is what {} says and is a real answer: a role may be granted every row. It is distinct from having no permission at all, which is settled before this is reached.

An Err names a session variable the caller does not carry. That is a refusal rather than an empty result, because a filter that silently compares against nothing is a filter that matches nothing for a reason the client cannot see – and Hasura says so too, in these words.