Hi Fabio,
> If the new subscribed resource doesn't require password value, then a new
password specification shouldn't be required.
> WDYT?
+1. Thanks for the explanation.
> This sounds a little bit strange.
> Let me understand ...
> 1. you synchronize a new user
> 2. you retrieve user details (from the admin console, I suppose) in order
to check for sync result
> 3. mapped virtual attributes are empty
Yes pretty much. I have a mocked up table in a H2 backend that I am
synchronizing from. I have a Virtual attribute (VirtualGivenName), and I am
mapping a column (GivenName -> VirtualGivenName) in the Resource Mapping. I
create a synchronization task, and execute it and examine the users (in the
console). I see the VirtualGivenName Virtual Attribute listed but with no
value. Looking at core-connid.log I see it is retrieving the value fine
initially:
16:31:26.783 DEBUG
org.connid.bundles.db.table.DatabaseTableConnector.executeQuery Column
values {GIVENNAME=GIVENNAME="Dave Yellow":[VARCHAR],
NAME=NAME="dave":[VARCHAR], PASSWORD=PASSWORD="password":[VARCHAR],
STATUS=STATUS="true":[VARCHAR], SURNAME=SURNAME="yellow":[VARCHAR]} from
result set
but then I see:
16:31:27.046 DEBUG Provide value for virtual attribute 'VirtualGivenName'
16:31:27.046 DEBUG Virtual attribute evaluation ended
16:31:27.098 DEBUG Provide value for virtual attribute 'VirtualGivenName'
16:31:27.098 DEBUG Virtual attribute evaluation ended
16:31:27.098 DEBUG
org.identityconnectors.framework.api.operations.SearchApiOp.search Return:
null
Thanks,
Colm.
On Mon, Jan 7, 2013 at 11:21 AM, Fabio Martelli <[email protected]>wrote:
>
> Il giorno 04/gen/2013, alle ore 17.37, Colm O hEigeartaigh ha scritto:
>
> >> Hum, you're right: would you mind to open an issue for this?
> >
> > https://issues.apache.org/jira/browse/SYNCOPE-265
> >
> >> You are actually talking about SYNCOPE-136, scheduled for 1.2.0.
> >> Subscribing a resource without providing a password has never been
> >> possible without additional tweaking (a.k.a extending UserController and
> >> overriding the update() method).
> >
> > Ok thanks. However I can't seem to subscribe the User to a new Resource
> > even by specifying the password - I guess it is complaining that the new
> > password is the same as the old one. So there is no way to propagate an
> > existing User to a remote resource without also changing the password, is
> > this correct?
>
> Hi Colm,
> the default password history is specified by the global password policy.
> You could change it to permit password change with the same password.
>
> BTW, I would implement a simple improvement related to your issue.
> I do think that in case of new resource subscription (explicitly or
> implicitly), password should be mandatory if and only a mapping for
> internal attribute "Password" exists for that resource.
>
> If the new subscribed resource doesn't require password value, then a new
> password specification shouldn't be required.
> WDYT?
>
> > One other thing. I have a mapping from a backend attribute to a user
> > virtual attribute in Syncope. I would have expected that on
> synchronization
> > that the User would then have a attribute with the same name as the name
> > specified in the mapping, with the given virtual value. However, I just
> see
> > a blank value. If I input a new value it propagates successfully. What
> am I
> > doing wrong here?
>
> This sounds a little bit strange.
> Let me understand ...
> 1. you synchronize a new user
> 2. you retrieve user details (from the admin console, I suppose) in order
> to check for sync result
> 3. mapped virtual attributes are empty
>
> What about the external attributes on the resource after the sync?
> External attributes mapped on virtual attributes are evaluated correctly?
>
> Please, let me have some details more.
>
> Regards,
> F.
>
> > Thanks,
> >
> > Colm.
> >
> > On Fri, Jan 4, 2013 at 3:30 PM, Francesco Chicchiriccò
> > <[email protected]>wrote:
> >
> >> On 04/01/2013 16:26, Colm O hEigeartaigh wrote:
> >>> Ok thanks. I guess it is something we should fix before the release.
> >>
> >> Hum, you're right: would you mind to open an issue for this?
> >>
> >>
> >>> Another question. I am creating a new user + adding a resource and it
> >>> propagates fine. Next, I create another new user without a resource. I
> >> then
> >>> edit the user again and try to add a resource, and I get an error about
> >> an
> >>> empty password. Is this a regression? I seem to recall that I could do
> >> this
> >>> before.
> >>
> >> You are actually talking about SYNCOPE-136, scheduled for 1.2.0.
> >> Subscribing a resource without providing a password has never been
> >> possible without additional tweaking (a.k.a extending UserController and
> >> overriding the update() method).
> >>
> >> Regards.
> >>
> >>> On Fri, Jan 4, 2013 at 3:22 PM, Francesco Chicchiriccò
> >>> <[email protected]>wrote:
> >>>
> >>>> On 04/01/2013 16:19, Colm O hEigeartaigh wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> Launching Syncope 1.1-SNAPSHOT in embedded mode, a lot of the users
> >> seem
> >>>> to
> >>>>> be invalid according to the schema. For example, "user1" is missing
> >>>> values
> >>>>> for the required attributes "surname" and "userId". Is this an
> >> oversight
> >>>> or
> >>>>> is there any reason for this?
> >>>> Hi Colm,
> >>>> no reason AFAICT: embedded users are test users, have been defined
> time
> >>>> over time and might not met current constraints.
> >>>>
> >>>> Naturally, it is possible to have users with missing required
> attributes
> >>>> only because they are not loaded via REST but at JDBC level.
> >>>>
> >>>> Regards.
> >>
> >> --
> >> Francesco Chicchiriccò
> >>
> >> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> >> http://people.apache.org/~ilgrosso/
> >>
> >>
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
