Changes in Execute 21.1.218

In this update, we have made some HUGE improvements to how we store credentials for 3rd party systems (required for integrations).

What needed to change

Previously, some credentials were stored in the Execute database, while others were embedded in plugins and configuration files.

• Credentials in the database were suboptimal for several reasons:
  • Users with read access to the database could potentially retrieve integration credentials
  • When copying from PROD to TEST you could inadvertently end up with a TEST environment that was integrating with PROD data
• Access to credentials in the plugins and configuration files were typically limited to the IT folks who manage those systems, but it’s still not a best practice to do things that way.

What’s New

With this update, we’ve added a new credential storage mechanism.

• For those of you with on-prem Execute environments, this is an encrypted file called credentials.bin in your service’s config folder. This file is encrypted using the Windows Data Protection API and unusable for any user other than the user running the Execute service. (NOTE: this means that changing the user that runs the Execute service will render all credentials stored in this file unusable!)
• For those of you with Quorum-hosted Execute environments, these credentials are stored securely in an Azure Key Vault.

All external credentials managed from within the Execute UI (Quorum OnDemand Well Operations (WellEz), Peloton, Enersight, and the Integration Agent) are automatically written to the new encrypted credential mechanism.

Relevant plugins and config file now support a sensitive information placeholder element which will refer to credentials stored in the credential store.

What happens on upgrade?

On upgrade, any database-stored credentials (such as WellEz, Peloton, Enersight, and the Integration Agent) will be automatically migrated to the secure credential store. Note that this will come with a change in behaviour as these credentials will no longer copy between Execute environments when you copy the database. While different, we strongly feel this is a much safer behaviour.

Any existing plugins/config files with embedded credentials will be left as-is. If desired, the process of migrating a secret from these files to the credential store is described below.

How do I add protection for credentials in my config and plugin files?

Many plugins (such as synchronizations to external systems) contain sensitive information like database connection strings.

<actual_cost_database>Data Source=SQL_Server;Initial Catalog=SQL_Server;Integrated Security=False;User ID=accounting;Password=hunter2;MultipleActiveResultSets=True</actual_cost_database>

We can replace the password in the connection string with a placeholder label (prefixed with @@@).

<actual_cost_database>Data Source=SQL_Server;Initial Catalog=SQL_Server;Integrated Security=False;User ID=accounting;Password=@@@ACCOUNTING_PASSWORD;MultipleActiveResultSets=True</actual_cost_database>

Then, an administrator with the Edit External Credentials admin privilege can navigate to Tools > Configuration > External Credentials and set the value for that placeholder.

Now, when Execute tries to connect to the accounting database it will evaluate the connection string and replace the placeholder @@@ACCOUNTING_PASSWORD with the password we defined in the External Credentials screen.

Note that for security purposes the password, once added, can never be read from the Execute UI. A best practice is to track integration passwords in a separate secure password management application so that they are available if needed in the future.

The new advanced task-based workflow module in Execute is great and allows you to tightly control the collection of information on your Wells, Sites, Jobs, AFEs, etc.

Up until now, the workflow always marched forward. Once a task was complete, it would stay complete. There was no way to reactivate part of the workflow and force those tasks to be re-run.

<announcer_voice>Until today. . .</announcer_voice>

In this update, we’ve added phase 1 of a new workflow reset feature that allows a task owner or an administrator with the Can Reactivate Workflow Task admin privilege to reactive a task. As part of the workflow definition, administrators can now configure what happens when a task is reactivated, such as:

• Does reactivating a task clear any data (forcing the user to re-enter those fields)?
• Does reactivating a task require the user to manually review/complete the task?
• If a parent task is reactivated, should the child/dependent task also be reactivated?

As mentioned, this is only the beginning.

In this update, task reactivation is a manual process.

Over the coming months, the plan is to introduce an automated aspect to this so that you can build rules like “If the location changes, automatically reset big chunks of the workflow.”

As part of this change, we have also cleaned up the behaviour of the “Manual Completion Behaviour”.

• If a task marked as “Require Manual Completion” has a Completion Rule, that completion rule must be satisfied before the task can be completed.
• If a task is not marked as “Require Manual Completion”, the task must have a Completion Rule to be completed. There is no option for a user to manually complete the task in this case. This is a change from the previous version where the software would incorrectly show a Complete button to the user.
• Tasks where “Require Manual Completion” = yes will show a “Save” and a “Save & Complete” button
• Tasks where “Require Manual Completion” = no will show a “Save” only

We’ve added some new functions to provide more options when building calculated fields against a subset of the data in a table.

• TableMaxDateFiltered - return the maximum date from a filtered subset of the rows in a table
• TableMinDateFiltered - return the minimum date from a filtered subset of the rows in a table
• TableMaxFiltered - return the maximum number from a filtered subset of the rows in a table
• TableMinFiltered - return the minimum number from a filtered subset of the rows in a table
• TableSumFiltered - return the sum of a numeric field on a filtered subset of the rows in a table
• TableCountFiltered - return the count of a filtered subset of the rows in a table

All of the above work like their non-filtered counterparts, but introduce two new parameters:

1. filterPath - is the path to a field on the table row that we are going to use to filter the rows.
2. filterValue - is a text value that we are going to compare to the value of the field in filterPath. The function will only process/include rows where the filterValue is a match to the filterPath value.

For example:

If I have a custom table for tracking Contract details (CUSTOM/CONTRACTS) and I wanted to return the most recent contract date (CUSTOM/CONTRACTS/CONTRACT_DATE) for any “Land”-type contract (CUSTOM/CONTRACTS/CONTRACT_TYPE = “Land”), I would use a formula like this:

TableMaxDateFiltered("CUSTOM/CONTRACTS","CONTRACT_DATE","CONTRACT_TYPE","Land")

(note: the fields above must be enclosed in quotes and not square brackets in this case.)

We will enable both types of authentication by default. They can be turned off by adding one of the following to the <castle> container in user.config.