PVO with MX_ATTR_STATE = 3, Privilege still shows Pending not Declined

[Former Member]

Hi Everyone

IdM 7.2 sp10 windows Oracle

I have created a simple UI task that sets an MX_ATTR_STATE of a PVO to 3. I have had varying success with it. It works instantly at a DB level but in the UI the status stays at Pending for *an amount of time* then *at some point* changes from Pending to Rejected aka Declined. Is this due to Java caching on the AS Java? Is there anyway to force the UI to recheck the DB for an entry?

Interested to know if anyone else experiences this or if it is unique to our system.

*****

Quick update - this morning (09/05) the status against 3 privileges that I set to MX_ATTR_STATE=3 at 13:00 on Friday (06/05) were still Pending. In previous testing the status changed to Rejected. Do I need to do something to the link state as well as the MX_ATTR_STATE to fully decline a PVO?

In the type of Pending that these Privileges were in, we have been able to remove them without causing a "Not allowed", and been able to successfully reassign the Privileges to the user. So that's good...

Thanks,

Andy

Message was edited by: andy minshull - updated with new detail

[clotilde_martinez · Accepted solution]

Hi Andy,

I just had the same problem (IDM 8 SP2), what I did to solve it :

- please check that the "Retrieve Attributes from pending value" has been selected on the source tab

- use a script to set all MX_ATTR_STATE to 3 on the mskeys with the same MX_PRIV_GROUPING_GUID as your pending value

Telle me if that works for you too,

Regards,

Clotilde

[Former Member · Accepted solution]

Thanks for replying Clotilde. This is a good idea. I have just tried to this and the for me the privileges stay at pending. Was it an instant change in the UI for you?

We do not use Business Roles, this is a "Privileges only" implementation. I selected the PVO mskeys for the privileges of one target system, in this case they have the same Grouping GUID and no other privilege assignments have the same GUID.

Was there anything else after setting the MX_ATTR_STATE to 3 that had to happen? in my script I do a uIS_PrivReconcile of the user mskey but do not think this is having any effect.

Thanks,

Andy

[clotilde_martinez · Accepted solution]

Hi Andy,

yes after refreshing the page, my business role is set to declined and no privileges are available under it. Before I set the script i just had the mx_attr_state set to 3 in the toIdStore pass and the BR stayed on OK and the privileges on pending.

The script uses the uis_setvalue to set the mx_attr_state to 3 on the privileges.

Nothing else is done afterwards, not even the privReconcile and it works this way.

On the privileges that are still pending, is this the case for only one user or were you able to reproduce it? Can you set a trace on a user and find out on what step it is blocked? do you have an entry in your provision queue?

Regards,

Clotilde

[Former Member · Accepted solution]

Thanks Clotilde

Earlier today I was able to replicate it so I thought I had a logical problem. When I tried again with the trace on the problem did not recur so I have nothing useful to share on the trace and an inconsistent problem to resolve - hooray. I will try a few more times to replicate it.

Still the original question stands - does something else need to happen as well as the MX_ATTR_STATE? I know you said it does not in IdM 8 - we are on 7.2 sp10 so this could be a patch level /version issue. On mxi_entry the mclinkstate =1 for the PVOs I set to MX_ATTR_STATE=3, as well as all the others still at MX_ATTR_STATE=1 - as I understand it this means that the member event tasks have not completed.

Nothing in mxpv_provision for the user mskey...

Thanks again,

Andy

[clotilde_martinez · Accepted solution]

Hi Andy,

were you able to solve the problem? Did you eventually open an OSS message with SAP?

We just had the same problem on 7.2 SP10 also for privileges assigned directly. In the mxp_provision there are entries but for the pending values that contain the user's mskey. and what i see is that my approval task is still "Ready to Run" so i guess it expects an action in the UI but when you force it in the DB the approval task does not really take it into account...

I don't know how to relaunch it, repair privs or reconciling them did not do anything. Nor relaunching the dispatchers or changing the mcchecklink column in the mxi_link.

So any help would be greatly appreciated

Thanks,

Clotilde