Product Updates in 2019 Q1

Product Updates Archive for 2019 Q1 period.

2019-02-28 - v3.13.0

Date	Details
February 28th, 2019	Platform release v3.13.0

New Features

Last Owner in Contract must stay

As contract owner I must not be able to leave the contract if I’m the only owner. At least one Owner should be left in the Contract which contains more than one user.

API endpoint to grant Tenant Admin role

New API endpoint for granting Tenant Admin rights to users. User with tenants.membership.edit permission can grant/remove Tenant Admin’s permissions to/from the user. See API documentation for more information.

Contract and Workspace Owner role management

Contract and workspace Owners are able to manage their own roles as well as to add new role from the list of available roles and remove any role except Owner role from themselves.

Migrate Contract Owner role permissions

Permissions contracts.repository.edit and contracts.devTeam.edit are removed from Contract Owner role. The Admin role is assigned automatically to all users, that currently have Owner role.

Contract Owner role can’t be removed

The Contract Owner role can not be removed from a Contract using contract.available_roles. If available_roles is not empty – it always will contain Contract Owner role (this item is pasted by API implicitly).

Improvements

Hints regarding the usage of JSONata in the mapping tool

We implemented hint box which explains that JSONata is used as mapping languages and provides examples.

Password requirements message

We provided more clear explanation for password requirements.

Wiper should use a service account

Service account was added for wiper. Several API endpoints allow performing a request with Service Account API-Key. The Wiper uses a Service Account credential for an API referring. A new workspaces.workspace.finish_delete permission was introduced.

Allow creating tenants without certificates

Now a Tenant can be created without utilizing domain certificates.

• Remove all subtitles on the pages.

• Introduce the Tenant Admin role and its permissions in the tenant’s scope.

• As a Contract Owner I want to be able to rename my contract within the API.

  There are two new permission sets for the contract’s scope: contracts.contract.edit and contracts.contract.edit_available_roles

  • the contracts.contract.edit permission is assigned to all of the contract owners during migration. It allows editing anything except the available_roles. Otherwise, an appropriate error will appear.
  • the contracts.contract.edit_avaialble_roles permission allows editing anything in the contract, including the available roles.

• As the Contract Owner I want to be able to rename my contract within the UI.

  To be able to rename the contract, click the Edit Contract Data button and the necessary form will appear.

• Create a simple tenant delete API endpoint.

  The endpoint deletes the tenant only in case it does not contain any contracts.

• Introducing roles and permissions for the Service Accounts.

  An internal issue implemented for:

  • assigning roles and permissions to Service Accounts, to limit its access;
  • making it possible for the Service Account utilizing these commonly used endpoints (“first-class” endpoints available for users): /v2/tenants,/v2/contracts, /v2/users;
  • unifying code that controls what is “allowed/not allowed” in the endpoints. That was made to differentiate the Service Accounts and grant the necessary privileges.

• Introducing 4 new environment variables to run migrations.

  Please be aware that the introduced variables are allowed for editing/customizing during the platform’s life cycle. Nevertheless, it is required for running the gendry job once the changes have been made, and immediately restarting all the services that are using the login+password (the appdirect and handmaiden) combination.

Please note, do not use the underscore symbol _ in your login & password credentials. The NGINX web server fails to handle it correctly, as it is being transferred within the HTTP headers.

The environment variables are a combination of login & password pairs for such Service Accounts as the handmaiden (tenant-operator) and appdirect (integration service):

1. The tenant-operator (aka handmaiden) is a special service that maintains ingresses to be aligned with tenants.

   1.1. The TENANT_OPERATOR_SERVICE_ACCOUNT_USERNAME variable should contain a login for the tenant-operator.

   1.2. The TENANT_OPERATOR_SERVICE_ACCOUNT_PASSWORD variable should contain (any string) a password. Can be generated by the following command pwgen -ny 15.

2. The service account for appdirect integration service. Different versions of this service are being used for:

   • the Tenant Admin account;
   • shared SERVICE_ACCOUNT.

   2.1. The APPDIRECT_SERVICE_ACCOUNT_USERNAME variable should contain a login for the appdirect integration service.

   2.2. The APPDIRECT_SERVICE_ACCOUNT_PASSWORD variable should contain (any string) a password. Can be generated by the following command pwgen -ny 15.

• Add unique to toJSONv2.

  This is an internal issue that refers to query optimization for a Mongo-related database. It solves the following problem: the frontend was not able to load a list of tasks from the API due to significant excessive load on the MongoDB server.

• Making certificates management more flexible.

  Introduced a new method to store the custom certificates that are being provided for the tenants. From now on, the user can upload certificates for the tenant and provide them with a reference right in the tenant’s configuration. A new environment variable CERTIFICATE_STORE_ENCRYPTION_PASSWORD was added. It is a password that is used to generate a key for encrypting or decrypting a certificate. There are no restrictions or limitations on how to generate one.

Fixed Bugs:

• Where some symbols were not considered as special in password rules.

  The next symbols are considered as special ~!@#$%^&*()_+-,.<>?/`|;:'[]=

• Where “Find property” search filed was missing in the mapper’s dropdown lists.

• Custom certificates now will be deleted along with Tenant they belong to.

• Where not all the logs are visible within the UI while some of the components generate a lot of data.

  We introduced pagination in the logs panel.

• Where it was possible to be blocked in the samples retrieval step.

  The first incoming sample is set by default.

• Where unnecessary icon appeared once expanding a form in the “Configure” input section.

2019-01-31 - v3.12.0

Date	Details
January 31st, 2019	Platform release v3.12.0

New Features:

Master API key gets better protection in our UI.

Instead of displaying the API key as it is, we replaced it with asterisk symbols. It is displayed as some ****** sings with a Copy button that appears on hover. The API key is hidden on the User Profile page and Implement Flow tab. The last 4 digits are visible. Just click the necessary text field to be able to copy the API key, Usage example curl, and Flow values into a clipboard.

Set a secure attribute on cookies.

In case a session is secured utilizing TLS, the web application has to set the “secure” attribute into the sessions cookies. Purpose: The “secure” attribute prevents the browser from sending cookies without encryption. For example, it may happen if some part of a web application contents is not encrypted. However, it can also occur throughout an active attack in which an attacker injects or presents unencrypted links or references. We set 3 types of cookies that have to be secure now:

• connect.sid - session cookie;
• elastic_remember - “remember me” cookie;
• last-contract - saves a recently used contract.

Password requirements for a new user.

In case a password is used as an authentication attribute, it should contain not less than 8 characters and should also include the following elements: upper and lower case letters, numbers, and special characters. Registered users can still log in without any problems, even if their passwords do not meet the requirements above. Allowed symbols:

• latin alphabet (upper and lower case);
• digits 0-9;
• special symbols ~!@#$%^&*()_+-,.<>?/`|;:'[]=

As the Contract Admin, I want to invite users to contract and workspace in one click right on the Contract Page.

Now, the Contract Admin is allowed to invite other users to a workspace and a contract simultaneously on the Contract Page.

Invite to a Contract and a Workspace in one click.

Now, the Contract Admin is allowed inviting any other user to a workspace and a contract simultaneously right on the Workspace Page.

Extend driver events to have a purpose message from a Pod’s container status.

Common issues related to running steps inside a flow are reflected in the runlog. For example, the Out of Memory issue will be addressed as “Component run out of memory and terminated.” This approach can help with improving an overall debugging procedure.

Check roles usage in the /v2/tenant/:id/roles.

An additional verifications were added for changing roles procedure in the Tenant:

• It is restricted to remove a role from the “Tenant-policy” if any user/contract utilizes it.
• In case the role has to be removed from the “Tenant-policy”, but one of the contract.availableRoles is still using it, the 409 error code will be returned.

Removing pending invites for contract.availableRoles and tenantPolicy.roles.

All the pending invites made with an already removed role from the Contract or Tenant will be deleted.

Bug Fixes:

• JSONata expression evaluation blocks the UI.

• The Transformation component was freezing while processing a significant amount of data.

• All the Components with optional Developer Mode tab received a new Evaluate button.

• The Transformation component has also received the Evaluate button.

• Retrieving a Mapping Result.

  To be able to retrieve a Mapping Result for Transformation component navigate to the Configure Input section paste the necessary expression into the text field and click Evaluate. While mapping is running in the background, the animated wheel icon appears. It indicates that everything is working fine and the page did not get stuck.

• The POST v2/users endpoint is no longer accepting the relationships.contracts in the body request.

  This endpoint was changed: the section relation was removed. Now, the user is being created out of the contract’s scope. The following means that he is not allowed to log into our platform. Therefore, this user has to be added to one of the contracts utilizing Add a new member to the Contract’s scope

• The Out of Memory record was not represented in the stderr file.

• Component search in the “Designer” is broken.

• I cannot utilize components on Frontend within the existed Revision, even if components are in the different contracts/teams.

• It is impossible to remove the user in case if he is a member of more than one contract.

• Permission assignment for OWNER role is static.

  The Contract Owner role is not required for the Contract. Now in case a contract is being created without an explicit Contract Owner role in the available_roles this role will not be added automatically.

• User cannot delete his account in case a Contract does not have a user with the contract-owner role.

  Now the user with the Contract Owner role cannot perform a permanent deletion his/her account in case there is no other Contract Owner left in a particular Contract. For the other contract roles delete users account function available without any checks.

2019-01-11 - v3.11.0

Date	Details
January 11th, 2019	Platform release v3.11.0

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:

• Get Tenant’s roles
• Update Tenant’s roles
• Get the list of available permissions

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:

• Get the list of available permissions
• Get Tenant’s roles and Update Tenant’s roles
• Get the Contract’s roles

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:

• Get Contract by Id allow to retrieve available_roles
• Create a Contract allow to assign available_roles
• Update a Contract allow to update available_roles

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:

• Suspend Contract
• Unsuspend Contract

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

• Suspend Contract. Marks contract as suspended. Allowed only for active contracts.
• Unsuspend Contract. Allowed only for suspended contracts.
• The new attribute status is added to the next endpoints: Get Contracts and Get Contract by Id. May have three values active, suspended, suspending.

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.