You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by Francesco Chicchiriccò <il...@apache.org> on 2017/12/05 08:08:20 UTC
Re: Question regarding upcoming PullAction changes in version 2.0.7
Hi Mikael,
the SyncDelta processing was modified by SYNCOPE-1234 [1].
The new preprocess() method is invoked before any other method of the
provided implementation, giving clear chance to alter the data coming
from underlying resource prior to any other Syncope-side consideration.
Before [1] the logic was not adequate as the internal matching logic [3]
could not be influenced by PullActions.
You have already discovered that SyncDelta instances are immutable; what
you are currently missing is that you can use SyncDeltaBuilder [4] to
generate new SyncDelta instances.
HTH
Regards.
[1] https://issues.apache.org/jira/browse/SYNCOPE-1234
[2]
https://github.com/apache/syncope/blob/2_0_X/core/provisioning-api/src/main/java/org/apache/syncope/core/provisioning/api/pushpull/PullActions.java#L40
[3]
https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/AbstractPullResultHandler.java#L741
[4]
http://connid.tirasa.net/apidocs/1.4/org/identityconnectors/framework/common/objects/SyncDeltaBuilder.html
On 04/12/2017 16:40, Mikael Ekblom wrote:
>
> Hi,
>
> I have one question: in version 2.0.7 I have noticed that you have
> added a preprocess function to the default pull actions class. We
> would like to alter the syncdelta in certain cases ie the user should
> be kept as enabled (ie. __ENABLED__ set to true) as the user can have
> two different roles simultaneously and one primary role should be kept
> even though if the user is seen to have lost one primary role in the
> case that the user (as an example) has graduated and has been archived
> within the study register (__ENABLED__ set to false within the
> connector in this case) + we get a match for the user and this
> archive. We get a match, but the user should be set to active.
>
> Arcada do not deprovision the users directly either if an entity
> matches an archived version for a specific master source.
>
> The user might still have a role as staff or employee and the
> syncdelta should be set to __ENABLE__=true in this particular case but
> the rest of the roles bound to the student role should be removed.
>
> This could be done in 2.0.6 within the beforeupdate function also,
> that in version 2.0.6 returned the SyncDelta but in version 2.0.7 the
> same function returns void. How is this supposed to work in the new
> implementation in 2.0.7 when you do not have the user information (or
> entity together with role information) available directly within the
> current function and syncdelta scope within preprocess? The SyncDelta
> object just has an read-only map of the current syncdelta attributes
> as far as I have seen if you try to alter the attributes within
> beforeupdate, so it seems to be too late for that there. You
> basically have to look up the user through the __UID__ I guess within
> preprocess, but through which function and through which library?
> What is the best option you have in this case?
>
> It is enough if you have a hint to give and I’ll find the rest. I hope
> this text is somehow understandable!
>
> Regards,
>
> Mikael
>
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
RE: Question regarding upcoming PullAction changes in version 2.0.7
Posted by Mikael Ekblom <mi...@arcada.fi>.
Hi,
Good to hear that we follow standards!...:)
Regards,
Mikael
Mikael Ekblom
System developer
Arcada, IT
Jan-Magnus Janssons plats 1,
FIN-00560 Helsingfors,
Finland
TFn: +358 207 699 467
Mobil: +358 207 699 467
From: Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
Sent: torstai 7. joulukuuta 2017 11.40
To: user@syncope.apache.org
Subject: Re: Question regarding upcoming PullAction changes in version 2.0.7
Hi Mikael,
using pullUtils to get internal matches (if found) is exactly the best-practice for preprocess() to get internal data, congrats :-)
Regards.
On 07/12/2017 09:10, Mikael Ekblom wrote:
Hi,
Thank you for the answer. Yes, I found the SyndDeltaBuilder when I was looking around. The thing was more ,that I needed the current internal entity information together with the syncdelta due to the fact that the contents of the syncdelta (in our case )should be determined by the roles currently assigned to the user at the time we retrieve the SyncDelta through the connector. In that sense, the 2.0.6 version was more straightforward or maybe easier to use, but I do see your point here…☺
Anyhow, I decided to use the pullutil to get the current user that matched the syncdelta uid to get the currently assigned roles and it seems to work. I then just as you said rebuilt the syncdelta accordingly via the SyncDeltaBuilder.
Regards,
Mikael
Mikael Ekblom
System developer
Arcada, IT
Jan-Magnus Janssons plats 1,
FIN-00560 Helsingfors,
Finland
TFn: +358 207 699 467
Mobil: +358 207 699 467
From: Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
Sent: tiistai 5. joulukuuta 2017 10.08
To: user@syncope.apache.org<ma...@syncope.apache.org>
Subject: Re: Question regarding upcoming PullAction changes in version 2.0.7
Hi Mikael,
the SyncDelta processing was modified by SYNCOPE-1234 [1].
The new preprocess() method is invoked before any other method of the provided implementation, giving clear chance to alter the data coming from underlying resource prior to any other Syncope-side consideration.
Before [1] the logic was not adequate as the internal matching logic [3] could not be influenced by PullActions.
You have already discovered that SyncDelta instances are immutable; what you are currently missing is that you can use SyncDeltaBuilder [4] to generate new SyncDelta instances.
HTH
Regards.
[1] https://issues.apache.org/jira/browse/SYNCOPE-1234
[2] https://github.com/apache/syncope/blob/2_0_X/core/provisioning-api/src/main/java/org/apache/syncope/core/provisioning/api/pushpull/PullActions.java#L40
[3] https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/AbstractPullResultHandler.java#L741
[4] http://connid.tirasa.net/apidocs/1.4/org/identityconnectors/framework/common/objects/SyncDeltaBuilder.html
On 04/12/2017 16:40, Mikael Ekblom wrote:
Hi,
I have one question: in version 2.0.7 I have noticed that you have added a preprocess function to the default pull actions class. We would like to alter the syncdelta in certain cases ie the user should be kept as enabled (ie. __ENABLED__ set to true) as the user can have two different roles simultaneously and one primary role should be kept even though if the user is seen to have lost one primary role in the case that the user (as an example) has graduated and has been archived within the study register (__ENABLED__ set to false within the connector in this case) + we get a match for the user and this archive. We get a match, but the user should be set to active.
Arcada do not deprovision the users directly either if an entity matches an archived version for a specific master source.
The user might still have a role as staff or employee and the syncdelta should be set to __ENABLE__=true in this particular case but the rest of the roles bound to the student role should be removed.
This could be done in 2.0.6 within the beforeupdate function also, that in version 2.0.6 returned the SyncDelta but in version 2.0.7 the same function returns void. How is this supposed to work in the new implementation in 2.0.7 when you do not have the user information (or entity together with role information) available directly within the current function and syncdelta scope within preprocess? The SyncDelta object just has an read-only map of the current syncdelta attributes as far as I have seen if you try to alter the attributes within beforeupdate, so it seems to be too late for that there. You basically have to look up the user through the __UID__ I guess within preprocess, but through which function and through which library? What is the best option you have in this case?
It is enough if you have a hint to give and I’ll find the rest. I hope this text is somehow understandable!
Regards,
Mikael
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/<http://home.apache.org/%7Eilgrosso/>
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
Re: Question regarding upcoming PullAction changes in version 2.0.7
Posted by Francesco Chicchiriccò <il...@apache.org>.
Hi Mikael,
using pullUtils to get internal matches (if found) is exactly the
best-practice for preprocess() to get internal data, congrats :-)
Regards.
On 07/12/2017 09:10, Mikael Ekblom wrote:
>
> Hi,
>
> Thank you for the answer. Yes, I found the SyndDeltaBuilder when I was
> looking around. The thing was more ,that I needed the current internal
> entity information together with the syncdelta due to the fact that
> the contents of the syncdelta (in our case )should be determined by
> the roles currently assigned to the user at the time we retrieve the
> SyncDelta through the connector. In that sense, the 2.0.6 version was
> more straightforward or maybe easier to use, but I do see your point
> here…J
>
> Anyhow, I decided to use the pullutil to get the current user that
> matched the syncdelta uid to get the currently assigned roles and it
> seems to work. I then just as you said rebuilt the syncdelta
> accordingly via the SyncDeltaBuilder.
>
> Regards,
>
> Mikael
>
> *Mikael Ekblom *
>
> System developer
>
> Arcada, IT
>
> Jan-Magnus Janssons plats 1,
>
> FIN-00560 Helsingfors,
>
> Finland
>
> TFn: +358 207 699 467
>
> Mobil: +358 207 699 467
>
> *From:*Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
> *Sent:* tiistai 5. joulukuuta 2017 10.08
> *To:* user@syncope.apache.org
> *Subject:* Re: Question regarding upcoming PullAction changes in
> version 2.0.7
>
> Hi Mikael,
> the SyncDelta processing was modified by SYNCOPE-1234 [1].
>
> The new preprocess() method is invoked before any other method of the
> provided implementation, giving clear chance to alter the data coming
> from underlying resource prior to any other Syncope-side consideration.
>
> Before [1] the logic was not adequate as the internal matching logic
> [3] could not be influenced by PullActions.
>
> You have already discovered that SyncDelta instances are immutable;
> what you are currently missing is that you can use SyncDeltaBuilder
> [4] to generate new SyncDelta instances.
>
> HTH
> Regards.
>
> [1] https://issues.apache.org/jira/browse/SYNCOPE-1234
> [2]
> https://github.com/apache/syncope/blob/2_0_X/core/provisioning-api/src/main/java/org/apache/syncope/core/provisioning/api/pushpull/PullActions.java#L40
> [3]
> https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/AbstractPullResultHandler.java#L741
> [4]
> http://connid.tirasa.net/apidocs/1.4/org/identityconnectors/framework/common/objects/SyncDeltaBuilder.html
>
> On 04/12/2017 16:40, Mikael Ekblom wrote:
>
> Hi,
>
> I have one question: in version 2.0.7 I have noticed that you have
> added a preprocess function to the default pull actions class. We
> would like to alter the syncdelta in certain cases ie the user
> should be kept as enabled (ie. __ENABLED__ set to true) as the
> user can have two different roles simultaneously and one primary
> role should be kept even though if the user is seen to have lost
> one primary role in the case that the user (as an example) has
> graduated and has been archived within the study register
> (__ENABLED__ set to false within the connector in this case) + we
> get a match for the user and this archive. We get a match, but the
> user should be set to active.
>
> Arcada do not deprovision the users directly either if an entity
> matches an archived version for a specific master source.
>
> The user might still have a role as staff or employee and the
> syncdelta should be set to __ENABLE__=true in this particular case
> but the rest of the roles bound to the student role should be
> removed.
>
> This could be done in 2.0.6 within the beforeupdate function also,
> that in version 2.0.6 returned the SyncDelta but in version 2.0.7
> the same function returns void. How is this supposed to work in
> the new implementation in 2.0.7 when you do not have the user
> information (or entity together with role information) available
> directly within the current function and syncdelta scope within
> preprocess? The SyncDelta object just has an read-only map of the
> current syncdelta attributes as far as I have seen if you try to
> alter the attributes within beforeupdate, so it seems to be too
> late for that there. You basically have to look up the user
> through the __UID__ I guess within preprocess, but through which
> function and through which library? What is the best option you
> have in this case?
>
> It is enough if you have a hint to give and I’ll find the rest. I
> hope this text is somehow understandable!
>
> Regards,
>
> Mikael
>
> --
> Francesco Chicchiriccò
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
> Member at The Apache Software Foundation
> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> http://home.apache.org/~ilgrosso/ <http://home.apache.org/%7Eilgrosso/>
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/
RE: Question regarding upcoming PullAction changes in version 2.0.7
Posted by Mikael Ekblom <mi...@arcada.fi>.
Hi,
Thank you for the answer. Yes, I found the SyndDeltaBuilder when I was looking around. The thing was more ,that I needed the current internal entity information together with the syncdelta due to the fact that the contents of the syncdelta (in our case )should be determined by the roles currently assigned to the user at the time we retrieve the SyncDelta through the connector. In that sense, the 2.0.6 version was more straightforward or maybe easier to use, but I do see your point here…☺
Anyhow, I decided to use the pullutil to get the current user that matched the syncdelta uid to get the currently assigned roles and it seems to work. I then just as you said rebuilt the syncdelta accordingly via the SyncDeltaBuilder.
Regards,
Mikael
Mikael Ekblom
System developer
Arcada, IT
Jan-Magnus Janssons plats 1,
FIN-00560 Helsingfors,
Finland
TFn: +358 207 699 467
Mobil: +358 207 699 467
From: Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
Sent: tiistai 5. joulukuuta 2017 10.08
To: user@syncope.apache.org
Subject: Re: Question regarding upcoming PullAction changes in version 2.0.7
Hi Mikael,
the SyncDelta processing was modified by SYNCOPE-1234 [1].
The new preprocess() method is invoked before any other method of the provided implementation, giving clear chance to alter the data coming from underlying resource prior to any other Syncope-side consideration.
Before [1] the logic was not adequate as the internal matching logic [3] could not be influenced by PullActions.
You have already discovered that SyncDelta instances are immutable; what you are currently missing is that you can use SyncDeltaBuilder [4] to generate new SyncDelta instances.
HTH
Regards.
[1] https://issues.apache.org/jira/browse/SYNCOPE-1234
[2] https://github.com/apache/syncope/blob/2_0_X/core/provisioning-api/src/main/java/org/apache/syncope/core/provisioning/api/pushpull/PullActions.java#L40
[3] https://github.com/apache/syncope/blob/2_0_X/core/provisioning-java/src/main/java/org/apache/syncope/core/provisioning/java/pushpull/AbstractPullResultHandler.java#L741
[4] http://connid.tirasa.net/apidocs/1.4/org/identityconnectors/framework/common/objects/SyncDeltaBuilder.html
On 04/12/2017 16:40, Mikael Ekblom wrote:
Hi,
I have one question: in version 2.0.7 I have noticed that you have added a preprocess function to the default pull actions class. We would like to alter the syncdelta in certain cases ie the user should be kept as enabled (ie. __ENABLED__ set to true) as the user can have two different roles simultaneously and one primary role should be kept even though if the user is seen to have lost one primary role in the case that the user (as an example) has graduated and has been archived within the study register (__ENABLED__ set to false within the connector in this case) + we get a match for the user and this archive. We get a match, but the user should be set to active.
Arcada do not deprovision the users directly either if an entity matches an archived version for a specific master source.
The user might still have a role as staff or employee and the syncdelta should be set to __ENABLE__=true in this particular case but the rest of the roles bound to the student role should be removed.
This could be done in 2.0.6 within the beforeupdate function also, that in version 2.0.6 returned the SyncDelta but in version 2.0.7 the same function returns void. How is this supposed to work in the new implementation in 2.0.7 when you do not have the user information (or entity together with role information) available directly within the current function and syncdelta scope within preprocess? The SyncDelta object just has an read-only map of the current syncdelta attributes as far as I have seen if you try to alter the attributes within beforeupdate, so it seems to be too late for that there. You basically have to look up the user through the __UID__ I guess within preprocess, but through which function and through which library? What is the best option you have in this case?
It is enough if you have a hint to give and I’ll find the rest. I hope this text is somehow understandable!
Regards,
Mikael
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/