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.

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.

1	Dependencies to use.
2	Undefined file structure. Can be used for assets, tools, common scripts, test configuration, …

Integrator Guide

Terminology

Extension terminology

Development Process

Security

Access control check flow

Tips and tricks

Modular approach

Extensions

TL;DR

Script signature

File structure

Server-scripts

Client-scripts

Meta

Server-scripts

Use when

Example use case

Client-scripts

Use when

Example use-cases

Automation triggers

Explicit triggers

Implicit triggers

Deferred triggers

Sink triggers

Automation iterators

Conventions

Writing triggers

Automation triggers

Conventions

Trigger interface

Trigger types

Explicit

Implicit

Deferred

Sink

Trigger constraints

Available comparison operators:

Automation iterators

Iterator interface

Iterator actions

API clients

Corredor helpers

Security Context

Script execution

Execution arguments

Execution context

Execution result

Debugging

Why is this script not valid?

Testing

Resources and Events

Compose events

system

system:sink

system:auth

system:user

system:role

system:role:member

system:application

Compose events

compose

compose:namespace

compose:page

compose:module

compose:record

Compose events

messaging

messaging:message

messaging:command

messaging:channel

messaging:channel:member

Constraint Resources

Corteza Low Code

Corteza Messaging

Corteza Internal System