Jump to
Product Updates
v24.50 v24.45 v24.40 v24.36 v24.27 v24.23 v24.17 v24.13 v24.09 v24.05 v24.01 v23.48 v23.44 v23.39 v23.31 v23.27 v23.27.1 v23.24 v23.19 v23.19.1 v23.14 v23.14.1 v23.12 v23.10 v23.08 v23.06 v23.04 v23.02 v22.52 v22.50 v22.48 v22.46 v22.44 v22.42 v22.40 v22.38 v22.36 v22.34 v22.32 v22.30 v22.28 v22.26 v22.24 v22.22 v22.20 v22.16 v22.14 v22.12 v22.10 v22.08 v22.06 v22.04 v22.02 v21.51 v21.49 v21.47 v21.45 v21.43 v21.41 v21.39 v21.37 v21.35 v21.33 v21.31 v21.27 v21.23 v21.19 v21.14 v21.10 v21.06 v21.02 v20.51 v20.47 v20.43 v20.39 v20.35 v20.31 v20.27 v20.23 v20.19 v20.15 v20.11 v20.07 v20.03
Updated on

Product Update - v22.18.1

Details of the product update v22.18.1 from 5th of May 2022.

HELM3

We constantly improve different aspects of HELM3 deployments in collaboration with our partners. This section lists updates and improvements done in this round.

Configure login attempts

You can now configure the number of failed login attempts allowed before users are locked out of the system. We added a new variable MAX_LOGIN_ATTEMPTS to the HELM3 secrets chart. You may set this variable according to your own requirements. The default value is set to five (5). Here is how we calculate this number:

  • In case you don’t have 2-factor Authentication (2FA) enabled, this is the number of failed login attempts.
  • In case you have 2FA enabled, this is combined number of failed 2FA code and login attempts. This means if your user has 2FA enabled and succeeded with login but failed with 2FA more than the value of MAX_LOGIN_ATTEMPTS then your user will be locked out of the system. To unlock such users the tenant administration must first disable 2FA for this user and instruct users to navigate /forgot address of the tenant to reset their password. This will reset the counter and user can login again.

Information in this section is intended for our customers who use OEM version of the elastic.io platform.

Removing docker registry builds on component deletion

The platform builds a component docker image every time you push a new version of your component. When you remove the component or a particular version of it from the platform, an associated docker build will remain until you would remove it at later stage directly from the docker registry.

With this update we improved the situation in the following way:

  • When you remove a version of your component, the platform removes the associated docker build.
  • When you remove your component entirely, the platform removes all builds of your component.
  • We created a special tool (remove-deleted-repos-from-docker) to help cleanup the remnant builds. Contact us to get a copy of this tool.
  • As an OEM customer, you must configure your own docker registry to enable delete images option.
  • As an OEM customer, please be aware that the deletion from docker registry does not free the memory automatically. To free the memory you would need to run the garbage collector job.

Components

CSV Component 3.1.3

  • FIXED Emit Batch behavior

Woocommerce Component 2.0.1

  • ADDED Raw Request action
  • ADDED Upsert Object action
  • ADDED Webhook trigger
  • REMOVED Create Object and Update Object actions removed in favor the new Upsert Object action.
  • ADDED metadata information to all actions.

Paypal component 1.3.0

  • ADDED Webhook trigger
  • ADDED Create Object action
  • ADDED Update Object action
  • IMPROVED the input metadata in Make a Payment action

Vtex component 1.4.0

  • ADDED Place Order action

MailChimp component 1.0.3

  • ADDED an ability to set Ansprache field for Add new Subscriber action

Updates to multiple components

As a part of our on-going improvements of integration components, we

  • UPDATED Sailor version to 2.6.27
  • UPDATED dependencies and addressed the packaged vulnerabilities
  • ADDED the component pusher job to Circle.ci configuration.

Here is the list of components for 22.18.1 release.