Prevent one user to see other user's automations

Please specify the rights of which user role you mean:

  1. Admin
  2. Staff
  3. User
    Screenshot_42

I am talking about “User” rights user.
And i am refering to the rights:
image
Why a “User” user is able to delete, view edit and execute automations of devices that current user nor his owned device have nothing to do with that specific automation?
“A” user that owns “a” device should not be able to view “B” user’s “b” device’s automation since “a” and “b” devices are not in any way related.

If you would like to change roles and permissions, you have to upgrade to the pro plan.

Upgrading to the pro plan will also give you the ability to share devices via sub organization. You can search the documentation for more details about sub organization.

Pro plan cost is not for me since i have a total of 3-4 devices as a hobbyist. I think that blynk team should correct this. I believe that default settings of user privileges should be as i described above.

1 Like

Free and Plus plans are designed for private use. E.g. family. We assume that you can instruct your family members not to use certain features - this is how all major smarthome apps work today.

@Pavel we keep going around in circles on this default user permissions thing, and you yourself keep giving mixed messages about it.

The current defaults are crazy, and i think this is crippling the Blynk as far as the “maker” community is concerned, and for no good reason that I can see.
App sharing in Legacy was far better than the current situation for Free and Plus users, and that has to be a backward step.

I had a rant about this almost 6 months ago, and Blynk still haven’t made the simple changes to the defaults that would make the world of difference to your loyal users who can’t justify a Pro subscription

If you think that changing these defaults will cost you potential Pro subscriptions then I really do think you’re wrong. In fact, I think it will boost Plus subscriptions because it will make the product work the way that it ought to.

Pete.

1 Like

Could you please explain why current defaults are wrong in your opinion? Or which permissions you think should be changed?

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.

7 Likes

Ok, it seems that the issue wasn’t fixed which causes all of these discussions over and over (while I was sure that it was fixed long time ago)

The planned fix is next:

  1. One admin per organization in FREE and PLUS plans
  2. Admin permissions are non-editable
  3. Disabled Staff Role in FREE and PLUS plans
  4. USER role will have these permissions (non-editable):
  • view and control any device in organization
  • view timeline
  • work with automations
  • assign tags
1 Like

Wow!, That was a waste of my time then.
I think Blynk just shot itself in the foot with that one.

Pete.

6 Likes

OMG!! Speechless !!! Please tell me that this is not your final decision Pavel.

1 Like

@PeteKnight the difference is only in 3 permissions which are:

  1. Provision new devices - maybe we can put it back to users, however, I don’t see how it’s needed for family use. Admin installs all devices for everyone
  2. Device actions log (clearly an admin feature)
  3. Download reports (not needed for family scenario)

Staff role is related to business and will be available in PRO, obviously.

Everything else is aligned with the set you proposed.

I disagree.
In most families you have a hierarchy of permissions for most things. At the risk of being stereotypical, you might have one parent who is the “maker” who creates the system and does the admin/development. The other parent who should be able to control everything via Blynk - central heating, garage door opener, lights etc but not be able to “break” anything. Then you have the kids who should be able to control the devices in their individual bedrooms - without triggering world war three because “he turned my lights off”, and “she messed with my TV just before Arsenal scored a goal”.

Under my proposed system where the User role can control their owned devices (the individual kids controlling the devices in their own rooms), the Staff role can control all devices (the parent, controlling the kids devices and everything else) and the Admin role (the other parent, controlling everything and being the administrator), all this is possible.

Asking the kids not to mess with their siblings devices, or change the central heating settings, or leave the garage door open for hours isn’t how things work in the real world, and Blynk should recognise that.

I totally understand the fact that you’re attempting to prevent the Free and Plus plans being used for business scenarios, but this is crippling the functionality for the Plus users - who are the core “maker” community. If someone’s paying $6.99 per month and getting 10 devices and 10 users I think they deserve to have functionality that segregates those devices and prevents all users from being able to control all devices. Don’t you?

BTW, maybe it’s best not to tell the wife that she’s classed as “Staff” :open_mouth:

Pete.

7 Likes

Pete, you couldn’t be more right!! What businness can stand with 10 devices max?
Ofourse i dont want my kids to mess with let’s say the alarm system , or the heating boiler parameters.
So i would like users to view and control only owned devices and automations. Staff role is not needed for my projects.
I upgraded to Blynk IOT from legacy skyrocketing the cost ,compared to legacy, but if i need PRO plan for 4-5 devices i am sorry but Blynk is not for me. I lived i dont know ,7-8 years along with it but nothing is for ever i guess.
Thanx Pete for the detailed analysis!

5 Likes

stand by it 100%

2 Likes

Totally agree Pete! I make your words mine!

Pavel, please review the situation, I hope you take the necessary care to satisfy Plus users, many people, even small businesses cannot afford an upgrade to another plan, I hope you enlighten yourself and make the right decision to satisfy your needs. users like Liq is asking, I’m sure this will attract many more people who are now free for PLUS.
Greetings!
kwiek

2 Likes

Currently all major smarthome apps don’t have such levels of permissions, which means that it works for them somehow. This is supported by our data as well: there are not too many FREE and PLUS organizations with more than 1 user. Moreover, the gap between 2 users and 3 per organization is significant.

This situation is very different for PRO plans, where we see significantly more users per organization.

Also, our PRO plan is extremely affordable for any company that wants to build a managed commercial IoT solution. There is literally no one else on the market to offer anything close to what we offer at this price.

This leads to a conclusion that permissions for private use are overrated (by power-users). We of course want (and hopefully will) satisfy everyone’s needs, but it seems that currently, business-wise, it’s a very logical setup for this feature. Once all issues are fixed, of course.

Pavel i see and i do understand your business perspective. But here is my example:
I have 5 devices. Four of them is at my home and one is on my father’s house. They are all about A/C , temp sensors , and furnace control. Obviously i don’t want my father to mess with my devices, he is 70 years old and i don’t want him to accidentally mess with my temperatures and appliances. What if i am away from home on vacation and he cranks up the heat at 40oC?

My most important devices are still on legacy server, because i don’t know if Blynk will continue to keep my owned, and my father’s owned, devices, isolated. I am deliberately postponing the migration to the new platform because of the above uncertainty, although it is the second year i have an active PLUS subscription. When you shutdown the legacy servers i am ready to migrate to my local - not updatable - blynk legacy server as the only option for now, even unsafe one. Apparently the subscription i bought is serving my dad only, and 2-3 of my owned test devices(not important ones)!

I think that my above example applies to a lot o Blynk hobbyist-level users. Bear in mind , about the statistics you are referring to , that a lot of users remain on legacy Blynk or local legacy Blynk server and their final decision will be made on December. At that time you will have a clear statistic conclusion about the usage of the platform. Users on December will decide Blynk IOT, Blynk legacy local or no Blynk at all.
I understand that business is business and profit is profit. But if i am not mistaken , Blynk project became popular through hobbyists’ community.

I am waiting for your final decision about device isolation on PLUS plan.

2 Likes

You can introduce a PIN code entry on heater UI which will trigger disabling (set property: isDisabled) for some controls on the heater when you are away. Don’t share this PIN with your father.

Or create a tab inside of device info, with a switch: vacation mode. Then use isDisabled as well. It’s unlikely someone will ever find it there.

It’s 3 lines of code. Should be easy.

1 Like

I’d always though of Blynk as being an innovator, not a sheep that follows the rest of the IoT pack.

As Blynk already has the permissions hierarchy built and working, why not tweak it’s defaults slightly so that it provides a sensible working solution for makers and provides something that the others don’t?

Pete.

5 Likes