I thought I’d done that already, but if it will help then I’ll say it in a different way here…
In my opinion, the three roles should, by default, be able to do the following:
User Role
See and control devices that they own
Staff Role
See and control all organisational devices
Admin Role
See, control and manage all organisational devices along with template, user, OTA etc. functions (The Admin role is fine as it is by default).
The default permissions for the Staff role prevents them from seeing or controlling owned devices or organisational devices, so this role can’t do anything and is therefore totally redundant.
The Staff role can already see and control all owned and organisational devices, but they can also delete devices, which I think should be an admin function.
Going through each section of the permissions screens, here’s what I think should be the defaults…
Permission Control - This is fine as it is, access only for the Admin role.
Users - This is fine as it is, access only for the Admin role.
Devices -
Owned Devices should look like this…
Organisational Devices should look like this…
Blynk Air - This is fine as it is, access only for the Admin role.
Templates - This is fine as it is, access only for the Admin role.
Organisations - Giving Staff the ability to “Access organisation settings” allows them to do things like change the organisation name, logo, phone number and time zone. I don’t think that this is appropriate, so should be restricted to the Admin role, making the basic settings look like this:
Organisations - sub categories:
Sub Organisations, Owned Locations, Organisations Locations, Developer API, Tags, Webhooks, Forms, Orders, Tours, Billing & Localisation - These are all fine, as they are either not relevant to the Free or Plus subscriptions, or are Admin role only functions.
Automations - These fall under the Organisations heading, and the current defaults look like this:
This is where it gets complicated, and where the subject of this topic comes-in.
Because automations aren’t linked to users or devices, but thy allow actions to be triggered that will change data states or settings on multiple devices, the security permissions aren’t easy to manage.
The simple solution is to prevent the User role from being able to execute automations at all. This would prevent them from seeing or executing automations that would affect devices that they don’t own, but isn’t ideal.
I think tasks like Creating, Editing and Deleting automations is probably something that should be restricted to the Admin role only by default, although maybe its necessary to edit some automations - such as those which allow time schedules to be changed - to get the most out of the functionality? (As you can tell, I’m not a user of the automatons functionality, except for testing or to help troubleshoot issues).
I suspect that the real solution to this is to change the way that users are given access to individual automations - maybe in a similar way to how Notification recipients are now being handled. The Admin role would need to add and remove users from a particular automation (with all users selected by default). In this case, both Staff and Admin would need to have default permissions that allowed them to be able to see and execute the automations that they have been granted access to.
I think that your Pro/Commercial customers will also want a different solution to automation security, as even with the access to change the user permissions that comes with these subscription levels, you still can’t define security on individual automations.
Analytics - There is no access to this functionality for any roles, but if it is later made available then it should probably be restricted to the Admin role.
Rue Engine - There is no access to this functionality for any roles, but if it is later made available then it should be restricted to the Admin role.
Hope this helps, I’m glad to discuss further if needed.
Pete.