Re: LDAP Role queries

[Francesco Chicchiriccò]

On 19/02/2013 14:13, Emmanuel Lécharny wrote:

Don't use uniqueMemeber. Never. Nine. Niet. Nix.

http://rfc-ref.org/RFC-TEXTS/4519/chapter2.html#d4e443387

This is far from what you expect it to be, and you'll get hard time with some 
Windows identifier having a # in their DN.


Hi Emmanuel,
what's your advice for LDAP group object class, since groupOfUniqueNames 
(and uniqueMemeber) is "Never. Nine. Niet. Nix."?


Thanks.

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

[jira] [Resolved] (SYNCOPE-319) Provide feature for reloading all connectors

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò resolved SYNCOPE-319.


Resolution: Fixed

http://svn.apache.org/r1448090

> Provide feature for reloading all connectors
> 
>
> Key: SYNCOPE-319
> URL: https://issues.apache.org/jira/browse/SYNCOPE-319
> Project: Syncope
>  Issue Type: Improvement
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
>
> It is a feature particularly useful during project deployment that will allow 
> to refresh all connector bundles and configuration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SYNCOPE-209) DB Table connector does not see changes in underlying table until restart

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò resolved SYNCOPE-209.


Resolution: Fixed

Resolving as part of SYNCOPE-319

> DB Table connector does not see changes in underlying table until restart
> -
>
> Key: SYNCOPE-209
> URL: https://issues.apache.org/jira/browse/SYNCOPE-209
> Project: Syncope
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.0.1-incubating
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
>
> Steps to reproduce:
> 1. generate a project from 1.0.2-incubating-SNAPSHOT or 
> 1.1.0-incubating-SNAPSHOT archetypes (both tested)
> 2. mvn clean package
> 3. cd console && mvn -P embedded
> 1. log in http://localhost:9080/syncope-console/
> 2, go to resources -> resource-testdb -> mapping
> 1. go to http://localhost:9082
> 2. select "Generic H2 (Server)"
> 3. set JDBC URL to "jdbc:h2:tcp://localhost:9092/testdb"
> 4. set username 'sa' and password 'sa'
> 5. connect
> 6. send SQL statement 'ALTER TABLE TEST ADD COLUMN newcol VARCHAR(255)'
> 1. log in http://localhost:9080/syncope-console/
> 2, go to resources -> resource-testdb -> mapping
> At this point, when trying to add a new schema mapping, 'newcol' is not shown 
> among available values until restart

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SYNCOPE-319) Provide feature for reloading all connectors

[JIRA]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582116#comment-13582116
 ] 

Francesco Chicchiriccò commented on SYNCOPE-319:


REST API upgrade wiki page [1] updated.

[1] https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade

> Provide feature for reloading all connectors
> 
>
> Key: SYNCOPE-319
> URL: https://issues.apache.org/jira/browse/SYNCOPE-319
> Project: Syncope
>  Issue Type: Improvement
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
>
> It is a feature particularly useful during project deployment that will allow 
> to refresh all connector bundles and configuration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (SYNCOPE-293) Show information (version, license, ...)

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò reassigned SYNCOPE-293:
--

Assignee: Francesco Chicchiriccò  (was: Massimiliano Perrone)

> Show information (version, license, ...)
> 
>
> Key: SYNCOPE-293
> URL: https://issues.apache.org/jira/browse/SYNCOPE-293
> Project: Syncope
>  Issue Type: Improvement
>  Components: console
>Reporter: Massimiliano Perrone
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
> Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, 
> Screenshot from 2013-02-19 15.png, welcomeOnChrome.png, wp.png
>
>
> Currently there is only a static label with core and console versions.
> Add a new Link to open a ModalPage with version and other project information 
> (eg. link to license)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (SYNCOPE-320) Support synchronizing role memberships from LDAP groupOfNames

[Colm O hEigeartaigh (JIRA)]

Colm O hEigeartaigh created SYNCOPE-320:
---

 Summary: Support synchronizing role memberships from LDAP 
groupOfNames
 Key: SYNCOPE-320
 URL: https://issues.apache.org/jira/browse/SYNCOPE-320
 Project: Syncope
  Issue Type: Bug
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
 Fix For: 1.1.0



This task is to support synchronizing role memberships from LDAP groupOfNames. 
As reported in the following mailing list thread, it is not possible to 
synchronize role memberships from groupOfNames currently (only 
groupOfUniqueNames):

http://syncope-dev.1063484.n5.nabble.com/LDAP-Role-queries-td5712875.html

The solution is to update the LDAPMembershipSyncActions to query the Connector 
for the configured group member attribute. If none is defined, then just fall 
back to "uniqueMember".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: LDAP Role queries

[Colm O hEigeartaigh]

Patch submitted for review here:

https://issues.apache.org/jira/browse/SYNCOPE-320

Colm.

On Mon, Feb 18, 2013 at 5:14 PM, Francesco Chicchiriccò  wrote:

> On 18/02/2013 16:08, Colm O hEigeartaigh wrote:
>
>> [...]
>>
>>
>>  LDAPMembershipPropagationActio**ns has "ldapGroups" as the group member
 attribute name, whereas LDAPMembershipSyncActions has "uniquemember". Is
 there a reason why it is different in both cases? Shouldn't they also
 check
 the value of the "groupMemberAttribute" property of the LDAP Connector?

  Could you explain the difference between "ldapGroups" and
>> "uniquemember"
>> here?
>>
>
> "ldapGroups" is the 'special' attribute that the LDAP connector uses
> internally to process group memberships.
> This attribute name is not subject to configuration, in the LDAP connector.
> This is needed because the ConnId framework does not support memberships,
> but only ACCOUNT and GROUP.
>
> "uniqueMember" is the actual LDAP attribute used when the object class
> 'groupOfUniqueNames' is configured.
> I am not sure whether there is any mean to derive this attribute name from
> LDAP connector configuration: if this is possible, I am totally +1 to
> change LDAPMembershipSyncActions#**getGroupMembershipAttrName
> implementation to empower that.
>
> Moreover, I agree with you that the method name
> (getGroupMembershipAttrName()) might be misleading and that we should
> change at least one: any proposal?
>
> Finally, consider that, as reported in SYNCOPE-26,
> LDAPMembershipPropagationActio**ns and LDAPMembershipSyncActions are
> sample classes provided by reference when needing to implement an
> unsupported operation, e.g. propagate and synchronize memberships from an
> external resource.
>
>
>  Shouldn't the latter be "uniqueMember"?
>>
>
> AFAIK LDAP is not case sensitive...
>
> Regards.
>
>  On Fri, Feb 15, 2013 at 5:12 PM, Francesco Chicchiriccò <
>> ilgro...@apache.org
>>
>>> wrote:
>>> On 15/02/2013 16:48, Colm O hEigeartaigh wrote:
>>>
>>>  Hi all (Francesco),

 I've been experimenting with propagating/synchronizing roles from an
 LDAP
 backend on trunk...here are some questions:

 1) When specifying the "Account Id", where does the "name" come from?
 For
 example, for user mapping it's "username", for the role mapping it's
 "name", which is a bit confusing (I would have guessed "rolename").

  This derives from UserTO.username and RoleTO.name, as per bean property
>>> resolution: to turn the latter into rolename we should change the
>>> property
>>> name and getter / setter on RoleTO.
>>>
>>>
>>>   2) If I create a new Role and propagate it with
>>>
 LDAPMembershipPropagationActions, it selects the principal
 specified

 in the
 Connector as the member in the backend resource. Is this expected
 behaviour?

  Unfortunately, yes: memberOf requires at least one value, and I've
>>> found
>>> that this is a common practice to overcome such limitation.
>>>
>>>
>>>   3) Are role hierarchies supported for either propagation or
>>>
 synchronization? They don't appear to be, but thought I'd check anyway.

  Currently, role hierarchy is not supported neither in propagation nor
>>> in
>>> synchronization.
>>>
>>>
>>>   4) Role membership is working fine for propagation (create a new role +
>>>
 propagate it, create a new user with that role + propagate it, and the
 new
 role in the backend has the correct "member" entry). However,
 synchronization doesn't work. If I then synchronize by running the task
 again (with LDAPMembershipSyncActions), the role of the User actually
 disappears. Was this working when testing or is it possibly a bug when
 using "member" instead of "memberof"?

  Definitely yes.
>>>
>>>
>>>   LDAPMembershipPropagationActions has "ldapGroups" as the group
>>> member
>>>
>>>  attribute name, whereas LDAPMembershipSyncActions has "uniquemember". Is
 there a reason why it is different in both cases? Shouldn't they also
 check
 the value of the "groupMemberAttribute" property of the LDAP Connector?

  +1
>>>
>>> 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

[jira] [Updated] (SYNCOPE-320) Support synchronizing role memberships from LDAP groupOfNames

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated SYNCOPE-320:


Attachment: syncope-320.patch


A patch for this issue.

Colm.

> Support synchronizing role memberships from LDAP groupOfNames
> -
>
> Key: SYNCOPE-320
> URL: https://issues.apache.org/jira/browse/SYNCOPE-320
> Project: Syncope
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: syncope-320.patch
>
>
> This task is to support synchronizing role memberships from LDAP 
> groupOfNames. As reported in the following mailing list thread, it is not 
> possible to synchronize role memberships from groupOfNames currently (only 
> groupOfUniqueNames):
> http://syncope-dev.1063484.n5.nabble.com/LDAP-Role-queries-td5712875.html
> The solution is to update the LDAPMembershipSyncActions to query the 
> Connector for the configured group member attribute. If none is defined, then 
> just fall back to "uniqueMember".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [connid-dev] Re: CSV Connector SNAPSHOT version

[Colm O hEigeartaigh]

> think that we can move Syncope 1.1.0 to ConnId 1.3.3-SNAPSHOT, thus avoid
> branching.
>

Any objections to me moving the Syncope trunk pom to use 1.3.3-SNAPSHOT,
and the SNAPSHOT versions of the Connector bundles?

Colm.

On Tue, Feb 19, 2013 at 2:19 PM, Colm O hEigeartaigh wrote:

>
> Given the retro-compatibility feature reported above, if confirmed
>> working, I think that we can move Syncope 1.1.0 to ConnId 1.3.3-SNAPSHOT,
>> thus avoid branching.
>>
>> Sorry for not having made this re-thinking clear.
>
>
> Ah, ok got it, thanks.
>
> Colm.
>
> On Tue, Feb 19, 2013 at 12:30 PM, Francesco Chicchiriccò <
> ilgro...@apache.org> wrote:
>
>> On 19/02/2013 13:04, Colm O hEigeartaigh wrote:
>>
>>> Hi Francesco,
>>>
>>>  I thought we could avoid this branching if we are able to verify that
 you can use "old" (e.g. compiled against ConnId 1.3.2) connectors with 
 "new"
 (e.g. 1.3.3-SNAPSHOT) framework,

>>>
>>> Ok, I guess I misunderstood. I understand that we want to run an "old"
>>> connector with the new framework, and so for example the CSV 0.6.x branch
>>> should be able to run against the 1.3.3-SNAPSHOT framework version.
>>>
>>> I don't understand though how we can avoid branching DB + LDAP if we want
>>> to have the fixes I mentioned available in Syncope 1.1?
>>>
>>
>> Given the retro-compatibility feature reported above, if confirmed
>> working, I think that we can move Syncope 1.1.0 to ConnId 1.3.3-SNAPSHOT,
>> thus avoid branching.
>>
>> Sorry for not having made this re-thinking clear.
>>
>> Regards.
>>
>>  On Tue, Feb 19, 2013 at 11:56 AM, Francesco Chicchiriccò <
>>> ilgro...@apache.org> wrote:
>>>
>>>  On 19/02/2013 12:51, Colm O hEigeartaigh wrote:

  How about a new branch for the LDAP + DB bundles that I can backport
>
>> fixes to?
>>
>>  In terms of the DB Connector first, trunk is at 2.1.5-SNAPSHOT. How
> about
> I
> update trunk to 2.2-SNAPSHOT + create a new branch called "2.1.X" (with
> version 2.1.5-SNAPSHOT) before the recent revisions were made? I will
> then
> selectively merge various fixes. Any objections to this?
>
>  I thought we could avoid this branching if we are able to verify that
 you
 can use "old" (e.g. compiled against ConnId 1.3.2) connectors with "new"
 (e.g. 1.3.3-SNAPSHOT) framework,

 Am I wrong?

 Regards.

   On Tue, Feb 19, 2013 at 10:56 AM, Fabio Martelli

> wrote:
>
>
>   Il giorno 19/feb/2013, alle ore 11.44, Colm O hEigeartaigh ha
> scritto:
>
>>   Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
>>
>>> Since we are expecting to release soon I'd like to be sure about the
 reliability of the 1.1.0.

  Why do you think 1.3.3 would be particularly unreliable? There
>>> have not
>>> been many fixes made from what I can see.
>>>
>>> I don't have strong objections to using 1.3.2 for Syncope 1.1,
>>> however I
>>> would like if the fixes I've made make it into Syncope for 1.1. I
>>> will
>>> backport the CSV fixes to the branch. How about a new branch for the
>>>
>>>  LDAP +
>>
>>  DB bundles that I can backport fixes to? In particular I would like
>>> to
>>>
>>>  have
>>
>>  LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.
>>>
>>>  OK Colm, probably we can do the following.
>> Since I'd like to maintain the possibility to switch from a newest
>> connector version  to an old one I'd ask you to verify before the
>> possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the
>> latest
>> framework version.
>> If I well remember this should be possible (the opposite is not
>> possible
>> for sure). This would be sufficient to have my +1.
>>
>> Best regards,
>> F.
>>
>>   On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli
>>
>>> wrote:
>>>
>>>
>>>   Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha
>>> scritto:
>>>
   When using the CSVDir 0.7-SNAPSHOT we would be forced to use
 ConnId

> 1.3.3-SNAPSHOT instead of 1.3.2.
>>
>>   Is there any reason why we can't just do that on trunk anyway? I
>>
> assume
> we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?
>
>  Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
 Since we are expecting to release soon I'd like to be sure about the
 reliability of the 1.1.0.

 Regards,
 F.

   Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?

> I will do.
>
> Colm.
>
>
>
> On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
> ilgro...@apache.org> wrote:
>
>   On 19/02/2013 11:13, Colm O hEigeartaigh wrote:
>

Re: [connid-dev] Re: CSV Connector SNAPSHOT version

[Francesco Chicchiriccò]

On 20/02/2013 13:28, Colm O hEigeartaigh wrote:

I think that we can move Syncope 1.1.0 to ConnId 1.3.3-SNAPSHOT, thus avoid
branching.

Any objections to me moving the Syncope trunk pom to use 1.3.3-SNAPSHOT,
and the SNAPSHOT versions of the Connector bundles?


Not at all, go ahead.

Regards.


On Tue, Feb 19, 2013 at 2:19 PM, Colm O hEigeartaigh wrote:


Given the retro-compatibility feature reported above, if confirmed

working, I think that we can move Syncope 1.1.0 to ConnId 1.3.3-SNAPSHOT,
thus avoid branching.

Sorry for not having made this re-thinking clear.


Ah, ok got it, thanks.

Colm.

On Tue, Feb 19, 2013 at 12:30 PM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:


On 19/02/2013 13:04, Colm O hEigeartaigh wrote:


Hi Francesco,

  I thought we could avoid this branching if we are able to verify that

you can use "old" (e.g. compiled against ConnId 1.3.2) connectors with "new"
(e.g. 1.3.3-SNAPSHOT) framework,


Ok, I guess I misunderstood. I understand that we want to run an "old"
connector with the new framework, and so for example the CSV 0.6.x branch
should be able to run against the 1.3.3-SNAPSHOT framework version.

I don't understand though how we can avoid branching DB + LDAP if we want
to have the fixes I mentioned available in Syncope 1.1?


Given the retro-compatibility feature reported above, if confirmed
working, I think that we can move Syncope 1.1.0 to ConnId 1.3.3-SNAPSHOT,
thus avoid branching.

Sorry for not having made this re-thinking clear.

Regards.

  On Tue, Feb 19, 2013 at 11:56 AM, Francesco Chicchiriccò <

ilgro...@apache.org> wrote:

  On 19/02/2013 12:51, Colm O hEigeartaigh wrote:

  How about a new branch for the LDAP + DB bundles that I can backport

fixes to?

  In terms of the DB Connector first, trunk is at 2.1.5-SNAPSHOT. How

about
I
update trunk to 2.2-SNAPSHOT + create a new branch called "2.1.X" (with
version 2.1.5-SNAPSHOT) before the recent revisions were made? I will
then
selectively merge various fixes. Any objections to this?

  I thought we could avoid this branching if we are able to verify that

you
can use "old" (e.g. compiled against ConnId 1.3.2) connectors with "new"
(e.g. 1.3.3-SNAPSHOT) framework,

Am I wrong?

Regards.

   On Tue, Feb 19, 2013 at 10:56 AM, Fabio Martelli


wrote:


   Il giorno 19/feb/2013, alle ore 11.44, Colm O hEigeartaigh ha
scritto:


   Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.


Since we are expecting to release soon I'd like to be sure about the

reliability of the 1.1.0.

  Why do you think 1.3.3 would be particularly unreliable? There

have not
been many fixes made from what I can see.

I don't have strong objections to using 1.3.2 for Syncope 1.1,
however I
would like if the fixes I've made make it into Syncope for 1.1. I
will
backport the CSV fixes to the branch. How about a new branch for the

  LDAP +

  DB bundles that I can backport fixes to? In particular I would like

to

  have

  LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.

  OK Colm, probably we can do the following.

Since I'd like to maintain the possibility to switch from a newest
connector version  to an old one I'd ask you to verify before the
possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the
latest
framework version.
If I well remember this should be possible (the opposite is not
possible
for sure). This would be sufficient to have my +1.

Best regards,
F.

   On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli


wrote:


   Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha
scritto:


   When using the CSVDir 0.7-SNAPSHOT we would be forced to use
ConnId


1.3.3-SNAPSHOT instead of 1.3.2.

   Is there any reason why we can't just do that on trunk anyway? I


assume
we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?

  Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.

Since we are expecting to release soon I'd like to be sure about the
reliability of the 1.1.0.

Regards,
F.

   Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?


I will do.

Colm.



On Tue, Feb 19, 2013 at 10:25 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:

   On 19/02/2013 11:13, Colm O hEigeartaigh wrote:


   Hi all,


Following the query on the CSV SNAPSHOT in Syncope, just
wondering

  why

are

we including 0.6.1-SNAPSHOT on trunk instead of 0.7-SNAPSHOT? The

former


does not include the fixes I made recently (in particular the


properties


file is in the wrong package name, and so the correct property keys


are


not

  displayed in Syncope).

   When using the CSVDir 0.7-SNAPSHOT we would be forced to use
ConnId


1.3.3-SNAPSHOT instead of 1.3.2.

Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?

Regards.


--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~**ilgrosso/

--
You received this message because you are subscribed to the Google Groups
"conn

[jira] [Updated] (SYNCOPE-320) Support synchronizing role memberships from LDAP groupOfNames

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò updated SYNCOPE-320:
---

  Component/s: core
Affects Version/s: 1.1.0

> Support synchronizing role memberships from LDAP groupOfNames
> -
>
> Key: SYNCOPE-320
> URL: https://issues.apache.org/jira/browse/SYNCOPE-320
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1.0
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: syncope-320.patch
>
>
> This task is to support synchronizing role memberships from LDAP 
> groupOfNames. As reported in the following mailing list thread, it is not 
> possible to synchronize role memberships from groupOfNames currently (only 
> groupOfUniqueNames):
> http://syncope-dev.1063484.n5.nabble.com/LDAP-Role-queries-td5712875.html
> The solution is to update the LDAPMembershipSyncActions to query the 
> Connector for the configured group member attribute. If none is defined, then 
> just fall back to "uniqueMember".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SYNCOPE-320) Support synchronizing role memberships from LDAP groupOfNames

[JIRA]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582143#comment-13582143
 ] 

Francesco Chicchiriccò commented on SYNCOPE-320:


Patch looks good to me: I'd only change things in getMembAttrValues() to call 
getGroupMembershipAttrName() only once.

> Support synchronizing role memberships from LDAP groupOfNames
> -
>
> Key: SYNCOPE-320
> URL: https://issues.apache.org/jira/browse/SYNCOPE-320
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1.0
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: syncope-320.patch
>
>
> This task is to support synchronizing role memberships from LDAP 
> groupOfNames. As reported in the following mailing list thread, it is not 
> possible to synchronize role memberships from groupOfNames currently (only 
> groupOfUniqueNames):
> http://syncope-dev.1063484.n5.nabble.com/LDAP-Role-queries-td5712875.html
> The solution is to update the LDAPMembershipSyncActions to query the 
> Connector for the configured group member attribute. If none is defined, then 
> just fall back to "uniqueMember".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [connid-dev] Re: CSV Connector SNAPSHOT version

[Fabio Martelli]

Il giorno 20/feb/2013, alle ore 13.28, Colm O hEigeartaigh ha scritto:

>> think that we can move Syncope 1.1.0 to ConnId 1.3.3-SNAPSHOT, thus avoid
>> branching.
>> 
> 
> Any objections to me moving the Syncope trunk pom to use 1.3.3-SNAPSHOT,
> and the SNAPSHOT versions of the Connector bundles?
+1
> 
> Colm.
> 
> On Tue, Feb 19, 2013 at 2:19 PM, Colm O hEigeartaigh 
> wrote:
> 
>> 
>> Given the retro-compatibility feature reported above, if confirmed
>>> working, I think that we can move Syncope 1.1.0 to ConnId 1.3.3-SNAPSHOT,
>>> thus avoid branching.
>>> 
>>> Sorry for not having made this re-thinking clear.
>> 
>> 
>> Ah, ok got it, thanks.
>> 
>> Colm.
>> 
>> On Tue, Feb 19, 2013 at 12:30 PM, Francesco Chicchiriccò <
>> ilgro...@apache.org> wrote:
>> 
>>> On 19/02/2013 13:04, Colm O hEigeartaigh wrote:
>>> 
 Hi Francesco,
 
 I thought we could avoid this branching if we are able to verify that
> you can use "old" (e.g. compiled against ConnId 1.3.2) connectors with 
> "new"
> (e.g. 1.3.3-SNAPSHOT) framework,
> 
 
 Ok, I guess I misunderstood. I understand that we want to run an "old"
 connector with the new framework, and so for example the CSV 0.6.x branch
 should be able to run against the 1.3.3-SNAPSHOT framework version.
 
 I don't understand though how we can avoid branching DB + LDAP if we want
 to have the fixes I mentioned available in Syncope 1.1?
 
>>> 
>>> Given the retro-compatibility feature reported above, if confirmed
>>> working, I think that we can move Syncope 1.1.0 to ConnId 1.3.3-SNAPSHOT,
>>> thus avoid branching.
>>> 
>>> Sorry for not having made this re-thinking clear.
>>> 
>>> Regards.
>>> 
>>> On Tue, Feb 19, 2013 at 11:56 AM, Francesco Chicchiriccò <
 ilgro...@apache.org> wrote:
 
 On 19/02/2013 12:51, Colm O hEigeartaigh wrote:
> 
> How about a new branch for the LDAP + DB bundles that I can backport
>> 
>>> fixes to?
>>> 
>>> In terms of the DB Connector first, trunk is at 2.1.5-SNAPSHOT. How
>> about
>> I
>> update trunk to 2.2-SNAPSHOT + create a new branch called "2.1.X" (with
>> version 2.1.5-SNAPSHOT) before the recent revisions were made? I will
>> then
>> selectively merge various fixes. Any objections to this?
>> 
>> I thought we could avoid this branching if we are able to verify that
> you
> can use "old" (e.g. compiled against ConnId 1.3.2) connectors with "new"
> (e.g. 1.3.3-SNAPSHOT) framework,
> 
> Am I wrong?
> 
> Regards.
> 
>  On Tue, Feb 19, 2013 at 10:56 AM, Fabio Martelli
> 
>> wrote:
>> 
>> 
>>  Il giorno 19/feb/2013, alle ore 11.44, Colm O hEigeartaigh ha
>> scritto:
>> 
>>>  Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
>>> 
 Since we are expecting to release soon I'd like to be sure about the
> reliability of the 1.1.0.
> 
> Why do you think 1.3.3 would be particularly unreliable? There
 have not
 been many fixes made from what I can see.
 
 I don't have strong objections to using 1.3.2 for Syncope 1.1,
 however I
 would like if the fixes I've made make it into Syncope for 1.1. I
 will
 backport the CSV fixes to the branch. How about a new branch for the
 
 LDAP +
>>> 
>>> DB bundles that I can backport fixes to? In particular I would like
 to
 
 have
>>> 
>>> LDAP-2, LDAP-5 and LDAP-6 available in Syncope 1.1.
 
 OK Colm, probably we can do the following.
>>> Since I'd like to maintain the possibility to switch from a newest
>>> connector version  to an old one I'd ask you to verify before the
>>> possibility to run, for example,  CsvDir 0.6.1-SNAPSHOT with the
>>> latest
>>> framework version.
>>> If I well remember this should be possible (the opposite is not
>>> possible
>>> for sure). This would be sufficient to have my +1.
>>> 
>>> Best regards,
>>> F.
>>> 
>>>  On Tue, Feb 19, 2013 at 10:36 AM, Fabio Martelli
>>> 
 wrote:
 
 
  Il giorno 19/feb/2013, alle ore 11.28, Colm O hEigeartaigh ha
 scritto:
 
>  When using the CSVDir 0.7-SNAPSHOT we would be forced to use
> ConnId
> 
>> 1.3.3-SNAPSHOT instead of 1.3.2.
>>> 
>>>  Is there any reason why we can't just do that on trunk anyway? I
>>> 
>> assume
>> we're going to release Syncope 1.1 with ConnId 1.3.3 anyway?
>> 
>> Guys, I'd prefere to keep the 1.3.2 for Syncope 1.1.0.
> Since we are expecting to release soon I'd like to be sure about the
> reliability of the 1.1.0.
> 
> Regards,
> F.
> 
>  Why not backporting your fix on 0.7-SNAPSHOT to 0.6.1-SNAPSHOT?
> 
>

Syncope-trunk - Build # 102 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Syncope-trunk (build #102)

Status: Failure

Check console output at https://builds.apache.org/job/Syncope-trunk/102/ to 
view the results.

[jira] [Commented] (SYNCOPE-319) Provide feature for reloading all connectors

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582160#comment-13582160
 ] 

Hudson commented on SYNCOPE-319:


Integrated in Syncope-trunk #102 (See 
[https://builds.apache.org/job/Syncope-trunk/102/])
[SYNCOPE-319][SYNCOPE-209] Introducing new REST operation 
ConnectorService#reload() and refactoring the ConnId layer (Revision 1448090)

 Result = FAILURE
ilgrosso : 
Files : 
* 
/syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/ConnectorServiceProxy.java
* 
/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/ConnectorService.java
* 
/syncope/trunk/common/src/main/java/org/apache/syncope/common/types/AuditElements.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/Resources.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/ConnectorRestClient.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/wicket/ajax/markup/html/IndicatingDeleteOnConfirmAjaxLink.java
* /syncope/trunk/console/src/main/resources/authorizations.xml
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/Configuration.html
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/Resources.html
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/Resources.properties
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/Resources_it.properties
* /syncope/trunk/console/src/main/webapp/img/reload_30.png
* 
/syncope/trunk/console/src/test/java/org/apache/syncope/console/ConnInstanceTestITCase.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/audit/JNDIFallbackConnectionSource.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/connid/ConnObjectUtil.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/init/ConnInstanceLoader.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/init/ConnectorManager.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/init/SpringContextInitializer.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/ConnectorRegistry.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/impl/ConnInstanceDAOImpl.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/impl/ResourceDAOImpl.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/Connector.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/ConnectorFactory.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/SyncopeConnector.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/TimeoutException.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/impl/AbstractPropagationTaskExecutor.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/impl/ConnectorFacadeProxy.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/ConnInstanceController.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/ResourceController.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/ConnInstanceDataBinder.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/services/ConnectorServiceImpl.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/LDAPMembershipSyncActions.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/SyncJob.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/SyncopeSyncResultHandler.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/util/ConnBundleManager.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/util/ConnIdBundleManager.java
* /syncope/trunk/core/src/main/resources/connid.properties
* /syncope/trunk/core/src/main/resources/content.xml
* /syncope/trunk/core/src/test/java/org/apache/syncope/core/AbstractTest.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/init/ConnInstanceLoaderTest.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/EntitlementTest.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ConnInstanceTestITCase.java
* /syncope/trunk/core/src/test/resources/bundles.properties
* /syncope/trunk/core/src/test/resources/connid.properties
* /syncope/trunk/core/src/test/resources/content.xml


> Provide feature for reloading all connectors
> 
>
> Key: SYNCOPE-319
> URL: https://issues.apache.org/jira/browse/SYNCOPE-319
> Project: Syncope
>  Issue Type: Improvement
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
>  

[jira] [Commented] (SYNCOPE-209) DB Table connector does not see changes in underlying table until restart

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582161#comment-13582161
 ] 

Hudson commented on SYNCOPE-209:


Integrated in Syncope-trunk #102 (See 
[https://builds.apache.org/job/Syncope-trunk/102/])
[SYNCOPE-319][SYNCOPE-209] Introducing new REST operation 
ConnectorService#reload() and refactoring the ConnId layer (Revision 1448090)

 Result = FAILURE
ilgrosso : 
Files : 
* 
/syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/ConnectorServiceProxy.java
* 
/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/ConnectorService.java
* 
/syncope/trunk/common/src/main/java/org/apache/syncope/common/types/AuditElements.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/Resources.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/rest/ConnectorRestClient.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/wicket/ajax/markup/html/IndicatingDeleteOnConfirmAjaxLink.java
* /syncope/trunk/console/src/main/resources/authorizations.xml
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/Configuration.html
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/Resources.html
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/Resources.properties
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/Resources_it.properties
* /syncope/trunk/console/src/main/webapp/img/reload_30.png
* 
/syncope/trunk/console/src/test/java/org/apache/syncope/console/ConnInstanceTestITCase.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/audit/JNDIFallbackConnectionSource.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/connid/ConnObjectUtil.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/init/ConnInstanceLoader.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/init/ConnectorManager.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/init/SpringContextInitializer.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/ConnectorRegistry.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/impl/ConnInstanceDAOImpl.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/persistence/dao/impl/ResourceDAOImpl.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/Connector.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/ConnectorFactory.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/SyncopeConnector.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/TimeoutException.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/impl/AbstractPropagationTaskExecutor.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/propagation/impl/ConnectorFacadeProxy.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/ConnInstanceController.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/ResourceController.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/data/ConnInstanceDataBinder.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/services/ConnectorServiceImpl.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/LDAPMembershipSyncActions.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/SyncJob.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/SyncopeSyncResultHandler.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/util/ConnBundleManager.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/util/ConnIdBundleManager.java
* /syncope/trunk/core/src/main/resources/connid.properties
* /syncope/trunk/core/src/main/resources/content.xml
* /syncope/trunk/core/src/test/java/org/apache/syncope/core/AbstractTest.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/init/ConnInstanceLoaderTest.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/persistence/dao/EntitlementTest.java
* 
/syncope/trunk/core/src/test/java/org/apache/syncope/core/rest/ConnInstanceTestITCase.java
* /syncope/trunk/core/src/test/resources/bundles.properties
* /syncope/trunk/core/src/test/resources/connid.properties
* /syncope/trunk/core/src/test/resources/content.xml


> DB Table connector does not see changes in underlying table until restart
> -
>
> Key: SYNCOPE-209
> URL: https://issues.apache.org/jira/browse/SYNCOPE-209
> Project: Syncope
>  Issue Type: Improvement
>  Components: core
>Affe

Re: LDAP Role queries

[Emmanuel Lécharny]

Le 2/20/13 11:26 AM, Francesco Chicchiriccò a écrit :
> On 19/02/2013 14:13, Emmanuel Lécharny wrote:
>> Don't use uniqueMemeber. Never. Nine. Niet. Nix.
>>
>> http://rfc-ref.org/RFC-TEXTS/4519/chapter2.html#d4e443387
>>
>> This is far from what you expect it to be, and you'll get hard time
>> with some Windows identifier having a # in their DN.
>
> Hi Emmanuel,
> what's your advice for LDAP group object class, since
> groupOfUniqueNames (and uniqueMemeber) is "Never. Nine. Niet. Nix."?

GroupOfNames and member.

You can control the cardinality at a upper level.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 

RE: [CONF] Apache Syncope > REST API upgrade

[Jan Bernhardt]

Hi Syncoper,

Here are some more best practices for RESTful APIs.

Use PUT if you want to persist an entity as it is. Use POST from any kind of 
processes.

Hence I would recommend to change:
PUT /connectors/reload

To

POST /connectors/reload

Best regards.
Jan

From: conflue...@apache.org [mailto:conflue...@apache.org]
Sent: Mittwoch, 20. Februar 2013 12:34
To: Jan Bernhardt
Subject: [CONF] Apache Syncope > REST API upgrade

REST API 
upgrade
Page edited by Francesco 
Chicchiricco

Changes (2)
...

| GET /connector/\{connectorId\}/configurationProperty/list | GET 
/connectors/\{connectorId\}/configuration | Returns configuration for selected 
connector. |
| POST /connector/check | POST /connectors/check | Checks if a connection can 
be established. |

| GET /connector/\{resourceName\}/connectorBean 
/connector/\{resourceName\}/readByResource | GET 
/connectors;resourceName=\{connectorId\} | Returns connector for resourceName. |

| PUT /connector/reload | PUT /connectors/reload | Reload all connector bundles 
and instances. |


h2. Entitlement Service

...

Full Content
[https://cwiki.apache.org/confluence/images/icons/emoticons/warning.gif]

Version warning
In Syncope 1.1.0 a new REST interface was introduced (referred as new in the 
following).
The REST interface available in 1.0.X (referred as old in the following) is 
still present but will be removed from releases >= 1.2.0.

This page shall give you an overview of old and new REST API.

  *   Configuration Service
  *   Connector Service
  *   Entitlement Service
  *   Logger Service
  *   Notification Service
  *   Policy Service
  *   Report Service
  *   Resource Service
  *   Role Service
  *   Schema Service
  *   Task Service
  *   User Service
  *   UserRequest Service
  *   Workflow Service
Main focus on redesign REST interface was to apply RESTful Best 
Practices

  *   use HTTP operations instead of URL encoded operation names
  *   GET does not modify any object (read-only safety operation)
  *   PUT and DELETE are idempotent operations
[*]   PUT and DELETE do not return (old) object any longer, except for 
Roles and Users, since they contain propagation status information

  *   CREATE operations return location URL in header for newly created object
[*]   In addition to that unique identifier of resource is also send in 
response header (org.apache.syncope.resource.id)
While redesigning interface, we also made changes to exception 
handling.
Configuration Service
Old URL

New URL

Comment

POST /configuration/create

POST /configurations

Creates a new Configuration.

GET /configuration/read/{key}

GET /configurations/{key}

Returns configuration element with matching key.

GET /configuration/list

GET /configurations

Returns a list of all configuration elements.

POST /configuration/update

PUT /configurations/{key}

Overwrites configuration element with matching key.

GET /configuration/delete/{key}

DELETE /configurations/{key}

Deletes configuration with matching key.

Old URL

New URL

Comment

GET /configuration/validators

GET /configurations/validators

Returns a list of known validators.

GET /configuration/mailTemplates

GET /configurations/mailTemplates

Returns a list of known mail-templates.

GET /configuration/dbexport

GET /configurations/dbDump

Returns configuration as an downloadable content.xml database export file.

Connector Service
Old URL

New URL

Comment

POST /connector/create

POST /connectors

Creates a new connector instance.

GET /connector/read/{connectorId}

GET /connectors/{connectorId}

Returns connector with matching id.

GET /connector/list?lang={lang}

GET /connectors?lang={lang}

Returns a list of all connectors. Default language is English.

POST /connector/update

PUT /connectors/{connectorId}

Overwrites connector with matching key.

GET /connector/delete/{connectorId}

DELETE /connectors/{connectorId}

Deletes connector with matching id.

Old URL

New URL

Comment

GET /connector/bundle/list?lang={lang}

GET /connectors/bundles?lang={lang}

Returns known bundles. Default language is English.

POST /connector/schema/list?showall={showall}

POST /connectors/{connectorId}/schemas?showAll={showall}

Returns schema names for connector. Default is showAll=false.

GET /connector/{connectorId}/configurationProperty/list

GET /connectors/{connectorId}/configuration

Returns configuration for selected connector.

POST /connector/check

POST /connectors/check

Checks if a connection can be established.

GET /connector/{resourceName}/readByResource

GET /connectors;resourceName={connectorId}

Returns connector for resourceName.

PUT /connector/reload

PUT /connectors/reload

Reload all connector bundles and instances.

Entitlement Service
Old URL

Re: [CONF] Apache Syncope > REST API upgrade

[Francesco Chicchiriccò]

On 20/02/2013 15:13, Jan Bernhardt wrote:

Hi Syncoper,

Here are some more best practices for RESTful APIs.

Use PUT if you want to persist an entity as it is. Use POST from any kind of 
processes.

Hence I would recommend to change:
PUT /connectors/reload

To

POST /connectors/reload


Hi Jan, thanks for reporting.

I'll do this right away.

Regards.

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

[jira] [Resolved] (SYNCOPE-293) Show information (version, license, ...)

[JIRA]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò resolved SYNCOPE-293.


Resolution: Fixed

http://svn.apache.org/r1448184

> Show information (version, license, ...)
> 
>
> Key: SYNCOPE-293
> URL: https://issues.apache.org/jira/browse/SYNCOPE-293
> Project: Syncope
>  Issue Type: Improvement
>  Components: console
>Reporter: Massimiliano Perrone
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
> Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, 
> Screenshot from 2013-02-19 15.png, welcomeOnChrome.png, wp.png
>
>
> Currently there is only a static label with core and console versions.
> Add a new Link to open a ModalPage with version and other project information 
> (eg. link to license)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (SYNCOPE-320) Support synchronizing role memberships from LDAP groupOfNames

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh resolved SYNCOPE-320.
-

Resolution: Fixed

> Support synchronizing role memberships from LDAP groupOfNames
> -
>
> Key: SYNCOPE-320
> URL: https://issues.apache.org/jira/browse/SYNCOPE-320
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1.0
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: syncope-320.patch
>
>
> This task is to support synchronizing role memberships from LDAP 
> groupOfNames. As reported in the following mailing list thread, it is not 
> possible to synchronize role memberships from groupOfNames currently (only 
> groupOfUniqueNames):
> http://syncope-dev.1063484.n5.nabble.com/LDAP-Role-queries-td5712875.html
> The solution is to update the LDAPMembershipSyncActions to query the 
> Connector for the configured group member attribute. If none is defined, then 
> just fall back to "uniqueMember".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (SYNCOPE-293) Show information (version, license, ...)

[Colm O hEigeartaigh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SYNCOPE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated SYNCOPE-293:


Attachment: Screenshot from 2013-02-20.png


Sorry to be a PITA, but I'm seeing the above when launching Syncope in embedded 
mode!

Colm.

> Show information (version, license, ...)
> 
>
> Key: SYNCOPE-293
> URL: https://issues.apache.org/jira/browse/SYNCOPE-293
> Project: Syncope
>  Issue Type: Improvement
>  Components: console
>Reporter: Massimiliano Perrone
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
> Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, 
> Screenshot from 2013-02-19 15.png, Screenshot from 2013-02-20.png, 
> welcomeOnChrome.png, wp.png
>
>
> Currently there is only a static label with core and console versions.
> Add a new Link to open a ModalPage with version and other project information 
> (eg. link to license)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SYNCOPE-293) Show information (version, license, ...)

[JIRA]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582243#comment-13582243
 ] 

Francesco Chicchiriccò commented on SYNCOPE-293:


You need to either re-generate your project or alternatively remove 
core/src/main/webapp/version.jsp

> Show information (version, license, ...)
> 
>
> Key: SYNCOPE-293
> URL: https://issues.apache.org/jira/browse/SYNCOPE-293
> Project: Syncope
>  Issue Type: Improvement
>  Components: console
>Reporter: Massimiliano Perrone
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
> Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, 
> Screenshot from 2013-02-19 15.png, Screenshot from 2013-02-20.png, 
> welcomeOnChrome.png, wp.png
>
>
> Currently there is only a static label with core and console versions.
> Add a new Link to open a ModalPage with version and other project information 
> (eg. link to license)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

API query

[Colm O hEigeartaigh]

Hi all,

>From the wiki:

https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#RESTAPIupgrade-UserService

GET /user/verifyPassword/{username}?password={password}  GET
/users?username={username}&pwd={password}  Returns user if username and
password match with an existing account.
This method actually returns a boolean not the user, and so the description
is invalid.

Could someone clarify whether the new API is intended to return a boolean
or the User?

Colm.


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

[jira] [Commented] (SYNCOPE-293) Show information (version, license, ...)

[Colm O hEigeartaigh (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582261#comment-13582261
 ] 

Colm O hEigeartaigh commented on SYNCOPE-293:
-


Yup that works, sorry for the noise.

Colm.

> Show information (version, license, ...)
> 
>
> Key: SYNCOPE-293
> URL: https://issues.apache.org/jira/browse/SYNCOPE-293
> Project: Syncope
>  Issue Type: Improvement
>  Components: console
>Reporter: Massimiliano Perrone
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
> Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, 
> Screenshot from 2013-02-19 15.png, Screenshot from 2013-02-20.png, 
> welcomeOnChrome.png, wp.png
>
>
> Currently there is only a static label with core and console versions.
> Add a new Link to open a ModalPage with version and other project information 
> (eg. link to license)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: API query

[Jan Bernhardt]

Hi Colm,

The description is wrong, this method returns a boolean.

Best regards.
Jan

> -Original Message-
> From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> Sent: Mittwoch, 20. Februar 2013 16:48
> To: dev@syncope.apache.org
> Subject: API query
> 
> Hi all,
> 
> From the wiki:
> 
> https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#
> RESTAPIupgrade-UserService
> 
> GET /user/verifyPassword/{username}?password={password}  GET
> /users?username={username}&pwd={password}  Returns user if username
> and password match with an existing account.
> This method actually returns a boolean not the user, and so the description is
> invalid.
> 
> Could someone clarify whether the new API is intended to return a boolean
> or the User?
> 
> Colm.
> 
> 
> --
> Colm O hEigeartaigh
> 
> Talend Community Coder
> http://coders.talend.com

Re: API query

[Colm O hEigeartaigh]

Thanks Jan, I have updated it. The "old" API method returns "null" if the
User does not exist, whereas the new API does not seem to return anything.
Would it not be better in both cases to return "false" explicitly? Or are
there backwards compatilbity concerns about changing this?

Colm.

On Wed, Feb 20, 2013 at 4:00 PM, Jan Bernhardt wrote:

> Hi Colm,
>
> The description is wrong, this method returns a boolean.
>
> Best regards.
> Jan
>
> > -Original Message-
> > From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
> > Sent: Mittwoch, 20. Februar 2013 16:48
> > To: dev@syncope.apache.org
> > Subject: API query
> >
> > Hi all,
> >
> > From the wiki:
> >
> > https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#
> > RESTAPIupgrade-UserService
> >
> > GET /user/verifyPassword/{username}?password={password}  GET
> > /users?username={username}&pwd={password}  Returns user if username
> > and password match with an existing account.
> > This method actually returns a boolean not the user, and so the
> description is
> > invalid.
> >
> > Could someone clarify whether the new API is intended to return a boolean
> > or the User?
> >
> > Colm.
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: API query

[Colm O hEigeartaigh]

A second thought is that a API to return the User matching the given
username + password would be quite nice, unless there is another way of
doing this that I am missing. WDYT?

Colm.

On Wed, Feb 20, 2013 at 4:04 PM, Colm O hEigeartaigh wrote:

>
> Thanks Jan, I have updated it. The "old" API method returns "null" if the
> User does not exist, whereas the new API does not seem to return anything.
> Would it not be better in both cases to return "false" explicitly? Or are
> there backwards compatilbity concerns about changing this?
>
> Colm.
>
>
> On Wed, Feb 20, 2013 at 4:00 PM, Jan Bernhardt wrote:
>
>> Hi Colm,
>>
>> The description is wrong, this method returns a boolean.
>>
>> Best regards.
>> Jan
>>
>> > -Original Message-
>> > From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
>> > Sent: Mittwoch, 20. Februar 2013 16:48
>> > To: dev@syncope.apache.org
>> > Subject: API query
>> >
>> > Hi all,
>> >
>> > From the wiki:
>> >
>> > https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#
>> > RESTAPIupgrade-UserService
>> >
>> > GET /user/verifyPassword/{username}?password={password}  GET
>> > /users?username={username}&pwd={password}  Returns user if username
>> > and password match with an existing account.
>> > This method actually returns a boolean not the user, and so the
>> description is
>> > invalid.
>> >
>> > Could someone clarify whether the new API is intended to return a
>> boolean
>> > or the User?
>> >
>> > Colm.
>> >
>> >
>> > --
>> > Colm O hEigeartaigh
>> >
>> > Talend Community Coder
>> > http://coders.talend.com
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: API query

[Sergey Beryozkin]

I wonder if

"GET /users?username={username}&pwd={password}"

is safe enough, as these URIs might get cached somewhere given it is GET 
(though not sure if the caching of URIs can happen with HTTPS).


Might make sense considering treating this as an action request, with 
the credentials being POSTed to /users resource and expecting a 
validated user rep back,


Cheers, Sergey



On 20/02/13 16:06, Colm O hEigeartaigh wrote:

A second thought is that a API to return the User matching the given
username + password would be quite nice, unless there is another way of
doing this that I am missing. WDYT?

Colm.

On Wed, Feb 20, 2013 at 4:04 PM, Colm O hEigeartaighwrote:



Thanks Jan, I have updated it. The "old" API method returns "null" if the
User does not exist, whereas the new API does not seem to return anything.
Would it not be better in both cases to return "false" explicitly? Or are
there backwards compatilbity concerns about changing this?

Colm.


On Wed, Feb 20, 2013 at 4:00 PM, Jan Bernhardtwrote:


Hi Colm,

The description is wrong, this method returns a boolean.

Best regards.
Jan


-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: Mittwoch, 20. Februar 2013 16:48
To: dev@syncope.apache.org
Subject: API query

Hi all,

 From the wiki:

https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#
RESTAPIupgrade-UserService

GET /user/verifyPassword/{username}?password={password}  GET
/users?username={username}&pwd={password}  Returns user if username
and password match with an existing account.
This method actually returns a boolean not the user, and so the

description is

invalid.

Could someone clarify whether the new API is intended to return a

boolean

or the User?

Colm.


--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com






--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com








--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Re: [CONF] Apache Syncope > REST API upgrade

[Francesco Chicchiriccò]

On 20/02/2013 15:15, Francesco Chicchiriccò wrote:

On 20/02/2013 15:13, Jan Bernhardt wrote:

Hi Syncoper,

Here are some more best practices for RESTful APIs.

Use PUT if you want to persist an entity as it is. Use POST from any 
kind of processes.


Hence I would recommend to change:
PUT /connectors/reload

To

POST /connectors/reload


Hi Jan, thanks for reporting.

I'll do this right away.


Done.

Regards.

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

[jira] [Commented] (SYNCOPE-319) Provide feature for reloading all connectors

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582437#comment-13582437
 ] 

Hudson commented on SYNCOPE-319:


Integrated in Syncope-trunk #103 (See 
[https://builds.apache.org/job/Syncope-trunk/103/])
[SYNCOPE-319][SYNCOPE-209] Turning PUT into POST for 
ConnectorService#reload, as per Jan suggestion (Revision 1448310)

 Result = FAILURE
ilgrosso : 
Files : 
* 
/syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/ConnectorServiceProxy.java
* 
/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/ConnectorService.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/ConnInstanceController.java


> Provide feature for reloading all connectors
> 
>
> Key: SYNCOPE-319
> URL: https://issues.apache.org/jira/browse/SYNCOPE-319
> Project: Syncope
>  Issue Type: Improvement
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
>
> It is a feature particularly useful during project deployment that will allow 
> to refresh all connector bundles and configuration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SYNCOPE-320) Support synchronizing role memberships from LDAP groupOfNames

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582440#comment-13582440
 ] 

Hudson commented on SYNCOPE-320:


Integrated in Syncope-trunk #103 (See 
[https://builds.apache.org/job/Syncope-trunk/103/])
[SYNCOPE-320] - Support synchronizing role memberships from LDAP 
groupOfNames
 - Patch applied with some feedback from Francesco (Revision 1448195)

 Result = FAILURE
coheigea : 
Files : 
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/sync/impl/LDAPMembershipSyncActions.java


> Support synchronizing role memberships from LDAP groupOfNames
> -
>
> Key: SYNCOPE-320
> URL: https://issues.apache.org/jira/browse/SYNCOPE-320
> Project: Syncope
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.1.0
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 1.1.0
>
> Attachments: syncope-320.patch
>
>
> This task is to support synchronizing role memberships from LDAP 
> groupOfNames. As reported in the following mailing list thread, it is not 
> possible to synchronize role memberships from groupOfNames currently (only 
> groupOfUniqueNames):
> http://syncope-dev.1063484.n5.nabble.com/LDAP-Role-queries-td5712875.html
> The solution is to update the LDAPMembershipSyncActions to query the 
> Connector for the configured group member attribute. If none is defined, then 
> just fall back to "uniqueMember".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SYNCOPE-310) Palette elements get translated

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582439#comment-13582439
 ] 

Hudson commented on SYNCOPE-310:


Integrated in Syncope-trunk #103 (See 
[https://builds.apache.org/job/Syncope-trunk/103/])
Upgrading to Wicket 6.6.0, reverting the fix for SYNCOPE-310 (Revision 
1448225)

 Result = FAILURE
ilgrosso : 
Files : 
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/wicket/markup/html/form/NonI18nPalette.java
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/wicket/markup/html/form/NonI18nPalette.html
* /syncope/trunk/pom.xml


> Palette elements get translated
> ---
>
> Key: SYNCOPE-310
> URL: https://issues.apache.org/jira/browse/SYNCOPE-310
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Affects Versions: 1.0.5, 1.1.0
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.0.6, 1.1.0
>
>
> Options shown in Wicket's palette are treated as label and searched for 
> available translations.
> For example, the 'title' role schema is rendered as "Policy Management" (i.e. 
> the modal window title) when managing synchronization policies.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SYNCOPE-293) Show information (version, license, ...)

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582438#comment-13582438
 ] 

Hudson commented on SYNCOPE-293:


Integrated in Syncope-trunk #103 (See 
[https://builds.apache.org/job/Syncope-trunk/103/])
[SYNCOPE-293] Consolidating version + minor restyling info window (Revision 
1448184)

 Result = FAILURE
ilgrosso : 
Files : 
* /syncope/trunk/archetype/pom.xml
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/SyncopeApplication.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/SyncopeSession.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/BasePage.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/InfoModalPage.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/Login.java
* 
/syncope/trunk/console/src/main/java/org/apache/syncope/console/pages/WelcomePage.java
* /syncope/trunk/console/src/main/resources/applicationContext.xml
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/InfoModalPage.html
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/InfoModalPage.properties
* 
/syncope/trunk/console/src/main/resources/org/apache/syncope/console/pages/InfoModalPage_it.properties


> Show information (version, license, ...)
> 
>
> Key: SYNCOPE-293
> URL: https://issues.apache.org/jira/browse/SYNCOPE-293
> Project: Syncope
>  Issue Type: Improvement
>  Components: console
>Reporter: Massimiliano Perrone
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
> Attachments: bp.png, infoModalOnChrome.png, infoModalOnFirefox.png, 
> Screenshot from 2013-02-19 15.png, Screenshot from 2013-02-20.png, 
> welcomeOnChrome.png, wp.png
>
>
> Currently there is only a static label with core and console versions.
> Add a new Link to open a ModalPage with version and other project information 
> (eg. link to license)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (SYNCOPE-209) DB Table connector does not see changes in underlying table until restart

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SYNCOPE-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582441#comment-13582441
 ] 

Hudson commented on SYNCOPE-209:


Integrated in Syncope-trunk #103 (See 
[https://builds.apache.org/job/Syncope-trunk/103/])
[SYNCOPE-319][SYNCOPE-209] Turning PUT into POST for 
ConnectorService#reload, as per Jan suggestion (Revision 1448310)

 Result = FAILURE
ilgrosso : 
Files : 
* 
/syncope/trunk/client/src/main/java/org/apache/syncope/client/services/proxy/ConnectorServiceProxy.java
* 
/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/ConnectorService.java
* 
/syncope/trunk/core/src/main/java/org/apache/syncope/core/rest/controller/ConnInstanceController.java


> DB Table connector does not see changes in underlying table until restart
> -
>
> Key: SYNCOPE-209
> URL: https://issues.apache.org/jira/browse/SYNCOPE-209
> Project: Syncope
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.0.1-incubating
>Reporter: Francesco Chicchiriccò
>Assignee: Francesco Chicchiriccò
> Fix For: 1.1.0
>
>
> Steps to reproduce:
> 1. generate a project from 1.0.2-incubating-SNAPSHOT or 
> 1.1.0-incubating-SNAPSHOT archetypes (both tested)
> 2. mvn clean package
> 3. cd console && mvn -P embedded
> 1. log in http://localhost:9080/syncope-console/
> 2, go to resources -> resource-testdb -> mapping
> 1. go to http://localhost:9082
> 2. select "Generic H2 (Server)"
> 3. set JDBC URL to "jdbc:h2:tcp://localhost:9092/testdb"
> 4. set username 'sa' and password 'sa'
> 5. connect
> 6. send SQL statement 'ALTER TABLE TEST ADD COLUMN newcol VARCHAR(255)'
> 1. log in http://localhost:9080/syncope-console/
> 2, go to resources -> resource-testdb -> mapping
> At this point, when trying to add a new schema mapping, 'newcol' is not shown 
> among available values until restart

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Syncope-trunk - Build # 103 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Syncope-trunk (build #103)

Status: Still Failing

Check console output at https://builds.apache.org/job/Syncope-trunk/103/ to 
view the results.