Getting Started
Basic Concepts
Tutorials
Advanced Concepts
How-to Guides
Building integration flows
Data transformation
Integration patterns
Developing Components
Components
CRM Components
ERP Components
E-Commerce Components
Basic Components
Utility Components
References
Sailor
Component Descriptor

v3.11.0 Release Notes

The release v3.11.0 was released on January 11, 2019.

New Features:

The support widget, if enabled, has been moved under the “Help” tab.

To contact our support team, please click the Profile’s Avatar (round icon) button in a lower left corner and select the “Help” menu item from the list.

As a contract Admin, I want to be able to see all workspaces in my contract.

The list of all Contracts’ Workspaces is shown for the Contract Admin under the Workspaces tab on the Contract’s settings page.

Introduced msg/size policies for local agent queues in the RabbitMQ.

The limits depend on environment variables RABBITMQ_MAX_MESSAGES_PER_QUEUE (default is 10000) and RABBITMQ_MAX_MESSAGES_MBYTES_PER_QUEUE (default is 100 MB). The actual values (for local agent queues) are divided by 10. Therefore the local agent queues are under limits 1000 and 10MB by default.

The REST endpoints have been implemented.

In regards to a flexible “Role Model” we added the following API endpoints:

Added a new label for marking depreciated or backward incompatible components’ changes.

By deprecation, we mean publishing a new component’s version without any changes to it. You mark an entire component or its triggers/actions as deprecated. These deprecation messages are shown in the UI.

The endpoint for getting roles per contract was introduced.

Endpoint Get the Contract’s roles returns all the roles that were assigned to the corresponding contract.

Frontend should support multiple user roles.

The multiple user roles are now correctly displayed on the Frontend. Roles’ actions to handle: view, assign, remove a particular role.

It means you can assign several Roles to a User while inviting him to a Contract or Workspace. You can also edit (reassign/unassign) Roles for already existing Users.

API accepts multiple User Roles.

The API User is now able to assign multiple roles to a regular user. The GET endpoints should return multiple roles as well. To be able to assign several Roles to a User the {"role":"admin"} object has to be replaced with the {"roles":["admin"]} array. Please see the API Documentation for more details.

Reworked the output format for the Get the list of available permissions endpoint.

Stringified the Scope->Object->Action permissions hierarchy into the ${scope}/${object}/${action} string for the following endpoints:

Renamed TASK to FLOW, ORGANIZATION to WORKSPACE, ACCOUNT to CREDENTIALS everywhere in the System.

Migration: Admin to Owner.

Now there are two default non-deletable roles in the System, such as the Contract Owner, and the Workspace Owner. All the existing Admins (Contract and Workspace) will be turned to an Owners (database migration).

Dynamic User Roles support on the Frontend.

Frontend retrieves an available roles’ list from the Get the Contract’s roles endpoint, instead of using a hardcoded list.

Migration: provide default roles (policies) for tenants.

The System uses per-tenant policies.

Please be informed that our internal system service Gendry installs non-deletable roles (Contract Owner and Workspace Owner) only. The migration service for installing the default roles (Contract Admin, Member, Workspace Admin, Integrator, Guest) was created.

Please also be aware that all the predefined System’s Roles have an additional isDefault field that accepts boolean values only. By default, it is set to true. Once a user initiates changes/edits to any of the Roles’ permissions, the isDefault will be set to false. This does not apply to the Owners’ Roles.

The custom API for assigning a subset of the Tenant Roles to the contract.

Requirements:
  • configuring contract to have the only subset of roles from its tenant
  • it is possible to get a list of visible roles
  • API should restrict granting an invisible role to a user
  • the only roles configured in tenant policy can be enabled in contract
  • the tenantAdmin and service account (appdirect) change this behavior
API modification:

Introduced new attribute available_roles in the following endpoints:

Example:

{
  "type":"contract",
  "attributes":{
    "name":"My Contract",
    "available_roles":[
      {
        "scope":"contracts",
        "role":"admin"
      },
      {
        "scope":"workspaces",
        "role":"admin"
      }
    ]
  }
}

An empty array means “no available roles behavior” – all tenant roles are available. If available_roles is not empty – it always contains two non-deletable roles (Contract Owner and Workspace Owner), those items are pasted by API implicitly. This request authorizes only for tenant-admin. To “reset available roles” – a client has to assign an empty array:

{
  "attributes":{
     "available_roles":[]
  }
}

Open GET the list of available permissions.

This endpoint is now available to all the platforms’ users.

Make workspace_id required in the Scheduled Executions endpoints.

Endpoints Verify credentials, Retrieve component’s metamodel and Retrieve component’s select model return 400 Bad Request in case of absent relation with workspace.

It is possible to suspend a contract:

Suspending a contract possibility. The following endpoints were implemented:

When a contract is suspended:

  • users can log in
  • users cannot start flows
  • users cannot retrieve samples
  • users cannot verify credentials => can’t create or edit credentials
  • users cannot retrieve dynamic metadata
  • users cannot retrieve dynamic dropdown models
  • users cannot request agents
  • existing agents are “logged off”
  • users cannot push components
  • users can delete their data (Flows, Creds, Workspaces, etc.)
  • users cannot create new components, workspaces
  • all flows will be stopped (not suspended)
API endpoints
Auth
  • New endpoints are allowed to use only by SystemAccounts.
  • Old/Outdated endpoints (Get Contracts and Get Contract by Id) work with the same authorization rules, as always. A new attribute was added. It is always visible.
Release process

This issue introduces migration and requires to configure 2 environment variables WIPER_SERVICE_ACCOUNT_USERNAME and WIPER_SERVICE_ACCOUNT_PASSWORD. Environment variables names are quite self-explanatory: login and password for system account used by the Wiper to finalize contract suspension. Username has to be chosen in some sensible way like wiper. The password may be any random string. To generate pwgen may be used: pwgen -n -y -s 15. Migration installs this service account into mongo to make it possible for API to authorize client that uses WIPER_SERVICE_ACCOUNT_USERNAME and WIPER_SERVICE_ACCOUNT_PASSWORD.

Support suspended contracts on the frontend.

The warning message “This contract has been suspended. Please, contact the support team for more information.” is shown on the contact page. This way it is more obvious that the contract was suspended. All the buttons that are responsible for creating/editing any entities were hidden.

Bug Fixes:

Valid step is displayed as broken.