> For the complete documentation index, see [llms.txt](https://atd-dts.gitbook.io/moped-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atd-dts.gitbook.io/moped-documentation/dev-guides/hasura/hasura-roles.md).

# Hasura Roles

### Three Initial Roles

A0s requested in [this document](https://docs.google.com/spreadsheets/d/1gNCz63qFpztiuL_JK4aPNnicjCglmATOW1dbpU0wxWk/edit#gid=351804243), there are currently three roles implemented in production:

* `moped-admin` This role can create a `moped-editor` as well as read-write access to any part of the database. No deletions are permitted, aggregations are not allowed either.
  * This should be reserved for DTS staff. It enables creation of new users on top of all other permissions that editors have.
* `moped-editor` This role has read-write access to any part of the database. No deletions are permitted, aggregations are not allowed either.
  * This should be used as the default role for new staff that need access to Moped.
* `moped-viewer` This role has read-only access to any part of the database.
  * This role exists in our Hasura permissions, but it is not implemented in the codebase. For example, when creating a new user, the new user form does not offer this role as an option.

### How are these roles implemented?

The rules are implemented through a Hasura metadata migration. First, the local Hasura cluster is started, then the console. While the console is open, the permissions are changed and then the console will automatically make changes to the metadata file.

### How can these roles be changed?

First, create a new branch in git. Then, start the cluster (locally), and open the Hasura console. Once the console is open, go to any table you need to make changes to, then change the permission settings for the specific role you need to change. 

Once you make changes, the console will directly make changes to the metadata file, which is tracked by git, meaning that git will show differences in the code which you can commit and push to your branch, those changes made to your PR can be tested by someone else without affecting staging and production, and once approved the branch will be merged to staging (or production) and the migration will be applied automatically by a [GitHub Action workflow](https://github.com/cityofaustin/atd-moped/actions/workflows/migrations-metadata-deployment.yml).