date:20170628


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

fabio martelli reassigned SYNCOPE-1135:
---

Assignee: fabio martelli  (was: Andrea Patricelli)

> Groups list not refreshing after realm change
> -
>
> Key: SYNCOPE-1135
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1135
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Affects Versions: 2.0.3
>Reporter: Andrea Patricelli
>Assignee: fabio martelli
> Fix For: 2.0.4, 2.1.0
>
>
> # Login  on Syncope Admin Console
> # Go to Realms -> USER and edit or create an user
> # Select a child realm that has groups (not present in the current base 
> realm, e.g. /). If on embedded environment select /even realm.
> # Groups list will not update according to realm change (on emebedded 
> environment for example additional group is not shown). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SYNCOPE-1135) Groups list not refreshing after realm change


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

Andrea Patricelli reassigned SYNCOPE-1135:
--

Assignee: Andrea Patricelli

> Groups list not refreshing after realm change
> -
>
> Key: SYNCOPE-1135
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1135
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Affects Versions: 2.0.3
>Reporter: Andrea Patricelli
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> # Login  on Syncope Admin Console
> # Go to Realms -> USER and edit or create an user
> # Select a child realm that has groups (not present in the current base 
> realm, e.g. /). If on embedded environment select /even realm.
> # Groups list will not update according to realm change (on emebedded 
> environment for example additional group is not shown). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1110) Error replacing group/auxclass/resource during self-management operation

2017-06-28 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on SYNCOPE-1110:
-

Github user andrea-patricelli commented on the issue:

https://github.com/apache/syncope/pull/47
  
@mat-ale we have almost finished. Please put a check to call  
completeUserObject only if cuastomForm is not null and not empty and add user 
virtual attributes management in  completeUserObject.   


> Error replacing group/auxclass/resource during self-management operation
> 
>
> Key: SYNCOPE-1110
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1110
> Project: Syncope
>  Issue Type: Bug
>  Components: enduser
>Affects Versions: 2.0.3
>Reporter: fabio martelli
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> Steps to reproduce:
> # perform a self registration by specifying 2 groups, 2 aux classes and 2 
> resources
> # submit and perform an approval with admin user
> # perform a self management by replacing one group/auxclass/resource with 
> another one
> # submbit and perform an approval with admin user
> # check the expected result into the administration console 
> Groups, auxclasses and resources assigned to the approved user will be three 
> instead of two.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] syncope issue #47: Fixes [SYNCOPE-1110], [SYNCOPE-1123]

2017-06-28 Thread andrea-patricelli

Github user andrea-patricelli commented on the issue:

https://github.com/apache/syncope/pull/47
  
@mat-ale we have almost finished. Please put a check to call  
completeUserObject only if cuastomForm is not null and not empty and add user 
virtual attributes management in  completeUserObject.   


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (SYNCOPE-1127) Membership attribute values are not shown


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

Andrea Patricelli commented on SYNCOPE-1127:


Commit 194385d3c0fc054c0a090f6afc9b66ac3540609e in syncope's branch 
refs/heads/2_0_X from Andrea Patricelli
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=194385d ]
SYNCOPE-1125 fixed not visible memebership attribute values

> Membership attribute values are not shown
> -
>
> Key: SYNCOPE-1127
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1127
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Affects Versions: 2.0.3
>Reporter: Andrea Patricelli
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> Login on Syncope console and create (or edit) an user and assign to him a 
> group that has type extensions. You should see a new accordion in plain 
> attributes tab named with the name of the group. Then edit values of the 
> attributes in that accordion and save. Re-edit the user and you'll see that 
> values are not shown in the form.
> But reading user through http://localhost:9080/syncope/rest/users/[username] 
> memberships plain attrs have values. The problem is related only to view.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1127) Membership attribute values are not shown


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

Andrea Patricelli commented on SYNCOPE-1127:


Commit b4713c15f9ea28bb108ee2e82d986a8011586c43 in syncope's branch 
refs/heads/master from Andrea Patricelli
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=b4713c1 ]
SYNCOPE-1125 fixed not visible memebership attribute values

> Membership attribute values are not shown
> -
>
> Key: SYNCOPE-1127
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1127
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Affects Versions: 2.0.3
>Reporter: Andrea Patricelli
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> Login on Syncope console and create (or edit) an user and assign to him a 
> group that has type extensions. You should see a new accordion in plain 
> attributes tab named with the name of the group. Then edit values of the 
> attributes in that accordion and save. Re-edit the user and you'll see that 
> values are not shown in the form.
> But reading user through http://localhost:9080/syncope/rest/users/[username] 
> memberships plain attrs have values. The problem is related only to view.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (SYNCOPE-1110) Error replacing group/auxclass/resource during self-management operation

2017-06-28 Thread ASF subversion and git services (JIRA)


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

Andrea Patricelli reopened SYNCOPE-1110:


> Error replacing group/auxclass/resource during self-management operation
> 
>
> Key: SYNCOPE-1110
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1110
> Project: Syncope
>  Issue Type: Bug
>  Components: enduser
>Affects Versions: 2.0.3
>Reporter: fabio martelli
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> Steps to reproduce:
> # perform a self registration by specifying 2 groups, 2 aux classes and 2 
> resources
> # submit and perform an approval with admin user
> # perform a self management by replacing one group/auxclass/resource with 
> another one
> # submbit and perform an approval with admin user
> # check the expected result into the administration console 
> Groups, auxclasses and resources assigned to the approved user will be three 
> instead of two.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1125) Password on external resource not updated via Enduser


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

ASF subversion and git services commented on SYNCOPE-1125:
--

Commit b4713c15f9ea28bb108ee2e82d986a8011586c43 in syncope's branch 
refs/heads/master from [~andrea.patricelli]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=b4713c1 ]

[SYNCOPE-1125] fixed not visible memebership attribute values


> Password on external resource not updated via Enduser
> -
>
> Key: SYNCOPE-1125
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1125
> Project: Syncope
>  Issue Type: Bug
>  Components: enduser
>Affects Versions: 2.0.3
>Reporter: Francesco Chicchiriccò
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> As [reported in mailing 
> list|https://lists.apache.org/thread.html/b0d3c5f584f107065b988400f4865f7b9e4bb951ae201da9fd99e908@%3Cuser.syncope.apache.org%3E],
>  the issue can be replicated with standalone distribution / embedded mode:
> # from Admin Console, create user {{ilgro...@apache.org}}, set 
> {{Password123}} as password value and assign `resource-ldap`
> # user is successfully created and propagated
> # binding via LDAP works fine with the password set above:
>  {code}
> ldapsearch -h localhost -p 1389 -D "uid=ilgro...@apache.org,ou=People,o=isp" 
> -x -w Password123 -b "uid=ilgro...@apache.org,ou=People,o=isp"
>  {code}
> # from Admin Console, update the user above by setting the password to 
> {{Password124}}
> # binding via LDAP works fine with updated password:
>  {code}
> ldapsearch -h localhost -p 1389 -D "uid=ilgro...@apache.org,ou=People,o=isp" 
> -x -w Password124 -b "uid=ilgro...@apache.org,ou=People,o=isp"
>  {code}
> # from Enduser UI, login as {{ilgro...@apache.org}} / {{Password124}} and set 
> the password to {{Password125}}
> At this point:
> * {{Password125}} is set on Syncope
> * {{Password124}} is still set on LDAP
> * a {{DELETE}} propagation task was created as consequence of Enduser UI 
> password change



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1125) Password on external resource not updated via Enduser

2017-06-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SYNCOPE-1125:
--

Commit 194385d3c0fc054c0a090f6afc9b66ac3540609e in syncope's branch 
refs/heads/2_0_X from [~andrea.patricelli]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=194385d ]

[SYNCOPE-1125] fixed not visible memebership attribute values


> Password on external resource not updated via Enduser
> -
>
> Key: SYNCOPE-1125
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1125
> Project: Syncope
>  Issue Type: Bug
>  Components: enduser
>Affects Versions: 2.0.3
>Reporter: Francesco Chicchiriccò
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> As [reported in mailing 
> list|https://lists.apache.org/thread.html/b0d3c5f584f107065b988400f4865f7b9e4bb951ae201da9fd99e908@%3Cuser.syncope.apache.org%3E],
>  the issue can be replicated with standalone distribution / embedded mode:
> # from Admin Console, create user {{ilgro...@apache.org}}, set 
> {{Password123}} as password value and assign `resource-ldap`
> # user is successfully created and propagated
> # binding via LDAP works fine with the password set above:
>  {code}
> ldapsearch -h localhost -p 1389 -D "uid=ilgro...@apache.org,ou=People,o=isp" 
> -x -w Password123 -b "uid=ilgro...@apache.org,ou=People,o=isp"
>  {code}
> # from Admin Console, update the user above by setting the password to 
> {{Password124}}
> # binding via LDAP works fine with updated password:
>  {code}
> ldapsearch -h localhost -p 1389 -D "uid=ilgro...@apache.org,ou=People,o=isp" 
> -x -w Password124 -b "uid=ilgro...@apache.org,ou=People,o=isp"
>  {code}
> # from Enduser UI, login as {{ilgro...@apache.org}} / {{Password124}} and set 
> the password to {{Password125}}
> At this point:
> * {{Password125}} is set on Syncope
> * {{Password124}} is still set on LDAP
> * a {{DELETE}} propagation task was created as consequence of Enduser UI 
> password change



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Installer error


On 28/06/2017 16:33, Colm O hEigeartaigh wrote:

Thanks! Some of the warnings relate to the fact that there are duplicate
"syncope-core-workflow-activiti" dependencies if you select Activiti. In
the archetype, the "syncope-core-workflow-activiti" is added as part of the
"all" profile already, and then the installer adds in another one if
activiti is selected. I guess the installer can skip adding this dependency?


By default, Activiti stuff is in the all profile, as generated by the 
archetype; when enabled via GUI, the installer adds the same elements in 
the main profile, thus generating the duplication warning.


In order to avoid that, I think we should remove Activiti from the all 
profile.


Regards.


On Wed, Jun 28, 2017 at 10:13 AM, Francesco Chicchiriccò  
wrote:


Hi Colm,
the problems with installer (actually, with archetype) on master are now
fixed by

http://git-wip-us.apache.org/repos/asf/syncope/commit/750247e6

Regarding the warning messages produced by Maven, feel free to fix :-)

Regards.

On 23/06/2017 15:32, Colm O hEigeartaigh wrote:


It works fine on 2.0.x but the pom there still looks a bit dodgy after the
installer is done with it. The plugin appears twice under build/plugins
and
also under profiles.

Colm.

On Fri, Jun 23, 2017 at 2:29 PM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:

Colm O hEigeartaigh  wrote:

Hi all,

I'm seeing an error with the installer on master, where I'm ending up
with an invalid console pom.xml, as it's copying an extra
"setupActivitiModeler" plugin. The code in the installer manually adds this
plugin in
ArchetypeProcess. Has something changed so that it no longer needs to do
this?


Hi,
I've recently changed the Activiti Modeler setup in 2_0_X, so probably
there was some problem when cherry-picking to master.

I'll take a look.
Regards.


--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

Re: Installer error

2017-06-28 Thread Colm O hEigeartaigh

Thanks! Some of the warnings relate to the fact that there are duplicate
"syncope-core-workflow-activiti" dependencies if you select Activiti. In
the archetype, the "syncope-core-workflow-activiti" is added as part of the
"all" profile already, and then the installer adds in another one if
activiti is selected. I guess the installer can skip adding this dependency?

Colm.

On Wed, Jun 28, 2017 at 10:13 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:

> Hi Colm,
> the problems with installer (actually, with archetype) on master are now
> fixed by
>
> http://git-wip-us.apache.org/repos/asf/syncope/commit/750247e6
>
> Regarding the warning messages produced by Maven, feel free to fix :-)
>
> Regards.
>
> On 23/06/2017 15:32, Colm O hEigeartaigh wrote:
>
>> It works fine on 2.0.x but the pom there still looks a bit dodgy after the
>> installer is done with it. The plugin appears twice under build/plugins
>> and
>> also under profiles.
>>
>> Colm.
>>
>> On Fri, Jun 23, 2017 at 2:29 PM, Francesco Chicchiriccò <
>> ilgro...@apache.org> wrote:
>>
>> Colm O hEigeartaigh  wrote:
>>>
>>> Hi all,

 I'm seeing an error with the installer on master, where I'm ending up
 with an invalid console pom.xml, as it's copying an extra
 "setupActivitiModeler" plugin. The code in the installer manually adds this
 plugin in
 ArchetypeProcess. Has something changed so that it no longer needs to do
 this?

>>> Hi,
>>> I've recently changed the Activiti Modeler setup in 2_0_X, so probably
>>> there was some problem when cherry-picking to master.
>>>
>>> I'll take a look.
>>> Regards.
>>>
>>
> --
> Francesco Chicchiriccò
>
> Tirasa - Open Source Excellence
> http://www.tirasa.net/
>
>
> Member at The Apache Software Foundation
> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
> http://home.apache.org/~ilgrosso/
>
>

-- 
Colm O hEigeartaigh

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

[jira] [Resolved] (SYNCOPE-1129) Third Party JWT SSO integration

2017-06-28 Thread ASF subversion and git services (JIRA)


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

Francesco Chicchiriccò resolved SYNCOPE-1129.
-
Resolution: Fixed

> Third Party JWT SSO integration
> ---
>
> Key: SYNCOPE-1129
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1129
> Project: Syncope
>  Issue Type: New Feature
>  Components: core
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.4, 2.1.0
>
>
> This task is to support SSO using third party JWT tokens.
> It involves two tasks:
> a) Create a new interface extending JwsSignatureVerifier to provide a method 
> to resolve a JWT subject into Syncope username (known user).
> b) When processing a received token, if the issuer is different from the 
> known issuer ("jwtIssuer" in security.properties), then instead of retrieving 
> the default jwsSignatureVerifier implementation, the authentication component 
> will enable the ClassPathScanImplementationLookup to dynamically discover an 
> implementation of the interface above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1129) Third Party JWT SSO integration


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

ASF subversion and git services commented on SYNCOPE-1129:
--

Commit 94708a3eed564f6bc33953075d7ac423a4ec167d in syncope's branch 
refs/heads/master from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=94708a3 ]

[SYNCOPE-1129] New interface JWTSSOProvider with default impl 
SyncopeJWTSSOProvider + docs


> Third Party JWT SSO integration
> ---
>
> Key: SYNCOPE-1129
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1129
> Project: Syncope
>  Issue Type: New Feature
>  Components: core
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.4, 2.1.0
>
>
> This task is to support SSO using third party JWT tokens.
> It involves two tasks:
> a) Create a new interface extending JwsSignatureVerifier to provide a method 
> to resolve a JWT subject into Syncope username (known user).
> b) When processing a received token, if the issuer is different from the 
> known issuer ("jwtIssuer" in security.properties), then instead of retrieving 
> the default jwsSignatureVerifier implementation, the authentication component 
> will enable the ClassPathScanImplementationLookup to dynamically discover an 
> implementation of the interface above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1129) Third Party JWT SSO integration

2017-06-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SYNCOPE-1129:
--

Commit 5a7010bb378ea236038fd91578fcdafe017cf551 in syncope's branch 
refs/heads/2_0_X from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=5a7010b ]

[SYNCOPE-1129] New interface JWTSSOProvider with default impl 
SyncopeJWTSSOProvider + docs


> Third Party JWT SSO integration
> ---
>
> Key: SYNCOPE-1129
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1129
> Project: Syncope
>  Issue Type: New Feature
>  Components: core
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.4, 2.1.0
>
>
> This task is to support SSO using third party JWT tokens.
> It involves two tasks:
> a) Create a new interface extending JwsSignatureVerifier to provide a method 
> to resolve a JWT subject into Syncope username (known user).
> b) When processing a received token, if the issuer is different from the 
> known issuer ("jwtIssuer" in security.properties), then instead of retrieving 
> the default jwsSignatureVerifier implementation, the authentication component 
> will enable the ClassPathScanImplementationLookup to dynamically discover an 
> implementation of the interface above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1133) Search panel used for relationships definition does not work

2017-06-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SYNCOPE-1133:
--

Commit f6e9fa3a59c1d0e1763bc297b312d519bf41c1b4 in syncope's branch 
refs/heads/2_0_X from [~fmartelli]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=f6e9fa3 ]

[SYNCOPE-1133] fixes the issue + provides refactoring


> Search panel used for relationships definition does not work
> 
>
> Key: SYNCOPE-1133
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1133
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Affects Versions: 2.0.3
>Reporter: fabio martelli
>Assignee: fabio martelli
> Fix For: 2.0.4, 2.1.0
>
>
> Search panel used for relationships definition does not work: search result 
> panel seems to be disabled and not visible.
> Steps to reproduce:
> # edit an anyobject
> # move to to the step to specify relationships
> # select the relationship type
> # select the object type
> # add a search clause you know returning one or more results and click the 
> lens
> ... Result table is not shown



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1133) Search panel used for relationships definition does not work

2017-06-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SYNCOPE-1133:
--

Commit 653afac686cc10a13bdd191b807b8f90e0b84e25 in syncope's branch 
refs/heads/master from [~fmartelli]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=653afac ]

[SYNCOPE-1133] fixes the issue + provides refactoring


> Search panel used for relationships definition does not work
> 
>
> Key: SYNCOPE-1133
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1133
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Affects Versions: 2.0.3
>Reporter: fabio martelli
>Assignee: fabio martelli
> Fix For: 2.0.4, 2.1.0
>
>
> Search panel used for relationships definition does not work: search result 
> panel seems to be disabled and not visible.
> Steps to reproduce:
> # edit an anyobject
> # move to to the step to specify relationships
> # select the relationship type
> # select the object type
> # add a search clause you know returning one or more results and click the 
> lens
> ... Result table is not shown



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SYNCOPE-1136) Groups list reset always after realm change

Andrea Patricelli created SYNCOPE-1136:
--

 Summary: Groups list reset always after realm change
 Key: SYNCOPE-1136
 URL: https://issues.apache.org/jira/browse/SYNCOPE-1136
 Project: Syncope
  Issue Type: Bug
  Components: enduser
Affects Versions: 2.0.3
Reporter: Andrea Patricelli
 Fix For: 2.0.4, 2.1.0


# Login on Syncope Enduser Console in self-edit an user assigned to a group 
(puccini for example if on embedded env).
# Go to groups tab and change realm (if on embedded from / to /even). All 
existing groups will disappear. This should not happen if group is alsdo 
visible from child realms. Reset groups otherwise



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SYNCOPE-1135) Groups list not refreshing after realm change


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

Andrea Patricelli updated SYNCOPE-1135:
---
Summary: Groups list not refreshing after realm change  (was: Groups page 
not refreshing after realm change)

> Groups list not refreshing after realm change
> -
>
> Key: SYNCOPE-1135
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1135
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Affects Versions: 2.0.3
>Reporter: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> # Login  on Syncope Admin Console
> # Go to Realms -> USER and edit or create an user
> # Select a child realm that has groups (not present in the current base 
> realm, e.g. /). If on embedded environment select /even realm.
> # Groups list will not update according to realm change (on emebedded 
> environment for example additional group is not shown). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SYNCOPE-1135) Groups page not refreshing after realm change

Andrea Patricelli created SYNCOPE-1135:
--

 Summary: Groups page not refreshing after realm change
 Key: SYNCOPE-1135
 URL: https://issues.apache.org/jira/browse/SYNCOPE-1135
 Project: Syncope
  Issue Type: Bug
  Components: console
Affects Versions: 2.0.3
Reporter: Andrea Patricelli
 Fix For: 2.0.4, 2.1.0


# Login  on Syncope Admin Console
# Go to Realms -> USER and edit or create an user
# Select a child realm that has groups (not present in the current base realm, 
e.g. /). If on embedded environment select /even realm.
# Groups list will not update according to realm change (on emebedded 
environment for example additional group is not shown). 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SYNCOPE-1134) Action menu not working after page refresh

Andrea Patricelli created SYNCOPE-1134:
--

 Summary: Action menu not working after page refresh
 Key: SYNCOPE-1134
 URL: https://issues.apache.org/jira/browse/SYNCOPE-1134
 Project: Syncope
  Issue Type: Bug
  Components: console
Affects Versions: 2.0.3
Reporter: Andrea Patricelli
Priority: Minor
 Fix For: 2.0.4, 2.1.0


# Login on Syncope Admin Console
# Go to Realms -> USER page and click on some user
# An action menu will be shown on the right
# Refresh the page with CTRL+R or CTRL+SHIFT+R or refresh button.
# Click again on some user -> action menu will NOT appear and you need to 
change page in order to let it wotk again.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (SYNCOPE-1132) Extraneous "dots" appearing in the Console when assigning relationships


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

Francesco Chicchiriccò closed SYNCOPE-1132.
---

> Extraneous "dots" appearing in the Console when assigning relationships
> ---
>
> Key: SYNCOPE-1132
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1132
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Reporter: Colm O hEigeartaigh
>Assignee: fabio martelli
>Priority: Trivial
> Attachments: occurredprop.png, syncope-dots.png
>
>
> There appears to be a regression with the latest 2.0.4 + 2.1.0 code (I 
> confirmed it is not present in 2.0.3) where extra "dots" are appearing in the 
> screen. I can reproduce by assigning a relationship to an AnyObject for 
> example in the console. See attached screenshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SYNCOPE-1132) Extraneous "dots" appearing in the Console when assigning relationships


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

Francesco Chicchiriccò updated SYNCOPE-1132:

Fix Version/s: (was: 2.0.4)
   (was: 2.1.0)

> Extraneous "dots" appearing in the Console when assigning relationships
> ---
>
> Key: SYNCOPE-1132
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1132
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Reporter: Colm O hEigeartaigh
>Assignee: fabio martelli
>Priority: Trivial
> Attachments: occurredprop.png, syncope-dots.png
>
>
> There appears to be a regression with the latest 2.0.4 + 2.1.0 code (I 
> confirmed it is not present in 2.0.3) where extra "dots" are appearing in the 
> screen. I can reproduce by assigning a relationship to an AnyObject for 
> example in the console. See attached screenshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SYNCOPE-1132) Extraneous "dots" appearing in the Console when assigning relationships

2017-06-28 Thread Colm O hEigeartaigh (JIRA)


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

Colm O hEigeartaigh resolved SYNCOPE-1132.
--
Resolution: Not A Problem

Thanks Fabio, I guess it was a cache issue, I can't reproduce it when I try 
again.

> Extraneous "dots" appearing in the Console when assigning relationships
> ---
>
> Key: SYNCOPE-1132
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1132
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Reporter: Colm O hEigeartaigh
>Assignee: fabio martelli
>Priority: Trivial
> Fix For: 2.0.4, 2.1.0
>
> Attachments: occurredprop.png, syncope-dots.png
>
>
> There appears to be a regression with the latest 2.0.4 + 2.1.0 code (I 
> confirmed it is not present in 2.0.3) where extra "dots" are appearing in the 
> screen. I can reproduce by assigning a relationship to an AnyObject for 
> example in the console. See attached screenshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SYNCOPE-1129) Third Party JWT SSO integration


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

Francesco Chicchiriccò updated SYNCOPE-1129:

Fix Version/s: 2.1.0

> Third Party JWT SSO integration
> ---
>
> Key: SYNCOPE-1129
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1129
> Project: Syncope
>  Issue Type: New Feature
>  Components: core
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.4, 2.1.0
>
>
> This task is to support SSO using third party JWT tokens.
> It involves two tasks:
> a) Create a new interface extending JwsSignatureVerifier to provide a method 
> to resolve a JWT subject into Syncope username (known user).
> b) When processing a received token, if the issuer is different from the 
> known issuer ("jwtIssuer" in security.properties), then instead of retrieving 
> the default jwsSignatureVerifier implementation, the authentication component 
> will enable the ClassPathScanImplementationLookup to dynamically discover an 
> implementation of the interface above.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SYNCOPE-1118) Update docs to explain what "anonymousKey" refers to

2017-06-28 Thread ASF subversion and git services (JIRA)


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

Francesco Chicchiriccò resolved SYNCOPE-1118.
-
Resolution: Fixed

Authorization Summary provided in the Reference Guide: 
https://ci.apache.org/projects/syncope/reference-guide.html#authorization-summary

> Update docs to explain what "anonymousKey" refers to
> 
>
> Key: SYNCOPE-1118
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1118
> Project: Syncope
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.4, 2.1.0
>
>
> In the getting-started guide, "anonymousKey" is defined as:
> "Provide any pseudo-random string here that will be used as an authentication 
> key for anonymous requests".
> However, anonymous requests are not referenced again in the getting started 
> guide or in the reference guide. We should add something (I guess to the 
> latter) to explain what anonymous requests are.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1118) Update docs to explain what "anonymousKey" refers to


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

ASF subversion and git services commented on SYNCOPE-1118:
--

Commit e4fb3d581c97b5758a16cf0c1d2df4f9ccaba0c5 in syncope's branch 
refs/heads/2_0_X from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=e4fb3d5 ]

[SYNCOPE-1118] Authorization summary provided


> Update docs to explain what "anonymousKey" refers to
> 
>
> Key: SYNCOPE-1118
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1118
> Project: Syncope
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.4, 2.1.0
>
>
> In the getting-started guide, "anonymousKey" is defined as:
> "Provide any pseudo-random string here that will be used as an authentication 
> key for anonymous requests".
> However, anonymous requests are not referenced again in the getting started 
> guide or in the reference guide. We should add something (I guess to the 
> latter) to explain what anonymous requests are.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1118) Update docs to explain what "anonymousKey" refers to

2017-06-28 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SYNCOPE-1118:
--

Commit 733b97203924daacc9c4e07b6caeddb9e85ddb97 in syncope's branch 
refs/heads/master from [~ilgrosso]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=733b972 ]

[SYNCOPE-1118] Authorization summary provided


> Update docs to explain what "anonymousKey" refers to
> 
>
> Key: SYNCOPE-1118
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1118
> Project: Syncope
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.4, 2.1.0
>
>
> In the getting-started guide, "anonymousKey" is defined as:
> "Provide any pseudo-random string here that will be used as an authentication 
> key for anonymous requests".
> However, anonymous requests are not referenced again in the getting started 
> guide or in the reference guide. We should add something (I guess to the 
> latter) to explain what anonymous requests are.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (SYNCOPE-1127) Membership attribute values are not shown


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

Andrea Patricelli reassigned SYNCOPE-1127:
--

Assignee: Andrea Patricelli

> Membership attribute values are not shown
> -
>
> Key: SYNCOPE-1127
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1127
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Affects Versions: 2.0.3
>Reporter: Andrea Patricelli
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> Login on Syncope console and create (or edit) an user and assign to him a 
> group that has type extensions. You should see a new accordion in plain 
> attributes tab named with the name of the group. Then edit values of the 
> attributes in that accordion and save. Re-edit the user and you'll see that 
> values are not shown in the form.
> But reading user through http://localhost:9080/syncope/rest/users/[username] 
> memberships plain attrs have values. The problem is related only to view.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: AnyObjects query

2017-06-28 Thread Sergey Beryozkin

Hi Francesco

One thing I can point to is this code:

https://github.com/apache/cxf/blob/master/rt/rs/extensions/search/src/main/java/org/apache/cxf/jaxrs/ext/search/jpa/AbstractJPATypedQueryVisitor.java#L167

There, in the end,

https://github.com/apache/cxf/blob/master/rt/rs/extensions/search/src/main/java/org/apache/cxf/jaxrs/ext/search/jpa/AbstractJPATypedQueryVisitor.java#L181

it branches to either doBuildPredicate() (==> similar to Syncope
SearchCondVisitor.visitPrimitive) or doBuildCollectionPredicate()

When we have "a.b.c" then if 'b' is a collection then it would branch
to doBuildCollectionPredicate.

It was awhile back since I played with the typed JPA2 code, Native one
is a mystery...

I agree supporting such queries is not easy...but supporting then can
offer an ultimate search experience :-)

Cheers, Sergey
On 28/06/17 10:26, Francesco Chicchiriccò wrote:

On 28/06/2017 10:59, Sergey Beryozkin wrote:

Hi Francesco

Thanks for the explanation.

I see why the example I pointed to won't be applicable to Syncope.
In that case when the linked beans are available, CXF
AbstractSearchParser will prepare a bean tree which would be
initialized with the values from the expression like "a.b.c" and the
OOB visitor like JPA2 one takes care of dealing with these linked beans.

In the SearchBean case it is up to the custom visitor whether to react
to the '.'s or not where a '.' indicates that for ex 'a' needs to have
'b' with a property 'c'.

Do you reckon Syncope custom visitors can be updated to support such
queries ? Not sure about ElasticSearch but for SQL it should probably
be possible...

Maybe in principle yes, it could be possible to support such queries but:

1. implementation would be rather complex as the query logic is already
quite involved

2. we haven't had may requests for such complex queries so far

...anyway, as you know, volunteers are welcome :-)

Regards.

On 28/06/17 09:46, Francesco Chicchiriccò wrote:

On 28/06/2017 10:41, Sergey Beryozkin wrote:

I think something similar works for a CXF FIQL JPA2 visitor, for
example:

https://github.com/apache/cxf/blob/master/rt/rs/extensions/search/src/test/java/org/apache/cxf/jaxrs/ext/search/jpa/JPATypedQueryVisitorFiqlTest.java#L65

(find the books which have been revied done by Ted)

Hi Sergey,
that would work if we had straight beans as in the linked sample.

Syncope data model is instead much more involved as new schema for
attributes can be defined at runtime: this is the reason why we have
SearchCondVisitor [1] translating FIQL into our internal search
conditions, which serve as input to one of available implementations
of AnySearchDAO like as the default one based on SQL views [2] and
another relying on Elasticsearch-based [3].

Regards.

[1]
https://github.com/apache/syncope/blob/2_0_X/core/persistence-api/src/main/java/org/apache/syncope/core/persistence/api/search/SearchCondVisitor.java

[2]
https://github.com/apache/syncope/blob/2_0_X/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/dao/JPAAnySearchDAO.java

[3]
https://github.com/apache/syncope/blob/2_0_X/ext/elasticsearch/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/dao/ElasticsearchAnySearchDAO.java

On 28/06/17 08:54, Francesco Chicchiriccò wrote:

On 27/06/2017 18:18, Colm O hEigeartaigh wrote:

Thanks Francesco! On a related note, let's say I have some AnyObjects
(Printer) with a relationship to other AnyObjects (Cartridge). Now
I want
to search for a Printer which has a relationship with a Cartridge
with a

"colour" attribute of "blue". Is there a way to do this via a FIQL
expression?

No, you cannot express such condition ATM; you could do for example:

SyncopeClient.getAnyObjectSearchConditionBuilder("PRINTER").
inRelationships("ce75249b-76e4-44b6-88ae-0841846faceb").
and().is("colour").equalTo("blue").query();

which translates to FIQL

$type==PRINTER;$relationships==ce75249b-76e4-44b6-88ae-0841846faceb;colour==blue

but this would rather search for blue printers having a
relationship with an any object with key
'ce75249b-76e4-44b6-88ae-0841846faceb'.

or alternatively

SyncopeClient.getAnyObjectSearchConditionBuilder("PRINTER").
inRelationshipTypes("WITH_CARTDRIGE").
and().is("color").equalTo("blue").query();

which translates to FIQL

$type==PRINTER;$relationshipTypes==WITH_CARTDRIGE;color==blue

but this would rather search for blue printers having a
relationship on type WITH_CARTDRIGE.

Regards.

On Tue, Jun 27, 2017 at 4:29 PM, Francesco Chicchiriccò
wrote:

On 27/06/2017 17:24, Colm O hEigeartaigh wrote:

Hi all,

How can I retrieve a list of AnyObjects? The following returns a
400:

curl -I -X GET -u admin:password
http://localhost:9080/syncope/rest/anyObjects

You must at least provide the AnyType, e.g.

http://localhost:9080/syncope/rest/anyObjects;fiql=%24type%3D%3DPRINTER

[jira] [Assigned] (SYNCOPE-1118) Update docs to explain what "anonymousKey" refers to


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

Francesco Chicchiriccò reassigned SYNCOPE-1118:
---

Assignee: Francesco Chicchiriccò

> Update docs to explain what "anonymousKey" refers to
> 
>
> Key: SYNCOPE-1118
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1118
> Project: Syncope
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Colm O hEigeartaigh
>Assignee: Francesco Chicchiriccò
> Fix For: 2.0.4, 2.1.0
>
>
> In the getting-started guide, "anonymousKey" is defined as:
> "Provide any pseudo-random string here that will be used as an authentication 
> key for anonymous requests".
> However, anonymous requests are not referenced again in the getting started 
> guide or in the reference guide. We should add something (I guess to the 
> latter) to explain what anonymous requests are.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: AnyObjects query


On 28/06/2017 10:59, Sergey Beryozkin wrote:

Hi Francesco

Thanks for the explanation.

I see why the example I pointed to won't be applicable to Syncope.
In that case when the linked beans are available, CXF 
AbstractSearchParser will prepare a bean tree which would be 
initialized with the values from the expression like "a.b.c" and the 
OOB visitor like JPA2 one takes care of dealing with these linked beans.


In the SearchBean case it is up to the custom visitor whether to react 
to the '.'s or not where a '.' indicates that for ex 'a' needs to have 
'b' with a property 'c'.


Do you reckon Syncope custom visitors can be updated to support such 
queries ? Not sure about ElasticSearch but for SQL it should probably 
be possible...


Maybe in principle yes, it could be possible to support such queries but:

1. implementation would be rather complex as the query logic is already 
quite involved

2. we haven't had may requests for such complex queries so far

...anyway, as you know, volunteers are welcome :-)

Regards.


On 28/06/17 09:46, Francesco Chicchiriccò wrote:

On 28/06/2017 10:41, Sergey Beryozkin wrote:

Hi

I think something similar works for a CXF FIQL JPA2 visitor, for 
example:


https://github.com/apache/cxf/blob/master/rt/rs/extensions/search/src/test/java/org/apache/cxf/jaxrs/ext/search/jpa/JPATypedQueryVisitorFiqlTest.java#L65 



(find the books which have been revied done by Ted)


Hi Sergey,
that would work if we had straight beans as in the linked sample.

Syncope data model is instead much more involved as new schema for 
attributes can be defined at runtime: this is the reason why we have 
SearchCondVisitor [1] translating FIQL into our internal search 
conditions, which serve as input to one of available implementations 
of AnySearchDAO like as the default one based on SQL views [2] and 
another relying on Elasticsearch-based [3].


Regards.

[1] 
https://github.com/apache/syncope/blob/2_0_X/core/persistence-api/src/main/java/org/apache/syncope/core/persistence/api/search/SearchCondVisitor.java 

[2] 
https://github.com/apache/syncope/blob/2_0_X/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/dao/JPAAnySearchDAO.java 

[3] 
https://github.com/apache/syncope/blob/2_0_X/ext/elasticsearch/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/dao/ElasticsearchAnySearchDAO.java 




On 28/06/17 08:54, Francesco Chicchiriccò wrote:

On 27/06/2017 18:18, Colm O hEigeartaigh wrote:

Thanks Francesco! On a related note, let's say I have some AnyObjects
(Printer) with a relationship to other AnyObjects (Cartridge). Now 
I want
to search for a Printer which has a relationship with a Cartridge 
with a

"colour" attribute of "blue". Is there a way to do this via a FIQL
expression?


No, you cannot express such condition ATM; you could do for example:

SyncopeClient.getAnyObjectSearchConditionBuilder("PRINTER").
inRelationships("ce75249b-76e4-44b6-88ae-0841846faceb").
 and().is("colour").equalTo("blue").query();

which translates to FIQL

$type==PRINTER;$relationships==ce75249b-76e4-44b6-88ae-0841846faceb;colour==blue 



but this would rather search for blue printers having a 
relationship with an any object with key 
'ce75249b-76e4-44b6-88ae-0841846faceb'.


or alternatively

SyncopeClient.getAnyObjectSearchConditionBuilder("PRINTER").
 inRelationshipTypes("WITH_CARTDRIGE").
 and().is("color").equalTo("blue").query();

which translates to FIQL

$type==PRINTER;$relationshipTypes==WITH_CARTDRIGE;color==blue

but this would rather search for blue printers having a 
relationship on type  WITH_CARTDRIGE.


Regards.

On Tue, Jun 27, 2017 at 4:29 PM, Francesco Chicchiriccò 
 wrote:



On 27/06/2017 17:24, Colm O hEigeartaigh wrote:


Hi all,

How can I retrieve a list of AnyObjects? The following returns a 
400:


curl -I -X GET -u admin:password
http://localhost:9080/syncope/rest/anyObjects


You must at least provide the AnyType, e.g.

http://localhost:9080/syncope/rest/anyObjects;fiql=%24type%3D%3DPRINTER 



Regards.


--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

[jira] [Resolved] (SYNCOPE-1125) Password on external resource not updated via Enduser

2017-06-28 Thread ASF subversion and git services (JIRA)


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

Andrea Patricelli resolved SYNCOPE-1125.

Resolution: Fixed

> Password on external resource not updated via Enduser
> -
>
> Key: SYNCOPE-1125
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1125
> Project: Syncope
>  Issue Type: Bug
>  Components: enduser
>Affects Versions: 2.0.3
>Reporter: Francesco Chicchiriccò
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> As [reported in mailing 
> list|https://lists.apache.org/thread.html/b0d3c5f584f107065b988400f4865f7b9e4bb951ae201da9fd99e908@%3Cuser.syncope.apache.org%3E],
>  the issue can be replicated with standalone distribution / embedded mode:
> # from Admin Console, create user {{ilgro...@apache.org}}, set 
> {{Password123}} as password value and assign `resource-ldap`
> # user is successfully created and propagated
> # binding via LDAP works fine with the password set above:
>  {code}
> ldapsearch -h localhost -p 1389 -D "uid=ilgro...@apache.org,ou=People,o=isp" 
> -x -w Password123 -b "uid=ilgro...@apache.org,ou=People,o=isp"
>  {code}
> # from Admin Console, update the user above by setting the password to 
> {{Password124}}
> # binding via LDAP works fine with updated password:
>  {code}
> ldapsearch -h localhost -p 1389 -D "uid=ilgro...@apache.org,ou=People,o=isp" 
> -x -w Password124 -b "uid=ilgro...@apache.org,ou=People,o=isp"
>  {code}
> # from Enduser UI, login as {{ilgro...@apache.org}} / {{Password124}} and set 
> the password to {{Password125}}
> At this point:
> * {{Password125}} is set on Syncope
> * {{Password124}} is still set on LDAP
> * a {{DELETE}} propagation task was created as consequence of Enduser UI 
> password change



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1125) Password on external resource not updated via Enduser


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

ASF subversion and git services commented on SYNCOPE-1125:
--

Commit 26fb9bdae50088dc69338b300d045212fe1d7d98 in syncope's branch 
refs/heads/master from [~andrea.patricelli]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=26fb9bd ]

[SYNCOPE-1125] fixed password propagation on resource after update on enduser


> Password on external resource not updated via Enduser
> -
>
> Key: SYNCOPE-1125
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1125
> Project: Syncope
>  Issue Type: Bug
>  Components: enduser
>Affects Versions: 2.0.3
>Reporter: Francesco Chicchiriccò
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> As [reported in mailing 
> list|https://lists.apache.org/thread.html/b0d3c5f584f107065b988400f4865f7b9e4bb951ae201da9fd99e908@%3Cuser.syncope.apache.org%3E],
>  the issue can be replicated with standalone distribution / embedded mode:
> # from Admin Console, create user {{ilgro...@apache.org}}, set 
> {{Password123}} as password value and assign `resource-ldap`
> # user is successfully created and propagated
> # binding via LDAP works fine with the password set above:
>  {code}
> ldapsearch -h localhost -p 1389 -D "uid=ilgro...@apache.org,ou=People,o=isp" 
> -x -w Password123 -b "uid=ilgro...@apache.org,ou=People,o=isp"
>  {code}
> # from Admin Console, update the user above by setting the password to 
> {{Password124}}
> # binding via LDAP works fine with updated password:
>  {code}
> ldapsearch -h localhost -p 1389 -D "uid=ilgro...@apache.org,ou=People,o=isp" 
> -x -w Password124 -b "uid=ilgro...@apache.org,ou=People,o=isp"
>  {code}
> # from Enduser UI, login as {{ilgro...@apache.org}} / {{Password124}} and set 
> the password to {{Password125}}
> At this point:
> * {{Password125}} is set on Syncope
> * {{Password124}} is still set on LDAP
> * a {{DELETE}} propagation task was created as consequence of Enduser UI 
> password change



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Installer error


Hi Colm,
the problems with installer (actually, with archetype) on master are now 
fixed by


http://git-wip-us.apache.org/repos/asf/syncope/commit/750247e6

Regarding the warning messages produced by Maven, feel free to fix :-)

Regards.

On 23/06/2017 15:32, Colm O hEigeartaigh wrote:

It works fine on 2.0.x but the pom there still looks a bit dodgy after the
installer is done with it. The plugin appears twice under build/plugins and
also under profiles.

Colm.

On Fri, Jun 23, 2017 at 2:29 PM, Francesco Chicchiriccò  
wrote:


Colm O hEigeartaigh  wrote:


Hi all,

I'm seeing an error with the installer on master, where I'm ending up with an invalid 
console pom.xml, as it's copying an extra "setupActivitiModeler" plugin. The 
code in the installer manually adds this plugin in
ArchetypeProcess. Has something changed so that it no longer needs to do
this?

Hi,
I've recently changed the Activiti Modeler setup in 2_0_X, so probably
there was some problem when cherry-picking to master.

I'll take a look.
Regards.


--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

Re: AnyObjects query


On 28/06/2017 10:41, Sergey Beryozkin wrote:

Hi

I think something similar works for a CXF FIQL JPA2 visitor, for example:

https://github.com/apache/cxf/blob/master/rt/rs/extensions/search/src/test/java/org/apache/cxf/jaxrs/ext/search/jpa/JPATypedQueryVisitorFiqlTest.java#L65 



(find the books which have been revied done by Ted)


Hi Sergey,
that would work if we had straight beans as in the linked sample.

Syncope data model is instead much more involved as new schema for 
attributes can be defined at runtime: this is the reason why we have 
SearchCondVisitor [1] translating FIQL into our internal search 
conditions, which serve as input to one of available implementations of 
AnySearchDAO like as the default one based on SQL views [2] and another 
relying on Elasticsearch-based [3].


Regards.

[1] 
https://github.com/apache/syncope/blob/2_0_X/core/persistence-api/src/main/java/org/apache/syncope/core/persistence/api/search/SearchCondVisitor.java
[2] 
https://github.com/apache/syncope/blob/2_0_X/core/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/dao/JPAAnySearchDAO.java
[3] 
https://github.com/apache/syncope/blob/2_0_X/ext/elasticsearch/persistence-jpa/src/main/java/org/apache/syncope/core/persistence/jpa/dao/ElasticsearchAnySearchDAO.java



On 28/06/17 08:54, Francesco Chicchiriccò wrote:

On 27/06/2017 18:18, Colm O hEigeartaigh wrote:

Thanks Francesco! On a related note, let's say I have some AnyObjects
(Printer) with a relationship to other AnyObjects (Cartridge). Now I 
want
to search for a Printer which has a relationship with a Cartridge 
with a

"colour" attribute of "blue". Is there a way to do this via a FIQL
expression?


No, you cannot express such condition ATM; you could do for example:

SyncopeClient.getAnyObjectSearchConditionBuilder("PRINTER").
inRelationships("ce75249b-76e4-44b6-88ae-0841846faceb").
 and().is("colour").equalTo("blue").query();

which translates to FIQL

$type==PRINTER;$relationships==ce75249b-76e4-44b6-88ae-0841846faceb;colour==blue 



but this would rather search for blue printers having a relationship 
with an any object with key 'ce75249b-76e4-44b6-88ae-0841846faceb'.


or alternatively

SyncopeClient.getAnyObjectSearchConditionBuilder("PRINTER").
 inRelationshipTypes("WITH_CARTDRIGE").
 and().is("color").equalTo("blue").query();

which translates to FIQL

$type==PRINTER;$relationshipTypes==WITH_CARTDRIGE;color==blue

but this would rather search for blue printers having a relationship 
on type  WITH_CARTDRIGE.


Regards.

On Tue, Jun 27, 2017 at 4:29 PM, Francesco Chicchiriccò 
 wrote:



On 27/06/2017 17:24, Colm O hEigeartaigh wrote:


Hi all,

How can I retrieve a list of AnyObjects? The following returns a 400:

curl -I -X GET -u admin:password
http://localhost:9080/syncope/rest/anyObjects


You must at least provide the AnyType, e.g.

http://localhost:9080/syncope/rest/anyObjects;fiql=%24type%3D%3DPRINTER 



Regards.







--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

Re: AnyObjects query

2017-06-28 Thread Sergey Beryozkin


Hi

I think something similar works for a CXF FIQL JPA2 visitor, for example:

https://github.com/apache/cxf/blob/master/rt/rs/extensions/search/src/test/java/org/apache/cxf/jaxrs/ext/search/jpa/JPATypedQueryVisitorFiqlTest.java#L65

(find the books which have been revied done by Ted)

thanks, Sergey

On 28/06/17 08:54, Francesco Chicchiriccò wrote:

On 27/06/2017 18:18, Colm O hEigeartaigh wrote:

Thanks Francesco! On a related note, let's say I have some AnyObjects
(Printer) with a relationship to other AnyObjects (Cartridge). Now I want
to search for a Printer which has a relationship with a Cartridge with a
"colour" attribute of "blue". Is there a way to do this via a FIQL
expression?


No, you cannot express such condition ATM; you could do for example:

 SyncopeClient.getAnyObjectSearchConditionBuilder("PRINTER").
inRelationships("ce75249b-76e4-44b6-88ae-0841846faceb").
 and().is("colour").equalTo("blue").query();

which translates to FIQL

$type==PRINTER;$relationships==ce75249b-76e4-44b6-88ae-0841846faceb;colour==blue 



but this would rather search for blue printers having a relationship 
with an any object with key 'ce75249b-76e4-44b6-88ae-0841846faceb'.


or alternatively

 SyncopeClient.getAnyObjectSearchConditionBuilder("PRINTER").
 inRelationshipTypes("WITH_CARTDRIGE").
 and().is("color").equalTo("blue").query();

which translates to FIQL

$type==PRINTER;$relationshipTypes==WITH_CARTDRIGE;color==blue

but this would rather search for blue printers having a relationship on 
type  WITH_CARTDRIGE.


Regards.

On Tue, Jun 27, 2017 at 4:29 PM, Francesco Chicchiriccò 
 wrote:



On 27/06/2017 17:24, Colm O hEigeartaigh wrote:


Hi all,

How can I retrieve a list of AnyObjects? The following returns a 400:

curl -I -X GET -u admin:password
http://localhost:9080/syncope/rest/anyObjects


You must at least provide the AnyType, e.g.

http://localhost:9080/syncope/rest/anyObjects;fiql=%24type%3D%3DPRINTER

Regards.





--
Sergey Beryozkin

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

[jira] [Updated] (SYNCOPE-1132) Extraneous "dots" appearing in the Console when assigning relationships


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

fabio martelli updated SYNCOPE-1132:

Component/s: console

> Extraneous "dots" appearing in the Console when assigning relationships
> ---
>
> Key: SYNCOPE-1132
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1132
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Reporter: Colm O hEigeartaigh
>Assignee: fabio martelli
>Priority: Trivial
> Fix For: 2.0.4, 2.1.0
>
> Attachments: occurredprop.png, syncope-dots.png
>
>
> There appears to be a regression with the latest 2.0.4 + 2.1.0 code (I 
> confirmed it is not present in 2.0.3) where extra "dots" are appearing in the 
> screen. I can reproduce by assigning a relationship to an AnyObject for 
> example in the console. See attached screenshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1132) Extraneous "dots" appearing in the Console when assigning relationships


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

fabio martelli commented on SYNCOPE-1132:
-

Hi Colm, I cannot reproduce your issue (see attached file).
Please reload your css, try out again and let me know.

Regards,
F.



> Extraneous "dots" appearing in the Console when assigning relationships
> ---
>
> Key: SYNCOPE-1132
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1132
> Project: Syncope
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: fabio martelli
>Priority: Trivial
> Fix For: 2.0.4, 2.1.0
>
> Attachments: occurredprop.png, syncope-dots.png
>
>
> There appears to be a regression with the latest 2.0.4 + 2.1.0 code (I 
> confirmed it is not present in 2.0.3) where extra "dots" are appearing in the 
> screen. I can reproduce by assigning a relationship to an AnyObject for 
> example in the console. See attached screenshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SYNCOPE-1132) Extraneous "dots" appearing in the Console when assigning relationships


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

fabio martelli updated SYNCOPE-1132:

Attachment: occurredprop.png

> Extraneous "dots" appearing in the Console when assigning relationships
> ---
>
> Key: SYNCOPE-1132
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1132
> Project: Syncope
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: fabio martelli
>Priority: Trivial
> Fix For: 2.0.4, 2.1.0
>
> Attachments: occurredprop.png, syncope-dots.png
>
>
> There appears to be a regression with the latest 2.0.4 + 2.1.0 code (I 
> confirmed it is not present in 2.0.3) where extra "dots" are appearing in the 
> screen. I can reproduce by assigning a relationship to an AnyObject for 
> example in the console. See attached screenshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: AnyObjects query


On 27/06/2017 18:18, Colm O hEigeartaigh wrote:

Thanks Francesco! On a related note, let's say I have some AnyObjects
(Printer) with a relationship to other AnyObjects (Cartridge). Now I want
to search for a Printer which has a relationship with a Cartridge with a
"colour" attribute of "blue". Is there a way to do this via a FIQL
expression?


No, you cannot express such condition ATM; you could do for example:

SyncopeClient.getAnyObjectSearchConditionBuilder("PRINTER").
inRelationships("ce75249b-76e4-44b6-88ae-0841846faceb").
and().is("colour").equalTo("blue").query();

which translates to FIQL

$type==PRINTER;$relationships==ce75249b-76e4-44b6-88ae-0841846faceb;colour==blue

but this would rather search for blue printers having a relationship 
with an any object with key 'ce75249b-76e4-44b6-88ae-0841846faceb'.


or alternatively

SyncopeClient.getAnyObjectSearchConditionBuilder("PRINTER").
inRelationshipTypes("WITH_CARTDRIGE").
and().is("color").equalTo("blue").query();

which translates to FIQL

$type==PRINTER;$relationshipTypes==WITH_CARTDRIGE;color==blue

but this would rather search for blue printers having a relationship on 
type  WITH_CARTDRIGE.


Regards.


On Tue, Jun 27, 2017 at 4:29 PM, Francesco Chicchiriccò  
wrote:


On 27/06/2017 17:24, Colm O hEigeartaigh wrote:


Hi all,

How can I retrieve a list of AnyObjects? The following returns a 400:

curl -I -X GET -u admin:password
http://localhost:9080/syncope/rest/anyObjects


You must at least provide the AnyType, e.g.

http://localhost:9080/syncope/rest/anyObjects;fiql=%24type%3D%3DPRINTER

Regards.


--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

[jira] [Assigned] (SYNCOPE-1132) Extraneous "dots" appearing in the Console when assigning relationships

2017-06-28 Thread ASF subversion and git services (JIRA)


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

fabio martelli reassigned SYNCOPE-1132:
---

Assignee: fabio martelli

> Extraneous "dots" appearing in the Console when assigning relationships
> ---
>
> Key: SYNCOPE-1132
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1132
> Project: Syncope
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: fabio martelli
>Priority: Trivial
> Fix For: 2.0.4, 2.1.0
>
> Attachments: syncope-dots.png
>
>
> There appears to be a regression with the latest 2.0.4 + 2.1.0 code (I 
> confirmed it is not present in 2.0.3) where extra "dots" are appearing in the 
> screen. I can reproduce by assigning a relationship to an AnyObject for 
> example in the console. See attached screenshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SYNCOPE-1053) Show actual pending modifications during approval


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

ASF subversion and git services commented on SYNCOPE-1053:
--

Commit b38b51e930b2c2abd234ff967880ba24278d2e04 in syncope's branch 
refs/heads/2_0_X from [~fmartelli]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=b38b51e ]

[SYNCOPE-1053] hides and disables approval details in case of formTO missing 
userTO


> Show actual pending modifications during approval
> -
>
> Key: SYNCOPE-1053
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1053
> Project: Syncope
>  Issue Type: Improvement
>  Components: console
>Reporter: Francesco Chicchiriccò
>Assignee: fabio martelli
> Fix For: 2.0.4, 2.1.0
>
>
> When performing approval via Admin Console, it is currently possible to look 
> at the data of the user being created / update.
> In case of update, however, it would be more useful to highlight somehow the 
> actual pending modifications.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SYNCOPE-1053) Show actual pending modifications during approval