User roles and permissions

There are three default roles

• Host

• Program Manager

• Administrator

To learn more about these roles, check the profiles and user account chapter.

In the radio administration these roles are realized using groups, holding an assigned set of permissions. But any of these permissions can also be assigned individually to user accounts.

The Host 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 and having a suiting starting point for their actual roles and permissions. When finalizing the radio station configuration, decide for one of these Host groups and modify individual permissions to your organizational needs.

Check the section Field-level permissions below to learn more about these default permission sets.

Entity-level permissions

Each user group holds entity-level[1] permissions, like the following.

Permission	Meaning
add <entity>	Can add a new object.
change <entity>	Can change some objects.
delete <entity>	Can delete some objects.
view <entity>	Can view any object.
create <entity>	Can add a new object. Overrules the ownership.
destroy <entity>	Can delete any object. Overrules the ownership.
list <entity>	Can list all objects. Overrules the ownership.
update <entity>	Can update any object. Overrules the ownership.

In addition to the having add_*, change_* and delete_* permissions, a user may also be required the be the owner of a parent entity or the object itself.

For example: To add a new episode, the user additionally needs to be in the “editorial staff” of the show.

The create, destroy, update and list permissions are intended for the Program Managers only.

Additionally, we have permissions that are used to enable some navigation items in the Dashboard.

Permission	Meaning
display_day_calendar	Can display the day calendar.
display_week_calendar	Can display the week calendar.
display_episode_list	Can display the episode list.

Generally you should not edit these default assignments beyond first setup. In any case it is good to learn what they are used for.

Example

In case of the host role, dealing with episodes, the default entity permissions are view episode and change episode. Having these entity-level permissions assigned, gives hosts full rights to view and some rights to change episode fields. The actual fields to be edited are specified using field-level permissions.

Just note, there is no update episode permission assigned, since this would give rights to edit all fields.

Field-level permissions

In order to apply additional, fine-grained permissions on the field-level, the permission change <entity> is required as a basis.

Example

A host allowed to edit the episode title only, requires having both of the permissions, change episode and edit title assigned.

Field permissions overview

The user groups are pre-configured with the permission assignments listed in the table below [3].

All cells without a permission string represent read-only access.

Learn more in the section public visibility of data.

This list only comprises the permissions for Host and Host+ users.

Program Managers have full entity-level permissions that overrule the ownership of the entities and don’t require field-level permissions.

Entity	Field	Host	Host+
show	default media		edit
show	description		edit
show	email		edit
show	hosts / editorial staff		edit
show	image		edit
show	links		edit
show	logo		edit
show	short description		edit
schedule	default media		edit
episode	cba id	edit	edit
episode	content	edit	edit
episode	contributors	edit	edit
episode	image	edit	edit
episode	languages		edit
episode	links	edit	edit
episode	media	edit	edit
episode	media description	edit	edit
episode	memo[2]	edit	edit
episode	summary	edit	edit
episode	tags	edit	edit
episode	title	edit	edit
media	file media-source	add	add
media	import media-source	add	add
media	line media-source		add
media	stream media-source		add
profile	biography		edit
profile	email		edit
profile	image		edit
profile	links		edit
profile	name	edit	edit
profile	owners		edit
timeslot	episode	edit	edit

Permissions by ownership

Permissions by ownership only affects the Host and Host+ roles, since Program Managers have all relevant permissions to manage all shows, profiles, and images.

Ownership of shows and episodes

Users who are assigned as show administrators in the show settings automatically have the permissions to manage their shows. This allows them to list and edit their own shows according to their assigned role (individual or group-level permissions). The permissions listed in the table only grant users editing rights for shows they actually own.

Ownership permissions on shows and their episodes is granted by having these wildcard permissions assigned:

show | Can change show:

Gives user permission to change data of owned shows.

episode | Can change episode:

Gives user permission to change episode data of owned shows.

That’s where the create and update permission come into play. Program managers should have all these permissions, besides the default add, change and delete.

Program Managers in contrast have these permissions, allowing them to edit fields of all shows and episodes without any restrictions:

show | Can update show:

Gives user permission to change all data of all shows.

episode | Can update episode:

Gives user permission to change all data of all episodes.

Ownership of public profiles

In the case of the public profile, beside the Program Manager, only owners can edit their profiles. Ownership is represented by a relationship between the user and the profile.

Ownership permissions on profiles are granted by having this wildcard permission assigned:

profile | Can change profile:

Gives user permission to change their own profile.

Permissions to add profile to episode contributors

Editorial staff members often need the ability to assign guests to certain episodes (so-called contributors). To do so, they either need to assign existing profiles or frequently also create new profiles on-the-fly.

To equip some host role with these abilities, add these permissions:

profile | can add profile:

Gives user permission to create a new public profile.

show | can edit contributors field:

Gives user permission to assign profile to episode contributors list.

Permissions to update show editorial staff profiles

The editorial staff section in the show settings lists all public profiles of a show.

Usually, hosts do not edit the list of editorial staff members as part of the general show settings. However, if you want to allow hosts to manage the team themselves, you can do so by adding these permissions:

profile | can add profile:

Gives user permission to create a new public profile.

show | can change show:

Gives user field-level permission ability.

show | can edit editorial staff field:

Gives user field-level permission to edit editorial staff field.

Ownership of images

An image can be edited by a user if it was created by the user, or it is used in an episode, profile or show which is owned by the user.

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. Essentially, the API provides all the data that is typically visible on radio station websites.

Additionally, this includes metadata such as when and by whom a record was created or last updated.

The only exceptions are fields that are visible only internally and editable only by certain roles:

Entity	Field	Visible only to these roles
user	*	Program managers
cba	*	All authenticated users
profile	*	Program managers
timeslot	memo	All authenticated users
show	email	All authenticated users
show	internal note	Program managers
show	involved people count	Program managers

Open data principle vs. user privacy

As advocates for open data, we value transparency, much like community radio stations. However, always remember to follow the laws in your area. For example, in the European Union, users must provide their consent before you share their personal data (GDPR). Therefore, be sure to obtain their written consent first.

Secure storage of user passwords

We want to assert that passwords are only stored in hashed form and are therefore not visible even to administrators. They are never exposed by the API, as authentication is performed using OpenID.

Assign roles and permissions

Read here, to learn on how to assign roles and permissions:

• Manage users

• Manage groups

---

Footnotes

---

[1]

In databases, an entity refers to a thing that you want to store information about. Each entity represents a real-world object or concept and has its own set of details. For example, in AURA relevant entities are show, episode, profile and timeslot.

[3]

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.

[2]

Field currently not in use.