[midPoint] URGENT: Account Modify Workflow

[Pavol Mederly]

Hello Dharmendra,

just to be sure - you are adding and then modifying resource assignment, 
aren't you?

This feature is quite new and is currently being implemented - it was 
not present in 3.1, and I hope I'll be able to finish it into 3.1.1.

Thank you very much for testing it. It seems that you've really found a 
bug. I've done just now some experiments with modifying multivalued 
attributes, and the behavior is indeed not quite correct. (In my case 
the assignment as such is processed correctly, but not the account on 
the resource.)

Anyway:
1) I have to work a little bit more on the implementation before it 
could be really useful. At least I have to fix problems that I see at 
this moment.
2) Your specific scenario could be helpful in testing. In particular, I 
currently do not see how it could be possible that the modify operation 
is not being caught by the wf aspect. Also I don't understand why 
valuesToAdd is null.

So, could you please check that you have both account-related change 
aspects enabled? I mean this:

<workflow>
   <changeProcessors>
     <primaryUserChangeProcessor>
*      <aspect>addResourceAssignmentAspect</aspect>**
**<aspect>modifyResourceAssignmentAspect</aspect>**
*    </primaryUserChangeProcessor>
   </changeProcessors>
</workflow>

And, then, could you please execute the actions you did with model 
logging level set to TRACE, and send me the logs (to private mail)? I 
just need to see the assignment deltas that enter the model, in order to 
use them in my own testing.

No need to hurry, however, because I'm afraid I'll be able to start 
working on this no sooner than on Friday.

Thank you.

Best regards,
Pavol


On 3. 3. 2015 7:27, Dharmendra Parakh wrote:
> Hi
>
> I have been trying to configure workflow for account modify operation. 
> I have observed something that looks like a bug to me.
>
> following are my observations:
>
> - When modify the account for first time change Aspect is triggered, 
> but if i try to modify the account again it is not triggered and 
> account is directly modified.
>
>     I did not understand why midpoint would behave like this, is it
>     the case where midpoint is caching the information where it looks
>     and does not initiate the workflow hook if workflow was not
>     initiated for this account modification in near past.
>
>
> - When account is modified and change aspect is triggered i observed 
> that delta is not populated correctly. Let me explain the scenario i 
> tried:
>
>     - I added another value of a multi-valued attribute. (Account was
>     modified for first time after creation)
>     - Change asect was triggered and when i see the delta instead of
>     having valuesToadd and the attribute i added it was null and
>     valueToDelete was having other attributes which were added while
>     creating the account.
>
>
>     Here is the snapshot i took while debugging:
>
>
>
>     Inline image 1
>
>
> I think there is an issue with midpoint but i am not very much 
> sure.Please let me know if I am doing anything wrong here.
>
> Thanks
> Dharmendra
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150304/c0d5fd73/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 33530 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20150304/c0d5fd73/attachment.png>