Re: AnyObjects query

2017-06-29 Thread Colm O hEigeartaigh
Thanks everyone for the feedback. Francesco, just sticking with curl again,
your suggestions works to get the blue cartridges that are in a
relationship with a Printer:

curl -X GET -u admin:password
"http:localhost:9080/syncope/rest/anyObjects?fiql=%24type==CARTDRIGE;color==blue;%24relationshipTypes==PRINTER_CAR
TDRIGE_ASSIGNMENT"

However, as the relationship was defined when I created the particular
Printer for example, I see an empty relationship value for the cartridge:
"relationships":[]. Am I right in thinking that your example only works if
the relationship was defined for the Cartridge as opposed to the printer?
Or is there a bug here that the Cartridge is not storing the relationship
that was created for the printer?

Colm.

On Thu, Jun 29, 2017 at 10:19 AM, Francesco Chicchiriccò <
ilgro...@apache.org> wrote:

> On 29/06/2017 11:04, Sergey Beryozkin wrote:
>
>> Hi Francesco
>>
>> OK. So, as far as the Syncope returning the list of printers to the
>> client code issuing the query, how would it guess that when someone
>> searches for the blue cartridges it is actually a list of printers is
>> expected ? Where will this code which next goes over the list of all the
>> cartridges and prepare a list of Printers will sit ?
>>
>> As far as the demand is concerned: it is driven by a too long URI
>> production issue Colm referred to
>>
>
> The URI too long is generated if you do the search the way Colm describes
> it.
>
> If instead, by following Fabio's suggestion, you search for all Cartdriges
> with "colour==blue" having a certain RelationshipType (which you have prior
> defined, with Printers, say it is named 'PRINTER_CARTDRIGE_ASSIGNMENT'),
> then you need a single query with the following FIQL:
>
> $type==CARTDRIGE;color==blue;$relationshipTypes==PRINTER_CAR
> TDRIGE_ASSIGNMENT
>
> Such query will return a list of AnyObjectTO instances, each of which
> containing a list of RelationshipTO, where each RelationshipTO instance has
> a type field.
>
> Hence, to get "the printers with a blue cartridge", it will be enough to
> iterate over the returned list of AnyObjectTO instances (of type
> CARTDRIGE), find the RelationshipTO instances of type
> PRINTER_CARTDRIGE_ASSIGNMENT, and finally get the other side of the
> relationship, e.g. the printer.
> Code-wise:
>
> PagedResult cartdriges = ...; // returned by the
> search
> List printers = new ArrayList<>();
> for (AnyObjectTO cartdrige: cartdriges.getResult()) {
> for (RelationshipTO relationship:
> cartdrige.getRelationships()) {
> if ("PRINTER_CARTDRIGE_ASSIGNMENT
> ".equals(relationship.getType())) {
> printers.add(relationship.getRightKey());
> }
> }
> }
>
> Anyway, as said, there is always room to improve.
> Regards.
>
>
> On 29/06/17 09:53, Francesco Chicchiriccò wrote:
>>
>>> On 29/06/2017 10:52, Sergey Beryozkin wrote:
>>>
 Hi Fabio

 That would not work at the generic level as it would require a 2-way
 relationship (cartridge - printer for ex) which is not always realistic to
 expect,

>>>
>>> In the Syncope data model, all Relationships are 2-way.
>>>
>>> I agree with Fabio: the use case proposed by Colm is doable with current
>>> implementation.
>>>
>>> Naturally, there is always room for improvements, but I don't see much
>>> demand ATM.
>>>
>>> Regards.
>>>
>>> On 29/06/17 09:07, Fabio Martelli wrote:

>
>
> Il 28/06/2017 18:34, Colm O hEigeartaigh ha scritto:
>
>> Thanks for the feedback guys! Let me just expand a bit on the
>> motivation
>> behind my previous example
>>
>> Let's say I'm managing hundreds of printers each of which have a
>> relationship to a cartridge (of which there are many hundreds) with a
>> colour attribute. I want to find the printers with a blue cartridge.
>>
>> So I first make a search for a list of "blue" cartridges. Then I
>> search for
>> the printers that have a relationship with these cartridges. The
>> problem is
>> on the second search I end up with a ginormous search expression
>> "relationships%3D%3D7db4512-ad25-40e8-bc78-63ad25c0e894%2C%
>> 24relationships%3D%3D16dc6acd-6.".
>> " that could be an invalid URL.
>>
>> Is there a better way of handling it than this?
>>
> Hi Colm, maybe you can search all the cartridges blue with a
> relationship with a printer.
> The result will be a list of cartridges. Each item will be reported
> including a specific field relationships (if I well remember) about all 
> the
> printers related to the item.
> In this case, you will have all the info you need retrieved by a
> single short query. Don't you agree?
>
> BR,
> F.
>
>>
>> Colm.
>>
>> On Wed, Jun 28, 2017 at 10:52 AM, Sergey Beryozkin <
>> sberyoz...@gmail.com>
>> wrote:
>>
>> Hi Francesco
>>>
>>> 

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

2017-06-29 Thread fabio martelli (JIRA)

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

fabio martelli resolved SYNCOPE-1135.
-
Resolution: Fixed

> 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] [Commented] (SYNCOPE-1135) Groups list not refreshing after realm change

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

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

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

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

[SYNCOPE-1135] provides dynamicac reload of groups and memberships if the realm 
changes


> 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] [Commented] (SYNCOPE-1135) Groups list not refreshing after realm change

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

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

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

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

[SYNCOPE-1135] provides dynamicac reload of groups and memberships if the realm 
changes


> 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] [Commented] (SYNCOPE-1134) Action menu not working after page refresh

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

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

ASF GitHub Bot commented on SYNCOPE-1134:
-

Github user mat-ale commented on the issue:

https://github.com/apache/syncope/pull/48
  
great, you're welcome @ilgrosso.


> 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
>Assignee: Francesco Chicchiriccò
>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)


[GitHub] syncope issue #48: Fixes [SYNCOPE-1134]

2017-06-29 Thread mat-ale
Github user mat-ale commented on the issue:

https://github.com/apache/syncope/pull/48
  
great, you're welcome @ilgrosso.


---
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-1134) Action menu not working after page refresh

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

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

ASF GitHub Bot commented on SYNCOPE-1134:
-

Github user ilgrosso commented on the issue:

https://github.com/apache/syncope/pull/48
  
Looks good, thanks @mat-ale!


> 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
>Assignee: Francesco Chicchiriccò
>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)


[GitHub] syncope issue #48: Fixes [SYNCOPE-1134]

2017-06-29 Thread ilgrosso
Github user ilgrosso commented on the issue:

https://github.com/apache/syncope/pull/48
  
Looks good, thanks @mat-ale!


---
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-1134) Action menu not working after page refresh

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

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

ASF GitHub Bot commented on SYNCOPE-1134:
-

Github user asfgit closed the pull request at:

https://github.com/apache/syncope/pull/48


> 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
>Assignee: Francesco Chicchiriccò
>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] [Resolved] (SYNCOPE-1134) Action menu not working after page refresh

2017-06-29 Thread JIRA

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

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

> 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
>Assignee: Francesco Chicchiriccò
>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] [Commented] (SYNCOPE-1134) Action menu not working after page refresh

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

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

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

Commit 4e8680b3f11064035d7a2038e7d50d085145c78b in syncope's branch 
refs/heads/master from [~skylark17]
[ https://git-wip-us.apache.org/repos/asf?p=syncope.git;h=4e8680b ]

Fixes [SYNCOPE-1134] - This closes #48


> 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
>Assignee: Francesco Chicchiriccò
>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)


[GitHub] syncope pull request #48: Fixes [SYNCOPE-1134]

2017-06-29 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/syncope/pull/48


---
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-1134) Action menu not working after page refresh

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

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

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

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

Fixes [SYNCOPE-1134]


> 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
>Assignee: Francesco Chicchiriccò
>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] [Assigned] (SYNCOPE-1134) Action menu not working after page refresh

2017-06-29 Thread JIRA

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

Francesco Chicchiriccò reassigned SYNCOPE-1134:
---

Assignee: Francesco Chicchiriccò

> 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
>Assignee: Francesco Chicchiriccò
>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] [Commented] (SYNCOPE-1134) Action menu not working after page refresh

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

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

ASF GitHub Bot commented on SYNCOPE-1134:
-

GitHub user mat-ale opened a pull request:

https://github.com/apache/syncope/pull/48

Fixes [SYNCOPE-1134]

Hi,

this fixes [SYNCOPE-1136].

Regards,
Matteo

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mat-ale/syncope SYNCOPE-1134

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/syncope/pull/48.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #48


commit cb95742ccc1233b632ad87860defb1f18ce8533f
Author: Matteo Alessandroni 
Date:   2017-06-29T13:45:36Z

Fixes [SYNCOPE-1134]




> 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)


[GitHub] syncope pull request #48: Fixes [SYNCOPE-1134]

2017-06-29 Thread mat-ale
GitHub user mat-ale opened a pull request:

https://github.com/apache/syncope/pull/48

Fixes [SYNCOPE-1134]

Hi,

this fixes [SYNCOPE-1136].

Regards,
Matteo

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mat-ale/syncope SYNCOPE-1134

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/syncope/pull/48.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #48


commit cb95742ccc1233b632ad87860defb1f18ce8533f
Author: Matteo Alessandroni 
Date:   2017-06-29T13:45:36Z

Fixes [SYNCOPE-1134]




---
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-1134) Action menu not working after page refresh

2017-06-29 Thread Matteo Alessandroni (JIRA)

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

Matteo Alessandroni commented on SYNCOPE-1134:
--

Update:
the issue comes out only when action menu is visible before refreshing.

> 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] [Assigned] (SYNCOPE-1111) New any type not shown unders Realms

2017-06-29 Thread Andrea Patricelli (JIRA)

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

Andrea Patricelli reassigned SYNCOPE-:
--

Assignee: Andrea Patricelli

> New any type not shown unders Realms
> 
>
> Key: SYNCOPE-
> URL: https://issues.apache.org/jira/browse/SYNCOPE-
> Project: Syncope
>  Issue Type: Bug
>  Components: console
>Affects Versions: 2.0.3
>Reporter: Francesco Chicchiriccò
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> From Admin Console:
> # create new any type (say {{DEVICE}})
> # go back to Realms: the new any type is not shown
> After logging out and back in, the new any type is shown as expected.



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


Re: AnyObjects query

2017-06-29 Thread Sergey Beryozkin
Sure this code works. For the client geared to do this specific query 
only. Def not an option for the 'curl' one :-)


Sergey
On 29/06/17 10:19, Francesco Chicchiriccò wrote:

On 29/06/2017 11:04, Sergey Beryozkin wrote:

Hi Francesco

OK. So, as far as the Syncope returning the list of printers to the 
client code issuing the query, how would it guess that when someone 
searches for the blue cartridges it is actually a list of printers is 
expected ? Where will this code which next goes over the list of all 
the cartridges and prepare a list of Printers will sit ?


As far as the demand is concerned: it is driven by a too long URI 
production issue Colm referred to


The URI too long is generated if you do the search the way Colm 
describes it.


If instead, by following Fabio's suggestion, you search for all 
Cartdriges with "colour==blue" having a certain RelationshipType (which 
you have prior defined, with Printers, say it is named 
'PRINTER_CARTDRIGE_ASSIGNMENT'), then you need a single query with the 
following FIQL:


$type==CARTDRIGE;color==blue;$relationshipTypes==PRINTER_CARTDRIGE_ASSIGNMENT 



Such query will return a list of AnyObjectTO instances, each of which 
containing a list of RelationshipTO, where each RelationshipTO instance 
has a type field.


Hence, to get "the printers with a blue cartridge", it will be enough to 
iterate over the returned list of AnyObjectTO instances (of type 
CARTDRIGE), find the RelationshipTO instances of type 
PRINTER_CARTDRIGE_ASSIGNMENT, and finally get the other side of the 
relationship, e.g. the printer.

Code-wise:

 PagedResult cartdriges = ...; // returned by the 
search

 List printers = new ArrayList<>();
 for (AnyObjectTO cartdrige: cartdriges.getResult()) {
 for (RelationshipTO relationship: 
cartdrige.getRelationships()) {
 if 
("PRINTER_CARTDRIGE_ASSIGNMENT".equals(relationship.getType())) {

 printers.add(relationship.getRightKey());
 }
 }
 }

Anyway, as said, there is always room to improve.
Regards.


On 29/06/17 09:53, Francesco Chicchiriccò wrote:

On 29/06/2017 10:52, Sergey Beryozkin wrote:

Hi Fabio

That would not work at the generic level as it would require a 2-way 
relationship (cartridge - printer for ex) which is not always 
realistic to expect,


In the Syncope data model, all Relationships are 2-way.

I agree with Fabio: the use case proposed by Colm is doable with 
current implementation.


Naturally, there is always room for improvements, but I don't see 
much demand ATM.


Regards.


On 29/06/17 09:07, Fabio Martelli wrote:



Il 28/06/2017 18:34, Colm O hEigeartaigh ha scritto:
Thanks for the feedback guys! Let me just expand a bit on the 
motivation

behind my previous example

Let's say I'm managing hundreds of printers each of which have a
relationship to a cartridge (of which there are many hundreds) with a
colour attribute. I want to find the printers with a blue cartridge.

So I first make a search for a list of "blue" cartridges. Then I 
search for
the printers that have a relationship with these cartridges. The 
problem is

on the second search I end up with a ginormous search expression
"relationships%3D%3D7db4512-ad25-40e8-bc78-63ad25c0e894%2C%24relationships%3D%3D16dc6acd-6.". 


" that could be an invalid URL.

Is there a better way of handling it than this?
Hi Colm, maybe you can search all the cartridges blue with a 
relationship with a printer.
The result will be a list of cartridges. Each item will be reported 
including a specific field relationships (if I well remember) about 
all the printers related to the item.
In this case, you will have all the info you need retrieved by a 
single short query. Don't you agree?


BR,
F.


Colm.

On Wed, Jun 28, 2017 at 10:52 AM, Sergey Beryozkin 


wrote:


Hi Francesco

One thing I can point to is this code:

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

There, in the end,

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s
earch/src/main/java/org/apache/cxf/jaxrs/ext/search/jpa/Abst
ractJPATypedQueryVisitor.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 

Re: AnyObjects query

2017-06-29 Thread Francesco Chicchiriccò

On 29/06/2017 11:12, Sergey Beryozkin wrote:
I guess one option would be for the client code itself to get all the 
printer links out of the cartridges and then issue one more query unless
the returned model has all the data inlined ? That might work but it 
would mean the client translating the queries can not be generic 
itself...


See my reply on the other fork of this thread.

Well, I agree there's always a room for some improvements :-). As I 
said I'll give it a try at enhancing the CXF level 'plain' visitors 
and post a link to show what I did...


Sounds good.
Regards.


On 29/06/17 10:04, Sergey Beryozkin wrote:

Hi Francesco

OK. So, as far as the Syncope returning the list of printers to the 
client code issuing the query, how would it guess that when someone 
searches for the blue cartridges it is actually a list of printers is 
expected ? Where will this code which next goes over the list of all 
the cartridges and prepare a list of Printers will sit ?


As far as the demand is concerned: it is driven by a too long URI 
production issue Colm referred to


Thanks, Sergey

On 29/06/17 09:53, Francesco Chicchiriccò wrote:

On 29/06/2017 10:52, Sergey Beryozkin wrote:

Hi Fabio

That would not work at the generic level as it would require a 
2-way relationship (cartridge - printer for ex) which is not always 
realistic to expect,


In the Syncope data model, all Relationships are 2-way.

I agree with Fabio: the use case proposed by Colm is doable with 
current implementation.


Naturally, there is always room for improvements, but I don't see 
much demand ATM.


Regards.


On 29/06/17 09:07, Fabio Martelli wrote:



Il 28/06/2017 18:34, Colm O hEigeartaigh ha scritto:
Thanks for the feedback guys! Let me just expand a bit on the 
motivation

behind my previous example

Let's say I'm managing hundreds of printers each of which have a
relationship to a cartridge (of which there are many hundreds) 
with a

colour attribute. I want to find the printers with a blue cartridge.

So I first make a search for a list of "blue" cartridges. Then I 
search for
the printers that have a relationship with these cartridges. The 
problem is

on the second search I end up with a ginormous search expression
"relationships%3D%3D7db4512-ad25-40e8-bc78-63ad25c0e894%2C%24relationships%3D%3D16dc6acd-6.". 


" that could be an invalid URL.

Is there a better way of handling it than this?
Hi Colm, maybe you can search all the cartridges blue with a 
relationship with a printer.
The result will be a list of cartridges. Each item will be 
reported including a specific field relationships (if I well 
remember) about all the printers related to the item.
In this case, you will have all the info you need retrieved by a 
single short query. Don't you agree?


BR,
F.


Colm.

On Wed, Jun 28, 2017 at 10:52 AM, Sergey Beryozkin 


wrote:


Hi Francesco

One thing I can point to is this code:

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

There, in the end,

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s
earch/src/main/java/org/apache/cxf/jaxrs/ext/search/jpa/Abst
ractJPATypedQueryVisitor.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:


Hi

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

Re: AnyObjects query

2017-06-29 Thread Francesco Chicchiriccò

On 29/06/2017 11:04, Sergey Beryozkin wrote:

Hi Francesco

OK. So, as far as the Syncope returning the list of printers to the 
client code issuing the query, how would it guess that when someone 
searches for the blue cartridges it is actually a list of printers is 
expected ? Where will this code which next goes over the list of all 
the cartridges and prepare a list of Printers will sit ?


As far as the demand is concerned: it is driven by a too long URI 
production issue Colm referred to


The URI too long is generated if you do the search the way Colm 
describes it.


If instead, by following Fabio's suggestion, you search for all 
Cartdriges with "colour==blue" having a certain RelationshipType (which 
you have prior defined, with Printers, say it is named 
'PRINTER_CARTDRIGE_ASSIGNMENT'), then you need a single query with the 
following FIQL:


$type==CARTDRIGE;color==blue;$relationshipTypes==PRINTER_CARTDRIGE_ASSIGNMENT

Such query will return a list of AnyObjectTO instances, each of which 
containing a list of RelationshipTO, where each RelationshipTO instance 
has a type field.


Hence, to get "the printers with a blue cartridge", it will be enough to 
iterate over the returned list of AnyObjectTO instances (of type 
CARTDRIGE), find the RelationshipTO instances of type 
PRINTER_CARTDRIGE_ASSIGNMENT, and finally get the other side of the 
relationship, e.g. the printer.

Code-wise:

PagedResult cartdriges = ...; // returned by the 
search

List printers = new ArrayList<>();
for (AnyObjectTO cartdrige: cartdriges.getResult()) {
for (RelationshipTO relationship: 
cartdrige.getRelationships()) {
if 
("PRINTER_CARTDRIGE_ASSIGNMENT".equals(relationship.getType())) {

printers.add(relationship.getRightKey());
}
}
}

Anyway, as said, there is always room to improve.
Regards.


On 29/06/17 09:53, Francesco Chicchiriccò wrote:

On 29/06/2017 10:52, Sergey Beryozkin wrote:

Hi Fabio

That would not work at the generic level as it would require a 2-way 
relationship (cartridge - printer for ex) which is not always 
realistic to expect,


In the Syncope data model, all Relationships are 2-way.

I agree with Fabio: the use case proposed by Colm is doable with 
current implementation.


Naturally, there is always room for improvements, but I don't see 
much demand ATM.


Regards.


On 29/06/17 09:07, Fabio Martelli wrote:



Il 28/06/2017 18:34, Colm O hEigeartaigh ha scritto:
Thanks for the feedback guys! Let me just expand a bit on the 
motivation

behind my previous example

Let's say I'm managing hundreds of printers each of which have a
relationship to a cartridge (of which there are many hundreds) with a
colour attribute. I want to find the printers with a blue cartridge.

So I first make a search for a list of "blue" cartridges. Then I 
search for
the printers that have a relationship with these cartridges. The 
problem is

on the second search I end up with a ginormous search expression
"relationships%3D%3D7db4512-ad25-40e8-bc78-63ad25c0e894%2C%24relationships%3D%3D16dc6acd-6.". 


" that could be an invalid URL.

Is there a better way of handling it than this?
Hi Colm, maybe you can search all the cartridges blue with a 
relationship with a printer.
The result will be a list of cartridges. Each item will be reported 
including a specific field relationships (if I well remember) about 
all the printers related to the item.
In this case, you will have all the info you need retrieved by a 
single short query. Don't you agree?


BR,
F.


Colm.

On Wed, Jun 28, 2017 at 10:52 AM, Sergey Beryozkin 


wrote:


Hi Francesco

One thing I can point to is this code:

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

There, in the end,

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s
earch/src/main/java/org/apache/cxf/jaxrs/ext/search/jpa/Abst
ractJPATypedQueryVisitor.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 

Re: AnyObjects query

2017-06-29 Thread Sergey Beryozkin
I guess one option would be for the client code itself to get all the 
printer links out of the cartridges and then issue one more query unless
the returned model has all the data inlined ? That might work but it 
would mean the client translating the queries can not be generic itself...


Well, I agree there's always a room for some improvements :-). As I said 
I'll give it a try at enhancing the CXF level 'plain' visitors and post 
a link to show what I did...


Thanks, Sergey
On 29/06/17 10:04, Sergey Beryozkin wrote:

Hi Francesco

OK. So, as far as the Syncope returning the list of printers to the 
client code issuing the query, how would it guess that when someone 
searches for the blue cartridges it is actually a list of printers is 
expected ? Where will this code which next goes over the list of all the 
cartridges and prepare a list of Printers will sit ?


As far as the demand is concerned: it is driven by a too long URI 
production issue Colm referred to


Thanks, Sergey

On 29/06/17 09:53, Francesco Chicchiriccò wrote:

On 29/06/2017 10:52, Sergey Beryozkin wrote:

Hi Fabio

That would not work at the generic level as it would require a 2-way 
relationship (cartridge - printer for ex) which is not always 
realistic to expect,


In the Syncope data model, all Relationships are 2-way.

I agree with Fabio: the use case proposed by Colm is doable with 
current implementation.


Naturally, there is always room for improvements, but I don't see much 
demand ATM.


Regards.


On 29/06/17 09:07, Fabio Martelli wrote:



Il 28/06/2017 18:34, Colm O hEigeartaigh ha scritto:
Thanks for the feedback guys! Let me just expand a bit on the 
motivation

behind my previous example

Let's say I'm managing hundreds of printers each of which have a
relationship to a cartridge (of which there are many hundreds) with a
colour attribute. I want to find the printers with a blue cartridge.

So I first make a search for a list of "blue" cartridges. Then I 
search for
the printers that have a relationship with these cartridges. The 
problem is

on the second search I end up with a ginormous search expression
"relationships%3D%3D7db4512-ad25-40e8-bc78-63ad25c0e894%2C%24relationships%3D%3D16dc6acd-6.". 


" that could be an invalid URL.

Is there a better way of handling it than this?
Hi Colm, maybe you can search all the cartridges blue with a 
relationship with a printer.
The result will be a list of cartridges. Each item will be reported 
including a specific field relationships (if I well remember) about 
all the printers related to the item.
In this case, you will have all the info you need retrieved by a 
single short query. Don't you agree?


BR,
F.


Colm.

On Wed, Jun 28, 2017 at 10:52 AM, Sergey Beryozkin 


wrote:


Hi Francesco

One thing I can point to is this code:

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

There, in the end,

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s
earch/src/main/java/org/apache/cxf/jaxrs/ext/search/jpa/Abst
ractJPATypedQueryVisitor.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:


Hi

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

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s

Re: AnyObjects query

2017-06-29 Thread Sergey Beryozkin

Hi Francesco

OK. So, as far as the Syncope returning the list of printers to the 
client code issuing the query, how would it guess that when someone 
searches for the blue cartridges it is actually a list of printers is 
expected ? Where will this code which next goes over the list of all the 
cartridges and prepare a list of Printers will sit ?


As far as the demand is concerned: it is driven by a too long URI 
production issue Colm referred to


Thanks, Sergey

On 29/06/17 09:53, Francesco Chicchiriccò wrote:

On 29/06/2017 10:52, Sergey Beryozkin wrote:

Hi Fabio

That would not work at the generic level as it would require a 2-way 
relationship (cartridge - printer for ex) which is not always 
realistic to expect,


In the Syncope data model, all Relationships are 2-way.

I agree with Fabio: the use case proposed by Colm is doable with current 
implementation.


Naturally, there is always room for improvements, but I don't see much 
demand ATM.


Regards.


On 29/06/17 09:07, Fabio Martelli wrote:



Il 28/06/2017 18:34, Colm O hEigeartaigh ha scritto:
Thanks for the feedback guys! Let me just expand a bit on the 
motivation

behind my previous example

Let's say I'm managing hundreds of printers each of which have a
relationship to a cartridge (of which there are many hundreds) with a
colour attribute. I want to find the printers with a blue cartridge.

So I first make a search for a list of "blue" cartridges. Then I 
search for
the printers that have a relationship with these cartridges. The 
problem is

on the second search I end up with a ginormous search expression
"relationships%3D%3D7db4512-ad25-40e8-bc78-63ad25c0e894%2C%24relationships%3D%3D16dc6acd-6.". 


" that could be an invalid URL.

Is there a better way of handling it than this?
Hi Colm, maybe you can search all the cartridges blue with a 
relationship with a printer.
The result will be a list of cartridges. Each item will be reported 
including a specific field relationships (if I well remember) about 
all the printers related to the item.
In this case, you will have all the info you need retrieved by a 
single short query. Don't you agree?


BR,
F.


Colm.

On Wed, Jun 28, 2017 at 10:52 AM, Sergey Beryozkin 


wrote:


Hi Francesco

One thing I can point to is this code:

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

There, in the end,

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s
earch/src/main/java/org/apache/cxf/jaxrs/ext/search/jpa/Abst
ractJPATypedQueryVisitor.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:


Hi

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

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s
earch/src/test/java/org/apache/cxf/jaxrs/ext/search/jpa/JPAT
ypedQueryVisitorFiqlTest.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] 

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

2017-06-29 Thread Andrea Patricelli (JIRA)

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

Andrea Patricelli resolved SYNCOPE-1110.

Resolution: Fixed

> 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-1110) Error replacing group/auxclass/resource during self-management operation

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

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

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

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

Fixes [SYNCOPE-1110], [SYNCOPE-1123]


> 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-1110) Error replacing group/auxclass/resource during self-management operation

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

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

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

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

Fixes [SYNCOPE-1110], [SYNCOPE-1123]. This closes #47


> 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-1110) Error replacing group/auxclass/resource during self-management operation

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

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

ASF GitHub Bot commented on SYNCOPE-1110:
-

Github user asfgit closed the pull request at:

https://github.com/apache/syncope/pull/47


> 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-1123) Enduser UserRequestValidator NPE on custom form empty sections

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

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

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

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

Fixes [SYNCOPE-1110], [SYNCOPE-1123]


> Enduser UserRequestValidator NPE on custom form empty sections
> --
>
> Key: SYNCOPE-1123
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1123
> Project: Syncope
>  Issue Type: Bug
>  Components: enduser
>Affects Versions: 2.0.3
>Reporter: Andrea Patricelli
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> With this customForm.json like this:
> {code}
> {
>   "PLAIN":
>   {
> "show": true,
> "attributes": 
> {
>   "username":  
>   {
> "defaultValues": [
>   "bellini"
> ]
>   },
>   "firstname":  
>   {
> "readonly": false
>   },
>   "surname":  
>   {
> "defaultValues": [
>   "nuovo_surname"
> ]
>   },
>   "fullname":  
>   {
> "defaultValues": [
>   "fullname"
> ]
>   },
>   "email":  
>   {
> "defaultValues": [
>   "t...@apache.org"
> ]
>   },
>   "userId": 
>   {
> "readonly": false
>   },
>   "ctype": 
>   {
> "readonly": false
>   }
> }
>   },
>   "DERIVED": 
>   {
> "show": false
>   },
>   "VIRTUAL": 
>   {
> "show": true,
> "attributes": {}
>   }
> }
> {code}
> self registration fails due to NPE



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


[jira] [Commented] (SYNCOPE-1123) Enduser UserRequestValidator NPE on custom form empty sections

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

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

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

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

Fixes [SYNCOPE-1110], [SYNCOPE-1123]. This closes #47


> Enduser UserRequestValidator NPE on custom form empty sections
> --
>
> Key: SYNCOPE-1123
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1123
> Project: Syncope
>  Issue Type: Bug
>  Components: enduser
>Affects Versions: 2.0.3
>Reporter: Andrea Patricelli
>Assignee: Andrea Patricelli
> Fix For: 2.0.4, 2.1.0
>
>
> With this customForm.json like this:
> {code}
> {
>   "PLAIN":
>   {
> "show": true,
> "attributes": 
> {
>   "username":  
>   {
> "defaultValues": [
>   "bellini"
> ]
>   },
>   "firstname":  
>   {
> "readonly": false
>   },
>   "surname":  
>   {
> "defaultValues": [
>   "nuovo_surname"
> ]
>   },
>   "fullname":  
>   {
> "defaultValues": [
>   "fullname"
> ]
>   },
>   "email":  
>   {
> "defaultValues": [
>   "t...@apache.org"
> ]
>   },
>   "userId": 
>   {
> "readonly": false
>   },
>   "ctype": 
>   {
> "readonly": false
>   }
> }
>   },
>   "DERIVED": 
>   {
> "show": false
>   },
>   "VIRTUAL": 
>   {
> "show": true,
> "attributes": {}
>   }
> }
> {code}
> self registration fails due to NPE



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


Re: AnyObjects query

2017-06-29 Thread Sergey Beryozkin

Hi Fabio

That would not work at the generic level as it would require a 2-way 
relationship (cartridge - printer for ex) which is not always realistic 
to expect,


Sergey
On 29/06/17 09:07, Fabio Martelli wrote:



Il 28/06/2017 18:34, Colm O hEigeartaigh ha scritto:

Thanks for the feedback guys! Let me just expand a bit on the motivation
behind my previous example

Let's say I'm managing hundreds of printers each of which have a
relationship to a cartridge (of which there are many hundreds) with a
colour attribute. I want to find the printers with a blue cartridge.

So I first make a search for a list of "blue" cartridges. Then I 
search for
the printers that have a relationship with these cartridges. The 
problem is

on the second search I end up with a ginormous search expression
"relationships%3D%3D7db4512-ad25-40e8-bc78-63ad25c0e894%2C%24relationships%3D%3D16dc6acd-6.". 


" that could be an invalid URL.

Is there a better way of handling it than this?
Hi Colm, maybe you can search all the cartridges blue with a 
relationship with a printer.
The result will be a list of cartridges. Each item will be reported 
including a specific field relationships (if I well remember) about all 
the printers related to the item.
In this case, you will have all the info you need retrieved by a single 
short query. Don't you agree?


BR,
F.


Colm.

On Wed, Jun 28, 2017 at 10:52 AM, Sergey Beryozkin 
wrote:


Hi Francesco

One thing I can point to is this code:

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

There, in the end,

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s
earch/src/main/java/org/apache/cxf/jaxrs/ext/search/jpa/Abst
ractJPATypedQueryVisitor.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:


Hi

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

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s
earch/src/test/java/org/apache/cxf/jaxrs/ext/search/jpa/JPAT
ypedQueryVisitorFiqlTest.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/persistenc
e-api/src/main/java/org/apache/syncope/core/persistenc
e/api/search/SearchCondVisitor.java
[2] https://github.com/apache/syncope/blob/2_0_X/core/persistenc
e-jpa/src/main/java/org/apache/syncope/core/persistenc
e/jpa/dao/JPAAnySearchDAO.java
[3] https://github.com/apache/syncope/blob/2_0_X/ext/elasticsear
ch/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 

Re: AnyObjects query

2017-06-29 Thread Sergey Beryozkin

Yes, as far as the convention is concerned, one would express it
as

GET

/printers?_s=cartridges.colour=blue

then at the the next stage it depends if a typed model already exists, 
if yes, then it can work OOB with for ex JPA2 CXF visitor.
In case of Syncope the model is dynamic, hence the custom Syncope 
visitor deals with a string such 'cartridges.colour=blue' itself but at 
the moment it does not attach any significance to a '.'.


It will need to be enhanced for it to process '.' and build a more 
sophisticated Natve JPA query. It is doable, I agree with Francesco it 
will be more involved...


I propose that at least we create a JIRA to track the enhancement request.

I can experiment at the CXF level to enhance its SQLPrinterVisitor to 
see what sort of processing can be required, I'm certain it can be done


Sergey

On 28/06/17 17:34, Colm O hEigeartaigh wrote:

Thanks for the feedback guys! Let me just expand a bit on the motivation
behind my previous example

Let's say I'm managing hundreds of printers each of which have a
relationship to a cartridge (of which there are many hundreds) with a
colour attribute. I want to find the printers with a blue cartridge.

So I first make a search for a list of "blue" cartridges. Then I search for
the printers that have a relationship with these cartridges. The problem is
on the second search I end up with a ginormous search expression
"relationships%3D%3D7db4512-ad25-40e8-bc78-63ad25c0e894%2C%24relationships%3D%3D16dc6acd-6.".
" that could be an invalid URL.

Is there a better way of handling it than this?

Colm.

On Wed, Jun 28, 2017 at 10:52 AM, Sergey Beryozkin 
wrote:


Hi Francesco

One thing I can point to is this code:

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

There, in the end,

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s
earch/src/main/java/org/apache/cxf/jaxrs/ext/search/jpa/Abst
ractJPATypedQueryVisitor.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:


Hi

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

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s
earch/src/test/java/org/apache/cxf/jaxrs/ext/search/jpa/JPAT
ypedQueryVisitorFiqlTest.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/persistenc
e-api/src/main/java/org/apache/syncope/core/persistenc
e/api/search/SearchCondVisitor.java
[2] https://github.com/apache/syncope/blob/2_0_X/core/persistenc
e-jpa/src/main/java/org/apache/syncope/core/persistenc
e/jpa/dao/JPAAnySearchDAO.java
[3] https://github.com/apache/syncope/blob/2_0_X/ext/elasticsear
ch/persistence-jpa/src/main/java/org/apache/syncope/core/
persistence/jpa/dao/ElasticsearchAnySearchDAO.java

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



On 

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

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

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

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

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

[SYNCOPE-1129] Fix IT execution


> 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-29 Thread ASF subversion and git services (JIRA)

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

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

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

[SYNCOPE-1129] Fix IT execution


> 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)


Re: AnyObjects query

2017-06-29 Thread Fabio Martelli



Il 28/06/2017 18:34, Colm O hEigeartaigh ha scritto:

Thanks for the feedback guys! Let me just expand a bit on the motivation
behind my previous example

Let's say I'm managing hundreds of printers each of which have a
relationship to a cartridge (of which there are many hundreds) with a
colour attribute. I want to find the printers with a blue cartridge.

So I first make a search for a list of "blue" cartridges. Then I search for
the printers that have a relationship with these cartridges. The problem is
on the second search I end up with a ginormous search expression
"relationships%3D%3D7db4512-ad25-40e8-bc78-63ad25c0e894%2C%24relationships%3D%3D16dc6acd-6.".
" that could be an invalid URL.

Is there a better way of handling it than this?
Hi Colm, maybe you can search all the cartridges blue with a 
relationship with a printer.
The result will be a list of cartridges. Each item will be reported 
including a specific field relationships (if I well remember) about all 
the printers related to the item.
In this case, you will have all the info you need retrieved by a single 
short query. Don't you agree?


BR,
F.


Colm.

On Wed, Jun 28, 2017 at 10:52 AM, Sergey Beryozkin 
wrote:


Hi Francesco

One thing I can point to is this code:

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

There, in the end,

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s
earch/src/main/java/org/apache/cxf/jaxrs/ext/search/jpa/Abst
ractJPATypedQueryVisitor.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:


Hi

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

https://github.com/apache/cxf/blob/master/rt/rs/extensions/s
earch/src/test/java/org/apache/cxf/jaxrs/ext/search/jpa/JPAT
ypedQueryVisitorFiqlTest.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/persistenc
e-api/src/main/java/org/apache/syncope/core/persistenc
e/api/search/SearchCondVisitor.java
[2] https://github.com/apache/syncope/blob/2_0_X/core/persistenc
e-jpa/src/main/java/org/apache/syncope/core/persistenc
e/jpa/dao/JPAAnySearchDAO.java
[3] https://github.com/apache/syncope/blob/2_0_X/ext/elasticsear
ch/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:


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

2017-06-29 Thread Andrea Patricelli (JIRA)

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

Andrea Patricelli updated SYNCOPE-1136:
---
Issue Type: Improvement  (was: Bug)

> Groups list reset always after realm change
> ---
>
> Key: SYNCOPE-1136
> URL: https://issues.apache.org/jira/browse/SYNCOPE-1136
> Project: Syncope
>  Issue Type: Improvement
>  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)


Re: Master tests failing?

2017-06-29 Thread Francesco Chicchiriccò

On 28/06/2017 19:18, Colm O hEigeartaigh wrote:

I'm seeing some failures on Master...

[INFO]
[ERROR] Failures:
[ERROR]   PolicyITCase.getCorrelationRules:159 expected:<1> but was:<0>
[ERROR]   PullTaskITCase.getPullActionsClasses:104
[ERROR]   ReportITCase.getReportletConfs:61
[ERROR]   ResourceITCase.getPropagationActionsClasses:104
[ERROR]   SchedTaskITCase.getJobClasses:57
[ERROR] Errors:
[ERROR]   AuthenticationITCase.issueSYNCOPE434:504 » SyncopeClient Unknown
[NullPointerE...


Hi Colm,
I have the same: let me take a look, as I believe it's related to my 
changes for SYNCOPE-1129 (even though I cannot figure out why 2_0_X is 
working fine, instead...).


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/