ESMC Users Cannot View/Edit Policies Without Read on All

[timconner 0]

I have a couple of ESMC users who have limited access to specific static groups. They specifically have Read, Use, and Write permissions to Policies on these static groups. However, they are unable to view or edit any policies that they have permissions to. Any attempt to simply view the policy in ESMC or edit are met with this error:

 ERROR WHILE INITIALIZING CONFIGURATION EDITOR.

The only way to get this working is to seemingly give them Read permission on Policies for the All static group. This allows them to see some policies I'd prefer they didn't. 

Running the following version on Windows Server 2016:
ESET Security Management Center (Server), Version 7.0 (7.0.577.0)
ESET Security Management Center (Web Console), Version 7.0 (7.0.429.0)

Is this a known issue?

Edited April 27, 2019 by timconner

[MichalJ 430]

All predefined policies are by default placed in group all. Therefore, you need to check, where they are placed with regards to access rights management “object groups”. You can change placement between the groups, so access rights to all won’t be needed.

[timconner 0]

8 hours ago, MichalJ said:

All predefined policies are by default placed in group all. Therefore, you need to check, where they are placed with regards to access rights management “object groups”. You can change placement between the groups, so access rights to all won’t be needed.

 

Hey MichalJ,

These are custom policies not predefined ones. I have indeed moved them to an Access Group where the users have a Permission Set granting them all the proper permissions. They wouldn't even be given the option to edit the policy if they didn't. However, I still receive this error. 

Edited April 28, 2019 by timconner

[MichalJ 430]

I have checked this with my colleagues and they recommend to enable full trace logging on ESMC server and the try to reproduce the problem. Afterwards please submit a ticket to our customer care. Also, would it be possible to include your DB, as that might be needed to properly understand the context of your hierarchy. 

Thanks,

Michal