ISC accessModelMetadata broke the Create Role API process

Feedback Bugs
, , ,
1

Hi all, :slight_smile:

Before accessModelMetadata was introduced we could do this:

  1. Take the JSON of an existing role
  2. Remove the id attribute
  3. Change all the values you want changed (including name)
  4. Create the role by passing the JSON to the POST /v2024/roles API.

Now if we create a basic role, then use this role in the steps above, we get this error:

400: Value of accessModelMetadata should be null.

The value accessModelMetadata of the JSON of the basic role was:

"accessModelMetadata": {
   "attributes": []
}

This is completely fine data, that the create API must be able to consume. Because it doesn’t, it breaks our process.

Kind regards,
Angelo

2

Thanks for reporting this Angelo. I have opened a ticket (IDNPALM-5847).

2 Likes
3

A news about this subject ?

4

That is a question for @colin_mckibben, who created the ticket. But as he is marked as Out of Office, @christina_gagnon, so you have insights on the status of this ticket by any chance?

7

@angelo_mekenkamp, I am checking with the engineering team.

2 Likes
8

Running into the same issue as the op: Cannot use the JSON from the get roles API in the create role because it gripes about the accessModelMetadata

Looks like a bug?

9

Any update on this one @christina_gagnon ?

10

Hi Angelo!

I hope you are doing well!

I am no longer on the Developer Relations Team as I transitioned to the Solutions Engineering team last May.

@tyler_mairose can you please follow up on this issue for Angelo?

11

Hey @angelo_mekenkamp,

Looking at the ticket for this I can see that it has been resolved, I just tested it and was able to create a role with the following accessModelMetadata!

"accessModelMetadata": {
   "attributes": []
}

Marking this as fixed.

12

Thank you @tyler_mairose!

But this seems to conflict with the message of @mario_rod . @mario_rod, can you perhaps double check the error you see and if so, give more details regarding it? This way we can see if the issue still exists on your side, or if you are experiencing a different issue.

Kind regards,
Angelo

13

@mario_rod,

Yes, it would be good to see the full payload with any sensitive info removed.

This is the whole payload that I used for my test. I did a GET /v2025/roles and then POST /v2025/roles with the same info, removing the key and changing the role name.

    {
        "name": "Developer Relations Test",
        "created": "2020-12-19T13:50:54.109Z",
        "modified": "2024-10-30T14:30:57.026863Z",
        "description": null,
        "owner": {
            "type": "IDENTITY",
            "id": "2c9180867624cbd7017642d8c8c81f67",
            "name": "colin.mckibben"
        },
        "entitlements": [],
        "accessProfiles": [
            {
                "id": "2c91808a7643763f01767b59d9d907cf",
                "type": "ACCESS_PROFILE",
                "name": "Employee Source"
            },
            {
                "id": "903b1e19281645278f9c9f665ea911b8",
                "type": "ACCESS_PROFILE",
                "name": "Airtable V4"
            }
        ],
        "membership": {
            "type": "IDENTITY_LIST",
            "criteria": null,
            "identities": [
                {
                    "type": "IDENTITY",
                    "id": "2c9180867dfe694b017e208e33db57bb",
                    "name": "Adam.Kennedy",
                    "aliasName": "Adam.Kennedy"
                }
            ]
        },
        "legacyMembershipInfo": null,
        "enabled": true,
        "requestable": false,
        "accessRequestConfig": {
            "commentsRequired": true,
            "denialCommentsRequired": true,
            "approvalSchemes": [
                {
                    "approverType": "OWNER",
                    "approverId": null
                }
            ],
            "reauthorizationRequired": false,
            "requireEndDate": false,
            "maxPermittedAccessDuration": null
        },
        "revocationRequestConfig": {
            "approvalSchemes": [
                {
                    "approverType": "OWNER",
                    "approverId": null
                },
                {
                    "approverType": "MANAGER",
                    "approverId": null
                }
            ]
        },
        "segments": [
            "a973e6ed-fcf6-450c-9013-f794bc50ee31"
        ],
        "dimensional": false,
        "dimensionRefs": [],
        "accessModelMetadata": {
            "attributes": []
        },
        "additionalOwners": []
    }
14

@angelo_mekenkamp @tyler_mairose

This payload works now. Was there an update recently? because it was failing earlier when I posted

{

    "name": "Test role for ",

    "description": "Test",

    "owner": {

        "type": "IDENTITY",

        "id": "xxxxx",

        "name": "xxxxxx"

    },

    "entitlements": [],

    "accessProfiles": [],

    "membership": null,

    "legacyMembershipInfo": null,

    "enabled": true,

    "requestable": true,

    "accessRequestConfig": {

        "commentsRequired": false,

        "denialCommentsRequired": false,

        "approvalSchemes": [],

        "reauthorizationRequired": false,

        "requireEndDate": false,

        "maxPermittedAccessDuration": null

    },

    "revocationRequestConfig": {

        "approvalSchemes": []

    },

    "segments": [],

    "dimensional": false,

    "dimensionRefs": [],

    "accessModelMetadata": {

        "attributes": []

    },

    "additionalOwners": []

}
16

I just retested and it does NOT work in PROD. Only works in sandbox