/**
 *规则链 动作 英文配置文件
  目前共有22个，分类按名称进行配置
 */
export default {
  title: 'Action',
  description: 'Perform special actions',
  assignToCustomer: {
    name: 'assign to customer',
    details: `Finds target Customer by customer name pattern and then assign Originator Entity to this customer. Will create new Customer if it doesn't exists and 'Create new Customer if not exists' is set to true.`,
    description: 'Assign Message Originator Entity to Customer',
  },
  clearAlarm: {
    name: 'clear alarm',
    details: `Details - JS function that creates JSON object based on incoming message. This object will be added into Alarm.details field.\nNode output:\nIf alarm was not cleared, original message is returned. Otherwise new Message returned with type 'ALARM', Alarm object in 'msg' property and 'metadata' will contains 'isClearedAlarm' property. Message payload can be accessed via <code>msg</code> property. For example <code>'temperature = ' + msg.temperature ;</code>. Message metadata can be accessed via <code>metadata</code> property. For example <code>'name = ' + metadata.customerName;</code>.`,
    description: 'Clear Alarm',
  },
  copyToView: {
    name: 'copy to view',
    details: `Copy attributes from asset/device to related entity view according to entity view configuration. \n Copy will be done only for attributes that are between start and end dates and according to attribute keys configuration. \nChanges message originator to related entity view and produces new messages according to count of updated entity views`,
    description:
      'Copy attributes from asset/device to entity view and changes message originator to related entity view',
  },
  createAlarm: {
    name: 'create alarm',
    details: `Details - JS function that creates JSON object based on incoming message. This object will be added into Alarm.details field.\nNode output:\nIf alarm was not created, original message is returned. Otherwise new Message returned with type 'ALARM', Alarm object in 'msg' property and 'metadata' will contains one of those properties 'isNewAlarm/isExistingAlarm'. Message payload can be accessed via <code>msg</code> property. For example <code>'temperature = ' + msg.temperature ;</code>. Message metadata can be accessed via <code>metadata</code> property. For example <code>'name = ' + metadata.customerName;</code>.`,
    description: 'Create or Update Alarm',
  },
  createRelation: {
    name: 'create relation',
    details: `If the relation already exists or successfully created -  Message send via <b>Success</b> chain, otherwise <b>Failure</b> chain will be used.`,
    description: `Finds target Entity by entity name pattern and (entity type pattern for Asset, Device) and then create a relation to Originator Entity by type and direction. If Selected entity type: Asset, Device or Customer will create new Entity if it doesn't exist and selected checkbox 'Create new entity if not exists'.<br> In case that relation from the message originator to the selected entity not exist and  If selected checkbox 'Remove current relations', before creating the new relation all existed relations to message originator by type and direction will be removed.<br> If relation from the message originator to the selected entity created and If selected checkbox 'Change originator to related entity', outbound message will be processed as a message from this entity.`,
  },
  deleteRelation: {
    name: 'delete relation',
    details: `If the relation(s) successfully deleted -  Message send via <b>Success</b> chain, otherwise <b>Failure</b> chain will be used.`,
    description: `Finds target Entity by entity name pattern and then delete a relation to Originator Entity by type and direction if 'Delete single entity' is set to true, otherwise rule node will delete all relations to the originator of the message by type and direction.`,
  },
  delay: {
    name: 'delay (deprecated)',
    details: `Delays messages for a configurable period. Please note, this node acknowledges the message from the current queue (message will be removed from queue). Deprecated because the acknowledged message still stays in memory (to be delayed) and this does not guarantee that message will be processed even if the "retry failures and timeouts" processing strategy will be chosen.`,
    description: `Delays incoming message (deprecated)`,
  },
  deviceProfile: {
    name: 'device profile',
    details: `Create and clear alarms based on alarm rules defined in device profile. The output relation type is either 'Alarm Created', 'Alarm Updated', 'Alarm Severity Updated' and 'Alarm Cleared' or simply 'Success' if no alarms were affected.`,
    description: `Process device messages based on device profile settings`,
  },
  generator: {
    name: 'generator',
    details: `Generates messages with configurable period. Javascript function used for message generation.`,
    description: `Periodically generates messages`,
  },
  gpsGeofencingEvents: {
    name: 'gps geofencing events',
    details: `Extracts latitude and longitude parameters from incoming message and returns different events based on configuration parameters`,
    description: `Produces incoming messages using GPS based geofencing`,
  },
  log: {
    name: 'log',
    details: `Transform incoming Message with configured JS function to String and log final value into Thingsboard log file. Message payload can be accessed via <code>msg</code> property. For example <code>'temperature = ' + msg.temperature ;</code>. Message metadata can be accessed via <code>metadata</code> property. For example <code>'name = ' + metadata.customerName;</code>.`,
    description: `Log incoming messages using JS script for transformation Message into String`,
  },
  messageCount: {
    name: 'message count',
    details: `Count incoming messages for specified interval and produces POST_TELEMETRY_REQUEST msg with messages count`,
    description: `Count incoming messages`,
  },
  pushToEdge: {
    name: 'push to edge',
    details: `Push messages from cloud to edge. Message originator must be assigned to particular edge or message originator is <b>EDGE</b> entity itself. This node used only on cloud instances to push messages from cloud to edge. Once message arrived into this node it’s going to be converted into edge event and saved to the database. Node doesn't push messages directly to edge, but stores event(s) in the edge queue. <br>Supports next originator types:<br><code>DEVICE</code><br><code>ASSET</code><br><code>ENTITY_VIEW</code><br><code>DASHBOARD</code><br><code>TENANT</code><br><code>CUSTOMER</code><br><code>EDGE</code><br><br>As well node supports next message types:<br><code>POST_TELEMETRY_REQUEST</code><br><code>POST_ATTRIBUTES_REQUEST</code><br><code>ATTRIBUTES_UPDATED</code><br><code>ATTRIBUTES_DELETED</code><br><code>ALARM</code><br><br>Message will be routed via <b>Failure</b> route if node was not able to save edge event to database or unsupported originator type/message type arrived. In case successful storage edge event to database message will be routed via <b>Success</b> route.`,
    description: `Push messages from cloud to edge`,
  },
  rpcCallReply: {
    name: 'rpc call reply',
    details: `Expects messages with any message type. Will forward message body to the device.`,
    description: `Sends reply to RPC call from device`,
  },
  rpcCallRequest: {
    name: 'rpc call request',
    details: `Expects messages with "method" and "params". Will forward response from device to next nodes.If the RPC call request is originated by REST API call from user, will forward the response to user immediately.`,
    description: `Sends RPC call to device`,
  },
  saveAttributes: {
    name: 'save attributes',
    details: `Saves entity attributes based on configurable scope parameter. Expects messages with 'POST_ATTRIBUTES_REQUEST' message type`,
    description: `Saves attributes data`,
  },
  saveEvent: {
    name: 'save event',
    details: `Saves entity event . Expects messages with 'POST_EVENT_REQUEST' message type`,
    description: `Saves device event data`,
  },
  saveTimeseries: {
    name: 'save timeseries',
    details: `Saves timeseries telemetry data based on configurable TTL parameter. Expects messages with 'POST_TELEMETRY_REQUEST' message type. Timestamp in milliseconds will be taken from metadata.ts, otherwise 'now' message timestamp will be applied. Allows stopping updating values for incoming keys in the latest ts_kv table if 'skipLatestPersistence' is set to true.\n <br/>Enable 'useServerTs' param to use the timestamp of the message processing instead of the timestamp from the message. Useful for all sorts of sequential processing if you merge messages from multiple sources (devices, assets, etc).\n<br/>In the case of sequential processing, the platform guarantees that the messages are processed in the order of their submission to the queue. However, the timestamp of the messages originated by multiple devices/servers may be unsynchronized long before they are pushed to the queue. The DB layer has certain optimizations to ignore the updates of the \"attributes\" and \"latest values\" tables if the new record has a timestamp that is older than the previous record. So, to make sure that all the messages will be processed correctly, one should enable this parameter for sequential message processing scenarios.`,
    description: `Saves timeseries data`,
  },
  saveToCustomTable: {
    name: 'save to custom table',
    details: `Administrator should set the custom table name without prefix: <b>cs_tb_</b>. <br>Administrator can configure the mapping between the Message field names and Table columns name.<br><b>Note:</b>If the mapping key is <b>$entity_id</b>, that is identified by the Message Originator, then to the appropriate column name(mapping value) will be write the message originator id.<br><br>If specified message field does not exist or is not a JSON Primitive, the outbound message will be routed via <b>failure</b> chain, otherwise, the message will be routed via <b>success</b> chain.`,
    description: `Node stores data from incoming Message payload to the Cassandra database into the predefined custom table that should have <b>cs_tb_</b> prefix, to avoid the data insertion to the common TB tables.<br><b>Note:</b> rule node can be used only for Cassandra DB.`,
  },
  synchronizationEnd: {
    name: 'synchronization end',
    details: ``,
    description: `This Node is now deprecated. Use "Checkpoint" instead.`,
  },
  synchronizationStart: {
    name: 'synchronization start',
    details: `This node should be used together with "synchronization end" node. \n This node will put messages into queue based on message originator id. \nSubsequent messages will not be processed until the previous message processing is completed or timeout event occurs.\nSize of the queue per originator and timeout values are configurable on a system level`,
    description: `This Node is now deprecated. Use "Checkpoint" instead.`,
  },
  unassigFromCustomer: {
    name: 'unassign from customer',
    details: `Finds target Entity Customer by Customer name pattern and then unassign Originator Entity from this customer.`,
    description: `Unassign Message Originator Entity from Customer`,
  },
};