You are reading the documentation for an outdated Corteza release. 2023.9 is the latest stable Corteza release.

Integrator Guide

This guide is tailored to the integrators; the people that wish to build upon Corteza to build new solutions. This guide will give you enough insight to the entire system that you will be confident into creating an entire application from scratch!

Terminology

Extension terminology

Extension

A collection of automation scripts, corresponding libraries and other assets,

Script or Automation Script

Combination of automation triggers, meta data and the code itself,

Client scripts

Automation scripts executed within a client’s browser,

Server scripts

Automation scripts executed inside the Corredor server,

Triggers or Automation Triggers

A set of rules, constraints and options to define when, where and how an automation script is executed,

Resource Type

Defines the resource that this automation script is compatible with. It also defines the input and output of the automation script,

Event Type

Defines what event causes this automation script to execute. For a full list of event types and availability based on the defined resource see @todo…​

Trigger constraints

A set of constraints that must be truthy in order for the automation script to be available and executable,

Trigger weight

Allows us to specify the order of automation script execution for the given event,

User interface properties or UIProps

Determine front-end aspects of the automation script invocation component; such as placement, label and color (see UIHooks),

Explicitly triggered or manual scripts

Automation scripts that are executed explicitly, such as a button press or an API endpoint call,

Implicitly triggered scripts

Automation scripts that are executed implicitly as a collateral to an event, such as record creation and form submission,

Deferred or scheduled scripts

Automation scripts that are executed at a specified time or on a configured interval,

Batch or iterator scripts

Automation scripts that are executed over a larger set of resources at the same time (used for batch processing).

Sink scripts

Automation scripts that are executed on HTTP requests and allow implementation of new endpoints,

Event bus

Event handling system inside client web applications and on the server,

UIHooks

Define a front-end components that is used to execute explicit (manual) automation scripts (see UIProps).

Development Process

Security

One of the main focuses when working with any kind of data in the enterprise environment is the data integrity and security, especially when working with sensitive information. Corteza takes this seriously and defines a powerful permission system that allows you to control access to any resource, being an application or a single module field.

Resource level permissions are described in detail in the following sections. This section merely outlines the system.

Corteza uses Role-based access control (RBAC) as a method of restricting access based on the roles of individual users within the system. RBAC lets users have access rights only to the parts of the system/application they need and prevents them from accessing information that doesn’t pertain to them. By default, a user is assigned to "Everyone" role which is very limited due to security (in case someone uninvited registers to your system, they won’t see any data, Messaging channels, list of applications, etc.).

The first registered user is granted admin rights by default.

Each permission can be in one of the following states:

Inherit

To check the setting in the layer above. For example: if an individual application has access permissions set to "Inherit", it will use the permission set for All applications (default: "Deny"). Explicit "Allow" or "Deny" always override the Inherit value,

Allow

To allow the role to perform the operation over a specified resource,

Deny

To deny the role to perform the operation over a specified resource.

It’s good practice to limit system users a much as possible to avoid potential security breaches.

Permissions setting is fine-grained, meaning the system administrator can control permissions on several layers, for example:

  • which role can access applications

  • which role can read the data

  • which role can edit the data

  • which role can access admin area, etc.

Access control check flow

The overall flow of verifications if a role has access to perform an operation on a resource is the following:

  • Can this combination of roles perform an operation on this specific resource

  • Can this combination of roles perform an operation on any resource of the type (wildcard)

  • Can anyone/everyone perform an operation on this specific resource

  • Can anyone/everyone perform an operation on any resource of the type (wildcard)

The check will return:

  • Inherit when:

    • No roles are given

    • More than 1 role is given and one of the given roles is Everyone

  • Deny when:

    • There is one rule with Deny value

  • Allow when:

    • There is at least one rule with Allow value (and no Deny rules)

Permissions in the Admin Panel are general and can be overwritten.

Tips and tricks

Modular approach

We suggest a modular role design, where we define multiple roles with a smaller set of permissions. For example:

  • CRM admin: only provides administration privileges for the CRM,

  • Messaging admin: only provides administration privileges for the messaging,

  • System admin: only provides administration privileges for the system.

Then we can easily "stick" these roles together when creating users.

There is no limit to the number of available roles or to the amount of members a role can have.

Extensions

TL;DR

Script signature

An automation script must conform to the given interface:

export interface Script extends ScriptFile {
  label?: string;(1)

  description?: string;(2)

  security?: {(3)
    runAs?: string;
    deny: string[];
    allow: string[];
  }|string;

  triggers?: Trigger[];(4)

  iterator?: Iterator;(5)

  exec?: ScriptFn;
}
1 User-friendly name for the script.
2 Additional description if needed.
3 Security context for the script; if defining runAs, you can provide a string.
4 Script triggers; refer to Automation triggers for details.
5 Script iterator; refer to [extensions:automation-iterators] for details.

File structure

Server-scripts
/server-scripts (1)
    /... (2)
1 Root folder for all server scripts (under each search path).
2 Undefined file structure; can be defined as needed.
Client-scripts
/client-scripts (1)
    /auth (2)
        /... (7)

    /admin (3)
        /... (7)

    /compose (4)
        /... (7)

    /messaging (5)
        /... (7)

    /shared (6)
        /... (7)
1 Root folder for all client scripts (under each search path).
2 Defines a bundle for Corteza Auth.
3 Defines a bundle for Corteza Admin.
4 Defines a bundle for Corteza Low Code.
5 Defines a bundle for Corteza Messaging.
6 Reserved directory for any shared logic, such as custom libraries, assets, …​
7 Undefined file structure; can be defined as needed.
Meta
/package.json(1)
/...(2)
1 Dependencies to use.
2 Undefined file structure. Can be used for assets, tools, common scripts, test configuration, …​

Server-scripts

Server-scripts are executed in the Corteza Corredor server.

Use when
  • Interaction with the user is not required,

  • response latency is not as important,

  • execution consistency is important,

  • automation script produces a heavy load on system resources.

Example use case
  • Insert additional record fields based on an external data source,

  • send an email when a new user signs up,

  • run statistic operations once a month for reporting purposes.

Client-scripts

Client-scripts are executed in the client’s browser (user agent; UA).

Use when
  • Interaction with the user is required,

  • response latency should be minimal,

  • execution reliability is not important,

  • we are not working with sensitive information such as authentication tokens or api credentials,

  • automation script produces a light load on system resources.

Example use-cases
  • Prompt user to confirm form submission,

  • validate or modify form’s data before submission,

  • redirect the user to another page; either in Corteza Low Code or other,

  • open an external resource inside a popup window.

Automation triggers

An automation triggers specify under what conditions an automation script should be executed execute and its execution context.

Explicit triggers

Explicit triggers execute on a specific user invocation, such as a button press. These include:

  • Manual.

Implicit triggers

Implicit triggers execute as a collateral to another system event such as record creation. These triggers include any before/after event. For a full list of events see resources and events.

Deferred triggers

The minimum time precision is 1 minute.

Requires explicit security context.

Only available inside server-scripts.

Deferred automation triggers are executed at a specific point in time; once or multiple times, such as a reminder. These include:

  • Scheduled,

  • interval.

Scheduled triggers use a ISO 8601 timestamp.

Interval triggers use cron expressions.

Sink triggers

Only available inside server-scripts.

Requires explicit security context.

Sink automation triggers are executed on a specific http request. They can be used to implement new routes on the API, such as a web hook to some external service.

Automation iterators

An automation iterators specify under what conditions an automation script iterator should execute and part of the execution context.

The given operation is executed over a set of resources defined by the iterator.

Conventions

Writing triggers
Use object destructuring

This helps you shorten the entire thing. For example:

// Instead of using:
triggers (t) {
  return t.after('create')
    .for('compose:record')
    .where('module', 'super_secret_module')
},

// you can do:
triggers ({ after }) {
  return after('create')
    .for('compose:record')
    .where('module', 'super_secret_module')
},

// Neat, right?!
Make trigger constraints as strict as possible

Having loose constraints can cause unwanted issues when there are multiple namespaces under the same Corteza Low Code. Two namespaces could easily define a module with the same handle, which would cause both of them to execute the given script. For example:

// Instead of using:
triggers (t) {
  return t.after('create')
    .for('compose:record')
    .where('module', 'super_secret_module')
},

// you can do:
triggers ({ after }) {
  return after('create')
    .for('compose:record')
    .where('module', 'super_secret_module')
    .where('namespace', 'super_secret_namespace')
},

Automation triggers

An automation trigger (later refereed as "trigger") specifies under what conditions an automation script should execute and part of the execution context.

The main difference between triggers and iterators is, that an iterator is executed for multiple resources defined by the constraints, one after another.

A trigger is executed for a single resource defined by the constraints.

Triggers are defined by the triggers (t) {…​} method defined by the automation script.

Triggers are evaluated in an isolated context, outside of the actual automation script. This prevents use of any constants or other symbols defiled outside of the trigger.

For example, the following trigger will not work:

const modName = 'Contact'
export default {
  triggers ({ on }) {
    return on('manual')
      .for(modName)
  },
  exec (args, ctx) {...}
}

Trigger and iterator are not compatible; you can only use one or the other within the same automation script.

Conventions

Use object destructuring

This helps you shorten the entire thing. For example:

// Instead of using:
triggers (t) {
  return t.after('create')
    .for('compose:record')
    .where('module', 'super_secret_module')
},

// you can do:
triggers ({ after }) {
  return after('create')
    .for('compose:record')
    .where('module', 'super_secret_module')
},

// Neat, right?!
Make trigger constraints as strict as possible

Having loose constraints can cause unwanted issues when there are multiple namespaces under the same Corteza Low Code. Two namespaces could easily define a module with the same handle, which would cause both of them to execute the given script. For example:

// Instead of using:
triggers (t) {
  return t.after('create')
    .for('compose:record')
    .where('module', 'super_secret_module')
},

// you can do:
triggers ({ after }) {
  return after('create')
    .for('compose:record')
    .where('module', 'super_secret_module')
    .where('namespace', 'super_secret_namespace')
},

Trigger interface

t.on

Defines the event type, such as 'manual', 'request' (see resources and events).

Not compatible with t.before, t.after, t.on, t.at.

t.before

Defines that the automation script is executed before a specific operation occurs.

You can define multiple event types for the given resource.

For example: before('create', 'update', 'delete')

Not compatible with t.on

t.after

Defines that the automation script is executed after a specific operation occurs.

You can define multiple event types for the given resource.

For example: after('create', 'update', 'delete')

Not compatable with t.on

t.at

Defines that the automation script is executed at a specific time, defined as a ISO 8601 timestamp.

Not compatable with t.on

t.every

Defines the interval in which the automation script is executed, defined as a cron expression.

Not compatable with t.on

t.for

Defines the resource type, such as 'compose:record' (see resources and events).

t.where

Defines the constraints that must match in order for the automation script to be executed (eg. t.where('module', 'Lead')). Refer to constraint resources for the full list of available resources and constraint options. See Trigger constraints for extra bits on this.

You can define multiple constraints inside the same trigger.

For example: .where('module', 'super_secret_module').where('namespace', 'super_secret_namespace')

t.uiProp

Defines the visual representation of the manual automation trigger, such as its color and label.

Only available for explicit scripts.

Trigger types

Explicit

Explicit triggers execute on a specific user invocation, such as a button press. These include:

Manual

They most commonly appear inside Low Code automation page blocks or inside Low Code record list toolbars.

Implicit

Implicit triggers execute as a collateral to another system event such as record creation. These triggers include before/after events. For a full list of available events refer to resources and events.

Deferred

Deferred automation triggers are executed at most once every minute, so you should not define an interval or timestamp that uses higher precision (seconds or milliseconds).

Deferred automation triggers are executed at a specific point in time; once or multiple times, such as a reminder. These include:

Scheduled

scheduled triggers are executed at an exact time specified by a time stamp in ISO 8601 format (This one — YYYY-MM-DDTHH:mm:ss.sssZ). This trigger is executed exactly once.

Interval

interval triggers are executed periodically in an interval defined by a cron expression (see robfig/cron package for details).

Sink

Sink automation triggers are executed on a specific http request. They can be used to implement new routes on the API, such as a web hook to some external service.

Trigger constraints

Trigger constraints allow you to specify when the script should be executed based on the resource that would like to execute it. Constraints take 2 + 1 arguments:

t.where(
  resourceAttribute,(1)
  comparator/value,(2)
  [value],(3)
)
1 The resource attribute that the constraint should check against. Refer to resources and events for a complete list of available things.
2 When 2 arguments are provided, this is the value to check against; when 3 arguments are provided, this is the comparison operator; see below.
3 When provided, this is the value to check against.
Available comparison operators:
Equals (default)
  • eq

  • =

  • ==

  • ===

Not equals
  • not eq

  • ne

  • !=

  • !==

Partial comparison
  • like

Supported wildcards:
  • one or more characters: %, *,

  • one character: _, ?.

Partial comparison; negated
  • not like

Supported wildcards:
  • one or more characters: %, *,

  • one character: _, ?.

Regex comparison
  • ~

Regex comparison; negated
  • !~

Automation iterators

An automation iterator (later refereed as "iterator") specifies under what conditions an automation script iterator should execute and part of the execution context.

The main difference between triggers and iterators is, that an iterator is executed for multiple resources defined by the constraints, one after another.

A trigger is executed for a single resource defined by the constraints.

Iterators are defined by the iterator (i) {…​} method defined by the automation script.

Iterators are evaluated in an isolated context, outside of the actual automation script. This prevents use of any constants or other symbols defiled outside of the iterator.

For example, the following iterator will not work:

// @todo provide an example, similar to how triggers have it.

Trigger and iterator are not compatible; you can only use one or the other within the same automation script.

Iterator interface

i

Defines the resource, action and the filter used for resource fetching. Passed object must conform to the interface:

interface {
  resourceType: string; (1)
  eventType: 'onManual' | 'onInterval' | 'onTimestamp' = 'onManual'; (2)
  action: 'update' | 'delete' | 'clone' | '' = ''; (3)
  filter: IteratorFilter; (4)
}
1 define the resource type; see resources and events for details.
2 define the event type; see resources and events for details.
3 define what action the script performs; see Iterator actions for details,
4 define the filter to use.
interface IteratorFilter {
  query: string; (1)
  sort: string; (2)
  limit: number | string; (3)
  offset: number | string; (4)
  [_: string]: number | string; (5)
}
1 SQL like query filter to use (WHERE <query>).
2 SQL like sort to use (ORDER BY <sort>).
3 Maximum number of resource.
4 Offset from first record.
5 additional non-standard resource specific parameters.
i.at

Defines that the automation script is executed at a specific time, defined as a ISO 8601 timestamp.

i.every

Defines the interval in which the automation script is executed, defined as a cron expression.

Iterator actions

Iterator script doesn’t perform any operation on the resource except if explicitly specified by the action property.

update

The result of the automation script will be used to update the original resource.

delete

The result of the automation script will be used to delete the original resource.

clone

The result of the automation script will be used to create a new resource with updated values; original resource is left unchanged.

API clients

API clients simplify the process of accessing information stored inside Corteza via the API. API clients can be found in the GitHub corteza-js repository.

When writing automation scripts, these API clients are automatically provided via the execution context.

These API clients greatly simplify the code so you should always use these instead of writing your own.

Corredor helpers

Corredor helpers simplify some of the more common operations that are usually performed inside automation scripts — creating records, filtering for specific records, creating messages, …​ These can be found in the GitHub corteza-js repository and the GitHub corteza-vue repository.

When writing automation scripts, these helpers are automatically provided via the execution context.

These helpers greatly simplify the code so you should always use these instead of writing your own.

These helpers can also be used outside of automation scripts, when creating portals based on Corteza, for example.

Corredor helpers are context-aware, meaning that they can determine some parts of the execution context on their own. For example, when a script is run for a record creation. ComposeHelper can automatically determine what namespace was used, what module and the created record.

Security Context

The security property allows you to manage security and access related things from inside the automation script.

Deferred and sink scripts require you to specify the security context as the invoker is unknown.

Iterators require you to specify the security context as the invoker is unknown.

You can specify the following:

security.runAs

Specify what user credentials should be used when executing the automation script. For example, if the value of admin@corredor.crust.tech is provided, the given user’s credentials will be used instead of the invoking user.

This is available only inside server-scripts.

security.allow

Explicitly define what roles have access to the automation script.

security.deny

Explicitly define what roles do not have access to the automation script.

Instead of giving users more permissions you can create a new system user with valid permissions and define the scripts security context.

Script execution

What operation the given script performs is determined by the execution function (referred to as the exec function). The function conforms to the following interface:

interface ScriptFn {
  (args: exec.Args, ctx?: exec.Ctx): unknown;
}

Execution arguments

Arguments to a client-script are provided via references to the original objects, meaning that any change to the argument parameter will reflect to the original object.

For example, running the following code in the client script’s exec function will reflect the values without the need of returning the updated record.

{
  ...
  async exec ({ $record }) {
    $record.values.Field1 = 'value1'
    $record.values.Field2 = 10
  },
}

The execution arguments provide an object containing all of the arguments related to the given operation and resource. For example, when working with records this will contain the $record, $module and $namespace.

Refer to resources and events for a complete list of available arguments.

Execution context

The execution context provides an object containing things related to the given system. It contains:

ctx.console

Used for logging. When running in the UA, this will be native window.console. When running in Corredor, this will be a Pino instance,

ctx.log

Shortcut for ctx.console.log,

ctx.$authUser

User object corresponding to the security context,

ctx.SystemAPI

API client for Corteza System interaction,

ctx.ComposeAPI

API client for Corteza Low Code interaction,

ctx.MessagingAPI

API client for Corteza Messaging interaction,

ctx.System

Helper class instance for the Corteza System,

ctx.Compose

Helper class instance for the Corteza Low Code,

ctx.ComposeUI

Helper class instance for the Corteza Low Code user interface,

ctx.Messaging

Helper class instance for the Corteza Messaging,

ctx.frontendBaseURL

Base URL used by front-end web applications. This is useful when generating URL’s inside server scripts.

Execution result

Unknown Error

An error aborts the script’s execution chain (the current script and all following scripts).

Aborted Error

An error with the value of 'Aborted' stops the execution of the current automation script. Any further scripts down the chain are executed as usual.

false

Same as aborted error. A return value of false stops the execution of the current automation script. Any further scripts down the chain are executed as usual.

unknown

Any other return value specifies that the execution was successful and the following script (if any) can execute.

Debugging

Why is this script not valid?

An automation script is valid if:
  • Defined in a .js file,

  • is located under client-scripts or server-scripts,

  • it defines an export default {…​},

  • defines at least one valid trigger or iterator,

  • defines a security context if it the script is a sink or deferred,

  • conforms to the Script signature.

Testing

Resources and Events

Compose events

system

List of events on system
  • onManual

  • onInterval

  • onTimestamp

Table 1. Event arguments for system
Name Type Immutable

invoker

auth.Identifiable

false

system:sink

List of events on system:sink
  • onRequest

Table 2. Event arguments for system:sink
Name Type Immutable

response

*types.SinkResponse

false

request

*types.SinkRequest

true

invoker

auth.Identifiable

false

system:auth

List of events on system:auth
  • beforeLogin

  • beforeSignup

  • afterLogin

  • afterSignup

Table 3. Event arguments for system:auth
Name Type Immutable

user

*types.User

false

provider

*types.AuthProvider

false

invoker

auth.Identifiable

false

system:user

List of events on system:user
  • onManual

  • beforeCreate

  • beforeUpdate

  • beforeDelete

  • afterCreate

  • afterUpdate

  • afterDelete

Table 4. Event arguments for system:user
Name Type Immutable

user

*types.User

false

oldUser

*types.User

true

invoker

auth.Identifiable

false

system:role

List of events on system:role
  • onManual

  • beforeCreate

  • beforeUpdate

  • beforeDelete

  • afterCreate

  • afterUpdate

  • afterDelete

Table 5. Event arguments for system:role
Name Type Immutable

role

*types.Role

false

oldRole

*types.Role

true

invoker

auth.Identifiable

false

system:role:member

List of events on system:role:member
  • beforeAdd

  • beforeRemove

  • afterAdd

  • afterRemove

Table 6. Event arguments for system:role:member
Name Type Immutable

user

*types.User

false

role

*types.Role

false

invoker

auth.Identifiable

false

system:application

List of events on system:application
  • onManual

  • beforeCreate

  • beforeUpdate

  • beforeDelete

  • afterCreate

  • afterUpdate

  • afterDelete

Table 7. Event arguments for system:application
Name Type Immutable

application

*types.Application

false

oldApplication

*types.Application

true

invoker

auth.Identifiable

false

Compose events

compose

List of events on compose
  • onManual

  • onInterval

  • onTimestamp

Table 8. Event arguments for compose
Name Type Immutable

invoker

auth.Identifiable

false

compose:namespace

List of events on compose:namespace
  • onManual

  • beforeCreate

  • beforeUpdate

  • beforeDelete

  • afterCreate

  • afterUpdate

  • afterDelete

Table 9. Event arguments for compose:namespace
Name Type Immutable

namespace

*types.Namespace

false

oldNamespace

*types.Namespace

true

invoker

auth.Identifiable

false

compose:page

List of events on compose:page
  • onManual

  • beforeCreate

  • beforeUpdate

  • beforeDelete

  • afterCreate

  • afterUpdate

  • afterDelete

Table 10. Event arguments for compose:page
Name Type Immutable

page

*types.Page

false

oldPage

*types.Page

true

namespace

*types.Namespace

true

invoker

auth.Identifiable

false

compose:module

List of events on compose:module
  • onManual

  • beforeCreate

  • beforeUpdate

  • beforeDelete

  • afterCreate

  • afterUpdate

  • afterDelete

Table 11. Event arguments for compose:module
Name Type Immutable

module

*types.Module

false

oldModule

*types.Module

true

namespace

*types.Namespace

true

invoker

auth.Identifiable

false

compose:record

List of events on compose:record
  • onManual

  • onIteration

  • beforeCreate

  • beforeUpdate

  • beforeDelete

  • afterCreate

  • afterUpdate

  • afterDelete

Table 12. Event arguments for compose:record
Name Type Immutable

record

*types.Record

false

oldRecord

*types.Record

true

module

*types.Module

true

namespace

*types.Namespace

true

recordValueErrors

*types.RecordValueErrorSet

false

invoker

auth.Identifiable

false

Compose events

messaging

List of events on messaging
  • onManual

  • onInterval

  • onTimestamp

Table 13. Event arguments for messaging
Name Type Immutable

invoker

auth.Identifiable

false

messaging:message

List of events on messaging:message
  • onManual

  • beforeCreate

  • beforeUpdate

  • beforeDelete

  • afterCreate

  • afterUpdate

  • afterDelete

Table 14. Event arguments for messaging:message
Name Type Immutable

message

*types.Message

false

oldMessage

*types.Message

true

channel

*types.Channel

false

invoker

auth.Identifiable

false

messaging:command

List of events on messaging:command
  • onInvoke

Table 15. Event arguments for messaging:command
Name Type Immutable

command

*types.Command

true

channel

*types.Channel

true

invoker

auth.Identifiable

false

messaging:channel

List of events on messaging:channel
  • onManual

  • beforeCreate

  • beforeUpdate

  • beforeDelete

  • afterCreate

  • afterUpdate

  • afterDelete

Table 16. Event arguments for messaging:channel
Name Type Immutable

channel

*types.Channel

false

oldChannel

*types.Channel

true

invoker

auth.Identifiable

false

messaging:channel:member

List of events on messaging:channel:member
  • beforeJoin

  • beforePart

  • beforeAdd

  • beforeRemove

  • afterJoin

  • afterPart

  • afterAdd

  • afterRemove

Table 17. Event arguments for messaging:channel:member
Name Type Immutable

member

*types.ChannelMember

false

channel

*types.Channel

false

invoker

auth.Identifiable

false

Constraint Resources

Corteza Low Code

Resource

Description

compose:module

module

Constraint checks the value against the module handle.

module.handle

Constraint checks the value against the module handle.

module.name

Constraint checks the value against the module name.

namespace

Constraint checks the value against the namespaces slug.

namespace.slug

Constraint checks the value against the namespaces slug.

namespace.name

Constraint checks the value against the namespaces name.

compose:namespace

namespace

Constraint checks the value against the namespaces slug.

namespace.slug

Constraint checks the value against the namespaces slug.

namespace.name

Constraint checks the value against the namespaces name.

compose:page

page

Constraint checks the value against the page’s handle.

page.handle

Constraint checks the value against the page’s handle.

page.title

Constraint checks the value against the page’s title.

namespace

Constraint checks the value against the namespaces slug.

namespace.slug

Constraint checks the value against the namespaces slug.

namespace.name

Constraint checks the value against the namespaces name.

compose:record

record.updatedAt

Constraint checks the value against the record’s updatedAt attribute in RFC3339 format (example: 2006-01-02T15:04:05Z07:00)

record.createdAt

Constraint checks the value against the record’s createdAt attribute in RFC3339 format (example: 2006-01-02T15:04:05Z07:00)

record.deletedAt

Constraint checks the value against the record’s deletedAt attribute in RFC3339 format (example: 2006-01-02T15:04:05Z07:00)

record.values.*

Constraint checks the value against the record’s value. Any field defined by the record’s module can be used.

module

Constraint checks the value against the module handle.

module.handle

Constraint checks the value against the module handle.

module.name

Constraint checks the value against the module name.

namespace

Constraint checks the value against the namespaces slug.

namespace.slug

Constraint checks the value against the namespaces slug.

namespace.name

Constraint checks the value against the namespaces name.

Corteza Messaging

Resource

Description

messaging:channel-member

channel-member.type

Constraint checks the value against the membership flag. The value can be owner, member or invitee.

channel

Constraint checks the value against the channel’s name.

channel.name

Constraint checks the value against the channel’s name.

channel.topic

Constraint checks the value against the channel’s topic.

channel.type

Constraint checks the value against the channel’s type. The value can be public, private or group.

messaging:channel

channel

Constraint checks the value against the channel’s name.

channel.name

Constraint checks the value against the channel’s name.

channel.topic

Constraint checks the value against the channel’s topic.

channel.type

Constraint checks the value against the channel’s type. The value can be public, private or group.

messaging:command

command

Constraint checks the value against the command’s name. The name does not include the leading /, for example 'shrug'.

command.name

Constraint checks the value against the command’s name. The name does not include the leading /, for example 'shrug'.

channel

Constraint checks the value against the channel’s name.

channel.name

Constraint checks the value against the channel’s name.

channel.topic

Constraint checks the value against the channel’s topic.

channel.type

Constraint checks the value against the channel’s type. The value can be public, private or group.

messaging:message

message

Constraint checks the value against the message’s content.

message.type

Constraint checks the value against the message type. The value can be channelEvent, inlineImage, attachment, illeism or omitted.

channel

Constraint checks the value against the channel’s name.

channel.name

Constraint checks the value against the channel’s name.

channel.topic

Constraint checks the value against the channel’s topic.

channel.type

Constraint checks the value against the channel’s type. The value can be public, private or group.

Corteza Internal System

Resource

Description

system:application

application.name

Constraint checks the value against the application’s name.

system:auth

user

Constraint checks the value against the user’s handle.

user.handle

Constraint checks the value against the user’s handle.

user.email

Constraint checks the value against the user’s email.

system:user

user

Constraint checks the value against the user’s handle.

user.handle

Constraint checks the value against the user’s handle.

user.email

Constraint checks the value against the user’s email.

system:role

role

Constraint checks the value against the role’s handle.

role.handle

Constraint checks the value against the role’s handle.

role.name

Constraint checks the value against the role’s name.

system:role-member

user

Constraint checks the value against the user’s handle.

user.handle

Constraint checks the value against the user’s handle.

user.email

Constraint checks the value against the user’s email.

role

Constraint checks the value against the role’s handle.

role.handle

Constraint checks the value against the role’s handle.

role.name

Constraint checks the value against the role’s name.

system:sink

request.remoteAddress

Constraint checks the value against the request’s remote address.

request.method

Constraint checks the value against the request’s method. The value can be any standard HTTP request method.

request.path

Constraint checks the value against the request’s URL path. For example, www.address.tld/some/path would require /some/path.

request.username

Constraint checks the value against the request’s basic authentication username.

request.password

Constraint checks the value against the request’s basic authentication password.

request.content-type

Constraint checks the value against the request’s content type header field.

request.get.*

Constraint checks the value against the request’s get query parameters. This will be truthy if any value matches in case of multiple query parameter values.

request.post.*

Constraint checks the value against the request’s post body parameters.

request.header.*

Constraint checks the value against the request’s header parameters.

system:mail

mail.header.subject

Constraint checks the value against the email’s subject.

mail.header.from

Constraint checks the value against the email’s from. This will be truthy if any value matches.

mail.header.to

Constraint checks the value against the email’s to. This will be truthy if any value matches.

mail.header.replyTo

Constraint checks the value against the email’s reply to. This will be truthy if any value matches.

mail.header.cc

Constraint checks the value against the email’s cc. This will be truthy if any value matches.

mail.header.bcc

Constraint checks the value against the email’s bcc. This will be truthy if any value matches.