We have 12 security roles in our VSA, from level 0 that allows an admin assistant or accounting team member to run reports, to level 9 that allows Master-like access (but blocks agent administration). Level 1 and 2 are for the engineers that allow agent management. There are 4 level 5 "specialist" roles that permit administration of specific VSA functions (patching, Auth-Anvil, and such), and two level 9 roles, one that allows security management. We then have 3 customer-access roles - Remote Desktop, L1, and L2 with increasing access levels.
We have two Dev VSA platforms, one on-prem and one in SaaS, and two prod VSA platforms. We develop in Dev On-Prem, test in Dev SaaS, and then deploy to Prod. Each VSA platform has the same configuration, right down to the roles and role names.
I have nearly 300 views, about half for either MSP-only or general use (all users, including clients), and the other half are used for policy control. As views are created, they are shared appropriately. The MSP-only views get the 9 MSP roles; the General Use roles get 9 MSP and 3 Customer roles, and the policy control views have no additional access.
Here's the issue:
The support engineer replicates this issue and escalates to engineering. Engineering says "this is by design" and I should open a Feature Request. I decline and ask to escalate. I think that if this was "by design" that either ALL or NONE of the security roles would be imported, but having SOME imported is not by design. If that were the case, how would the decision be made as to which role is imported and which is excluded? Digital dice roll, perhaps? I've gone round and round with this for the past month in support, PSE, and engineering, so - I figure I'd put it to the community:
Is this a BUG or BY DESIGN??
Let me know your thoughts.
Glenn
gbarnas We had a similar issue and have also been told the same thing - that it is by design. I think that just means that they accept that it's an issue but can't be bothered to do anything about it.
If you run this on your SQL Server then you can bulk add perm's to view
Update ksubscribers.dbo.viewDef
Set readWrite = 1 , shareAll = 1
where viewName like '%WhatEverViewNamesYouWantToUpdate%'
Thanks, Paul.
I'm pressing the issue because it needs to work in SaaS. I rewrote a bunch of our tools to eliminate the SQL queries we use to get around other such bugs, but we've got no control over this one.
Asking for SQL queries in SaaS is pointless.. I opened a ticket for the Managed Variable bug that crashes the procedure when you reference an undefined value. Kaseya PSE provided a SQL query almost identical to what we had. I tested and verified it would work, then submitted a ticket for them to deploy it in our SaaS environment. They said they needed to review and approve it. (really? you gave it to me!) It's going on 8 weeks now - I gave up and developed a workaround that doesn't require the SQL query.