You are reading the documentation for an outdated Corteza release. 2024.9 is the latest stable Corteza release.

Upgrade Guide

This guide will help you upgrade your Corteza to the newest version in no time!

While there are internal safeguards in place that can prevent data loss or other kinds of disasters, make sure you backup your database before you do an upgrade. Refer to devops guide on backup procedure for details.

If you are upgrading multiple versions at the same time; for example from 2019.12 to 2020.9; you should follow all the upgrade guides between the two versions.

Recommended steps for Corteza upgrade

Especially before any major version upgrade we recommend that before upgrading your production you either:

  • upgrade your staging environment, or

  • deploy a temporary environment with a copy of the production database and do a test upgrade there

Steps to upgrade Corteza when deployed with docker-compose

  1. changing image versions in your docker-compose.yaml (or .env) file,

  2. pull new images from docker hub with docker-compose pull,

  3. recreate containers with docker-compose up -d.

Upgrading to 2020.12

Due to database schema changes it’s not possible to downgrade or revert your installation after upgrading to 2020.12. Please be extra careful, backup your database and follow recommended steps.

If you use Corteza REST API, please note that paging parameters on certain endpoints have changed. Refer to developers guide for details.

After upgrade

Field expressions and automation scripts

With the introduction of field expressions, some Corredor automation scripts became obsolete and were removed from the 2020.12 release. This affects existing deployments that use CRM and Service Solution applications.

We did not want to make an automated upgrade and change your module fields on those applications (namespaces). It’s not possible to know what kind of changes you might have made in your modules.

Table 1. Module modifications:
Module Field Value expression Sanitizer Validators

Account

BillingStreet

trim(value)

Account

BillingCity

trim(value)

Account

BillingState

trim(value)

Account

BillingPostalCode

trim(value)

Account

ShippingStreet

trim(value)

Account

ShippingCity

trim(value)

Account

ShippingState

trim(value)

Account

ShippingPostalCode

trim(value)

Account

GeneratedBillingAddress

trim(trim(trim(BillingStreet?BillingStreet:"") + "\n" + trim(trim(trim(BillingPostalCode?BillingPostalCode:"") + " " + trim(BillingCity?BillingCity:"")) + " " + trim(BillingState?BillingState:""))) + "\n" + trim(BillingCountry?BillingCountry:""))

Account

GeneratedShippingAddress

trim(trim(trim(BillingStreet?BillingStreet:"") + "\n" + trim(trim(trim(BillingPostalCode?BillingPostalCode:"") + " " + trim(BillingCity?BillingCity:"")) + " " + trim(BillingState?BillingState:""))) + "\n" + trim(BillingCountry?BillingCountry:""))

Lead

Street

trim(value)

Lead

City

trim(value)

Lead

State

trim(value)

Lead

PostalCode

trim(value)

Lead

GeneratedAddress

trim(trim(trim(BillingStreet?BillingStreet:"") + "\n" + trim(trim(trim(BillingPostalCode?BillingPostalCode:"") + " " + trim(BillingCity?BillingCity:"")) + " " + trim(BillingState?BillingState:""))) + "\n" + trim(BillingCountry?BillingCountry:""))

Lead

RecordLabel

trimFirstName ? FirstName : "") + " " + (LastName ? LastName : ""

Quote

Discount

value < 0: "Discount can not be a negative number"

Quote

Subtotal

value < 0: "Sub total can not be a negative number"

Quote

Tax

value < 0: "Tax can not be a negative number"

Quote

TotalPrice

max(maxSubtotal?Subtotal:0) - (Discount?Discount:0), 0) + (ShippingHandling?ShippingHandling:0

Quote

GrandTotal

TotalPrice * (Tax ? 1+Tax/100 : 1)

Federation (experimental feature)

Currently Corteza does not import Federation roles and RBAC rules when upgrading existing database. This can be done manually by running the following command:

docker-compose exec server corteza-server import /corteza/provision/200_federation

Upgrading to 2020.9

After upgrade

Corteza Service Cloud

Corteza 2020.9 renames Corteza Service Cloud to Corteza Service Solution. The new automation scripts are not compatible with the previous namespace.

Follow this set of steps to properly update your instance:

  1. Rename the Service Cloud namespace name to Corteza Service Solution

  2. Change the service-cloud namespace slug to service-solution

  3. Go over each page in the Corteza Service Solution namespace and replace the old service-cloud automation buttons with new service-solution buttons

  4. Test your changes to assure everything works as expected :APP_NAME_SHELL: One :APP_NAME_AUTH: Auth :APP_NAME_ADMIN: Admin :APP_NAME_COMPOSE: Low Code :APP_NAME_MESSAGING: Messaging :APP_NAME_FEDERATION: Federation :APP_AUTOMATION: Corredor :PRODUCT_NAME: Corteza :DOMAIN: cortezaproject.org

Upgrading to 2020.3

After upgrade

Corredor scripts

Corteza 2020.3 introduces a new way of how automation scripts are stored, handled and executed. The code, configuration and triggers are no longer stored in the Corteza database, but are defined as JavaScript files on the filesystem and accessed directly by the Corteza Corredor server.

All pre-installed scripts for the CRM and ServiceCloud have already been migrated and are ready for use.

You will need to migrate any custom automation scripts manually.

There are 2 available script-migrator commands, one for system other one for Low Code service:

docker-compose exec server system script-migrator --dst 
docker-compose exec server compose script-migrator --dst

These two commands will create a simple structure under <base-location>/<service>/custom (system/custom/ and compose/custom/) containing scripts from both services.

The script migrator tool directly exports the script’s source code and triggers without running any checks or tests. Make sure you test each script and trigger after the migration.

Point script-migrator tool (base-location) to Corredor’s usr/server directory. This will create script source files (javascript) directly to the recommended location.

Script files names are created from the script names (with suffixing script ID in case of any duplicated). Migrator skips all deleted scripts, deleted triggers, scripts with "test" name or without any code.

If possible, module handle is used where a module is referenced (in Compose scripts).