[ 
https://issues.apache.org/jira/browse/UNOMI-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15239593#comment-15239593
 ] 

Thomas Draier commented on UNOMI-23:
------------------------------------

It's now possible to create custom conditions :

curl -H "Content-Type: application/json" --user karaf:karaf -XPOST 
'http://localhost:8181/cxs/definitions/conditions' -d '
{
  "metadata": {
    "id": "toto-condition",
    "name": "toto-condition",
    "description": "",
    "tags": [
      "demographic",
      "profileCondition"
    ],
    "readOnly": true
  },
  "parentCondition": {
    "type": "profilePropertyCondition",
    "parameterValues": {
      "propertyName": "properties.firstName",
      "propertyValue": "toto",
      "comparisonOperator": "equals"
    }
  },

  "parameters": [
  ]
}
'



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

Reply via email to