Project

General

Profile

Actions
Copy link

Defect #884

closed

no _ENABLE_ attribute in virtual systems

Added by Marcel Poul over 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Vít Švanda
Category:
Virtual systems
Target version:
Garnet (7.7.0)
Start date:
12/22/2017
Due date:
% Done:

90%

Estimated time:
Affected versions:
Owner:

Description

I have a virtual system that has ENABLE attributed mapped for provisioning. It is as is common mapped into Identity's attribute "disabled".

When I change something (assigne new role) on identity, the task for virtual system is generated, but there is no ENABLE attribute there. Then if I manually deactivate identity, new task for virtual system has ENABLE to be set to false. But there is no previous value.

If I check the provisioning archive. There is no computed value on the left side of the attributes table.

Altogether it is somewhat inconsistent.

Files

Download all files
no_previous_value.png (39.3 KB) no_previous_value.png Marcel Poul, 12/22/2017 12:39 PM
no_attribute_value_in_provisioning.png (73.8 KB) no_attribute_value_in_provisioning.png Marcel Poul, 12/22/2017 12:39 PM
no_enable_attribute.png (57.7 KB) no_enable_attribute.png Marcel Poul, 12/22/2017 12:39 PM
true.png (14.4 KB) true.png Ondřej Kopr, 02/02/2018 10:10 AM
false.png (14 KB) false.png Ondřej Kopr, 02/02/2018 10:10 AM
Actions
Copy link
 #1

Updated by Vít Švanda over 6 years ago

  • Status changed from New to In Progress
  • Assignee changed from Vít Švanda to Ondřej Kopr
  • % Done changed from 0 to 60
  • I tested this scenario and in my case was ENABLE attribute between changed attributes (provisioning, vs request too).

But I found problem with create/upadate account, when parameter ""idm.sec.acc.provisioning.allowedAutoMappingOnExistingAccount = false". In this case was every change of account evaluated as "Create". This was in async case, when wasn't update SystemEntity.wish from "true" to "false".

  • I fixed this in the VS module (now is system entity directly changed (wish=false)).

Ondra, please try simulate problem discribed by Marcel, and do review for second fixed problem.

Actions
Copy link
 #2

Updated by Vít Švanda over 6 years ago

  • Status changed from In Progress to Needs feedback
Actions
Copy link
 #3

Updated by Ondřej Kopr over 6 years ago

  • Assignee changed from Ondřej Kopr to Vít Švanda
Actions
Copy link
 #4

Updated by Marcel Poul over 6 years ago

updated: Everything I did on online demo. hence all should be visible there including provisioning history, VS requests etc...

Actions
Copy link
 #5

Updated by Vít Švanda about 6 years ago

  • Status changed from Needs feedback to In Progress
Actions
Copy link
 #6

Updated by Vít Švanda about 6 years ago

  • Status changed from In Progress to Needs feedback
  • Assignee changed from Vít Švanda to Ondřej Kopr
  • % Done changed from 60 to 90
  • I fixed problem with no return enable attribute to FE.
  • I fixed problem with not show value in the provisining table.
  • When virtual system does not supports the enable/disable account, then ENABLE attribute is not returned now (wish, vs account).
  • I created new test in VS module (disableRequestTest).

https://github.com/bcvsolutions/CzechIdMng/commit/d6b518a8167f21384ecee24e5f07475670cdf2bc

Actions
Copy link
 #7

Updated by Ondřej Kopr about 6 years ago

Thanks for fix this problem, I try it by new request for virtual system with enabled and disabled user and it works! Thank you.

Actions
Copy link
 #8

Updated by Ondřej Kopr about 6 years ago

  • Status changed from Needs feedback to Resolved
  • Assignee changed from Ondřej Kopr to Vít Švanda
Actions
Copy link
 #9

Updated by Vít Švanda about 6 years ago

  • Status changed from Resolved to Closed
Actions
Copy link

Also available in: Atom PDF