Release Notes v5.20
  • 27 May 2022
  • 3 Minutes to read
  • Dark
    Light

Release Notes v5.20

  • Dark
    Light

Article summary

What's new?

  • Drilldown will be available directly from reports, measures, and objects into the data model screen, with focus on the asset in question, via the zone navbar.
  • Module import will keep track of changes to both the module definition of all assets (measures, lookup tables, semantic mapping templates, etc), as well as the local version of those assets. For example, after being imported, an asset may or may not be localized. And, after being imported, the module version of that asset might have been updated. It's possible that both have happened. Thus, the four possible "Merge States" as displayed on the module import screen are, "All Matching", "Local Edits", "Updated Module", and "Branching Edits".
  • Depending on where the changes have been, the rules for including an asset as part of a module import will be different. For example, if neither the local version or the module version has changed, then the asset will always skip being imported, because nothing would change. If the local version has changed (i.e., "Local Edits" or "Branching Edits"), the default will be to skip the import, though users dealing with
  • "Branching Edits" assets would be well served to manually determine the nature of the edits and possibly pull in the updated module assets.
  • It has long been the case that during module import, some assets will hold back from overwriting aspects of the incumbent asset. For example, if the start date or user list of a report has been localized, then that setting will not be overwritten by the incoming module asset. Similarly, if an Integrator object is set with the "Clear Input Stacks for Module Submission" checkbox, then any localized mapping to input stacks will be honored even upon overwrite of the rest of the object. In all of these cases, a change to a non-overwriting part of an asset will not be considered a change to the asset, for the purposes of determining the merge state. Ad-hoc derived fields in measures do get overwritten upon re-import of a measure, so changes to these fields are considered a change to the asset.
  • These rules will be fully operational for all assets that have been imported after v5.19.0. For assets that were imported before v5.19.0, the merge logic will tend to overclassify as "Branching Edits" any asset with either a "Local Edit" or an "Updated Module", because Ursa Studio won't have kept track of the asset state at last import.
  • All assets except value sets and lookup tables will be clever enough to consider as "All Matching" any change that was independently but exactly updated on both the local and the module version of the asset.
  • Category filter for object workshop, which allows users to filter the object list by tag, layer, namespace, object type, or to screen out precursor objects.

What improvements have we made to existing features?

  • Public boards will be captured in the module submission/import process. The user that performs the module import becomes the owner of the imported board.
  • During module import, reports with boards will show each board as a separately importable asset. Users are not allowed to import a board if they do not import the report. If the report already exists in the target environment, users can choose which, if any, boards to overwrite in the target environment, and these boards will follow the same default merging logic as other assets.
  • ELT has been renamed ELT across Ursa Studio, to better reflect our philosophy of performing all our transformations within the database, and not during the load from any external sources.
  • When cloning a measure with an attached replicated object, the clone will be created without any replicated object.
  • The ADD DECIMAL TO ICD patterns will not add a decimal to a field that already contains one.
  • The filter control will by default be hidden on boards in Analytics Portal. Users can use the chevron tab icon to show or hide the filter control.

What's been fixed?

  • Value set ranges with alpha characters will be considered to have a super-inclusive upper range, as value set ranges without alpha characters already do. For example, the value range 100-200 has always matched not only 100, 150, and 200, but 200.75 as well. Now, the value range A100-A200 will also match A200.75, as had not been the case previously.

Was this article helpful?