This is an internal documentation. There is a good chance you’re looking for something else. See Disclaimer.


2.25: ReCaptcha

We now use ReCaptcha v3 for a few use cases. For each installation a client key and a secret (server) key needs to be configured.

The keys for development (localhost only) are configured in hivemodule.xml and won’t work when deployed. The production keys are automatically configured through ansible.

See the 2.25 Migration comments in Backoffice for the links to the ReCaptcha keys.

If different keys need to be used for a certain installation the following properties need to be overridden:

The client key needs to be configured with the nice2.userbase.captcha.client.key property. The secret key needs to be configured with the nice2.userbase.captcha.secret property.

All domains where the ReCaptcha is used must be configured in the property. Normally this should happen automatically through Ansible.

These properties must be set via Ansible. The properties can set via the env variable as described in Ansible: Properties and Env. Vars.. Either override them for a customer or single installation, see Variable Precedence.

3.3: Elastichsearch

In Short

  1. Keep a copy of the freshly migrated DB.

  2. Check how long it takes for the index to be created.

  3. If indexing would exceed the planned maintenance window, follow the instructions in Details or ask operations to do so.


Create an Elasticsearch index when upgrading to v3.3 can take a long time. When creating a testnew installation for a large customer, check how much time was needed to create the index.


Index creation as seen on Task_execution.

Time to index, as shown above, can be inaccurate as result of restarts during the migration. Recreate the index to obtain a more accurate time.

Index won’t be fully available while the index is being created. When index creation exceeds the maintenance window planned either the customer needs to be informed that index won’t be fully available or the index needs to be created in advance. You can see in what order entities are indexed and how long indexing takes for a single entity in the bottom right corder of the above screenshot. This may be useful when deciding whether it is acceptable for indexing to exceed the maintenance window.

Create Index in Advance

For this, create a {{ customer_name }}test-index-migration via Ansible and configure it to use the index from producton:

    elasticsearch_server: "{{ hostvars[customer_name].elasticsearch_server }}"
    elasticsearch_index: "{{ hostvars[customer_name].elasticsearch_index }}"
    elasticsearch_password: "{{ hostvars[customer_name].elasticsearch_password }}"

Replace ${customer} with the customer’s name but leave {{…}} untouched.

Then use a freshly upgraded copy of the DB for this installation and wait for the indexing to complete. Then stop and remove the installation again.


For this to work, a freshly updated DB must be used. The index check looks at pk and version to decide whether the index needs to be updated. There is a good chance that pk and version will incorrectly match when the DB is being used actively.

The automatic index repair will correct any differences after the prod migration automatically.