Feature #2148
closedAdd type of role guarantor
100%
Description
When defining the role guarantor (by role or a certain identity), I'd like to be able to choose a type of the relation. E.g. if the role grants access to more then one system I'd like to specify a guarantor for each system, in a special approval workflow there would be a task for each type of a guarantor. The workflow from this example is not a part of this feature (there will be a separate ticket).
Whet I click on the Add button I should be able to select a role/identity and select the type of the guarantor from a code list or enumeration.
Updated by Vít Švanda over 4 years ago
- Target version changed from 10.2.0 to 10.3.0
Updated by Vít Švanda over 4 years ago
- % Done changed from 60 to 90
I added guarantee_type to a guarantor by identity and role.
Component on UI use codelist component and code list with code guarante-type.
This fields are not use in IdM now (no bussines logic is implemented)! Are designed for specific using in a projects (for example in approval WF).
For better back compatibility, I improved codelist component for new options showOnlyIfOptionsExists -> least one option in codelist must exist for show this componet.
Commit: https://github.com/bcvsolutions/CzechIdMng/commit/bff68b0ecfb4548ecbf299a2834ab35f0fe11c1b
Documentation: https://wiki.czechidm.com/tutorial/adm/new_role#role_-_creatingediting
Updated by Vít Švanda over 4 years ago
- Status changed from In Progress to Needs feedback
- Assignee changed from Vít Švanda to Ondrej Husník
Updated by Ondrej Husník over 4 years ago
- Assignee changed from Ondrej Husník to Vít Švanda
I did review of this task and it works as suggested in the ticket. Flyway scripts for both postgres and mssql seem to be correct and work.
There is one thing to contemplate:
- If the whole codelist or its item is deleted and was previously used as a role guarantee "parameter" (doesn't matter whether set by role or identity), it still remains set in DB table (idm_role_guarantee or idm_role_guarantee_role). Should not be codelist deletion prevented or "guarantee" tables modified?
Updated by Vít Švanda over 4 years ago
- Assignee changed from Vít Švanda to Ondrej Husník
Code lists intentionally do not have referential integrity. If for some value missing code value, then only text-area with string value is show (because this value could be synced). Code lists is only rendere here.
Updated by Ondrej Husník over 4 years ago
- Status changed from Needs feedback to Resolved
- Assignee changed from Ondrej Husník to Vít Švanda
- % Done changed from 90 to 100
Updated by Vít Švanda over 4 years ago
- Status changed from Resolved to In Progress
Updated by Vít Švanda over 4 years ago
- Status changed from In Progress to Needs feedback
- Assignee changed from Vít Švanda to Radek Tomiška
- % Done changed from 100 to 90
I realized that projects will definitely need to find all the guarantors for a given role, but only for a specific type of guarantor. I implemented this filter (including a tests).
If you need to find guarantors for a given role, but only for a given type, you can use the IdmIdentityFilter.setGuaranteeType("type") filter. Filtering by guarantor type will only work if the filter contains the required role IdmIdentityFilter.setGuaranteesForRole(roleId).
Commit: https://github.com/bcvsolutions/CzechIdMng/commit/cfc75741b10f36fc80d540bc858167f0739e3af6
Could you please give feedback. I modified the IdentityGuaranteesForRoleFilter, I didn't find a better way to implement it, but maybe I'm wrong.
Updated by Radek Tomiška over 4 years ago
- Status changed from Needs feedback to Resolved
- Assignee changed from Radek Tomiška to Vít Švanda
- % Done changed from 90 to 100
I think extending IdentityGuaranteesForRoleFilter is the best way how to implement this feature :)
I did test by rest and code review, it works, thx!
I've added new column into guarantee tables, if code list is specified (the same behavior as on guarantee detail):
https://github.com/bcvsolutions/CzechIdMng/commit/21c739de075ab64e0f7c278355fbdc80629dfdbc#diff-46be554a6170c4c1461cb94948120054
Updated by Radek Tomiška over 4 years ago
- Status changed from Resolved to Closed