Defect #1362
closedConflict of two different attribute mapping strategies is not shown
100%
Description
Please now is possible create two conflict strategies. For example rights attribute in VS - merge and set mapping are in conflict but mapping are created.
Check checking of conflict attributes and update it.
Related issues
Updated by Ondřej Kopr about 6 years ago
- Related to Task #1353: Provisioning za 00000062 added
Updated by Vladimír Kotýnek about 6 years ago
- Subject changed from Conflict two different mapping attribute strategies are not show to Conflict of two different attribute mapping strategies is not shown
Updated by Ondřej Kopr about 6 years ago
- Target version changed from Onyx (9.3.0) to Opal (9.4.0-rc.1)
Updated by Vít Švanda about 6 years ago
- Target version deleted (
Opal (9.4.0-rc.1))
Updated by Roman Kučera over 2 years ago
- Target version changed from 12.2.0 to 13.0.0
Updated by Roman Kučera over 2 years ago
- Status changed from New to In Progress
- Assignee changed from Ondřej Kopr to Roman Kučera
- Affected versions 11.2.3, 12.2.0, 12.2.1, 10.8.5 added
This is still an issue.
Create VS, by default there is "rights" attribute with merge strategy.
Create some other role with mapping to this system and override "rights" attribute with different strategy then merge => Everything is saved no message is shown.
There is supposed to be check for this during provisioning, but the check is not working right now. The issue is that in parenAttribute is the overridden so checking by merge strategy is not working, because the strategy is SET or whatever you picked.
Firstly I'll fix this issue on BE during provisioning.
Then I'll look if there is some easy way how to prevent saving attribute with conflict strategy
Updated by Roman Kučera over 2 years ago
- % Done changed from 0 to 50
Implementation in https://github.com/bcvsolutions/CzechIdMng/tree/kucerar/1362-conflict-mapping-strategy
Validation was already there, but the way how it was write could never work (conditions were true, because attribute had different strategy then merge)
Now we are directly comparing attributes with overloaded attributes a checking strategies.
I tested it and works nicely. The result is that event end with error and on detail you can see the message that strategies are in conflict.
Next, I will look for some validation on FE.
Updated by Roman Kučera over 2 years ago
- Status changed from In Progress to Needs feedback
- Assignee changed from Roman Kučera to Tomáš Doischer
- % Done changed from 50 to 80
Strategy select is on role detail system tab is read only, so user will not be able to change the strategy to non compatible one.
PR https://github.com/bcvsolutions/CzechIdMng/pull/225
@doischert Can you do a review please?
Updated by Tomáš Doischer over 2 years ago
- Status changed from Needs feedback to In Progress
- Assignee changed from Tomáš Doischer to Roman Kučera
- % Done changed from 80 to 50
This works well but after some consultation and the presentation, it could lead to some issues.
If you have a conflicting strategy now or if you change the strategy in the mapping, you wouldn't be able to change it in the future.
Mapping is not Eventable so a processor cannot be used, so we will create a small LRT that will check sys_role_system_attributes and set the strategy according to the system mapping. (Or maybe we will come up with something better.)
Updated by Tomáš Doischer over 2 years ago
- Sprint set to Sprint 12.3-1 (srp 03 - srp 17)
Updated by Roman Kučera over 2 years ago
- % Done changed from 50 to 80
Events are implemented.
LRT is implemented for changing strategy for one or more attributes base on system attribute mapping strategy.
LRT is called from update processor. Processor was called two times, because the update of roleAttribute perform save of mappingAttribute. This is solved by conditional method in processor.
Rebased onto current develop.
Github action still in progress.
https://github.com/bcvsolutions/CzechIdMng/pull/225
Updated by Roman Kučera over 2 years ago
- Status changed from In Progress to Needs feedback
- Assignee changed from Roman Kučera to Tomáš Doischer
- % Done changed from 80 to 90
@doischert can you do a review please?
https://github.com/bcvsolutions/CzechIdMng/pull/225
Updated by Tomáš Doischer over 2 years ago
- Status changed from Needs feedback to In Progress
- Assignee changed from Tomáš Doischer to Roman Kučera
It looks good and it works well. I just noticed that localization is missing, see the PR.
Updated by Roman Kučera over 2 years ago
- Status changed from In Progress to Needs feedback
- Assignee changed from Roman Kučera to Tomáš Doischer
@doischert thx, localization added.
Updated by Tomáš Doischer over 2 years ago
- Status changed from Needs feedback to Resolved
- Assignee changed from Tomáš Doischer to Roman Kučera
- % Done changed from 90 to 100
LGTM, merged to develop.
Updated by Tomáš Doischer almost 2 years ago
- Status changed from Resolved to Closed