Re: AnyObjects query
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
[ 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
[ 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
[ 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
[ 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]
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
[ 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]
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
[ 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
[ 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
[ 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]
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
[ 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
[ 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
[ 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 AlessandroniDate: 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]
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 AlessandroniDate: 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
[ 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
[ 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
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 Beryozkinwrote: 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
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 Beryozkinwrote: 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
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 Beryozkinwrote: 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
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 Beryozkinwrote: 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
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 Beryozkinwrote: 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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 Beryozkinwrote: 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
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 Beryozkinwrote: 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
[ 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
[ 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
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 Beryozkinwrote: 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
[ 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?
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/