You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2013/01/04 16:19:37 UTC
Users in trunk embedded mode
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?
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Users in trunk embedded mode
Posted by Fabio Martelli <fa...@gmail.com>.
Il giorno 08/gen/2013, alle ore 17.46, Colm O hEigeartaigh ha scritto:
> 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
Oh, can it be related to the issue just closed today?
https://issues.apache.org/jira/browse/SYNCOPE-267
If your accountid is username or SyncopeUser id or a derived attribute the cause is that.
Please, try with the latest snapshot.
Regards,
F.
>
> Thanks,
>
> Colm.
>
> On Mon, Jan 7, 2013 at 11:21 AM, Fabio Martelli <fa...@gmail.com>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ò
>>> <il...@apache.org>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ò
>>>>> <il...@apache.org>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
Re: Users in trunk embedded mode
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <fa...@gmail.com>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ò
> > <il...@apache.org>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ò
> >>> <il...@apache.org>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
Re: Users in trunk embedded mode
Posted by Fabio Martelli <fa...@gmail.com>.
Il giorno 08/gen/2013, alle ore 08.49, Jan Bernhardt ha scritto:
>>> 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?
>>
>
> +1
> I think this is an excellent idea! Passwords should only be mandatory, if they should be synchronized.
This is the new issue
https://issues.apache.org/jira/browse/SYNCOPE-266
Since this improvement seems to be really simple and useful, I'd like to implement it on 1.0.X as well.
Regards,
F.
RE: Users in trunk embedded mode
Posted by Jan Bernhardt <jb...@talend.com>.
> > 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?
>
+1
I think this is an excellent idea! Passwords should only be mandatory, if they should be synchronized.
Best regards.
Jan
Re: Users in trunk embedded mode
Posted by Fabio Martelli <fa...@gmail.com>.
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ò
> <il...@apache.org>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ò
>>> <il...@apache.org>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
Re: Users in trunk embedded mode
Posted by Colm O hEigeartaigh <co...@apache.org>.
> 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?
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?
Thanks,
Colm.
On Fri, Jan 4, 2013 at 3:30 PM, Francesco Chicchiriccò
<il...@apache.org>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ò
> > <il...@apache.org>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
Re: Users in trunk embedded mode
Posted by Francesco Chicchiriccò <il...@apache.org>.
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ò
> <il...@apache.org>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/
Re: Users in trunk embedded mode
Posted by Colm O hEigeartaigh <co...@apache.org>.
Ok thanks. I guess it is something we should fix before the release.
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.
Colm.
On Fri, Jan 4, 2013 at 3:22 PM, Francesco Chicchiriccò
<il...@apache.org>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
Re: Users in trunk embedded mode
Posted by Francesco Chicchiriccò <il...@apache.org>.
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/