Changes in Execute 21.1.298

Caution: This version has known issues and is not recommended for production.

We’ve identified a problem in this version that may generate invalid license identifiers, which could impact existing licenses. To avoid any disruptions, we recommend installing a later version.

Features️

  • Execute can now be configured to log system messages to Azure AppInsights. This is primarily to streamline monitoring and support of Quorum-hosted Execute environments, but may also be used by on-prem customers if desired. #system #312727
  • By popular demand… Execute now allows you to automatically release an AFE for approval after review is completed! #afe #admin #341618

    Using the new automatic_release.config.sample plugin, you can configure Execute to automatically release an AFE for approval when the review process is complete.

    1. Create a new System Review Position Rule called something like “Automatic Release for Approval” (the name doesn’t matter). Record the DOCUMENT_ID for this position (the GUID in the URL).
      1. Don’t include any people on this position. The system will automatically mark it as review complete once all other reviewers have finalized their review.
      2. Adjust the position rule to include it as the last reviewer on any AFEs you’d like the auto-release behavior for. This lets you fine-tune the behavior (maybe you want this on EVERY AFE, or maybe just your Abandonment AFEs).
    2. Create a plugin from automatic_release.config.sample and update the positionRuleId to be the DOCUMENT_ID value obtained earlier.
    3. Restart Execute

    Now… When you save an AFE that is (a) routed (b) has only this single reviewer as incomplete… and it’s the special new “Automatic Release” reviewer, it’ll automatically complete the review and release the AFE for approval.

  • Foundation for Execute’s new in-app update mechanism, which will allow an authorized user to upgrade to future releases from within Execute. Note that this change does make changes to the folder structure of the Execute Service and adjusts permissions for the Execute service user so that it can make future updates to those folders and the Execute Service itself. #admin #system #316299
  • Most Execute documents now support “Shared Locks”. This means multiple users can simultaneously edit the same document (Well, Job, or Site) and have their changes magically merged together. This helps avoid those situations where you can’t update your job with the latest spud date because Jim was busy updating the job’s safety information and went for lunch leaving it locked. #system #327274

    Since early times, Execute ensured that only a single user could edit a document (AFE, Well, Job, …) at a time. This was handy for some document types (such as AFEs) with a very strong workflow, but a bit cumbersome for heavily multi-person documents like Wells, Sites and Jobs.

    So… we’ve changed things a bit.

    Execute will now take shared locks for Wells, Sites, Jobs and all of your custom document types. This allows multiple users to be actively editing the same document and, upon save, their changes will be merged together. It means a whole lot less waiting for someone else to finish their work before you can do yours!

    Note: If you are making changes where you think you would benefit from the old-style exclusive locks, you can find “Edit with Exclusive Lock” under the more menu.

    This functionality gets really interesting when you include fields from related documents on custom tabs. Previously, for example, you could include read-only well-level fields on your Job for reference but now you can opt-in to allowing those well-level fields to be editable (from the Job) by adding EDIT_REFERENCED_DOC_FIELDS to your “Additional Configuration Flags” in settings.

Enhancements

  • The admin-facing field selection screen has transitioned from the recently released drop-down tree control to the same control used in the report field selector. The report selector version offers a better user experience and handles large numbers of fields more efficiently. #admin #334455
  • Updated the components used by the schedule printing functionality. #opsched #338042
  • We’ve improved the behavior in Execute’s new Approval Paths to better handle situations where multiple adjacent approvers have the same approval authority. #afe #admin #338680
  • We’ve added a new formula function to create a new DateTime (DateTime( "2024-05-01", "America/Edmonton")) and a new formula function to query if a workflow task is complete or hidden (i.e., needing attention or not). #formula #340773
  • We now support for List Filters on Workflow Tasks. #admin #workflow #293061
  • We’ve added icons to fields on Tasks and Custom Tabs to identify fields from related documents (vs. the document the user is currently working with). #system #318332

Bugs

  • Resolved an issue where you could create invalid AFE history by manually calling the Supplement AFE API and failing to save the historical (supplemented) version of the AFE. This only applied to those writing code against Execute’s APIs to supplement AFEs. #afe #api #339273
  • We’ve added the “Document Display Identifier” back into the field list in Execute’s custom business rules (Blockly). #admin #339421
  • Resolved an issue where list filters wouldn’t immediately clear an invalid value but would, instead, clear on save. #system #admin #341220
  • Resolved an issue where the FieldInfo report would show an error in the Field Type column for fields that had been deleted. #admin #341516
  • Resolved an issue where Custom Business rules failed to show custom fields on the AFE’s well table. #admin #338359
  • Resolved an issue where the order of Workflow Task fields could break field permissions. #workflow #334861
Ready to update?
  • For Quorum-hosted Aucerna Execute environments, email an upgrade request to Execute Support.
  • For on-prem instances of Execute:
    • Always ensure you have a recent backup of your Execute database before updating.
    • Download the installer from the Client Portal.