ARES-12077: Unable to assign public apps using certain UEM console built-in roles

[AlbertGuR]

Hello, we upgrade recently WorkspaceOne UEM from 2001 to 2005 on-prem version, and now we have problem with assignment  applications using UEM console built-in role Application Managers. I was find in release notes for 2006 version information about resolve issue "ARES-12077: Unable to assign public apps using certain UEM console built-in roles". But 2006 version not available right now for on-premises deployments. May be somebody have information about workaround for resolve issue for WorkspaceOne UEM version 2005 on-premises?

[callegrafi]

We have had the same. Add the REST API permissions from the attached role.

[AlbertGuR]

Hi Callegrafi, thank you for xml file, I comparised built-in role with your variant and finded lot off differences gived lot off additional access rights. I think Security Supervisers don't will approve this customised Applcation Management role.

[bbolling]

Pretty sure I'm seeing something along these lines as well. I have a ticket opened since 8/28/2020 that's been escalated a few times but no resolution. SaaS Customer version 2008 as of this post. We're using custom roles and found that removing edit access to certain modules creates unexpected results.

One such example is when the intended role has only admin read rights on the API node/module:

If we give full read/write permissions to everything for the api admin read role we get all admin accounts returned.

Adding full read rights to all functions lets us see only the api account itself and no other admin accounts returned.

From full rights and removing "edit" permissions on the "Apps&Books" module we get a total of roughly half the admin accounts returned.

From full rights and removing "edit" permissions on the "Configurations" module we get a total of just over half of the admin accounts returned.

From full rights and removing "edit" permissions on the "Email Management" module we get a total of 15% admin accounts returned.

The expected result based on how things were working before was that the api account role that we have should be able to read all admin user data only with read permission on API>REST>Admins>Read and no permissions elsewhere.