I was interested in grabbing the workflow approval for access profiles. Using the beta/access-profiles call there is an approval scheme (profile.accessRequestConfig.approvalSchemes).
If the “Access Profile Owner” is the approver, the data returned looks like this: @{approverType=OWNER; approverId=}.
I would expect to see an approverId there. If it is a governance group, the ID of the group is returned.
Is this a bug or did I miss something?
Welcome to the developer community Juan.
Thank you for bringing this to our attention. I am able to reproduce the issue you have discovered, and I created a bug report for engineering. I will keep this topic updated when the fix is released.
Thanks Colin! Appreciate the response.
After talking with engineering, this is not a bug and is working as designed. The approverId
for the APP_OWNER
approverType can’t be known until the request is made, so that will always be null. However, I have made a case for the approverId
for the OWNER
and SOURCE_OWNER
approverTypes to be populated, since those can be determined before the access request is made. It may be a while before this gets implemented, so here is what you can do in the meantime.
- If the approverType is
OWNER
, you can get the ID of the owner by using theowner
property in the response. This property will contain the ID of the identity that owns the access profile. - If the approverType is
SOURCE_OWNER
, you can call the get source API using the ID from thesource
property in the access profile. The Sources API will tell you the owner of the source.
Again, the owner and source Id can be found in the response of the access-profile
{
"description": null,
"enabled": false,
"requestable": true,
"owner": {
"type": "IDENTITY",
"id": "2c9180867624cbe3017642d8c8c82341",
"name": "john.doe"
},
"source": {
"type": "SOURCE",
"id": "2c91808a7778dbb6017b63c91c3d0f4f",
"name": "Discourse"
},