That message means that you can’t ask for an unfiltered parent list and get all details for every returned parent.

I think that having an IEnumerated method for a view will cause this message to appear. As so as you have that in your graph, the implication is that something other than a simple select to get the details is in play and ACM doesn’t want to potentially grind away calculating the details for every parent.

So, when you set up your request with a filter on a single parent record via the key fields, you’ll get the details that you’re looking for.

As a potential work around, if the data exists in the database that you’re looking for, you might be able to create a GI and expose that GI to the API to get the information that you’d like to display.

Thanks for your reply Django,

I believe I set up the request with a filter on a single parent record in my example by adding “/Administrator” to the end of the URL. This returns a single role and I expected the expanded AccessRights field for that single record.

The potential workaround for a GI will work for read-only as far as I know. I also need to update this information via API.

You’re correct - the GI is read-only. It’s just helpful for if you want to get a listing for the outside application.

I think that Access Rights by Role has at least two keys. You can’t see any access rights until you click on Role (name) and then something in the tree. A quick poke around the database (because the screen editor doesn’t seem to be revealing much) shows that the RolesInGraph table has ScreenID, Rolename, and ApplicationName for a primary key. (Quick test showed that this table was updated by changes in Access Rights by Screen)

There are also tables called RolesInCache and RolesInMembers with longer primary keys.

Someone might have more experience on how to do what you’d like through the REST API.

Another potential option to explore is a Webhook which would allow you to take a JSon payload with that information and handle that however you’d like and thus you’d be able to manage the updates by writing code vs being “stuck” with what the web endpoints offer. But this option means more coding and there’s not a huge amount of documentation on creating webhooks.

Thanks for the additional information Django,

You’re right, there is likely more information needed in order to display Access Rights at least from the Access Rights by Role screen perspective. I was hoping to get a list of all Access Rights of a Role using this extended API.

A workspace, screen, form or form object need to be selected before any Access Rights appear, but these are different entities with different key fields as well. The closest thing I can find to a reference of what is being shown is the PX.SM.Role DAC. Judging by the looks of it, I believe it’s similar to a database view of Roles, RolesInMember and RolesInGraph to display the information in a common way. This is why we can see CacheName, Membername, and ScreenID in the DAC when RolesInGraph has no Membername field. I think RolesInGraph relates to Screen access whereas RolesInMember relates to forms and controls. Please correct me if I’m mistaken.

If anyone knows how to manage this information using the Contract-Based API that would be most ideal. If not I’m also open to other options such as a webhook as you’ve mentioned Django. Any resources on how this may be accomplished would be appreciated as well.