Users have three different access rights in incy.io:
Observation reporting rights - These rights define what kind of observations the user can add the the incy.io system. The reporting rights can be limited to certain categories and/or to certain places.
Observation view rights - These rights define what kind of observations the user is allowed to view. The rights can be limited to certain categories and/or certain places.
Observation edit rights - These rights define what kind of observations the user is allowed to edit. The rights can be limited to certain categories and/or to certain places. The user must have view rights to categories/places to which they have edit rights.
Admins always have rights to report, view and edit every kind of observations. Organisation admins are also allowed to access the administration side where all the organisation settings are editable. User access rights are always decided based of user account. It is possible to allow observation reporting without a user account by using the open links feature. Reading or editing observations without a user account is not possible.
For non-admin user accounts the roles can be defined either on role based method, or by specifying custom access rights. Custom access rights are better for organisations that have only a few different places and where wanted access control rules are simple. Role based access rights are better for organisations with lots of places and/or where the the wanted access rights are more complex. The used access control method is decided on user basis, so it is possible use both in the same organisation.
Non-admin user account can also be set to be restricted admins. This allows the user to create and edit and remove other accounts that have less access rights than itself.
Role based access rights
In role based access rights each user is given a single role. Roles specify which categories the user can report, view and edit. The role also specifies whether the report, view and/or edit rights apply to all places in the organisation, or just each user's own places (defined in user settings).
When a user is selected to use role based access rights, the user edit page allows admin(s) to set the user's own place(s). The role can use these places to specify what access rights the user has.
The user's places can be set by either specifying individual places, or by selecting the places based on tags. With tag based place selection it is easy to select groups of places without having to select them individually.
Example of role based access rights
Lets say we have a entertainment organisation working in Europe. The places are entertainment venues, and there are a couple different types. The places tag groups are set as following:
- Country, options: Finland, Sweden, Germany
- Venue type, options: Cinema, Opera, Theatre
Now it is possible to set the following access rights:
Can do what: Can report, view, and edit everything in the service.
How to create: Set user to be a admin in user edit page.
Name: Country manager
Can do what: can report, view and edit any observations that target any venues in the chosen country.
How to create: Create role "Country manager" with report, view and edit rights to user's own places. In the user edit page set that user's own places are set by following tags: Country: [what country/countries this user manages]
Name: Regional chain manager
Can do what: can report, view and edit any observations that target to certain venue type in certain country.
How to create: Create role "Regional chain manager" with report, view and edit rights to user's own places. In the user edit page set that user's own places are set by following tags: Venue type: [what venue type(s) this user manages] and Country: [what countries this user manages]
Name: Security guard
Can do what: can report certain kind of observations that target to certain venue in certain country.
How to create: Create role "Security guard" with report rights to the wanted categories. In the user edit page set that user's own places to only contain where they work.
Custom access rights (users without roles)
When a user uses custom access rights, all the rights of the user are specified in the user edit page. So if the user need to be able to report observations to 20 different places, each of those 20 different places must be specified in the edit page. Similarly also each view and edit access places must be specified separately.
In small organisations this works, but in larger larger organisations this solution may become hard to maintain. Especially when a new place is added, the access rights must be added to each user. Even though our support team can do such changes for you, it is still hard to validate that each users access rights are correct.
Other means of getting access rights
Besides the normal access rights method the system always gives out following access rights:
- The reporter of an observation always gets edit rights to that specific observation. This does not apply to observations created through open links.
- The people assigned to an observation always get edit rights to that specific observation. The edit rights get removed if the assignee is removed.
- The people added as participants to the observation get view rights to the observation.