[
https://issues.apache.org/jira/browse/UNOMI-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17432489#comment-17432489
]
David Griffon commented on UNOMI-518:
-------------------------------------
h2. pull request
https://github.com/apache/unomi/pull/355
h2. Explanation
We now have a way to detect tracked rules as soon as the rule defines a
parameter prefixed by {{tracked_}}
The rest of the param name is the property to look at in the source event
For instance, for a click event that generate a source event that contains a
{{pageInfo}} object, it can be set as follow:
{{tracked_pageInfo_properties_pagePath}}.
Underscores will be replaced by dot.
This parameter will be transformed in a property query of
{{pageInfo.properties.pagePath}} against the object from the source event. If
the query match, the rule is returned as a tracked rule by the context servlet.
h2. Testing
The functionality is covered by an integration test in the RuleServiceIT test.
> trackedConditions are not compatible with conditions generated by the
> condition builder
> ---------------------------------------------------------------------------------------
>
> Key: UNOMI-518
> URL: https://issues.apache.org/jira/browse/UNOMI-518
> Project: Apache Unomi
> Issue Type: Bug
> Components: core
> Affects Versions: 2.0.0, 1.6.0, 1.5.7
> Reporter: David Griffon
> Priority: Major
> Fix For: 2.0.0, 1.6.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To be able to make the source condition working on Unomi side we would
> require to parse the parent Condition of the trackedCondition. So it mean a
> fix would be required in Unomi RuleService.getTrackedConditions(...) to be
> able to better detect the source condition when a condition like ours is
> using it's own definition but actually contains a source condition in it's
> parent definition.
> Currently Unomi tracked conditions are detecting the boolean condition that
> would contains a sourceEventCondition to check if the source of the request
> match the sourceEventCondition of the tracked condition.
> But this cannot work with a built condition like the clickEventCondition,
> because this condition is not a boolean condition it self.
> {code}
> {
> "metadata": {
> "id": "clickEventCondition",
> "name": "clickEventCondition",
> "description": "",
> "systemTags": [
> "availableToEndUser",
> "behavioral",
> "profileTags",
> "event",
> "condition",
> "eventCondition",
> "usableInPastEventCondition",
> "trackedCondition"
> ],
> "readOnly": true
> },
> "parentCondition": {
> "type": "booleanCondition",
> "parameterValues": {
> "subConditions": [
> {
> "type": "eventTypeCondition",
> "parameterValues": {
> "eventTypeId": "click"
> }
> },
> {
> "type": "sourceEventPropertyCondition",
> "parameterValues": {
> "path": "parameter::pagePath"
> }
> },
> {
> "type": "eventPropertyCondition",
> "parameterValues": {
> "propertyName": "target.itemId",
> "propertyValue": "parameter::itemId",
> "comparisonOperator": "equals"
> }
> }
> ],
> "operator": "and"
> }
> },
> "parameters": [
> {
> "id": "pagePath",
> "type": "string",
> "multivalued": false
> },
> {
> "id": "itemId",
> "type": "string",
> "multivalued": false
> }
> ]
> }
> {code}
> But the clickEventCondition is using a parent condition that is a boolean.
> So we may look into improve the Unomi algoritm to detect the
> sourceEventCondition of the trackedCondition that are not boolean condition,
> by looking into the parent condition if we find something.
> It's also possible to do completely differently if we find a more suitable
> solution. (new systemtag for this kind of condition ? new handling of this in
> unomi without breaking the existing behaviors ?)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
