Roles Remaining after Dropping User from Group

[Derek Jones]

I noticed something odd when I saw a few ITIL-granted users leave recently—their group memberships were cleared, but their inherited roles were still linked to their accounts, with records on the sys_user_has_role table, of course.  Typically, I would expect the OOB Group Member Delete business rule to deal with the cleanup, but not in these cases.  Also, just to confirm, the business rule is OOB, as is the glide.role_management.use.inh_count property being set to true.   

In a dev instance, I used a quick script to manually remove the records on the sys_user_has_role table by making two passes: one to "false" the inherited value, followed by a second deleteRecord() pass, which worked.  However, I'm not wild about doing that in production without a better understanding of what's going on, and figuring out what's changed.  

Before I open a Support ticket, I was curious if anyone else has seen anything similar.  

[MadhanMaddy · Accepted solution]

Hi @Derek Jones ,

There is a work around for this. Which we also used earlier.  

First update inherited=false  then delete. This is a common workaround. You can try it before reaching out to ServiceNow for raising HI case.

The OOB Group Member Delete business rule doesn’t always clear inherited roles as expected, especially when the inherited=true flag is stuck

If my answer has helped with your question, please mark my answer as the accepted solution and give a thumbs up.

Best regards,
Madhan

[Bert_c1]

The Support team has a tool to re-calculate inheritance and after review of the tool's findings, it can be re-run to correct any descrepancies.  Assumes you have the 'Contextual Security: Role Management V2' plugin activated.