[jira] [Resolved] (UNOMI-204) Optimize pastEvents conditions execution and count
[ https://issues.apache.org/jira/browse/UNOMI-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier resolved UNOMI-204. - Resolution: Fixed > Optimize pastEvents conditions execution and count > -- > > Key: UNOMI-204 > URL: https://issues.apache.org/jira/browse/UNOMI-204 > Project: Apache Unomi > Issue Type: Improvement >Reporter: Thomas Draier >Priority: Major > > Past event condition query execution is based on an aggregate on events to > get all profile ids, then generate an id query on profiles with each id. This > leads to different issues : > - the terms aggregate is limited to 5000 buckets by default ( configurable > thanks to UNOMI-119 ), so the condition will anyway not return more than 5000 > users (which is an issue for updateExistingProfilesForSegment ). The limit is > necessary to avoid out of memory, but we still need the list of profiles - > using aggregate filter/partition should help getting all items. > - The id query can be huge (millions of ids ?) - even if, in the end, we have > a limit on the size of results we want. This is unfortunately difficult to > optimize, as 1/we don't know if a limit will be used or not and 2/ the > condition can be part of a and boolean condition, which would require an > unknown minimal number of ids > - the "count" method is not optimal as it executes the full query and gets > the number of results, where it can in some cases be optimized. For > pastEventCondition, we generate an IdQuery with a list of ids to just get the > count of profiles - counting the ids should be enough, and in some cases we > could even use cardinality aggregate to directly get the count. In all cases, > keeping the list of all ids in memory should not be needed for counting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (UNOMI-204) Optimize pastEvents conditions execution and count
[ https://issues.apache.org/jira/browse/UNOMI-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16647950#comment-16647950 ] Thomas Draier commented on UNOMI-204: - There are multiple optimizations, depending on the cases. Segment creation : 1/ On segment/scoring save, we already had rules created for the existing past event conditions. These rules are setting a property for profile who matched the event condition, with the number of occurences. The initial properties values are initialized for every profile in updateExistingProfilesForPastEventCondition . A simple term aggregate was used, but terms aggregated are limited to 5000 - so only 5000 profiles were updated with the property. I split the term aggregate with partitions so that all profiles are correctly updated, avoiding memory issues. In a second phase, updateExistingProfilesForSegment/ updateExistingProfilesForScoring is called to add/remove segments to all profiles. This is done by doing a query on profiles, with query scrolling, using the PastEventConditionESQueryBuilder. PastEventConditionESQueryBuilder / query : This one was doing a first term aggregate to list all profiles id (still sized to 5000), then generate an id query, then returning the id query. The ids query was maximum 5000 ids, so anyway, it was not possible to have more than 5000 users returned by this query (and was kind of limiting the segments) - I did change the PastEventConditionESQueryBuilder to check if a generated property exists, and use it (which is the case after segment/scoring creation). If number of occurences is specified in the condition, use a range query, otherwise a simple exists query. This is much lighter than the id query, do not need intermediate aggregate, and find all profiles (not only 5000). - If the property is not set, then I still generate an id query - but uses again a split on the term aggregate to avoid the 5000 limit. This may not even be very useful, as I added a limit to the size of the id query that can be generated to avoid creating huge query and memory issues. I rather send an exception here than generate a big (tbd?) query. Note that this case is actually rarely used - in our cases only for getting aggregated count, when the count method cannot be used. queryCount : That's where count methods are introduced - they are called by queryCount if they are available on the condition builder. Only PastEventConditionESQueryBuilder implements it for now - so a count on boolean condition (with inner past events) will still continue to use the query builder (and probably the second case, where property is not set). PastEventConditionESQueryBuilder / count : For count on past event conditions (so, as root condition) , 2 cases : - no min/max event occurences : was doing the query and counting the result, which was : a first term aggregate to list all profiles id (5000), then generate an id query, then execute the id query to get the count of profiles (!). Now, just do a cardinality aggregate, return the total count. - with min/max event occurences : do a term aggregate with partition, and count the profiles that match the number of occurences. Also take into account that buckets are sorted by doc count. Return the count. > Optimize pastEvents conditions execution and count > -- > > Key: UNOMI-204 > URL: https://issues.apache.org/jira/browse/UNOMI-204 > Project: Apache Unomi > Issue Type: Improvement >Reporter: Thomas Draier >Priority: Major > > Past event condition query execution is based on an aggregate on events to > get all profile ids, then generate an id query on profiles with each id. This > leads to different issues : > - the terms aggregate is limited to 5000 buckets by default ( configurable > thanks to UNOMI-119 ), so the condition will anyway not return more than 5000 > users (which is an issue for updateExistingProfilesForSegment ). The limit is > necessary to avoid out of memory, but we still need the list of profiles - > using aggregate filter/partition should help getting all items. > - The id query can be huge (millions of ids ?) - even if, in the end, we have > a limit on the size of results we want. This is unfortunately difficult to > optimize, as 1/we don't know if a limit will be used or not and 2/ the > condition can be part of a and boolean condition, which would require an > unknown minimal number of ids > - the "count" method is not optimal as it executes the full query and gets > the number of results, where it can in some cases be optimized. For > pastEventCondition, we generate an IdQuery with a list of ids to just get the > count of profiles - counting the ids should be enough, and in some cases we > could even use cardinality aggregate to directly get the count.
[jira] [Created] (UNOMI-204) Optimize pastEvents conditions execution and count
Thomas Draier created UNOMI-204: --- Summary: Optimize pastEvents conditions execution and count Key: UNOMI-204 URL: https://issues.apache.org/jira/browse/UNOMI-204 Project: Apache Unomi Issue Type: Improvement Reporter: Thomas Draier Past event condition query execution is based on an aggregate on events to get all profile ids, then generate an id query on profiles with each id. This leads to different issues : - the terms aggregate is limited to 5000 buckets by default ( configurable thanks to UNOMI-119 ), so the condition will anyway not return more than 5000 users (which is an issue for updateExistingProfilesForSegment ). The limit is necessary to avoid out of memory, but we still need the list of profiles - using aggregate filter/partition should help getting all items. - The id query can be huge (millions of ids ?) - even if, in the end, we have a limit on the size of results we want. This is unfortunately difficult to optimize, as 1/we don't know if a limit will be used or not and 2/ the condition can be part of a and boolean condition, which would require an unknown minimal number of ids - the "count" method is not optimal as it executes the full query and gets the number of results, where it can in some cases be optimized. For pastEventCondition, we generate an IdQuery with a list of ids to just get the count of profiles - counting the ids should be enough, and in some cases we could even use cardinality aggregate to directly get the count. In all cases, keeping the list of all ids in memory should not be needed for counting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UNOMI-202) Handle migration scripts for json definitions
[ https://issues.apache.org/jira/browse/UNOMI-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier resolved UNOMI-202. - Resolution: Fixed > Handle migration scripts for json definitions > - > > Key: UNOMI-202 > URL: https://issues.apache.org/jira/browse/UNOMI-202 > Project: Apache Unomi > Issue Type: New Feature >Reporter: Thomas Draier >Assignee: Thomas Draier >Priority: Major > > https://lists.apache.org/thread.html/f77b1955bb01e152ead03822bc40cfe72fdabfe33cd4ca4b4f23fda4@%3Cdev.unomi.apache.org%3E > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (UNOMI-202) Handle migration scripts for json definitions
[ https://issues.apache.org/jira/browse/UNOMI-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier reassigned UNOMI-202: --- Assignee: Thomas Draier > Handle migration scripts for json definitions > - > > Key: UNOMI-202 > URL: https://issues.apache.org/jira/browse/UNOMI-202 > Project: Apache Unomi > Issue Type: New Feature >Reporter: Thomas Draier >Assignee: Thomas Draier >Priority: Major > > https://lists.apache.org/thread.html/f77b1955bb01e152ead03822bc40cfe72fdabfe33cd4ca4b4f23fda4@%3Cdev.unomi.apache.org%3E > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UNOMI-201) Remove context.js script
[ https://issues.apache.org/jira/browse/UNOMI-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier resolved UNOMI-201. - Resolution: Fixed > Remove context.js script > > > Key: UNOMI-201 > URL: https://issues.apache.org/jira/browse/UNOMI-201 > Project: Apache Unomi > Issue Type: Task >Reporter: Thomas Draier >Priority: Major > > As discussed in > https://lists.apache.org/thread.html/46b266516735faf3fc5efd510c1afc149b44d62215b424b6f3aae245@%3Cdev.unomi.apache.org%3E > , we can remove the script generated by /context.js call -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UNOMI-202) Handle migration scripts for json definitions
Thomas Draier created UNOMI-202: --- Summary: Handle migration scripts for json definitions Key: UNOMI-202 URL: https://issues.apache.org/jira/browse/UNOMI-202 Project: Apache Unomi Issue Type: New Feature Reporter: Thomas Draier https://lists.apache.org/thread.html/f77b1955bb01e152ead03822bc40cfe72fdabfe33cd4ca4b4f23fda4@%3Cdev.unomi.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UNOMI-201) Remove context.js script
Thomas Draier created UNOMI-201: --- Summary: Remove context.js script Key: UNOMI-201 URL: https://issues.apache.org/jira/browse/UNOMI-201 Project: Apache Unomi Issue Type: Task Reporter: Thomas Draier As discussed in https://lists.apache.org/thread.html/46b266516735faf3fc5efd510c1afc149b44d62215b424b6f3aae245@%3Cdev.unomi.apache.org%3E , we can remove the script generated by /context.js call -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UNOMI-198) Segment evaluation can go into infinite recursion
[
https://issues.apache.org/jira/browse/UNOMI-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Draier resolved UNOMI-198.
-
Resolution: Fixed
> Segment evaluation can go into infinite recursion
> -
>
> Key: UNOMI-198
> URL: https://issues.apache.org/jira/browse/UNOMI-198
> Project: Apache Unomi
> Issue Type: Bug
>Affects Versions: 1.1.0-incubating, 1.2.0-incubating, 1.3.0-incubating
>Reporter: Thomas Draier
>Assignee: Thomas Draier
>Priority: Major
> Fix For: 1.4.0-incubating
>
>
> Every time a profile is update, an updatedProfile event is sent and triggers
> the segment evaluation rule. It's easy to create a segment of all users that
> are not in this segment, which will produce an infinite recursion and go
> into StackOverflowError :
> {code:json}
> {
> "itemId": "_3a71uuslk",
> "itemType": "segment",
> "version": 4,
> "condition": {
> "parameterValues": {
> "segments": ["_3a71uuslk"],
> "matchType": "none"
> },
> "type": "profileSegmentCondition"
> },
> "metadata": {
> "id": "_3a71uuslk",
> "name": "test",
> "description": null,
> "scope": "systemscope",
> "tags": [],
> "systemTags": [],
> "enabled": false,
> "missingPlugins": false,
> "hidden": false,
> "readOnly": false
> }
> }
> {code}
>
> Probably other kind of rules can also go into StackOverflowError. We should
> try to avoid going into this kind of recursion
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (UNOMI-197) Disabling a segment has no impact when getting the list of segments of a user
[ https://issues.apache.org/jira/browse/UNOMI-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier resolved UNOMI-197. - Resolution: Fixed > Disabling a segment has no impact when getting the list of segments of a user > - > > Key: UNOMI-197 > URL: https://issues.apache.org/jira/browse/UNOMI-197 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier >Priority: Major > > The method getSegmentsAndScoresForProfile, which is used by the rule to > evaluate the segments of a user, does not check the enabled/disabled status > of a segment ( although it does it for the scoring plans) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UNOMI-198) Segment evaluation can go into infinite recursion
Thomas Draier created UNOMI-198:
---
Summary: Segment evaluation can go into infinite recursion
Key: UNOMI-198
URL: https://issues.apache.org/jira/browse/UNOMI-198
Project: Apache Unomi
Issue Type: Bug
Reporter: Thomas Draier
Assignee: Thomas Draier
Every time a profile is update, an updatedProfile event is sent and triggers
the segment evaluation rule. It's easy to create a segment of all users that
are not in this segment, which will produce an infinite recursion and go into
StackOverflowError :
{code:json}
{
"itemId": "_3a71uuslk",
"itemType": "segment",
"version": 4,
"condition": {
"parameterValues": {
"segments": ["_3a71uuslk"],
"matchType": "none"
},
"type": "profileSegmentCondition"
},
"metadata": {
"id": "_3a71uuslk",
"name": "test",
"description": null,
"scope": "systemscope",
"tags": [],
"systemTags": [],
"enabled": false,
"missingPlugins": false,
"hidden": false,
"readOnly": false
}
}
{code}
Probably other kind of rules can also go into StackOverflowError. We should try
to avoid going into this kind of recursion
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (UNOMI-197) Disabling a segment has no impact when getting the list of segments of a user
Thomas Draier created UNOMI-197: --- Summary: Disabling a segment has no impact when getting the list of segments of a user Key: UNOMI-197 URL: https://issues.apache.org/jira/browse/UNOMI-197 Project: Apache Unomi Issue Type: Bug Reporter: Thomas Draier Assignee: Thomas Draier The method getSegmentsAndScoresForProfile, which is used by the rule to evaluate the segments of a user, does not check the enabled/disabled status of a segment ( although it does it for the scoring plans) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UNOMI-154) Update build documentation
Thomas Draier created UNOMI-154: --- Summary: Update build documentation Key: UNOMI-154 URL: https://issues.apache.org/jira/browse/UNOMI-154 Project: Apache Unomi Issue Type: Task Reporter: Thomas Draier The documentation at [https://unomi.incubator.apache.org/versions/1.2/building-and-deploying.html] does not seem uptodate anymore : * configuration files in an existing karaf should be updated * additional features are in the package, which are not described here -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (UNOMI-153) Profiles Import rules are not replicated in cluster
Thomas Draier created UNOMI-153: --- Summary: Profiles Import rules are not replicated in cluster Key: UNOMI-153 URL: https://issues.apache.org/jira/browse/UNOMI-153 Project: Apache Unomi Issue Type: Improvement Affects Versions: 1.2.0-incubating Reporter: Thomas Draier When creating a new import (or export ) configuration, a route is created in camel only on the local node. There will be created on other nodes only when they restart (or when the import bundles restart). An automatic refresh should happen more frequently. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (UNOMI-149) Fallback is not returned when no conditions match in a scoring condition strategy
[ https://issues.apache.org/jira/browse/UNOMI-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier resolved UNOMI-149. - Resolution: Fixed > Fallback is not returned when no conditions match in a scoring condition > strategy > - > > Key: UNOMI-149 > URL: https://issues.apache.org/jira/browse/UNOMI-149 > Project: Apache Unomi > Issue Type: Bug >Affects Versions: 1.3.0-incubating >Reporter: Mohamed-Tayeb BENTERKI >Priority: Major > Fix For: 1.3.0-incubating > > > Solution could be: improve the strategy of getting the personalized content, > through adding a boolean condition to test if there is at least one condition > that matches with the personalization -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (UNOMI-134) Added personalized sort feature in ContextServlet
[
https://issues.apache.org/jira/browse/UNOMI-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Draier updated UNOMI-134:
Description:
Hi,
In order to use unomi to personalization, we currently rely on the "filter"
feature of the ContextServlet. This field allows to ask unomi if a condition is
matched or not by the current user/session. This is however quite limited to do
complex personalization - we don't only want to know if a content matches/does
not match a user, but rather know which content matches "best". Instead of
simple a yes/no filter.
I suggest we add a new field in the ContextRequest, that would allow to ask
unomi for a sort. Unomi could have different (pluggable) strategies to do the
sort.
As an example, the "score" strategy could sort the items based "scoring plan"
like condition - each item is associated a list of condition-score pairs -
score with matching conditions are summed up and items sorted based on the
final score value.
Context request could look like :
{{ {
...
"source" : .. ,
"events" : [ ... ],
"sorts" : [
{
"id":"mysort",
"strategy": "score",
"strategyOptions": {
"threshold" : 10
},
"contents" : [
{
"filterid": "item1",
"filters": [
{
"condition": {
"parameterValues": {
"segments": [
"_nfpvub955"
],
"matchType": "all"
},
"type": "profileSegmentCondition"
},
"properties": {
"score":25
}
}
]
},
{
"filterid": "item2",
"filters": [
{
"condition": {
"type": "deviceCategoryCondition",
"parameterValues": {
"deviceCategories": [
"PDA",
"Personal computer"
],
"matchType": "in"
}
},
"properties": {
"score":100
}
}
]
}
]
}
]
...
} }}
Based on the results, unomi will return the sorted list :
{{ {
...
"sortResults":{"mysort":["item1","item2"]}
...
} }}
Strategies would be implemented as dedicated classes, taking the Sort object as
parameter, returning sorted list of ids.
Other simpler strategies that could be used for personalization could be a
simple "filter" (as the current filter field, will just filter the list based
on the fact a condition is matched or not, but keep the order), or "random"
(same as filter, but randomly sort the results at the end)
was:
Hi,
In order to use unomi to personalization, we currently rely on the "filter"
feature of the ContextServlet. This field allows to ask unomi if a condition is
matched or not by the current user/session. This is however quite limited to do
complex personalization - we don't only want to know if a content matches/does
not match a user, but rather know which content matches "best". Instead of
simple a yes/no filter.
I suggest we add a new field in the ContextRequest, that would allow to ask
unomi for a sort. Unomi could have different (pluggable) strategies to do the
sort.
As an example, the "score" strategy could sort the items based "scoring plan"
like condition - each item is associated a list of condition-score pairs -
score with matching conditions are summed up and items sorted based on the
final score value.
Context request could look like :
{{
{
...
"source" : .. ,
"events" : [ ... ],
"sorts" : [
{
"id":"mysort",
"strategy": "score",
"strategyOptions": {
"threshold" : 10
},
"contents" : [
{
"filterid": "item1",
"filters": [
{
"condition": {
"parameterValues": {
"segments": [
"_nfpvub955"
],
"matchType": "all"
},
"type": "profileSegmentCondition"
},
"properties": {
"score":25
}
}
]
},
{
"filterid": "item2",
"filters": [
{
"condition": {
"type": "deviceCategoryCondition",
"parameterValues": {
"deviceCategories": [
"PDA",
"Personal computer"
],
"matchType": "in"
}
},
"properties": {
"score":100
}
}
]
}
]
}
]
...
}
}}
Based on the results, unomi will return the sorted list :
{{
{
...
[jira] [Created] (UNOMI-134) Added personalized sort feature in ContextServlet
Thomas Draier created UNOMI-134:
---
Summary: Added personalized sort feature in ContextServlet
Key: UNOMI-134
URL: https://issues.apache.org/jira/browse/UNOMI-134
Project: Apache Unomi
Issue Type: New Feature
Components: web
Reporter: Thomas Draier
Assignee: Thomas Draier
Priority: Normal
Hi,
In order to use unomi to personalization, we currently rely on the "filter"
feature of the ContextServlet. This field allows to ask unomi if a condition is
matched or not by the current user/session. This is however quite limited to do
complex personalization - we don't only want to know if a content matches/does
not match a user, but rather know which content matches "best". Instead of
simple a yes/no filter.
I suggest we add a new field in the ContextRequest, that would allow to ask
unomi for a sort. Unomi could have different (pluggable) strategies to do the
sort.
As an example, the "score" strategy could sort the items based "scoring plan"
like condition - each item is associated a list of condition-score pairs -
score with matching conditions are summed up and items sorted based on the
final score value.
Context request could look like :
{{
{
...
"source" : .. ,
"events" : [ ... ],
"sorts" : [
{
"id":"mysort",
"strategy": "score",
"strategyOptions": {
"threshold" : 10
},
"contents" : [
{
"filterid": "item1",
"filters": [
{
"condition": {
"parameterValues": {
"segments": [
"_nfpvub955"
],
"matchType": "all"
},
"type": "profileSegmentCondition"
},
"properties": {
"score":25
}
}
]
},
{
"filterid": "item2",
"filters": [
{
"condition": {
"type": "deviceCategoryCondition",
"parameterValues": {
"deviceCategories": [
"PDA",
"Personal computer"
],
"matchType": "in"
}
},
"properties": {
"score":100
}
}
]
}
]
}
]
...
}
}}
Based on the results, unomi will return the sorted list :
{{
{
...
"sortResults":{"mysort":["item1","item2"]}
...
}
}}
Strategies would be implemented as dedicated classes, taking the Sort object as
parameter, returning sorted list of ids.
Other simpler strategies that could be used for personalization could be a
simple "filter" (as the current filter field, will just filter the list based
on the fact a condition is matched or not, but keep the order), or "random"
(same as filter, but randomly sort the results at the end)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (UNOMI-37) Add incubator-relevant information to website
[ https://issues.apache.org/jira/browse/UNOMI-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier updated UNOMI-37: --- Fix Version/s: (was: 1.1.0-incubating) 1.2.0-incubating > Add incubator-relevant information to website > - > > Key: UNOMI-37 > URL: https://issues.apache.org/jira/browse/UNOMI-37 > Project: Apache Unomi > Issue Type: Improvement > Components: website >Affects Versions: 1.1.0-incubating >Reporter: Christophe Laprun >Priority: Minor > Fix For: 1.2.0-incubating > > > See http://incubator.apache.org/guides/branding.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (UNOMI-58) issue when deploying binary package
[ https://issues.apache.org/jira/browse/UNOMI-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier closed UNOMI-58. -- > issue when deploying binary package > --- > > Key: UNOMI-58 > URL: https://issues.apache.org/jira/browse/UNOMI-58 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.1.0-incubating > > > The copy-karaf target crashes when deploying jars to repository, because it > actually tries to move the same file twice. Using a copy instead would avoid > the issue -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (UNOMI-57) Fix LGPL license issues within binary build
[ https://issues.apache.org/jira/browse/UNOMI-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier resolved UNOMI-57. Resolution: Fixed > Fix LGPL license issues within binary build > --- > > Key: UNOMI-57 > URL: https://issues.apache.org/jira/browse/UNOMI-57 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (UNOMI-58) issue when deploying binary package
[ https://issues.apache.org/jira/browse/UNOMI-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier updated UNOMI-58: --- Fix Version/s: 1.1.0-incubating > issue when deploying binary package > --- > > Key: UNOMI-58 > URL: https://issues.apache.org/jira/browse/UNOMI-58 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.1.0-incubating > > > The copy-karaf target crashes when deploying jars to repository, because it > actually tries to move the same file twice. Using a copy instead would avoid > the issue -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (UNOMI-58) issue when deploying binary package
[ https://issues.apache.org/jira/browse/UNOMI-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier resolved UNOMI-58. Resolution: Fixed > issue when deploying binary package > --- > > Key: UNOMI-58 > URL: https://issues.apache.org/jira/browse/UNOMI-58 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.1.0-incubating > > > The copy-karaf target crashes when deploying jars to repository, because it > actually tries to move the same file twice. Using a copy instead would avoid > the issue -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (UNOMI-58) issue when deploying binary package
Thomas Draier created UNOMI-58: -- Summary: issue when deploying binary package Key: UNOMI-58 URL: https://issues.apache.org/jira/browse/UNOMI-58 Project: Apache Unomi Issue Type: Bug Reporter: Thomas Draier Assignee: Thomas Draier The copy-karaf target crashes when deploying jars to repository, because it actually tries to move the same file twice. Using a copy instead would avoid the issue -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (UNOMI-57) Fix LGPL license issues within binary build
Thomas Draier created UNOMI-57: -- Summary: Fix LGPL license issues within binary build Key: UNOMI-57 URL: https://issues.apache.org/jira/browse/UNOMI-57 Project: Apache Unomi Issue Type: Bug Reporter: Thomas Draier Assignee: Thomas Draier -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (UNOMI-55) typing issue in defaultDeniedProperties (org.apache.unomi.privacy.cfg)
[ https://issues.apache.org/jira/browse/UNOMI-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier updated UNOMI-55: --- Fix Version/s: 1.1.0-incubating > typing issue in defaultDeniedProperties (org.apache.unomi.privacy.cfg) > -- > > Key: UNOMI-55 > URL: https://issues.apache.org/jira/browse/UNOMI-55 > Project: Apache Unomi > Issue Type: Bug >Reporter: Damien GAILLARD > Fix For: 1.1.0-incubating > > > Tested CXS 1.1.0 #685: > - open /etc/org.apache.unomi.privacy.cfg > - the property "linedInId" has a typing issue - the "k" is missing > -> please add (linkedInId) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (UNOMI-54) Add mappings for scoring and userList + add score mapping in profile
[ https://issues.apache.org/jira/browse/UNOMI-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier updated UNOMI-54: --- Fix Version/s: 1.1.0-incubating > Add mappings for scoring and userList + add score mapping in profile > > > Key: UNOMI-54 > URL: https://issues.apache.org/jira/browse/UNOMI-54 > Project: Apache Unomi > Issue Type: Improvement >Reporter: Quentin Lamerand >Assignee: Quentin Lamerand > Fix For: 1.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (UNOMI-46) Avoid NPE when asking for the definition of a missing tag + Return 404
[ https://issues.apache.org/jira/browse/UNOMI-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier updated UNOMI-46: --- Fix Version/s: 1.1.0-incubating > Avoid NPE when asking for the definition of a missing tag + Return 404 > -- > > Key: UNOMI-46 > URL: https://issues.apache.org/jira/browse/UNOMI-46 > Project: Apache Unomi > Issue Type: Bug >Reporter: Quentin Lamerand >Assignee: Quentin Lamerand > Fix For: 1.1.0-incubating > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (UNOMI-48) Add validation to scoring plan deletion
[ https://issues.apache.org/jira/browse/UNOMI-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier updated UNOMI-48: --- Fix Version/s: 1.1.0-incubating > Add validation to scoring plan deletion > --- > > Key: UNOMI-48 > URL: https://issues.apache.org/jira/browse/UNOMI-48 > Project: Apache Unomi > Issue Type: Bug >Reporter: Quentin Lamerand >Assignee: Quentin Lamerand > Fix For: 1.1.0-incubating > > > Like for the segments, add validation to scoring plan deletion to check > before if it's used elsewhere in a condition -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (UNOMI-30) Move out specific conditions/rules from unomi
[ https://issues.apache.org/jira/browse/UNOMI-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier reopened UNOMI-30: > Move out specific conditions/rules from unomi > - > > Key: UNOMI-30 > URL: https://issues.apache.org/jira/browse/UNOMI-30 > Project: Apache Unomi > Issue Type: Task >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.1.0-incubating > > > Lot of conditions provided by default in Unomi are actually related to Jahia > usage and should be moved out from the standard package. It now possible to > dynamically register custom condition/rules thanks to UNOMI-23 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (UNOMI-30) Move out specific conditions/rules from unomi
[ https://issues.apache.org/jira/browse/UNOMI-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier closed UNOMI-30. -- Resolution: Fixed > Move out specific conditions/rules from unomi > - > > Key: UNOMI-30 > URL: https://issues.apache.org/jira/browse/UNOMI-30 > Project: Apache Unomi > Issue Type: Task >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.1.0-incubating > > > Lot of conditions provided by default in Unomi are actually related to Jahia > usage and should be moved out from the standard package. It now possible to > dynamically register custom condition/rules thanks to UNOMI-23 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (UNOMI-26) Query default limit is 0 (no results)
[ https://issues.apache.org/jira/browse/UNOMI-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier closed UNOMI-26. -- > Query default limit is 0 (no results) > - > > Key: UNOMI-26 > URL: https://issues.apache.org/jira/browse/UNOMI-26 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.1.0-incubating > > > When using a Query object through the rest endpoint, default limit is 0, so > no results are returned . We should either use -1 or a higher default value > for the result size limit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (UNOMI-25) CSV export do not contains user segments
[ https://issues.apache.org/jira/browse/UNOMI-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier updated UNOMI-25: --- Fix Version/s: 1.1.0-incubating > CSV export do not contains user segments > > > Key: UNOMI-25 > URL: https://issues.apache.org/jira/browse/UNOMI-25 > Project: Apache Unomi > Issue Type: Improvement >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.1.0-incubating > > > It would be nice to include segment names in CSV profile export -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (UNOMI-25) CSV export do not contains user segments
[ https://issues.apache.org/jira/browse/UNOMI-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier closed UNOMI-25. -- > CSV export do not contains user segments > > > Key: UNOMI-25 > URL: https://issues.apache.org/jira/browse/UNOMI-25 > Project: Apache Unomi > Issue Type: Improvement >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.1.0-incubating > > > It would be nice to include segment names in CSV profile export -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (UNOMI-29) Event chain can be executed on previous profile in case of profile switch
[ https://issues.apache.org/jira/browse/UNOMI-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier updated UNOMI-29: --- Fix Version/s: 1.1.0-incubating > Event chain can be executed on previous profile in case of profile switch > - > > Key: UNOMI-29 > URL: https://issues.apache.org/jira/browse/UNOMI-29 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.1.0-incubating > > > When the MergeProfiles action is executed and detect a profile switch (user > is logging out / logging in with a different user), the rest of the actions, > like EvaluateProfileSegmentsAction, are executed on the previous profile, > where they should be called on the new profile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (UNOMI-23) Allows to dynamically add custom conditions
[ https://issues.apache.org/jira/browse/UNOMI-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier updated UNOMI-23: --- Fix Version/s: 1.1.0-incubating > Allows to dynamically add custom conditions > --- > > Key: UNOMI-23 > URL: https://issues.apache.org/jira/browse/UNOMI-23 > Project: Apache Unomi > Issue Type: Improvement >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.1.0-incubating > > > I was thinking of some possible improvements on the condition types, to make > them more flexible. > Currently, condition types are defined in unomi plugins - they are read from > a json inside a plugin bundle, and then loaded into memory. Some of the base > conditions rely on actual java code, so it make sense to put them into a > bundle - but other some other conditions are only simple combination of other > conditions, and are usually very specific to a domain. An end user may want > to create his own condition using simple JSON definition, and may not want to > develop and deploy a bundle just for that. It would be nice to be able to add > new condition types by simply using REST API. > If you look at the pageViewEventCondition - it is only based on simple > boolean and property conditions, and is very specific to the type of events > that will be sent by a third party server. They should get out of default > unomi installation, and rather be created directly by the server that will > send these events. > Allowing to create/edit conditions will of course require to persist them, > and so require some changes in the ConditionType object, changing from > "PluginType" to "Item", and the way they are read by the definitions service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (UNOMI-23) Allows to dynamically add custom conditions
[ https://issues.apache.org/jira/browse/UNOMI-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier closed UNOMI-23. -- > Allows to dynamically add custom conditions > --- > > Key: UNOMI-23 > URL: https://issues.apache.org/jira/browse/UNOMI-23 > Project: Apache Unomi > Issue Type: Improvement >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.1.0-incubating > > > I was thinking of some possible improvements on the condition types, to make > them more flexible. > Currently, condition types are defined in unomi plugins - they are read from > a json inside a plugin bundle, and then loaded into memory. Some of the base > conditions rely on actual java code, so it make sense to put them into a > bundle - but other some other conditions are only simple combination of other > conditions, and are usually very specific to a domain. An end user may want > to create his own condition using simple JSON definition, and may not want to > develop and deploy a bundle just for that. It would be nice to be able to add > new condition types by simply using REST API. > If you look at the pageViewEventCondition - it is only based on simple > boolean and property conditions, and is very specific to the type of events > that will be sent by a third party server. They should get out of default > unomi installation, and rather be created directly by the server that will > send these events. > Allowing to create/edit conditions will of course require to persist them, > and so require some changes in the ConditionType object, changing from > "PluginType" to "Item", and the way they are read by the definitions service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (UNOMI-20) birthDate range definition is inconsistent
[ https://issues.apache.org/jira/browse/UNOMI-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier updated UNOMI-20: --- Fix Version/s: 1.1.0-incubating > birthDate range definition is inconsistent > -- > > Key: UNOMI-20 > URL: https://issues.apache.org/jira/browse/UNOMI-20 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier >Priority: Minor > Fix For: 1.1.0-incubating > > > The birthDate property defines inconsistent ranges : they not get all > possible values (ranges from now to now-10y, next range start at now-11y) and > has overlaps (one range is 10 years ago to now, another range is 51 years ago > to now) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (UNOMI-40) scoring plans update leads to NPE
[ https://issues.apache.org/jira/browse/UNOMI-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier resolved UNOMI-40. Resolution: Fixed > scoring plans update leads to NPE > - > > Key: UNOMI-40 > URL: https://issues.apache.org/jira/browse/UNOMI-40 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier > > When creating or updating a new scoring plan, the update of existing profiles > gives a npe in the logs : > org.apache.cxf.interceptor.Fault: failed to execute script > at > org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:170)[126:org.apache.cxf.cxf-api:2.7.11] > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:136)[126:org.apache.cxf.cxf-api:2.7.11] > at > org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:204)[139:org.apache.cxf.cxf-rt-frontend-jaxrs:2.7.11] > at > org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:101)[139:org.apache.cxf.cxf-rt-frontend-jaxrs:2.7.11] > at > org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)[126:org.apache.cxf.cxf-api:2.7.11] > at > org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:94)[126:org.apache.cxf.cxf-api:2.7.11] > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)[126:org.apache.cxf.cxf-api:2.7.11] > at > org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)[126:org.apache.cxf.cxf-api:2.7.11] > at > org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241)[133:org.apache.cxf.cxf-rt-transports-http:2.7.11] > at > org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:248)[133:org.apache.cxf.cxf-rt-transports-http:2.7.11] > at > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:222)[133:org.apache.cxf.cxf-rt-transports-http:2.7.11] > at > org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:153)[133:org.apache.cxf.cxf-rt-transports-http:2.7.11] > at > org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:171)[133:org.apache.cxf.cxf-rt-transports-http:2.7.11] > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286)[133:org.apache.cxf.cxf-rt-transports-http:2.7.11] > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206)[133:org.apache.cxf.cxf-rt-transports-http:2.7.11] > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:595)[65:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0.0] > at > org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:262)[133:org.apache.cxf.cxf-rt-transports-http:2.7.11] > at Proxyfa6b6d5e_069f_477a_a050_bcfdaf25f5ef.service(Unknown Source)[:] > at > org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)[70:org.eclipse.jetty.aggregate.jetty-all-server:8.1.17.v20150415] > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:503)[70:org.eclipse.jetty.aggregate.jetty-all-server:8.1.17.v20150415] > at > org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[79:org.ops4j.pax.web.pax-web-jetty:3.2.3] > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[70:org.eclipse.jetty.aggregate.jetty-all-server:8.1.17.v20150415] > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)[70:org.eclipse.jetty.aggregate.jetty-all-server:8.1.17.v20150415] > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[70:org.eclipse.jetty.aggregate.jetty-all-server:8.1.17.v20150415] > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[70:org.eclipse.jetty.aggregate.jetty-all-server:8.1.17.v20150415] > at > org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:240)[79:org.ops4j.pax.web.pax-web-jetty:3.2.3] > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429)[70:org.eclipse.jetty.aggregate.jetty-all-server:8.1.17.v20150415] > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[70:org.eclipse.jetty.aggregate.jetty-all-server:8.1.17.v20150415] > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[70:org.eclipse.jetty.aggregate.jetty-all-server:8.1.17.v20150415] >
[jira] [Created] (UNOMI-39) Privacy service : handle anonymous browsing
Thomas Draier created UNOMI-39: -- Summary: Privacy service : handle anonymous browsing Key: UNOMI-39 URL: https://issues.apache.org/jira/browse/UNOMI-39 Project: Apache Unomi Issue Type: Improvement Reporter: Thomas Draier Assignee: Thomas Draier A user can choose through the privacy API if he want to browse anonymously or not. He also has the possibility to anonymize all his previous browsing data and detach it from his current profile. An "anonymous" profile should be used instead of the real user profile to store all these events/session. The anonymous profile should not store any property or segment. The anonymous profile should only keep browsing information. There should be no link from an anonymous profile to the real profile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (UNOMI-30) Move out specific conditions/rules from unomi
[ https://issues.apache.org/jira/browse/UNOMI-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier resolved UNOMI-30. Resolution: Fixed > Move out specific conditions/rules from unomi > - > > Key: UNOMI-30 > URL: https://issues.apache.org/jira/browse/UNOMI-30 > Project: Apache Unomi > Issue Type: Task >Reporter: Thomas Draier >Assignee: Thomas Draier > > Lot of conditions provided by default in Unomi are actually related to Jahia > usage and should be moved out from the standard package. It now possible to > dynamically register custom condition/rules thanks to UNOMI-23 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (UNOMI-30) Move out specific conditions/rules from unomi
Thomas Draier created UNOMI-30: -- Summary: Move out specific conditions/rules from unomi Key: UNOMI-30 URL: https://issues.apache.org/jira/browse/UNOMI-30 Project: Apache Unomi Issue Type: Task Reporter: Thomas Draier Assignee: Thomas Draier Lot of conditions provided by default in Unomi are actually related to Jahia usage and should be moved out from the standard package. It now possible to dynamically register custom condition/rules thanks to UNOMI-23 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (UNOMI-29) Event chain can be executed on previous profile in case of profile switch
[ https://issues.apache.org/jira/browse/UNOMI-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier resolved UNOMI-29. Resolution: Fixed > Event chain can be executed on previous profile in case of profile switch > - > > Key: UNOMI-29 > URL: https://issues.apache.org/jira/browse/UNOMI-29 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier > > When the MergeProfiles action is executed and detect a profile switch (user > is logging out / logging in with a different user), the rest of the actions, > like EvaluateProfileSegmentsAction, are executed on the previous profile, > where they should be called on the new profile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (UNOMI-29) Event chain can be executed on previous profile in case of profile switch
Thomas Draier created UNOMI-29: -- Summary: Event chain can be executed on previous profile in case of profile switch Key: UNOMI-29 URL: https://issues.apache.org/jira/browse/UNOMI-29 Project: Apache Unomi Issue Type: Bug Reporter: Thomas Draier When the MergeProfiles action is executed and detect a profile switch (user is logging out / logging in with a different user), the rest of the actions, like EvaluateProfileSegmentsAction, are executed on the previous profile, where they should be called on the new profile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (UNOMI-26) Query default limit is 0 (no results)
[ https://issues.apache.org/jira/browse/UNOMI-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier resolved UNOMI-26. Resolution: Fixed > Query default limit is 0 (no results) > - > > Key: UNOMI-26 > URL: https://issues.apache.org/jira/browse/UNOMI-26 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier > > When using a Query object through the rest endpoint, default limit is 0, so > no results are returned . We should either use -1 or a higher default value > for the result size limit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (UNOMI-26) Query default limit is 0 (no results)
[ https://issues.apache.org/jira/browse/UNOMI-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15257757#comment-15257757 ] Thomas Draier commented on UNOMI-26: Default result size set to 10. Added configuration in org.apache.unomi.persistence.elasticsearch.cfg file : defaultQueryLimit=10 > Query default limit is 0 (no results) > - > > Key: UNOMI-26 > URL: https://issues.apache.org/jira/browse/UNOMI-26 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier > > When using a Query object through the rest endpoint, default limit is 0, so > no results are returned . We should either use -1 or a higher default value > for the result size limit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (UNOMI-26) Query default limit is 0 (no results)
Thomas Draier created UNOMI-26: -- Summary: Query default limit is 0 (no results) Key: UNOMI-26 URL: https://issues.apache.org/jira/browse/UNOMI-26 Project: Apache Unomi Issue Type: Bug Reporter: Thomas Draier When using a Query object through the rest endpoint, default limit is 0, so no results are returned . We should either use -1 or a higher default value for the result size limit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (UNOMI-26) Query default limit is 0 (no results)
[ https://issues.apache.org/jira/browse/UNOMI-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier reassigned UNOMI-26: -- Assignee: Thomas Draier > Query default limit is 0 (no results) > - > > Key: UNOMI-26 > URL: https://issues.apache.org/jira/browse/UNOMI-26 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier > > When using a Query object through the rest endpoint, default limit is 0, so > no results are returned . We should either use -1 or a higher default value > for the result size limit. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (UNOMI-25) CSV export do not contains user segments
Thomas Draier created UNOMI-25: -- Summary: CSV export do not contains user segments Key: UNOMI-25 URL: https://issues.apache.org/jira/browse/UNOMI-25 Project: Apache Unomi Issue Type: Improvement Reporter: Thomas Draier Assignee: Thomas Draier It would be nice to include segment names in CSV profile export -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (UNOMI-24) Contextual parameters not interpolated in PastEventConditions
[
https://issues.apache.org/jira/browse/UNOMI-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Draier resolved UNOMI-24.
Resolution: Fixed
> Contextual parameters not interpolated in PastEventConditions
> -
>
> Key: UNOMI-24
> URL: https://issues.apache.org/jira/browse/UNOMI-24
> Project: Apache Unomi
> Issue Type: Bug
>Reporter: Thomas Draier
>Assignee: Thomas Draier
>
> By creating the following custom condition :
> {
> "metadata": {
> "id": "productPurchaseProfileCondition",
> "name": "productPurchaseProfileCondition",
> "description": "",
> "tags": [
> "event",
> "profileCondition"
> ],
> "readOnly": true
> },
> "parentCondition": {
> "type": "pastEventCondition",
> "parameterValues": {
> "eventCondition": {
> "type": "productPurchaseEventCondition",
> "parameterValues": {
> "productId": "parameter::productId"
> }
> },
> "minimumEventCount": 1
> }
> },
> "parameters": [
> {
> "id": "productId",
> "type": "string",
> "multivalued": false
> }
> ]
> }
> The "productId" is not replaced by the parameter value
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (UNOMI-24) Contextual parameters not interpolated in PastEventConditions
Thomas Draier created UNOMI-24:
--
Summary: Contextual parameters not interpolated in
PastEventConditions
Key: UNOMI-24
URL: https://issues.apache.org/jira/browse/UNOMI-24
Project: Apache Unomi
Issue Type: Bug
Reporter: Thomas Draier
Assignee: Thomas Draier
By creating the following custom condition :
{
"metadata": {
"id": "productPurchaseProfileCondition",
"name": "productPurchaseProfileCondition",
"description": "",
"tags": [
"event",
"profileCondition"
],
"readOnly": true
},
"parentCondition": {
"type": "pastEventCondition",
"parameterValues": {
"eventCondition": {
"type": "productPurchaseEventCondition",
"parameterValues": {
"productId": "parameter::productId"
}
},
"minimumEventCount": 1
}
},
"parameters": [
{
"id": "productId",
"type": "string",
"multivalued": false
}
]
}
The "productId" is not replaced by the parameter value
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (UNOMI-23) Allows to dynamically add custom conditions
[ https://issues.apache.org/jira/browse/UNOMI-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier resolved UNOMI-23. Resolution: Fixed > Allows to dynamically add custom conditions > --- > > Key: UNOMI-23 > URL: https://issues.apache.org/jira/browse/UNOMI-23 > Project: Apache Unomi > Issue Type: Improvement >Reporter: Thomas Draier >Assignee: Thomas Draier > > I was thinking of some possible improvements on the condition types, to make > them more flexible. > Currently, condition types are defined in unomi plugins - they are read from > a json inside a plugin bundle, and then loaded into memory. Some of the base > conditions rely on actual java code, so it make sense to put them into a > bundle - but other some other conditions are only simple combination of other > conditions, and are usually very specific to a domain. An end user may want > to create his own condition using simple JSON definition, and may not want to > develop and deploy a bundle just for that. It would be nice to be able to add > new condition types by simply using REST API. > If you look at the pageViewEventCondition - it is only based on simple > boolean and property conditions, and is very specific to the type of events > that will be sent by a third party server. They should get out of default > unomi installation, and rather be created directly by the server that will > send these events. > Allowing to create/edit conditions will of course require to persist them, > and so require some changes in the ConditionType object, changing from > "PluginType" to "Item", and the way they are read by the definitions service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (UNOMI-23) Allows to dynamically add custom conditions
Thomas Draier created UNOMI-23: -- Summary: Allows to dynamically add custom conditions Key: UNOMI-23 URL: https://issues.apache.org/jira/browse/UNOMI-23 Project: Apache Unomi Issue Type: Improvement Reporter: Thomas Draier I was thinking of some possible improvements on the condition types, to make them more flexible. Currently, condition types are defined in unomi plugins - they are read from a json inside a plugin bundle, and then loaded into memory. Some of the base conditions rely on actual java code, so it make sense to put them into a bundle - but other some other conditions are only simple combination of other conditions, and are usually very specific to a domain. An end user may want to create his own condition using simple JSON definition, and may not want to develop and deploy a bundle just for that. It would be nice to be able to add new condition types by simply using REST API. If you look at the pageViewEventCondition - it is only based on simple boolean and property conditions, and is very specific to the type of events that will be sent by a third party server. They should get out of default unomi installation, and rather be created directly by the server that will send these events. Allowing to create/edit conditions will of course require to persist them, and so require some changes in the ConditionType object, changing from "PluginType" to "Item", and the way they are read by the definitions service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (UNOMI-22) Filters with "or" condition between session/user conditions do not work
[
https://issues.apache.org/jira/browse/UNOMI-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Draier resolved UNOMI-22.
Resolution: Fixed
> Filters with "or" condition between session/user conditions do not work
> ---
>
> Key: UNOMI-22
> URL: https://issues.apache.org/jira/browse/UNOMI-22
> Project: Apache Unomi
> Issue Type: Bug
>Reporter: Thomas Draier
>Assignee: Thomas Draier
>
> When passing the following condition in a filter :
> {
> "type": "booleanCondition",
> "parameterValues": {
> "operator": "or",
> "subConditions": [
> {
> "type": "profilePropertyCondition",
> "parameterValues": {
> "propertyName": "properties.firstName",
> "comparisonOperator": "equals",
> "propertyValue": "ffds"
> }
> },
> {
> "type": "geoLocationSessionCondition",
> "parameterValues": {
> "country": "AI"
> }
> }
> ]
> }
> }
> We receive an IllegalArgumentException . Any "or" condition between a session
> and profile condition will throw an exception. It should be possible to
> evaluate the condition on the current session, even the condition types are
> mixed.
> Note that it works if the operator is "and".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (UNOMI-22) Filters with "or" condition between session/user conditions do not work
Thomas Draier created UNOMI-22:
--
Summary: Filters with "or" condition between session/user
conditions do not work
Key: UNOMI-22
URL: https://issues.apache.org/jira/browse/UNOMI-22
Project: Apache Unomi
Issue Type: Bug
Reporter: Thomas Draier
Assignee: Thomas Draier
When passing the following condition in a filter :
{
"type": "booleanCondition",
"parameterValues": {
"operator": "or",
"subConditions": [
{
"type": "profilePropertyCondition",
"parameterValues": {
"propertyName": "properties.firstName",
"comparisonOperator": "equals",
"propertyValue": "ffds"
}
},
{
"type": "geoLocationSessionCondition",
"parameterValues": {
"country": "AI"
}
}
]
}
}
We receive an IllegalArgumentException . Any "or" condition between a session
and profile condition will throw an exception. It should be possible to
evaluate the condition on the current session, even the condition types are
mixed.
Note that it works if the operator is "and".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (UNOMI-20) birthDate range definition is inconsistent
Thomas Draier created UNOMI-20: -- Summary: birthDate range definition is inconsistent Key: UNOMI-20 URL: https://issues.apache.org/jira/browse/UNOMI-20 Project: Apache Unomi Issue Type: Bug Reporter: Thomas Draier Assignee: Thomas Draier Priority: Minor The birthDate property defines inconsistent ranges : they not get all possible values (ranges from now to now-10y, next range start at now-11y) and has overlaps (one range is 10 years ago to now, another range is 51 years ago to now) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (UNOMI-15) Use token to authenticate third party servers and secure login events
[ https://issues.apache.org/jira/browse/UNOMI-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier reassigned UNOMI-15: -- Assignee: Thomas Draier > Use token to authenticate third party servers and secure login events > - > > Key: UNOMI-15 > URL: https://issues.apache.org/jira/browse/UNOMI-15 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (UNOMI-14) Merge of profile for user using the same browser
[ https://issues.apache.org/jira/browse/UNOMI-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Draier updated UNOMI-14: --- Fix Version/s: 1.0.0-incubating > Merge of profile for user using the same browser > > > Key: UNOMI-14 > URL: https://issues.apache.org/jira/browse/UNOMI-14 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier >Assignee: Thomas Draier > Fix For: 1.0.0-incubating > > > Merge should happen only between current anonymous profile and existing > identified profile. We should not merge multiple identified profiles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (UNOMI-15) Use token to authenticate third party servers and secure login events
[ https://issues.apache.org/jira/browse/UNOMI-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126264#comment-15126264 ] Thomas Draier commented on UNOMI-15: http://mail-archives.apache.org/mod_mbox/incubator-unomi-dev/201602.mbox/%3ccakm8eost_ytq-cerdqdz1qjbzgqce8hkj+-gqzky3hhahpd...@mail.gmail.com%3e > Use token to authenticate third party servers and secure login events > - > > Key: UNOMI-15 > URL: https://issues.apache.org/jira/browse/UNOMI-15 > Project: Apache Unomi > Issue Type: Bug >Reporter: Thomas Draier > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (UNOMI-15) Use token to authenticate third party servers and secure login events
Thomas Draier created UNOMI-15: -- Summary: Use token to authenticate third party servers and secure login events Key: UNOMI-15 URL: https://issues.apache.org/jira/browse/UNOMI-15 Project: Apache Unomi Issue Type: Bug Reporter: Thomas Draier -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (UNOMI-14) Merge of profile for user using the same browser
Thomas Draier created UNOMI-14: -- Summary: Merge of profile for user using the same browser Key: UNOMI-14 URL: https://issues.apache.org/jira/browse/UNOMI-14 Project: Apache Unomi Issue Type: Bug Reporter: Thomas Draier Merge should happen only between current anonymous profile and existing identified profile. We should not merge multiple identified profiles. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
