# User roles and permissions There are three default roles - **Host / Editorial Staff** - **Programme Manager** - **Radio Station Administrator** To learn more about these roles, check the [user and host profile](../user/index.md) page. In the radio administration these roles are realized using groups and an assigned set of permissions. But any of these permissions can also be assigned individually to user accounts. The _Host / Editorial Staff_ role is provided in two flavors, in form of a host **Host** and **Host+** group. This allows administrators to get an impression on different permission capabilities more quickly. When finalizing the radio station configuration, decide for one of these _Host_ groups and modify individual permissions to your organizational needs. ## Public visibility of data Whenever editing any data, keep in mind, that almost all data is visible via public APIs. All the data is read-only for non authenticated users. Basically the API provides all data which is typically also visible on radio station websites. Additionally, this also includes metadata like when and by whom a record was created or updated last. The only exceptions are those fields, which are only visible internally and only editable by certain roles: | Area | Field | Visible only to these roles | | ---- | ------------- | --------------------------- | | user | first name | All authenticated users | | user | last name | All authenticated users | | user | email | All authenticated users | | host | email | All authenticated users | | show | email | All authenticated users | | show | internal_note | Programme managers | ```{admonition} Open data principle vs. user privacy :class: alert As advocates for open data, we're all about transparency, just like community radio stations. But remember, always follow the law in your area. For example, in the European Union (GDPR), users need to agree before you share their personal data. So, be sure to get their written consent first. ``` ```{admonition} Secure storage of user passwords :class: info We want to assert, that passwords are only stored in hashed form and are therefore not even visible to administrators. They are never exposed by API, since authentication is performed using OpenID. ``` ## Groups and their default permissions Beside the default read-access, the groups are pre-configured with these permission assignments: | Area | Field | **Host** | **Host+** | **Programme Manager** | | ------------ | ----------------------- | -------------------- | -------------------- | --------------------- | | show | name | | | `edit` | | show | slug | | | `edit` | | show | short description | | `edit` | `edit` | | show | description | | `edit` | `edit ` | | show | logo | | `edit` | `edit` | | show | image | | `edit` | `edit` | | show | categories | | | `edit` | | show | topics | | | `edit` | | show | music genres | | | `edit` | | show | languages | | | `edit` | | show | type | | | `edit` | | show | email | | `edit` | `edit` | | show | links | | `edit` | `edit` | | show | hosts / editorial staff | | `edit` | `edit` | | show | administrators | | | `edit` | | show | funding category | | | `edit` | | show | cba id | | | `edit` | | show | predecessor | | | `edit` | | show | internal_note | **_no read access_** | **_no read access_** | `display`, `edit` | | show | is active | | | `edit` | | show | default media source | | `edit` | `edit` | | schedule | default media source | | `edit` | `edit` | | episode | title | `edit` | `edit` | `edit` | | episode | summary | `edit` | `edit` | `edit` | | episode | content | `edit` | `edit` | `edit` | | episode | image | `edit` | `edit` | `edit` | | episode | contributors | `edit` | `edit` | `edit` | | episode | topics | | | `edit` | | episode | languages | | `edit` | `edit` | | episode | tags | `edit` | `edit` | `edit` | | episode | links | | `edit` | `edit` | | media-source | file | `select` | `select` | `select` | | media-source | line | | `select` | `select` | | media-source | stream | | `select` | `select` | | media-source | import | | `select` | `select` | | media-source | m3u | | `select` | `select` | | host | name | `edit` | `edit` | `edit` | | host | biography | | `edit` | `edit` | | host | email | | `edit` | `edit` | To serve the overview, permission strings in the table are simplified. When looking up the actual permission string, take the permission verb and combine it with the field name in format `Can {verb} {field}`. For example `Can edit music genres` is the permission string you will find in the permission assignment interface. All cells without a permission string represent read-only access, except the ones marked with **_no read access_**. Each group also holds wildcard permission assignments like `add episode`, `change episode`, `delete episode` and `view episode` which is not visible here. These are required for properly granting access to data by inheriting global permissions. Some are required for permissions through ownership (see next chapter). Generally you should not edit these assignments. ## Permissions through ownership Permissions through ownership only affects the _Host_ and _Host+_ roles, since _Programme Managers_ have all relevant permissions to manage all shows and profiles. ### Ownership of shows and episodes Users which are assigned as _Show Admins_ in the show settings, automatically have the permissions to list and edit their own shows, according to the assigned role (_Host_, _Host+_, or individual permissions). The permissions listed in the table, only grant users editing rights for shows they are actually owning. Ownership permissions on shows and their episodes is granted by having these wildcard permissions assigned: ```py Can change show Can change episode ``` ### Ownership of host profiles In case of the host profile, only the owner can edit the fields, they have permissions on. Here ownership is represented by a relation between user and the host profile. Additionally editorial staff members need the ability to assign guests to certain episodes (contributors). To do so, they often need to create host profiles on-the-fly. Ownership permissions on host profiles is granted by having these wildcard permissions assigned: ```py Can change host ``` ## Assign roles and permissions Read here, to learn on how to assign roles and permissions: - [Manage users](manage-users.md) - [Manage groups](manage-groups.md)