IdStory Identity Manager

• role becomes deprecated or is being replaced by another one. Role should still be active, but users should not be able to apply for it.
• role is new, but is not intended for user's applications yet - e.g. the administrator is now preparing role in IdM, but do not want to show them for users yet.
• role will never be able to apply for - some admin roles, strategic end system roles etc.

So the question is. Should we really implement the "apply for" attribut check on FE as well as BE? I think yes, but we have to find a solutions that can meet the point 3 usecase, but we should still be able to add the role to the user manually.

The other question is where to impelement the attribute - role or roleCalalogue. I think both solutions are possible and in fact are complementary. Catalog attribute turns on and off the visibility of the object in GUI. Role is more complex - it is more about applying for a role then just the visibility

I would not distinguish between the role and role catalogue attributes. It should both have the same behavior:
On role: If true -> users can apply for role
On catalogue: If true -> users can apply for any role under this folder

The only thing left is to decide, whether attribute on role would have greater priority (you can apply for role in forbidden catalogue if it has set this attribute to true). I think that this is subject for bigger discussion.

As for the ability to be able to assign forbidden roles, it looks to me, that it should be bound with some kind of permission so we can somehow say that these people can assign forbidden roles.

So after consulting this with Marcel and Ondra we came up with this plan:

For now, implementation of this attribute will be only on roles. This will suffice for all usecases we currently need. However when time comes and we will be implementing richer behavior around this, then I propose to change this boolean value to enum, which will support direct setting of value on role (APPLYABLE, NOT_APPLYABLE) and some kind of inheritance (INHERIT_SUPER_ROLE, INHERIT_CONTAINER). I think that this approach is more straightforward and readable for users since they will exactly know what is happening when they set this property as opposed to having to remember priorities of some boolean field in object hierarchy.