3.13.0 Platform Release

v3.13.0 release date is February 28, 2019.

New Features:

  • 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.

  • 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 Owners are able to manage their own roles.

    Contract and workspace Owners are able 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.

  • Role Contract Owner can’t be removable 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).

  • 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 some minimale examples.

  • The message with requirements for user’s password is changed.

    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.