Defect #2660
closed
Missing configuration of one system after exporting+importing 2 systems at the same time, missing settings of synchronization of contracts
Added by Alena Peterová almost 4 years ago.
Updated almost 4 years ago.
Description
Tested with 10.7.0 and 10.7.2.
- 2 systems - "HR identities" and "HR contracts"
- Export both of them at the same time -> file hrdata-all.zip
- Import the file to another instance.
- The system "HR identities" is fine, but the system "HR contracts" is created with empty configuration properties:
When I exported every system separately (hridentities.zip, hr-contracts.zip) and imported them one by one, both systems seems fine.
Files
- File sync_contracts_import.png sync_contracts_import.png added
- Subject changed from Missing configuration of one system after exporting+importing 2 systems at the same time to Missing configuration of one system after exporting+importing 2 systems at the same time, missing settings of synchronization of contracts
Update: even when importing the "HR - contracts" as a single system, it's not fully OK - the synchronization settings is missing from the imported systems. There is a message:
- Status changed from New to In Progress
- Target version set to 10.8.0
- Status changed from In Progress to Needs feedback
- Assignee changed from Vít Švanda to Radek Tomiška
- % Done changed from 0 to 90
Fixed - Problem was in the export operation. Exactly in IdmFormInstanceDto. This DTO is unique, because doesn't have a table in DB and ID. I need ID for export in every DTO. As workaround I setted ID of form definition to the IdmFormInstanceDto. This caused the problem, because this ID is not unique for more systems with same connector (has same form definitions). ID of DTO is use as name of file in batch, so IdmFormInstanceDtos were override by next system.
I fixed this by generate unique UUID for every IdmFormInstanceDto.
I created test for this case too.
Commit: https://github.com/bcvsolutions/CzechIdMng/commit/2589eb1dfabfe6502f9b7c7da52126ec25af020b
Commit: https://github.com/bcvsolutions/CzechIdMng/commit/5c64e890c7b2bc4c0b345a9be28f056a268a40ae
Note: The reason SyncContractConfig import was canceled in the batch is that no entity from the required fields was found. In this case, I expect that the node / tree type was not found because it does not exist on the target IdM.
Vít Švanda wrote:
Note: The reason SyncContractConfig import was canceled in the batch is that no entity from the required fields was found. In this case, I expect that the node / tree type was not found because it does not exist on the target IdM.
There was only default tree type with the same code "ORGANIZATIONS" in both environments, that should be enough for the import, isn't it? That's what I understood from https://redmine.czechidm.com/issues/2348#note-9
The UID of the tree type is usually not the same, because the tree types are generated automatically.
Alena Peterová wrote:
There was only default tree type with the same code "ORGANIZATIONS" in both environments, that should be enough for the import, isn't it? That's what I understood from https://redmine.czechidm.com/issues/2348#note-9
The UID of the tree type is usually not the same, because the tree types are generated automatically.
You have right, tree type and node should be searching by code. I debugged import and I found your scenario. You don't have filled in the tree node but only tree type. I counted with tree node. Exported batch doesn't contains embedded tree type data in this scenario.
I improved export. Scenario with filling only tree type works now too.
Commit: https://github.com/bcvsolutions/CzechIdMng/commit/13d9a9e7f2ed650cae593ca620fe9a9a40b89556
- Status changed from Needs feedback to Closed
- Assignee changed from Radek Tomiška to Vít Švanda
- % Done changed from 90 to 100
I did test and code review, both issues are ok now, thx!
Also available in: Atom
PDF
