CKM-477

REST-like Direct Links to Subdomain Home (and other subdomain tabs)

Add a direct link that can be used to open the subdomain home directly when opening CKM via this link.

This is similar functionality as we already have for archetypes, templates, termsets, release set and project & incubators.

Direct URL style:

…/ckm/subdomains/<cid-subdomain>

The direct link is displayed in the browser and can e. g. be copied from there.

CKM-1164

Add a "Reason for Checkout" freetext when checking out a branch

Add a Reason for Checkout free text text area when checking out a resource to a branch.

The provided Reason for Checkout is then used as part of the log message for the first branch revision. Currently this is always “New branch” in CKM’s main server language and cannot usually be changed by the user checking out the resource.

On checkout of a resource there should be a new Text area describing the “Reason for checkout”. This must be optional to fill in.

Rename the text areas to

• “Checkout log message” - for checking out

  • Normal checkout: Provide an empty text similar to the other empty texts (e.g. “Please provide a brief log message that describes the reason for checkout.”

  • Translation checkout (for uploading translation or starting an online translation): Prefill the log message text area with “Translation”

• “Update log message” - for any branch updates

On the checkout tab of a resource (i.e., when the resource is already opened), remove the “Revision History” Button because it is more confusing than useful at this place. Keep at all other places a checkout can occur.

Refer to CKM-1802: Display shortened "Reason for Checkout" freetext in the branch title on how this will be displayed (in addition to the normal log message).

CKM-1286

Automatically link Change Requests mentioned in a log message to the Change Request

Automatically link Change Requests mentioned in a log message (e.g. CR-123) to go to the CKM Change Request directly.

For each CR mentioned in the log message, a link is added underneath the log message that opens the Change Request directly.

For this link to work the Change Request MUST exist and be a Change Request of the resource (and not for some other resource).

Open

CKM-1406

Display link to CKM resources on GIT more prominently

In a CKM with configured GIT export of its resources, there should be a panel linking to the archetypes and templates on the GIT repository available from the Export tab.

This link panel should be available for all archetypes, templates and termsets that are

• in an active state and

• owned by a project (not an incubator).

The full path within the git repository needs to be constructed considering

• the local vs remote state of an archetype (they need to go to different git folders: local vs remote)

  • If remote, the namespace of the remote subdomain is added.

• the RM Class of the resource (e.g. OBSERVATION → entry/observation)

• the archetype id or the template name as filename.

See e.g. https://github.com/openEHR/CKM-mirror for the openEHR CKM git repository.

This new panel has been added to the Archetype/Template Export panels underneath the buttons but before the “Archetype Transforms”.

CKM-1429

Overview Page of All Projects and Incubators grouped by Subdomains

Currently projects and incubators are mainly opened via Projects / Open Project or the respective Open Incubator menu item. This displays a select box to open a project. Alternatively, the projects and incubators can be opened from the left hand accordion panel. However, neither provides a good overview of what projects are available in the CKM instance. It would therefore be very useful to have an overview of all projects and (visible to the user) incubators and their descriptions, grouped by subdomains.

In this new overview, the subdomains should be sorted so that the local subdomains are displayed first in alphabetical order, followed by the remote subdomains (which often will only have one project anyway). This new overview is available from the Projects Menu: Projects & Incubator Overview.

Open

CKM-1481

Add appropriate support for TRANSLATION_DETAILS.other_contributors and version_last_translated

With the advent of TRANSLATION_DETAILS.other_contributors as per SPECBASE-23 as well as version_last_translated, this needs to be supported appropriately by CKM.

• This includes parsing, storing, reconstructing of archetypes with these fields set in TRANSLATION_DETAILS

• Appropriate display in the simple and mindmap views of the archetype.

• Appropriate support when translating an archetype with these fields set using CKM’s online translation functionality.

  • When translating an archetype directly in CKM, other_contributors of the translation can be added directly in the translation tree.

  • version_last_translated is shown if already set in the archetype and in these cases can be updated. It will however not be exposed to the online translation if not populated at all.

Example display:

Example of the display in CKM’s online translation functionality.

Note that as discussed in SPECBASE-23 this is only available explicitly in combination with ADL2. Therefore, the translations other_details map is used with a key of other_contributors. This can be used with ADL1.4 to store the other_contributors, one row per other contributor to the translation.

CKM-1514

Archetypes Overview Mind Map of each project

Each project and incubator now provides an overview mind map of all its archetypes, organised by RM classes.

A similar mind map is already available for all archetypes via the Archetypes menu in CKM.
However, nowadays, this mind map typically contains so many archetypes in larger CKM instances that it make less sense than it used to.

The new project-based mind map will provide a better overview on a per project basis.

In addition to making the project-based mind map available, this issue also includes various extensions and finetuning of the mind map:

• Ensure all ITEM_* archetypes are added as structure (get ckm-test or openEHR CKM)

• Fix missing icon on Structure node

• Only add RM class nodes with archetypes in it

• More flexibly assign RM class nodes to the left or right of the mind map, in a best-effort to keep a logical structure, for example: ENTRY nodes should be adjacent to each other on one side if there are others, but in case there are only ENTRY nodes can use a layout that considers the typical clockwise order of Observation, Evaluation, Instruction, Action.

• Add resource status icon as image to the individual nodes

• Finetune horizontal rule (hr) display

• On hover over each node, more information is revealed, such as

  • the archetype id,

  • the revision number,

  • the resource description (concept description), and

  • an indication of the ownership status of the resource (owned by project, referenced by project, remote).

CKM-1590

Support REST-like URLs for direct links to discussions

In CKM 1.18.0 there are direct links like for example:

• …./ckm/#showGComment_1013.18.1787 to directly go to a general discussion

• …./ckm/#showAComment_1013.18.1600_1013.1.3574 for a discussion with citeable id 1013.18.1600 for an archetype with citeable id 1013.1.3574,

• similar for other resource types (templates, termsets, release sets),

• and discussions for projects as whole: …./ckm/#showPComment_1013.18.1748_1013.30.44 for a discussion with citeable id 1013.18.1748 for a project with citeable id 1013.30.44.

These links should be REST-like, e.g.

• For General Discussions: …./ckm/discussions/1013.18.1787 (or maybe .../generaldiscussions/... for clarity’s sake?)

• For archetype-related discussions: …./ckm/archetypes/<archetype-cid>/discussions/<discussion-thread-cid>

• Similar for templates, termsets, release sets

• For project-related discussions: …./ckm/projects/<project-cid>/discussions/<discussion-thread-cid>

If the discussion-thread-cid is specified (and valid) the exact Change Request is opened. If no discussion-thread-cid is provided (or it is not valid/unknown), the discussion tab for the resource or project is opened without expanding any particular Change Request.

Note: The plural form of “discussion*s*” is consistently used instead of discussion, comment or comments.

These new REST-like links are also now used in generated CKM emails (such as for a new comment for an archetype or a new general comment) and are shown as direct URL underneath the discussion thread as well as in the browser toolbar.

CKM-1591

Improve Audit Log Initial View

When the Audit Log is opened, up to now a result has immediately been displayed based on the default search parameters (everything in the last month).

Unfortunately, the fact that this result only covers the last month is is not very clear and thus the fact that this is not the complete available audit log may be missed.

Therefore, this issue changes the behaviour in the following way:

1. Do not display an initial result grid. Display the grid only after the user has specified the options and clicked on the search button.

2. In the header of the result grid, show the actual parameters used for the search if they are constrained (such as start date, end date, actor, event and asset type).

CKM-1592

Add the Resource Main Id to the Audit Log when a Resource event is audited (esp. deletion)

Capture the resource’s main Id to the Audit Log when a Resource event is audited, for example: add the archetype id to the Audit Log when an archetype event is audited.

This is most relevant for deletion, but has also been implemented for updates and creations.

Issue created as result of this CKM discussion:
https://ckm.openehr.org/ckm/#showGComment_1013.18.1787

CKM-1647

Increase usage of css variables to better support the creation of themes

Due to Internet Explorer’s incapability to use css variables, core css variables have so far only been used for unessential styling.

However, in the absence of Internet Explorer 11, and with all reasonably latest releases including for Edge supporting this properly, it is now possible to use css variables to streamline the creation and maintenance of the various ckm themes.

Streamline the current themes (blue, gray, ocean) so that (nearly) the only thing that needs to be specified in the gray and the ocean themes are these variables, mainly for colour changes. This will greatly increase maintainability of existing and make the creation of new themes a lot easier and less error prone.

The CKM gray theme was based on a gray theme of the core framework, however this additional dependency has been removed as well as part of this streamlining.

CKM-1700

Improve recipients of email notifications for submitted translations

Currently, only project editors get notified of submitted translations via email.

However, in many cases, the integration of the translation could and should be done by translation editors of the project.

After some discussion, the following behaviour has been implemented:

• If at least one translation editor exists for the project owning the archetype, send the notification email to all translation editors of the project.

• If no translation editors exist in the project at all, all editors of the project are notified instead.

• If the translation branch competes with other active branches or is outdated because it was not branched from the latest trunk revision:
  Notify both the resource's project editors and translation editors. This is because in this case, translation editors need to coordinate the commit process with the project editors: Due to the restrictions introduced in CKM-1477 of CKM’s 1.18.0 release, it is no longer possible for translation editors to commit the translation on their own.

To clarify this behaviour, the email template for notifying the translation editors or editors has been finetuned and the following sentences have been added after “Please check and commit the translation as soon as possible.”:

Please coordinate the commit process with the project editors and translation editors as appropriate: Translation editors can only commit a translation branch if there are no other active branches and if the translation branch is branched from the latest trunk revision of the archetype. In all other cases, translation editors need to coordinate the commit with the project editors.

CKM-1702

Remote Archetypes Import: Ability to filter archetypes (free text filter on the archetype id and displayed concept name)

In order to improve the usability of the functionality to import remote archetypes or update them to a newer revision, CKM now offers the ability in the Remote Archetypes Import/Update panel to filter on archetype id and concept name (as displayed).

For this, a “Filter” text field has been added that can be used to quickly filter the displayed archetypes for their archetype concept name (as displayed) and archetype id, considering partial results, case-insensitively.

All archetypes that don’t fit the filter are temporarily hidden from the archetypes displayed, if and only if they are not selected (checkbox). Any already selected archetypes are shown in addition, so that it is always clear which archetypes are to be imported or updated, when the Import button at the bottom is clicked.

This functionality applies to the NEW and UPDATED archetype panels.

CKM-1728

Upgrade to Twitter [X] API v2

For new twitter apps, tweeting is only possible via the new v2 of the Twitter API. Alternatively, each app/CKM would need to apply for elevated access to be able to continue the use of v1.1 of the Twitter API. For current apps, this restriction has been gradually implemented by Twitter/X as well, making this an important update also for CKMs with existing Twitter configuration.

Unfortunately, the library currently in used by CKM for twitter access does not seem to be maintained anymore and is not likely to experience upgrades to v2.

Therefore, the connection to twitter had to be completely rewritten so that CKM can continue to support twittering for new CKMs or existing CKMs that would like to configure the twitter functionality.

Existing users of the CKM twitter functionality, will need to to create project-based app credentials with OAuth1a enabled and update accordingly.

Without this, a 403 Forbidden error is likely to occur:

Existing customers that use CKM’s twitter functionality, therefore must follow these steps:

1. Go to https://developer.twitter.com/en/portal/dashboard and login with the account used for CKM twittering.

2. Ensure that OAuth1a is enabled for the existing App (with the credentials used by CKM).

3. Create a new project.

4. Add the existing App (with the credentials used by CKM) to it.

5. If OAuth authentication details have changed as part of the process, they need to be supplied, so that CKM’s twitter connection can be updated accordingly.

CKM-1730

WCAG Level AA: Add alternate (alt) attributes to images where necessary (and remove where redundant)

To improve accessibility and comply with WCAG Level AA, all relevant images should have “alt” attributes with a short alternate description of the image.

Ideally this alt attribute should only exist if there is no identical text next to it.

This issues comprises many such additions, including but not limited to the following places:

• The left hand resources panels

• All combo boxes which contain images for the trigger area

• Data type images

• Project & Incubator icons in panel titles

• TreePanels and TreeNodes

• Resource type images

• Remote archetype import dashboard for status icons, RM icons, etc

• InfoTooltip icons

• UserPanel, Users overview panel, Tri.states renderer, user tooltip

• The collapsed and expand icons in the Archetype html view that are updated accordingly on collapse and expand

• The more info and more details (zoom) images.

• Reviews (question marks for special questions, padlock for closed review rounds, …)

• Loading Panel loading icon

• Export icon in grids and charts.

• ResourceAdvancedDisplayPanel: RM class images in the results header.

• Workflow states in the Tasks Panel

• …

Also, restructure generic Panels to automatically add alt tags to the placeholder img used for the background icons as applied via css. This avoids the problem in all such Panels with an icon in the header.

CKM-1732

Catalan Localisation

Add a new Catalan Localisation (ca) for CKM.

CKM-1735

Remote Archetypes Import/Update Panel: Show Semantic Revision numbers of the remote archetype and the local archetype

In the panel to import remote archetypes, the semantic revision numbers should be made available, especially where archetypes can be updated.

1. Show the semantic revision numbers of the remote archetype for

   1. the latest asset version and

   2. the latest published

2. Show the current semantic revision number of the local archetype

Do this in a similar way as we currently have this already for archetypes used in templates, e.g.

For example:

Certificate (openEHR-EHR-COMPOSITION.certificate.v0) 

↪ Latest revision: 6 1.0.1-alpha 

↪ Latest published revision: 5 1.0.0 

↪ Current revision used in this CKM: 3 0.0.1-alpha

CKM-1736

Remote Archetypes Import Update Panel: Ability to compare a (newer) revision of a remote archetype with the currently used revision in CKM

When updating remote archetypes, it would be very helpful if it was possible to compare the remote archetype with the currently used local one.

Therefore, two new links are provided in the Remote Archetypes Import/Update Panel to

1. compare the latest remote version with the latest version in the local CKM, and

2. the latest remotely published version with the with the latest version in the local CKM.

This is done by providing two new links that open the respective comparison in a new CKM tab.

CKM-1737

Remote Archetypes Import/Update Panel: Ability to filter by project

In the panel to import and update archetypes from a remote CKM, it would be very helpful to be able to filter by archetypes of one project only - i.e. usually the remote archetypes referenced by this project.

This is very useful to be able to quickly see which archetypes may need to be updated for a certain project.

CKM-1742

WCAG Level AA: All colour contrasts used in CKM should have sufficient contrast in all themes

To increase accessibility and to improve compliance with WCAG Level AA all colour contrasts used in CKM should have a ratio of 4.5:1 or greater for normal text and 3:1 for large text as defined by the guideline.

Changes include but are not limited to the following examples:

• Passed Deadlines in grids where the contrast seems not sufficient for WCAG AA.

• Version color in left hand trees

• Colour for mindmap nodes

• clickable-tree css file for the template form display.

• Drop area background

• Introduce an unobtrusive color var in the css to use in various places that can be used for sufficient contrast ratio on white background. Rework various generators to increasingly use the related css classes.

• Fine-tune colour codes in org chart css (used for the statistics) to have sufficient contrast and also slightly increase the text size for the smaller text.

• Add incomplete colour code to css that is WCAG compliant and replace various direct references to a red warning colour + use unobtrusive colour for some grey (insufficient contrast) colours in grids.

• Colour contrasts of User classification Tags

• Colour contrasts for non specialised items in a specialised archetype.

• …

CKM-1743

WCAG Level AA: Improve Page Structure for Accessibility

To improve accessibility and improve compliance with WCAG Level AA, CKM’s page structure should be improved.

This is typically possible either by using html structural elements such as header. While this is the preferred method, this is not easily possible everywhere - in this case adding the equivalent ARIA role attribute is helpful (and required for WCAG AA compliance)

For further ARIA roles and explanations refer to:

CKM-1744

WCAG Level AA: Avoid tables structures for layout purposes or where not avoidable use ARIA presentation role to mark the structure as presentational

To improve accessibility and to improve WCAG Level AA compliance, tables structure should not be used for layout purposes or be marked with ARIA Role “presentation”.

Layout tables exist merely to position content visually but the content is not at all tabular in nature. They can introduce reading and navigation order issues. Screen readers may interpret them as data tables and thus introduces significant overhead on screen reader users.

Therefore either

• replace the layout table with other html elements and style using CSS, or

• add ARIA role="presentation" to the table (and possibly all tables underneath if required) to ensure it is not identified as a table to screen reader users.

While the first is preferred, some layout tables can not easily be replaced with the currently used components and in these case adding a role=presentation attribute is helpful for screen reader and ensure WCAG 2 AA compliance.

Some Horizontal and Vertical Panels can be replaced with new and more powerful implementations based on Flex layout.

CKM-1747

Remote Archetypes Import/Update Panel: Ability to filter the information and warning panels as well for the filter text and project

On the Remote Archetypes Import/Update Panel, CKM-1702: Remote Archetypes Import: Ability to filter archetypes (free text filter on the archetype id and displayed concept name) and CKM-1737: Remote Archetypes Import/Update Panel: Ability to filter by project have added the ability to filter by free text and by project a remote archetype is referenced in.

This functionality so far is only applied to archetypes that can be imported or updated.

This card extends the above filtering on free text and project to the Information and Warning Panels of the Remote Archetypes Import and Update Panel as well.

CKM-1749

Remote Archetypes Import/Update Panel: Ability to open the local archetype from the "Updated Remote Archetypes" panel

In the Remote Archetypes Import/Update Panel, add the ability to open the local archetype from the "Updated Remote Archetypes" panel (in a new CKM tab).

This is done by displaying a link » after the

Current revision used in this CKM: 3 0.0.1-alpha

as implemented as part of CKM-1735: Remote Archetypes Import/Update Panel: Show Semantic Revision numbers of the remote archetype and the local archetype

CKM-1750

Finetune the English Versions of Various Review Deadline Notification Emails

Finetune the English Versions of Various Review Deadline Notification Emails, in particular the

• The Review Round Deadline Expired Email sent to the Editors upon expiry.

• The Review Round Deadline Expired Reminder Email sent to the Editors on a weekly basis for the first month after expiry.

• The Review Round Deadline Expired A Long time ago Email to the Clinical Knowledge Administrators, sent if no editors follow up for approx. a month.

CKM-1751

Update openEHR logo

Update the openEHR logos where used in CKM to the latest version of the logo / favicon; see

This affects the AboutPanel in CKM in the Powered by Section in all CKM instances.

In addition, there are three places where the logo may be used by various CKM instances:

• In the header, top left as the instance logo

• In the About Panel - as the big instance logo

• As the favicon

CKM-1752

Add new CKM logo to About Panel, About Menu Item and (randomly) Dashboard

Add the new CKM logo to the About Panel in CKM and the corresponding menu item.

Also add the logo to the Dashboard as one of the randomly chosen community images. For a dark theme like the ocean blue, the dark version of the logo is used, for the lighter themes (blue, gray) the light version of the logo is used.

CKM-1760

Remote Archetypes Import/Update Panel: Filter by Created and/or last modified date

As an editor importing or updating remote archetype, it is very helpful to be able to filter or sort by the creation and/or last modification date of the remote archetype, so that the newest additions can be found easily. This way the editor can quickly exclude all archetypes that have previously been considered (and rejected) for use in the local ckm.

More specifically, a date box is added to the other new filtering options of the Remote Archetypes Import/Updated Panel.

If a date is selected and the results are filtered, the following filter applies:

1. For new archetypes that can be imported: In addition to any already selected archetypes, any new archetype will only be displayed if it has been created (in its initial asset version) on or after the selected date.

2. For already imported archetypes that can be updated: In addition to any already selected archetypes, any archetype that can be updated will only be displayed if it has been modified (in its latest asset version) on or after the selected date.

CKM-1761

Icon improvements

Various icons have been improved or added for this release:

• Rework Log off icon

• Rework the Add “+” icon that scales better

• New “Update” icon for use in Remote Archetype Import Panel

• Archetype from Remote icon converted to SVG to avoid having various differently sized icons with insufficient rendering in small.

• Subdomain icon simplified and converted to SVG to avoid having various differently sized icons with insufficient rendering in small.

• Rework validation icon as SVG and to better differentiate it from a generic warning icon in CKM, use a shield with an exclamation mark in it.

• Rework Classification “tick-box” icon as SVG: Better colour contrast for some themes (similar to the related resources green).

• Rework Change Requests / To Do list icon: New SVG icon with a minor tick and change colour to blue for better visibility in some themes.

CKM-1766

Make projects and subdomains crawlable

Projects and Subdomains should be crawlable in a similar way to archetypes, templates and projects so that they can be picked up by search engines.

This is deemed to be of particular importance for remote subdomains because cross-linking typically increases the importance.

CKM-1776

Remote Archetypes Import/Update Panel: Various additional improvements

In addition to the many other improvements and additions to the remote archetypes import process in this release, the following additional improvements have been made:

• Rework the layout of the display of each archetype (Floating icon, two lines, separator dotted line between each archetype, rename current revision to “imported revision” for clarity.

• Ability to open the local (as well as the remote) archetype from all warnings that an archetype with the same archetype id exists already in the local CKM.

• Improve project filter to deal correctly with the edge case of remote archetypes that have changed the archetype id. Previously, such archetype would not reappear when the filter is removed again. Cp. CKM-1737: Remote Archetypes Import/Update Panel: Ability to filter by project.

• Add Major version, Minor version and Patch labels to indicate the type of change between the currently imported version and the latest and latest published version from the remote CKM.

• Use Collapsible panel for the filter options and finetune display.

• Add Filter icon to Filter button.

• Add new icons to the New and Updated archetypes panels.

• Do not show a comparison option for the latest published revision if it is identical to the currently imported revision (but a more recent latest revision exists).

• Move the Select and Deselect buttons to a toolbar at the bottom of the Updated and New archetypes panels.

• Only show the Demographic archetype select and deselect buttons if there is at least one in either updated or new archetype panels, for consistency

• Harmonise and finetune some column widths.

• Increase maximum width of the drop down list of the remote subdomain select box to fit longer CKM names + URLs.

• Finetune vertical alignment of resource status icon and name as well as the comparison icon and name.

Under the hood, the following changes have supported this:

• Extend with a Tooltip and use GWTLabelledDatebox for the Date Filter.

• Extend the GWTLinkPanel used to create the links to be able to properly center align using a flex layout.

• Many Code and comment improvements, cleaning up and streamlining.

• Add German translations.

CKM-1786

WCAG Level AA: Add title tags for initial iframes

To improve accessibility and improve compliance with WCAG Level AA, title tags have been added to two two iframes in the loading html.

CKM-1787

Remote Archetypes Import/Update Panel: If no semantic version exists for the imported version, visualise this

In the remote archetypes import and update panel, if no semantic version exists for the imported version, this should be visualised with a tag similar to “minor revision”, “major revision” “patch” next to the imported version: “Semantic Version: N/A”.

This only occurs for archetypes that have been unchanged for many many years before semantic versions were introduced to CKM archetypes.

This is to provide a clear indication that this archetype should be updated.

CKM-1788

WCAG Level AA: Fix missing, empty or double form labels causing a WCAG AA validation error as e.g. used by Checkboxes and Focus panels

CKM-1789

Break overly long paths in Comparison Panels

Overly long paths were not broken into multiple lines in the Comparison Panels.

This is particular relevant for some very long path in the OPT Comparison Panel where this is destroying the table structure.

Very large paths (and words) should be broken into multiple lines if required at forward slashes .

CKM-1790

Comparison Panel: Harmonise the display of the semantic version change using a coloured tag

Harmonise the display of the semantic version change (“Major Revision”, “Minor Revision”, “Patch”) using a coloured tag. This is both for the overall compatibility as well as for each individual change.

CKM-1792

WCAG Level AA: Avoid Buttons and ToolbarButtons without text or provide an alternative text

To improve accessibility and increase compliance with WCAG Level AA, Buttons without Text should either be avoided or an alternative text should be provided via an ARIA label.

This includes changes to for example, buttons in the main panels of all resources, projects and subdomains.

CKM-1795

Comparison Panels: Display the Translation Language of changes in client language where possible in addition to the ISO language code

In the archetype comparison panels, CKM now displays the Translation Language of changes in the client language (where possible) in addition to the ISO language code.

For example:

The archetype has translations changes for: German de, Italian it

instead of the previous slightly confusing

The archetype has translations changes for: de, it

CKM-1801

Visualise the difference between archetypes referenced from remote or referenced from another (local) project/incubator in the Project Resources View

With increased governance, it is sometimes important to be able to clearly and easily differentiate whether an archetype is

• owned by the project/incubator,

• referenced from another (local) project or incubator, or

• referenced from a remote CKM instance.

This is especially relevant in the following places:

• Left hand explorer: As soon as a project or incubator is selected, it is currently only possible to differentiate local and remote references by hovering over it to display the tooltip.

• Project Dashboard, Project Resources and Project Hierarchy Views where it so far has not been possible to differentiate between referenced from remote or referenced from local project/incubator.

As a first step, this issue tackles the Project Resources View as available from e.g. Resources of Project Common Resources, International Clinical Knowledge Manager

In this Project Resources View, the remote (@) icon is displayed in the Owned column as applicable and a tooltip has been added for the three states:

• owned = tick icon,

• remote = remote @ icon,

• referenced from another local project = empty.

CKM-1802

Display shortened "Reason for Checkout" freetext in the branch title

In the resource revision history, the checkout reason introduced as part of CKM-1164: Add a "Reason for Checkout" freetext when checking out a branch should be displayed as part of the branch title. This is especially important if the branch is active and has not been committed yet.

Because the reason for checkout can potentially be quite long, only a shortened version should be displayed in the title, using “…” to cut it off so that it does not usually take more than one line.

For legacy reasons, if the reason for checkout is just a localisation of “new branch”, we don’t display this in the title as it is not very useful. Likewise for the old (up to approx. 2017) default message of “Branched archetype created by checking out the archetype.“ (or templates and termsets, respectively).

The complete reason for checkout is displayed as the “Log message” in the same way as the log message has always been displayed.

This issue also includes some finetuning of the visuals of title of the branch, so that where possible only one line is used for the branch name (user name) and the revision number and version, for example using a tag for the revision number and semantic version.

CKM-1805

Present the LATEST PUBLISHED revision as a green tag in the revision history

Present the Revision tag for the LATEST PUBLISHED revision as a “published” green tag in the revision history.

Especially, in the Development View of the revision history, this improves the way the published vs. more recent but unstable or previous revisions can be differentiated.

Also make the individual revision boxes slightly wider to accommodate sufficient space for slightly longer names without requiring a line break.

CKM-1806

Finetune shortening algorithm to consider line breaks as a word boundary to ensure that the "reason for checkout" is not shortened more than necessary

CKM-1802: Display shortened "Reason for Checkout" free text in the branch title adds a shortened “Reason for Checkout” to the always visible title of the corresponding element in the Revision History.

If the reason for checkout (log message) has a line break, this was not considered as a word boundary for shortening and may have caused the reason for checkout to be shortened more than necessary.

CKM-1810

Enable Open Graph Meta Tags and Twitter cards for sharing of archetypes, templates, projects and subdomains on Discourse, LinkedIn, Mastodon, Slack, Facebook, Twitter and others

This issue adds support for sharing archetypes and templates, on various Social Media services. Similar support has also been included for projects and subdomains which now support direct links as well (cp. CKM-1766: Make projects and subdomains crawlable).

Twitter cards are now supported for direct sharing of archetypes. templates, project and subdomains. Considering the current state of Twitter/X, and to simply support a wider range of tools, it is increasingly relevant to support other sites as well. Therefore, in addition CKM now provides Open Graph meta tags and thus support support other social media platforms, including but not limited to

• Discourse

• Mastodon

• LinkedIn

• Facebook

• Slack

• …

This is useful if someone copies a direct link to post in a social media site that supports open graph meta tags to extract the relevant information for display etc.

Sharing links like for example

will then display the resource type and its name as well as its description as applicable, followed by a short CKM description and the CKM image.

Discourse example:

CKM-1812

Display terminology bindings of runtime name constraints

Terminology bindings of runtime name constraints should be displayed in the relevant views of an archetype just as bindings in a DV_CODED_TEXT, DV_SCALE or DV_ORDINAL or in a choice of data types etc. are currently displayed in CKM.

The Spirometry result archetype available from is an example where term bindings are used to the various available runtime name constraints.

CKM-1814

When auditing the deletion of a branch, add the branch version, committed into version and branch status to the audit log message

When auditing the deletion of a branch, the following additional information is now added to the audit log message. This is helpful to improve the understanding what has been deleted:

• Branch version, e.g. 7.3 (most importantly the trunk revision this branch was checked out from)

• The branch status at time of deletion (active, committed, resolved, rejected)

• If the branch was committed to the trunk: Committed into trunk version, e.g. 8

CKM-1818

Visualise the difference between archetypes referenced from remote or referenced from another (local) project/incubator in the Project Dashboard

With increased governance, it is sometimes important to be able to clearly and easily differentiate whether an archetype is

• owned by the project/incubator,

• is referenced from another (local) project or incubator, or

• is referenced from a remote CKM instance.

In the project dashboard (e.g. Dashboard of Project Common Resources, International Clinical Knowledge Manager ), it is not currently possible to see if an archetype is from a remote subdomain. The remote @ icon should be displayed next to the concept name of the each archetype from remote.

This change is related to CKM-1801: Visualise the difference between archetypes referenced from remote or referenced from another (local) project/incubator in the Project Resources View

CKM-1821

Revision History: Last Revision of a Committed Branch should indicate if it was not committed to the directly subsequent trunk revision

In the Revision History of a resource, the Last Revision of a Committed Branch should highlight the Trunk revision number if it is not the one it was checked out from +1.

For example, if a branch of an archetype has been checked out from Trunk Rev. 8, but is not committed into trunk Rev. 9 but into Trunk Rev. 12, this should be highlighted in the Revision History.

The rationale is that it should be easy to identify when a branch is not following the most common flow of being checked out an committed again into the next trunk revision. This is especially useful when other circumstances (such as bulk updates without a branch or selectively deleted branches) further complicate the revision history.

This is achieved by the following changes:

1. Add an information icon next to the trunk revision number

2. On hover show a tooltip “This branch has been checked out from trunk revision 7, but was committed to the - not directly subsequent - trunk revision 9.“

3. Add the identical text to the “Committed to trunk version” field in the expanded panel.

All three changes are exemplified in the following screenshot:

CKM-1823

Add an immediate warning that an active review round exists on initiating a new review round as well as a final warning just before creating the review round

When an editor starts to initiate a new review round for a resource while there is an active review round for the same resource and the same review type (e.g. content of an archetype, translation or terminology) and same subtype (e.g. the translation language or the terminology to be reviewed), the editor is currently presented with a popup warning when clicking on “Next >” while “Start new review round” is selected.

This popup warning can be clicked away by the editor:

While this is helpful, it would be even more intuitive to be warned directly on the initial page where the resource is selected.

Therefore, this release of CKM adds a warning panel on the first page with the following warning:

An active review round of the same type exists. “Start new review round” will close the currently active review round and create a new review round. Please ensure that you really want to create a new review round”.

For archetype content and template and termset reviews, this warning can be displayed as soon as the resource has been selected (by double-click in the left hand panel or by being preselected).

For archetype translation and terminology reviews, the warning depends on the actual translation language or terminology selected and can only ever be displayed for the translation language or terminology currently selected in the language or terminology select box.

The existing popup warning will still be displayed in case the editor ignores the new initial warning.

While it may occasionally be useful to set up a new review round without explicitly having closed the old one, usually, the editors would close the review round to provide feedback to the reviewers some time before starting a new review round. Thus, this popup warning seems still to be a useful in addition.

On top of this, an additional warning is displayed at the very end just before the new review round is actually created. Apart from serving as another reminder, this may also be useful in the unlikely case that two editors (or one and the same in different browser or browser tabs) simultaneously work on setting up a new review round without coordination at the same time, thus avoiding the creation of two review rounds when only one was intended.

CKM-1824

Review Invitation Templates: Add additional placeholder for the initiating user and rename editor-full-name placeholder

The Review invitation templates as introduced in CKM Release 1.18.0 have a placeholder named “editor-full-name”. This placeholder is replaced by a comma separated list of the full names of all applicable editors as well as the original initiator of the review round.

(Note: The original initiator of the review round would usually also be an editor of the project, but could also be a CKA or may have been removed from the project team afterwards.)

This placeholder is somewhat problematic for the following reasons:

1. It is not clear from its name that it potentially refers to more than one person (beyond the person initiating the review round).

2. There are places/occasions within the review invitation where it is useful to only list the full name of the initiator of the review round instead of all editors of the project (which may be many in some projects on some CKMs).

Therefore:

1. Rename “editor-full-name” to “project-editors-and-initiator-full-names” to avoid confusion about the purpose of the placeholder.

   1. Update the explanatory text as well the initial email template.

   2. Update the correct placeholder checks to support “project-editors-and-initiator-full-names”

   3. “editor-full-name” still needs to be supported for internal purposes, “project-editors-and-initiator-full-name” can simply map to it.

2. Additionally, add a new placeholder for the editor or CKA that sets up the review round. This new placeholder is named “initiator-full-name”.

   1. Update the explanatory text as well the initial email template.

   2. Update the correct placeholder checks to support “initiator-full-name”

   3. “initiator-full-name” must be replaced with the (original) initiator of the review round.

NB: “initiator-full-name” always refers to the original initiator of the review round. If another editor or CKA updates the review round later (e.g. correcting a typo or adding/modifying a special question), the initiator of the review round remains the same.

NB: The placeholders are replaced only when displaying the invitation (inline invitation) to the reviewer as well as immediately on sending out the emails (mail invitation).

CKM-1826

WCAG Level AA: Avoid empty links, even if hidden

To improve accessibility and conformance to WCAG Level AA, links, even if just used for switching between tabs, should not simply have an empty link. Where this was missing, these need to be added or reworked in other ways,

CKM-1830

Left-hand explorer: Show inactive archetypes if the specialised archetype underneath needs to be displayed

Left-hand explorer: Show inactive (i.e. deprecated as well as rejected) archetypes if the specialised archetype underneath needs to be displayed because it is not inactive.

E.g.

• exam.v1 – deprecated (or rejected)

  • exam-u.v1 – active

  • exam-v.v1 – active

  • …

Otherwise the specialised archetypes are hoisted and this is undesirable/confusing,. This needs to be work on at least three levels as shown in the screenshot above. This should also work with differences in v0 vs v1 in the specialisation hierarchy.

Similar action needs to be taken if the specialised archetype is in a project selected in the left-hand-explorer drop down and the parent or grandparent is not.

CKM-1831

"Deprecated" and "rejected" revisioning label should also show the version and semantic revision

The DEPRECATED and REJECTED revisioning label at the top right of each deprecated or rejected resource should also show the version and semantic revision in the top right of the display of an archetype.

For example:

CKM-1839

Minor display improvements to the Tooltip of the resources in the left hand accordion panels

Minor layout improvements to the Tooltip of the resources in the left hand accordion panels.

Changes include:

• Increasing the size of the remote @ icon and floating it on the left

• Displaying the revision number as a revision number tag

• Finetuning of some padding and margins

• Use “Revision” instead of “Rev.”

CKM-1843

Subdomains: Add the Projects and Incubators panel directly to the subdomain's default homepage and restyle the Subdomain's homepage

Add the Projects and Incubators panel directly to the subdomain's default page and restyle the subdomain homepage to be similar to the Overview Page of All Projects introduced in CKM-1429: Overview Page of All Projects and Incubators grouped by Subdomains. Remove the now redundant specific Projects and Incubators tab for each subdomain.

Rationale: There is not much on the default page and the fairly useful overview of all projects and incubators is easily missed.

CKM-1846

Rewrite of CKM's PictureServer for improved performance

CKM’s PictureServer is used to serve all images that are configurable. This includes user pictures, the default user pictures, various logos, subdomain icons and the favicon.

While the PictureServer in its current form is performing well, generally speaking, it is important to maximise its efficiency and ensure it works reliably and fast under heavy load. Therefore, CKM’s PictureServer has been improved in the following ways:

• Avoid writing the configurable pictures that already exist to the temp file folder each time.

• Where temporary files are still used, remove the need for redundant unique timestamps where there is no benefit if creating a temporary file already guarantees a unique name.

• Ensure that images are deleted after a while or even better they don’t even need to be stored as file but can be returned directly.

• Introduce a byte cache for some of the most frequently retrieved configurable assets stored in the database (such as the default user picture, the logos and favicon).

This has required some significant rework of the PictureServer, however this considerably

• reduces the load on the Asset Management System,

• reduces the load on the Servlet Container, and

• increases the speed with which the all configured images (such as user pictures, logos) are being served,

especially on loading CKM and when displaying many users at once who have not uploaded a specific user photo, such as in discussion threads.

CKM-1848

Resource Statistics: Option to restrict the Resource Status pie chart to active resources only

In the resource statistics, we have an overview of active vs inactive archetypes first and then another pie chart with the breakdown of all states.

This is accurate, however also slightly misleading because the % of e.g. published archetypes is then based on the total of all archetypes and thus potentially quite a bit lower, although it is clear that these will never be published (and in the case of deprecated actually have been published before the have been replaced with a successor).

Therefore, add a checkbox to indicate whether inactive (rejected+deprecated) resources should be included or not. By default, they are not included.

On the “Look what have been up to” widget on the CKM Dashboard, this should also use the version without inactive archetypes.

Cp. LinkedIn: If you're ever looking at the openEHR CKM - www.openEHR.org/CKM - and…
In the 'Status' donut chart below, there are currently 176 archetypes published - the percentage, however, is related to all archetypes including those deprecated and rejected. So a more realistic Published% is 176 published/648 active archetypes = 27.1%. Not a bad effort at all for a volunteer community.

CKM-1852

Use different default date format in Catalan CKM Translation

The date format required in the Catalonian context is different to what can currently be provided from the gwt implementation of it.

Therefore, this issue introduces a special date renderer to construct the date format differently in this case, for example:

17-nov-2022 instead of 17-de nov.-2022

CKM-1901

Archetype Proposals and Change Requests: Should not be able to submit at all if no description (and no title in the case of Change Requests)

Archetype Proposals: Should not be able to submit a new/updated proposal at all if no description has been provided.

Change Requests: Should not be able to submit a new/updated proposal at all if no description or title has been provided.

Otherwise there is a fairly generic error message stating that e.g. “XPath args is invalid: missing element 'description'“.

Therefore the “Save” button should only be active if a description and - in case of change requests - a title have been provided. Invalid description and title fields are highlighted accordingly (red border, exclamation mark with tooltip indicating that the field is required.

CKM-1903

WCAG Level AA: Fine-tune "Commit, Resolve or Reject Resource" grid to display an outdated trunk revision and ensure WCAG-AA colour contrast

For improved accessibility and conformance to WCAG Level AA ensure the following colour contrasts etc.

Commit, Resolve or Reject Resource (e.g. Commit, Resolve or Reject Archetype from the Archetypes/Revise Archetype menu) to

• fine-tune warning icon and warning colour used to fulfill WCAG-AA colour contrast requirements

• use a background colour for the outdated revision to make this more prominent

• Also add the “outdated branch” tooltip to the Branch name in the grid, so that it is more easily accessible

CKM-1905

Add "Powered by Ocean Health Systems" lettering to the openEHR CKM instance

Add "Powered by Ocean Health Systems" lettering to the openEHR CKM instance.

Place this underneath the logo and the “Clinical Knowledge Manager” lettering.

“Ocean Health Systems” should link to the Ocean homepage.

CKM-1906

WCAG Level AA: Make the OPT to HTML transform WCAG-AA compliant (colour contrasts, labels, ...)

For improved accessibility and conformance to WCAG Level AA:

The OPT to HTML transform needs to generate WCAG-AA compliant colour contrasts, labels, etc. to avoid WCAG-AA validation errors.

This is particular relevant regarding colour contrasts and form labels.

CKM-1910

WCAG Level AA: Rework Loading panel to avoid table layout, add alt tags, and finetune visuals

For improved accessibility and conformance to WCAG Level AA:

Rework Loading panel to use a horizontal flex layout in order to avoid table layouts for presentation purposes, add alt tags, and also finetune the visuals of the Loading Panel (vertically centered, loading indicator, …)

CKM-1911

Presume a change from a non-constrained top-level attribute to an ITEM_STRUCTURE to be a minor version change only

A change to the Archetype Comparer may be useful when a previously unconstrained “protocol” (or possibly another “top-level” attribute based on an ITEM_STRUCTURE) is constrained in a new revision.

While this is technically a breaking change requiring a major version change, in practice it is unlikely to be one, because there would likely not be a protocol at all in any data in that case (or at least not contradicting data).

Instead, when comparing two archetypes revisions where the protocol (or any other top-level ITEM_STRUCTURE is not constrained in Revision N, but constrained to something (most likely an ITEM_TREE) in Revision N+1, the Comparer should then not report this a breaking change requiring a major revision, but only as a minor revision presumed, accompanied with a special tooltip explanation.

From a non-constrained ITEM_STRUCTURE to ITEM_* could be seen as a minor version change only, especially for top-level attributes like data or protocol.

Rationale: While the exact technical meaning is that this is a breaking change, the part of the archetype would be (specialisation aside maybe) pretty much unusable practically speaking. For practical purposes: no ITEM_* defined in the ADL usually (nearly always) means that no data is expected here, not that any kind of data should be captured in that place.

See discussion at:

Rev 13 → 14

CKM-1912

Norwegian Date Format Improvements

According to The Language Council of Norway, who “works to strengthen the Norwegian language and language diversity in Norway. The Language Council is the state's consultative body on language issues. It follows up Norway's language policy on assignment for the Ministry of Culture”, there are various ways to express date in Norwegian writing and it has been determined with the Norwegian editors to use the format as in the following example

• 1. jan. 2023

• 10 feb. 2023

• 15 mai 2023

In particular:

• no 0 prefix to ensure double digit days

• shorten all months to three characters and add a full stop (except for mai which does not required shortening):

  • jan.

  • feb.

  • mar.

  • apr.

  • mai (only month with only three characters, hence no full stop)

  • jun.

  • jul.

  • aug.

  • sep.

  • okt.

  • nov.

  • des.

CKM-1913

WCAG Level AA: Avoid empty label for the Filter textfield of the Recently Modified Panel when logging in using a stored session

To improve accessibility and increase compliance with WCAG Level AA, the should be no empty label for the Filter textfield of the Recently Modified Panel when logging in using a stored session cookie.

This only occurs when the user logs in very quickly after loading CKM (usually via a stored session cookie of the CKM’s “Remember Me” functionality.

More generally, the issue is that the Recently Modified Accordion Panel on the left hand is refreshed/reloaded before fully loaded. This refresh is required due to the existence of private incubator resources.

CKM-1914

WCAG Level AA: Remove redundant title of the Remember Me Checkbox

For improved accessibility and conformance to WCAG Level AA:

Remove redundant title of the Remember Me Checkbox

CKM-1915

Support REST-like URL for Direct Links to Resource Proposals

Currently the direct link exists, however this uses the

#archetypeproposals_<cid> style.

This should be improved to (also) support

/archetypeproposals/<cid>

The REST-like direct link should be used whereever the link is displayed, including in email templates.

CKM-1916

Support for non-master (e.g. main) branch names as the branch for a ckm git mirror

Currently CKM requires the “master” branch for a git repository to push to.

Other branch names should be supported and configurable when setting up the git repository. Most commonly the branch name used nowadays would be “main”.

CKM-1917

Add additional configuration option for CKM's south panel

Currently CKM’s south panel (Bottom panel - only visible if something to display) is used primarily for temporary notifications such as to notify user about an imminent maintenance window.

In addition however it is used to display e.g. licencing information, and other CKM instance would like to use this for example to prominently show CKM’s git repository.

Therefore, the ability to configure a secondary notification that can be used for more permanent messages would be useful to avoid the need to reconfigure this each time after an upgrade. This message can either only be displayed when there is no temporary notification, or both messages can displayed in combination.

CKM-1923

Support (REST-like) direct link to individual Change Requests

Currently links to change requests are to the change requests page as a whole. The link used is e.g. …/ckm/archetypes/1013.1.5365/changerequests where 1013.1.5365 is the citeable id of the archetype (or template etc.) for which the change request has been created.

However with an increasing number of Change Requests, it is useful to be able to support a link that directly opens a particular change request on the page of all Change Requests, i.e. the requested Change Request should be expanded upon loading.

…/ckm/archetypes/1013.1.5365/changerequests/1013.36.10 where 1013.1.5365 is the citeable id of the archetype and 1013.36.10 is the citeable id of the change request.

This URL should be used in the new change request and new change request note emails and when clicked upon should be opened in CKM.

This URL should be displayed at the individual Change Request as a link and if possible directly in the address bar in the same this has now been implemented for Archetype Proposals as well in CKM-1915: Support REST-like URL for Direct Links to Resource Proposals for this release.

CKM-1924

Add an easy/obvious way to access reviews of the predecessor as well so that they are not missed when looking at the review overview

Scenario: A user looks at the content reviews of v2 of the Blood Pressure archetype on the openEHR CKM . In this case, all review rounds have been done on the v1 predecessor archetype and thus no reviews or review rounds are displayed for the v2 archetype.

If you look at Clinical Knowledge Manager - BP v1 Content Reviews, you’ll find these reviews.

The break between major versions is needed - we still need the predecessor available and governed.

We have previously added an info panel pointing to any predecessor archetype when looking at the status of a v2+ archetype, see e.g. Clinical Knowledge Manager - BP v2 Status. Also, a user can see and access any predecessor (or successor, respectively) from the revision history of these archetypes.

This issue aims to reduce the confusion caused by multiple major versions of an archetype by adding an easy/obvious way to get to the reviews of the predecessor as well so that they are not missed when looking at the review overview. This can be an information panel very similar to the one already used on the Status page for archetypes with an a predecessor in CKM.

CKM-1927

Must have appropriate role in target project to reassign a resource to that project

For historic reasons, it is possible for editors of a project A to reassign any resources to any other (suitable) project even if the editor of Project A is not an editor of Project B.

This has initially been deemed useful so that editors can effortlessly reassign any resources they don’t feel belong in their project.

However, with larger scale CKMs such as the international CKM this model seems less suitable nowadays as projects are often fairly independent. Also, each CKM has Clinical Knowledge Administrators (CKAs), and it seems the natural role of these CKAs to handle the reassignment if the owner project of a resource is in doubt.

In consideration, it seems to be a better approach to only allow editors of a given project to reassign resources of that project to a new project if the reassigning editor is also an editor of the target project. Otherwise the user can only reassign if the user is a CKA (or technical admin) or a subdomain admin for the subdomain of the target project.

If need be, CKAs can create a Project with “Unclaimed archetypes” and give any editors of other project editorship for this helper project.

CKM-1928

Review Round Combobox should display the language name instead of the ISO code of the language if possible

The Combobox to select an existing review round (as e.g. used when modifying a review round) uses the ISO language code in the summary string displayed in the Combobox:

Preferably, this would be the localised display language instead (so “German” instead of “de” in this case.

CKM-1931

Upgrade LOINC version to LOINC 2.74

Upgrade LOINC version to the latest LOINC 2.74.

CKM-1933

Add REST-like direct links for the various resource statistics

Currently direct links exist for the General statistics #generalstatistics (or #userstatistics).

This should be a REST-like URL that is also displayed and thus can also be copied as URL from the browser toolbar.

…ckm/statistics/general

In addition, the following …ckm/statistics/archetypes, …ckm/statistics/templates and …ckm/statistics/termsets should be supported.

CKM-1935

Improve logout confirmation dialog and extend the CKM message box to be able to use custom icons

Improve the logout confirmation dialog:

Add logout icon. For this extend the CKM message box to be able to specify individual icons, not only the typical warning, info and error icons. Also finetune layout.

CKM-1936

The listResources Report should advise Crawlers not to index the page, but nonetheless follow its links

The listResources Report should advise Crawlers not to index the page, but nonetheless follow its links.

The listResources Report which is mainly used for internal and crawling purposes appears prominently in some search engines.

Search engines should be advised to follow all links in the document, but not index the page itself.

CKM-1938

Improve crawlable Repository Report Overview Page

Improve the (internal, mainly for crawlers) Repository Report available from retrieveResources?list=true

This report is sometimes shared as well for users and indeed provides a good overview of resources available in CKM.

In particular add the following:

• Add the logo of the instance and the big CKM logo at the top.

• Add the Repository short name (e.g. openEHR, Apperta, …) available from the configuration

• link-to-introduction, e. g. "<https://openehr.atlassian.net/wiki/display/healthmod/Clinical+Knowledge+Manager">

• link-to-faq, e. g. "<https://openehr.atlassian.net/wiki/display/healthmod/Frequently+Asked+Questions">

• link-to-get-involved, e. g. "< >

• Add the additional about text: add-about-text, e. g. "Some extra text about this particular instance of CKM can go here. This however is just a placeholder."

• link-on-logo, e. g. "<https://www.openehr.org"> add to the logo.

• publisher-organisation, e. g. "openEHR"

• publisher-namespace, e. g. "org.openehr"

• Add a link to the git repository if it exists git:repository-url

• Link to openEHR and link to Ocean including logos at the bottom.

• Improve style and paddings of the various headings

• Use css for links so that the links appear in vivid colour as in CKM.

• Make better direct link available beyond retrieveResources?list=true → ckm/respositoryoverview

• Various layout finetuning

• Localise for each language

CKM-1942

Empty translation descriptions should be considered as translated

When an archetype is translated, it is possible that e.g. a description is intentionally not translated, e.g the placeholder translation is completely removed in CKM’s online translation functionality.

This results in - legal - ADL such as

["at0005"] = <
text = <"Våken og adekvat">
description = <"">
>

However, on a subsequent translation, the placeholder translation may be added again in CKM’s translation functionality, and if not manually deleted again, on saving this result in e.g.

["at0005"] = <
text = <"Våken og adekvat">
description = <"*Keenly responsive.(en)">
>

A translation of something to an empty string is technically legal and thus should be honoured. A possible use case for this is in the translation language, the text and description can be combined into a text only.

Consequently, CKM’s online translation functionality should not (re-)add the placeholder for non-translated items in the following case:

1. In the current (branch) revision, the translation language already exists, at least in a rudimentary form.

2. The empty item is a description item.

NB: While the specs treat text and description identically, we only change the behaviour for description at this stage, since it is very likely that we don't want a completely empty text in the translation if the original text exists.

NB2: We continue to add these placeholders for description items in the initial translation if using CKM's online translation functionality. This is because is most circumstances it is desired to keep track of untranslated description items for the translation language.

Also, it should not mark these as missing translations in the translation functionality.

Finally, in the Translation Completeness Reports available from the status page, such empty-string translation should not be counted as missing translations.

CKM-1943

Add Twitter / Open Graph social media tags to the CKM startup pages

Add Twitter / Open Graph / social media tags to the CKM startup pages, so that they can be shared via e.g. Twitter, Discourse, LinkedIn, Mastodon, Facebook, and other services supporting Open Graph Social media tags.

For example Discourse preview:

CKM-1957

Various Modifications to "Email Projects, Reviewers, Users" from the "Projects" menu

The editor functionality to "Email Projects, Reviewers, Users" is currently placed in the Projects menu.

However, in most cases, this functionality is currently not sought in the context of a project, but more generally in the context of e.g. a Review Round or for some other notification to selected users.

Therefore:

1. Add a new menu item “Email Reviewers” to the Reviews menu.

2. Add a new menu item “Email Users” to the Tools menu.

3. Change the text of the menu item in the Projects menu from "Email Projects, Reviewers, Users" to the simple “Email Project Members”

4. Adapt the order of the tabs to select the email recipients according to reflect the menu it was opened from.

5. Finetune some text and instructions, also partly depending on the primary recipient type (project members, reviewers, other users)

6. Some internal rework and simplification of the panel implementation, extending CKMTabbedPanel.

7. Internal rework to simplify the Resource Selection panels as required for implementing the above.

CKM-1960

Add ADL2 converted archetypes to a separate folder of the same git export

Following the discussion and the resolution described by Erik Sundvall at , CKM should also export ADL2 converted archetypes to a separate directory of the same git repository. This directory should have the same folder structure as the current archetypes directory

CKM-mirror

• local

  • archetypes

    • cluster

    • composition

    • …

  • archetypes-adl2

    • cluster

    • composition

    • …

  • templates

    • …

• remote

  • …

Not all CKM instances may want to mirror ADL2 archetypes, therefore a new configuration option has been added that controls whether to export ADL2 archetypes to the git mirror or not.

CKM Instance owners, please contact Ocean to have ADL2 git export configured.

CKM-1965

Improve some - mainly - Catalan localisations and fix some related layout problems

Improve internationalisation and Catalan localisation in the following ways:

• Various straightforward improvements and corrections to the Catalan localisation

• Fix a few accidental html tags appearing in emails and other localisations

• Finetune layout of project members overview panel to ensure width and height is ok in Catalan (& Norwegian as well), including some panel rework.

• ShareWithColleaguePanel: Ensure “direct link” label is on one line in all languages

• Separate project members, incubator members, subdomain members internationalisation due to gender differences in Catalan making the previous approach impossible

• Make a few localisation message parameters optional for more straightforward translation into Catalan (“historial” without the resource type)

• Properly internationalise and localise Top-level types for archetype tab headings

• Incomplete Localisation Text for "Ressalta les diferències de text (text antic = vermell; text nou = verd)"

• Capitalise Find resources subtab header initial character.

• Increase width of review deadline date select box and other date select boxes to ensure it can always show the complete Catalan date.

• Correct and update English and German translation of the Identification Explanation tooltip as reported by Richard Kavanagh at

• Improve various widths for the Release Sets Tab Panel and the Watches panel for Catalan.

CKM-1966

Internalise an Archetype: Autopopulate the "Reference to original resource" Text Area as far as possible

When Internalising a remote archetype for local modification, a “Reference to original resource” is requested.

The corresponding text area is pre-populated as follows.

Derived from: <Add reference to original resource here>

It is recommended to use the syntax from the Share With Colleague tab of the remote archetype, for example for the Apgar Score v2:

Apgar score, Published archetype Internet. openEHR Foundation, openEHR Clinical Knowledge Manager cited: 2023-05-05. Available from:

This issue automates adding the reference directly to the text area, so that some effort is spared in having to go to the remote CKM and copy/paste from there.

<Concept name of archetype in best available language>, <Resource Status> Internet. <Original publisher from archetype OR current custodian from archetype>, <Remote subdomain name, possibly adding/replacing “CKM” with “Clinical Knowledge Manger”>. Available from: <Remote CKM URL>/archetypes/<remote-cid>

Available from and Internet to be localised as well.

CKM-1998

Left Hand Projects & Incubators Panel should sort the subdomain folders in harmony with the new Projects and Incubators overview and always display the correct icon in the tree

The Left Hand Project & Incubators accordion panel is grouped by subdomains, i.e. the top-level folders are subdomains.

All subdomains with at least a project or incubator are listed here, empty subdomains don’t need to be listed.

Currently, these subdomains are not fully sorted alphabetically, which they preferably should be.

In harmony with the new Projects and Incubators Overview from the Projects menu, they should be sorted in the following way:

1. local subdomains before remote subdomains, and then

2. alphabetically, case-insensitively by subdomain name.

For each subdomain, all projects and incubators should then be sorted alphabetically, case-insensitively by project/incubator name in the left hand panel.

The subdomains should show the subdomain's subdomain icon or if none is configured either the remote icon for remote subdomains or the normal subdomain icon for local subdomains. Likewise, projects, public and private incubators should all show their respective icon to be able to quickly differentiate the three types.

CKM-1733

Double specialised archetypes: Inherited items when specialising in "2nd generation" should be displayed like the grandparent not like the child

Double specialised archetypes: Inherited items when specialising in "2nd generation" should be displayed like the grandparent not like the child, i.e. grey not white background.

See attachment from which is specialised from , and which again is a specialising of

In the display, it is not possible to tell that a lot of the items are inherited from its parent.
It is more useful to differentiate the display (grey or white background) based on whether the items are inherited on any higher specialisation level, not only from the corresponding non-specialised archetype.

CKM-1763

Sudden asset.query vs asset.get discrepancy

The following problem with one TEST database has been investigated.

It seems that for one asset at least, the following occurs:

 Neither

• asset.query :where cid='1013.1.18'

nor e.g.

• asset.query :where id=420  :use-indexes 0  (420 = 1013.1.18)

yield any result anymore although the asset is there. The second query indicates that this is likely not an indexing problem.

A direct asset.get however works fine.

A backup-restore of the database does not change this behaviour. The asset hasn’t been modified in nearly two years, the server version has not changed.

NB: This is on a local machine in a test environment only.

This was tracked down to a defect in the asset management system behaviour with “cached collections” and has subsequently been fixed.

Note: Because, CKM has only explored the use of some “cached collections” for speed improvements in a test environment, this is an issue that has been taken seriously but has not had any impact on any production CKMs.

CKM-1770

A project with zero resources shows change requests

When a project has just been created and does not yet have any resources (i.e neither archetypes, nor templates, nor termsets) in it, the overview of the project’s change request may show Change Requests.

1. Create a new Project

2. Go to the Project’s Change Request tab.

3. Assuming, the CKM instance has appropriate Change Requests for resources in other projects, Change Requests will be displayed for this project as well, instead of not displaying any change requests at all.

Obviously, no change requests should be shown in this case.

CKM-1771

Review Invitation Templates: Create Invitation Template does not close the tab properly when clicking on the header tab close icon

Review Invitation Templates Create Invitation Template does not close the tab properly when clicking on the tab close icon in the tab header.

Steps to reproduce as a CKA:

1. Reviews/Manage Invitation Templates

2. Click Create Invitation Template button

3. Try to close the tab (via the tab header)

→ The tab is not properly closed and removed.

Expected: CKM should warn about losing changes (if applicable) and then close the tab as requested.

CKM-1773

Create Subdomain: Very quickly double-clicking the button causes the subdomain to be created twice

Create Subdomain: Very quickly double-clicking the button cause the the subdomain to be created twice.

To reproduce:

1. As a CKA: Choose Projects/Create subdomain.

2. Fill in the required subdomain fields.

3. Very quickly click the Create Subdomain button twice.

4. Check in the list of subdomains → It is possible (if you were very quick in pressing the button twice) that the same subdomain has been created twice.

CKM-1785

Active tab header has an unnecessary bottom border in some resolution/zoom combinations

An active tab header displays an unnecessary bottom border in some screen resolutions/zoom combinations.

This seems to be mainly happening on Chromium-based browsers such as Vivaldi.

In the screenshot below, no border should be displayed underneath “Dashboard”.

CKM-1793

If a branch was created by an admin on behalf of another user, the branch name should display as the other user's name, not as the admin's name

If a branch was created by an admin on behalf of another user, the branch name should display as the other user's name, not as the admin's name.

For example if a user “Mr Ocean” creates a branch on behalf of another user, the branch is created correctly, but in the revision history this is displayed as

where this should probably better be the name of the other user in the title even if created by “Mr Ocean”.

Note: This is not functionality exposed to the UI - you cannot currently checkout for another user from the frontend and thus this is an issue that does not occur in production systems.

CKM-1804

After a user self-registers, the user may not appear in the "Manage Users" tab for a while

If a new user is created via self-sign up (“Register” button), the user cannot immediately be found in the “Manage Users” tab. When searching using the “Lookup User” the new user can be found immediately.

“Refresh All Tabs” reloads the Manage User tab but the reloaded grid still does not show the new user.

The user would however appear once other changes to a user are made or after some time has passed.

Steps to reproduce:

1. Sign up as a new user using the “Register” button in the top-right toolbar.

2. Login as CKA and open Tools/Manage Users

3. Optionally, sort the user by Registration date to ensure you see the latest registrations first.

→ Note that the new user is not yet available in the table of users.

This was caused by insufficient invalidation of a cache and has been fixed.

CKM-1813

The "About CKM" Panel does not open if no link is configured for the CKM instance logo

Each CKM instance can configure a link for the top-left logo in CKM to e.g. go to the main website of openEHR International.

If a CKM instance has no link configured for this top-left CKM instance logo, the About Panel available from Help/About CKM does not open.

Expected: The About CKM Panel opens and also displays the CKM’s logo top-right.

CKM-1815

Wrong (false positive) Validation Error displayed when changing the archetype ID of a specialised archetype

When changing an archetype id of a specialised archetype, CKM shows an error message falsely stating that the change to the archetype id is not valid because

The concept name part (" + concept + ") of the archetype id is invalid - only use A-Z, a-z, 0-9 and '_' (plus '-' for specialisations).

For example: the concept part of a specialised archetype id is to be changed to imaging_exam-cervix.

The change is still performed (as correct), however the incorrect error message is confusing.

CKM-1819

Console Error if a user is accessing an archetype or template via a direct link and the user is being logged in immediately using the "Remember Me" functionality

The following Console Error is displayed under two circumstances:

• a user is accessing an archetype or template via a direct link and

• the user is being logged in immediately using the Remember Me functionality.

(TypeError) : Cannot read properties of null (reading 'containsKey_9_g$')
Unknown.isProjectOrIncubator_0_g$(ProjectsAndSubdomains…

This error has no effect as long as the resource is not private.

However, resources in private incubators would not be displayed if accessed in exactly the described way.

CKM-1820

The editor review round summary email may replace placeholders with the wrong archetype details under some circumstances

The editor review round summary email may have replaced placeholders with the wrong archetype (or template) details under some specific circumstances.

Steps to reproduce:

1. Create a new review round for an archetype

   1. use placeholders like %{resource-main-id}% and %{resource-main-display-name}% in the invitation details, and

   2. invite at least one reviewer,

2. Check the review invitation summary email (“Invitation of Reviewers Summary”) email sent to all editors of the archetype:
   This email replaces the placeholders in the invitation details with the values from a wrong archetype (for example the ‘Body temperature' archetype) even though the review round has been created for a different archetype (e.g. 'Imaging exam of a lesion’).

Note: The usual replacements in the normal text to the editors are made correctly:

The following 2 users have been invited to review Examination of a lesion (openEHR-EHR-CLUSTER.exam-lesion.v0); Review type: Content

Note 2: This issue is limited to the review summary email sent to editors only. It has no effect on the reviewers - for reviewers all placeholders have always been replaced correctly.

Note that the invitation details placeholders can only be replaced in the email to the editors if at least one reviewer has been invited. Otherwise, the following text is added to the email to clarify this: “Any placeholders will LATER be replaced with the correct values.”

This issue also includes some additional tweaks of the layout of the email (invited users as list, usage of bold vs underline, slight indent and left border for the invitation details).

CKM-1822

Project Resources are not updated after drag and drop of a resource

Project Resources are not updated after drag and drop of a resource.

The resource is added to the project as a reference, but the Project Resources are not immediately updated.

To reproduce:

1. Go to the Project Resources Tab of a Project, and

2. Drag and drop an archetype from the left hand panel.

The Project Resource Tab is NOT updated with the additional archetype as it should.

When navigating to different project functionality and then returning to the Project Resources Tab, the added archetype is correctly visible.

CKM-1825

[Internal] When a review round cannot be deleted because it is not the latest review round of its type for the resource, there should be an error message

When - internally - using the review round delete service for a review round, a couple of validation checks take place.

For example, a review round cannot be deleted if it is not the latest review round of its type for the resource.

The validation is correct, however, there should be an appropriate error message returned from the service if this is the case. Currently, the review round is then - correctly - not deleted, but no message is displayed in the internal terminal.

Note: The CKM User Interface would not give the option to delete such a review round in the first place, therefore this issue is internal only, and not relevant to CKM editors using CKM.

CKM-1827

Incorrect warning displayed if editors invite users from projects and all users have already explicitly been invited

Scenario: An editor invites users to a review round by in BOTH of the following two ways:

1. By explicitly naming the users AND

2. Via a project role the users hold in a project.

In case ALL users of a project are also explicitly invited, the editor is presented with a warning (that is also added to the reviewer summary email) that

No new review invitations have been sent out for user of project 'PROJECT_NAME' because all users with the selected project roles have been invited previously already.

This warning is misleading - it should only occur if these users have been invited previously, i.e when the editors have set up the review round and are in a later step adding additional reviewers via selecting project roles for a project. If this does not create any new invitations, the editor should be warned because this is likely unintentional. However, in the above edge case scenario, this is not the case.

CKM-1829

Should be able to mark an archetype that has been superseded by a version n+1 as deprecated afterwards from the context menu

It should be able to mark an archetype that has been superseded by a version n+1 as deprecated afterwards from the context menu in the revision history (etc.)

This is currently only possible from the resource status page, but should consistently be either available (or not possible at all).

CKM-1833

Left hand explorer filtering: Very first time when filtering for a text that is only available in a specialised archetype, the tree is not expanded automatically

Left hand explorer filtering: The very first time when filtering for a text that is only available in the concept name of a specialised archetype, the tree is not expanded automatically to show the specialised archetype containing the text.

For example - depending on the CKM instance - this behaviour can be reproduced using a free text filter “cranial”:

The correct behaviour is that the tree expands all nodes leading to the specialised (archetype) node, for example:

CKM-1844

Wrong/unintuitive order of comparison across major versions when selected from Revision History

When two major versions of an archetype are compared, e.g. the final v1 version with the first v2 version, the comparison is displayed the wrong way round, i.e. it compares for example

• Old: v2.0.0 with

• New: v1.9.6

instead of the other way round.

This happens for example if the old version is marked as deprecated only after the next revision is published.

See for example and compare Rev 3.0.0 (24-Dec-2021 12:26) and Rev. 2.05 (24-Dec-2021 12:38)

Also if an outdated branch has been marked as resolved or rejected (after the trunk has moved on), the comparison order may have been from the branch to the trunk revision which seems unintuitive.

CKM-1849

Compare archetype with uploaded (local) archetype: If the uploaded archetype does not exist, the Loading panel is not removed

When comparing a CKM archetype with an uploaded [“local”] archetype: If the uploaded archetype does not exist the Loading panel is not removed.

Steps to reproduce:

1. Open Archetypes/Compare Archetypes/Compare with Local Archetype

2. Upload an archetype with an archetype id that does not exist in the CKM instance.

3. An error window pops up as expected, however the Loading Panel (Please wait) is never removed.

This process can be repeated and the user ends up with multiple Loading Panels then as in the screenshot below.

CKM-1893

Editorial Board Member shows SysAdmin panel menu entry

Users with the (rare) role of Editorial Board Member are shown the SysAdmin menu entry in the Tools menu.

It is not functional (nothing happens when the menu item is clicked), however it should not be there in the first place for Editorial Board Members.

CKM-1894

Archetypes and Templates Overview mind maps: ADMIN_ENTRY resources are not displayed correctly

The archetypes and templates overview mind maps (of all archetypes / templates) show a mind map node for Admin, but ADMIN_ENTRY resources are not correctly assigned to it.

Also the admin cog icon is missing for that mind map node.

CKM-1898

Text rendering bug in mind map popup: The > sign when used in a comment is not properly rendered

The > sign is rendered as gt; in mind map popup, see attached screenshot and compare to attached correct rendering in tabbed view.

See Genomic Variant Result Cluster archetype → Comment on the “Variant” Parsable:

Comment: For example: 'g.33038255C>A'. If both this element and the 'Structured variant' SLOT are used simultaneously, they need to represent identical data.

should correctly be displayed as

Comment: For example: 'g.33038255C>A'. If both this element and the 'Structured variant' SLOT are used simultaneously, they need to represent identical data.

in the mind map as well.

CKM-1899

Order Templates only: Using Find Order Templates from the Order template menu shows a (wrong) temporary notification that this has not yet been implemented

Order Templates only: Using Find Order Templates from the Order template menu shows a (wrong) temporary notification that this functionality has not yet been implemented.

The Menu item functions as desired, but also displays an incorrect temporary notification that this functionality has not yet been implemented.

CKM-1918

Problem opening resources in CKMs with more than 100 projects/incubators

Problem opening resources in CKMs with more than 100 projects/incubators.

This happens for all Vital Signs archetypes such as Blood Pressure etc.

CKM will only display the first 100 projects. Resources owned by projects beyond 100 (alphabetically) could not be retrieved.

CKM-1919

Crawlers may fail to process direct resource URLs if the URL also contains a version number

Crawlers may fail to process direct resource URLs if the URL also contains a version number.

CKM’s CrawlFilter only deals with direct URLs like

.../archetypes/1013.1.130 or ../archetypes/1013.1.130/adl

It does however not deal properly with URLs like

.../archetypes/1013.1.130/5 or .../archetypes/1013.1.130/5/adl

This is not usually a problem because this is not accessible to normal users, but only accessible by crawlers and CKM only presents links to the latest resources to crawlers. However, when a direct url to CKM is found elsewhere on the web it may well be processed by crawlers and this direct url may contain a version. This in fact happens. Thus the version should not prevent crawlers from processing the archetype or template.

CKM-1920

The JSON-LD Structured Data Generator may fail to properly escape json if invoked from server side

The JSON-LD for the various resources (archetypes and templates mainly) generated for the various resources needs be generated both on server and client side.

For Crawlers, this is generated server side. In this case, the escaping of the values (resource name, resource description etc.) may fail to be properly escaped.

As a consequence, the provided json may be invalid and may prevent proper indexing of such resources.

See: JSON-LD - JSON for Linking Data for further information.

CKM-1921

Future-proof various backend queries that would cause too few results in large result sets

While only relevant for large CKM instances, some backend queries have been identified that may have caused too few results in large result sets.

This includes selected queries related to listing

• project invitations,

• comment subscriptions,

• release sets containing other sub release sets,

• review feedbacks,

• subdomains,

• user configurations,

• resource watches, and

• templates using other templates,

• members of an ontology class

• distinct commenters on a resource.

Note: This is unlikely to have caused any issue in production systems so far, however with the growing number of CKM assets and users, this issue future-proofs these queries.

CKM-1922

Certain advanced search texts prevent the search for resources to execute successfully

Some advanced search texts prevent the search for resources to execute successfully.

For example this search text is one that fails:

'C:\Users\JS\PROJEKTY\VisualStudio\NCZI\docs\IM_eZdravie_4_2_4(1)\IM_eZdravie_4_2_4\eZdravie_Duzby\Pri3.0.25\P_3.0.25\Schemy

After some investigation, this has been simplified to “test\test”.

To reproduce just copy into the Search Text Field of the Find Resource tab in CKM.

CKM-1929

Classification Sort Options cannot be initially set or updated

Clinical Knowledge Administrators (CKAs) cannot initially set or update the sort options of a classification.

Steps to Reproduce:

1. Log in as a Clinical Knowledge Administrator user

2. Open Tools/Manage Classification

3. Right-click on any class in any scheme (e.g. Addiction in scheme Health Domain)

4. Click on Options in the menu

5. Set a Sort key or select “Sort behind last normal element”

6. Click on “Save”

Expected Result: The sort options are saved and honoured.

Actual Result in CKM 1.18.0 (only): The sort options are not saved at at all and ignored.

CKM-1930

Starting a Template Review from the Dashboard may fail to open the review tab under certain conditions

Starting a Template Review from the Dashboard may fail to open the review tab under certain conditions.

This may happen if the template id does not contain any dots.

Note: This issue was only present in an early release candidate of CKM 1.19.0 and as such was never an issue in any production system.

CKM-1953

Structured Data for Resources: Crawlers expect at least 50 characters as description (and do not count empty trailing whitespace)

In the structured data generated by CKM for resources such as archetypes, to be presented to crawlers, crawlers expect at least 50 characters as description and may not index the resource (e.g. archetype) properly, see e.g. the Gender archetype in the openEHR CKM.

If the description is too short, as e.g. currently for the Gender archetype, we need to add more text, even if it just a dummy “Clinical Knowledge Manager CKM” addition until 50 characters are reached. We previously tried to circumvent this problem by just adding whitespace at the end, but this does not seem to be counted anymore, at least not by the google validator, thus preventing the indexing in these (rare) cases.

CKM-1954

Tasks for Dashboard To Do List cannot be retrieved if there is a relevant task for a termset

Tasks for Dashboard To Do List cannot be retrieved if there is a relevant task for a termset.

If a user logs in and such a task needs to be displayed on the Dashboard widget for the user, an error message is shown that the To List cannot be loaded.

Note: This has only been a problem if a task for termset needed to be displayed, in all other cases, the functionality worked fine.

CKM-1958

Search User Options and Search Discussions Options are breaking too much in Catalan localisation

1. Go to Catalan version of CKM (add /ca)

2. Log in as CKA or technical administrator

3. Open Eines/Cerca usuaris from the menu

In case users are found, the button to select may be off the window real estate or only half visible.

Similar for the General Discussion where some of the search options break the line.

These search options should automatically adjust in width for a best fit in each translation.

CKM-1961

Git Export: On first cloning of repository, a file handle may remain open

On first cloning of a git repository for exporting archetypes and templates, a file handle remains open until a restart.

This is not particularly harmful because the repository will only be cloned once, but should be fixed nonetheless.

CKM-1963

Resource Statistics Reports: Selecting a subdomain without any resources of the selected type does not show a result and does not stop showing the Loading panel.

When selecting a subdomain in the Resource Statistics Reports that does not contain at least one resource of the selected type, no result is shown.

Instead the “Loading data. Please wait…” Loading panel remains forever.

Steps to reproduce

1. Select Reports/Template Statistics.

2. Select a subdomain that does not contain any templates owned by any of its projects or incubators.

→ Loading data. Please wait…

Likewise for subdomains without a termset or archetype.

This is a regression introduced by CKM-1632 - Resource Statistics Panels - improve "No resources found message" when certain states are selected. for CKM 1.18.0.

CKM-1964

Review Invitations: When inviting project teams and selecting "Show all Projects & Incubators", the same project may be shown twice in the confirmation dialog

When inviting project teams to a review round and selecting "Show all Projects & Incubators", the same project may be shown twice in the confirmation dialog. Also projects that have not been selected may appear.

Steps to reproduce:

1. Start creating a new review round for an archetype.

2. In “Step 1: Invite Users”, select one or more projects.

3. Then, click the “Show all projects & incubators” checkbox.

4. Select same or different projects again.

5. Continue to the final step of the review round creation process.

6. Press the button to create the new review round.

→ In the confirmation dialog, a project that has been selected both in 2. and 4. above will be displayed twice. While this is slightly confusing, it is even more confusing if projects that have only been selected in 2. are listed as project teams to be invited.

CKM-1967

If User Self Registration is disabled in a CKM instance, the Dashboard's Register panel and button should not be displayed either

If a CKM instance has been configured to not allow the self-registration of users, CKM correctly hides the Register button in the login toolbar (and also generally disables the functionality to self-register).

However, the Register message and register button on the Dashboard (within the “Become a part of our online community” widget) if not logged in, is not hidden by this. This should not be displayed either if self-registration is turned off.

Note: This issue did NOT allow any users to actually register if self-registration is disabled, because this is prevented by backend security.

CKM-1969

Width of Quick Search Widget on Dashboard is too small for normal logged in users

The width of the Quick Search Widget on the Dashboard is too small for normal logged in users.

For Editors, CKAs or users not logged in at all, this is either not displayed or has the appropriate width, however for normal users the width is too small.

Note: This issue was never an issue in a production system but is a regression of CKM-1744: WCAG Level AA: Avoid tables structures for layout purposes or where not avoidable use ARIA presentation role to mark the structure as presentational which internally introduced a Flex layout with slightly different behaviour.

CKM-1972

Catalan Version Only: Submitting an online translation to the editors shows an error

In the Catalan translation of CKM, submitting an online translation to the editors only succeeds partially:

1. The translation is stored ok

2. However, usually a task is created for the archetype’s editors to check and commit the translation.

This task cannot be created and an error is shown.

Steps to reproduce in a CKM with a Catalan server locale:

• Checkout and translate an archetype using CKM’s online translation functionality

• Submit the translation to the editors

Also: Preempt potential similar problems with a Change Request and quite theoretically specific terminology name under review (if there is a terminology that contains a ' in the future).

CKM-1975

Archetype Data Points ("Informe">"Tipus de dades als arquetips") don't show in Catalan CKM

Archetype Data Points ("Informe">"Tipus de dades als arquetips") do not show with the following error message.

CKM-1977

Message displayed that No changes found in modified file when changing Archetype RM Class

When attempting to change the RM Class of an Archetype (which is only possible if it does not have any active branches and has never been published), a message is displayed that no changes are found in the modified Archetype file.

In the example below, the Component was updated which was not recognised as a change when the updated Archetype file was uploaded.

New Archetype uploaded in any Active Branches

Changed Component from Observation to Evaluation

Message displayed when Archetype file with updated Component uploaded

CKM-1978

Error message displayed when uploading Archetype with Language added via Archetype Editor

When attempting to upload an Archetype with a Language added to it via Archetype Editor, a Java Language error message is encountered.

In the Archetype file attached in the example below, the language French was added to the Archetype file via Archetype Editor

Error message displayed when attempting to upload Archetype File

CKM-1979

Message displayed that outdated branches were found when changing Archetype RM Class

When changing the Archetype ID of an archetype by submitting a new file (usually with a changed RM class), a warning panel was displayed (above the table with all Changes) indicating that there are “Outdated Branches”.

This warning always appeared and at the same time is always incorrect because the process of changing the archetype id can only be started if there are no active branches at all - outdated or not.

Therefore, this warning panel should never be needed when changing the archetype id and thus should never be displayed.

This is caused by a regression that has been introduced in CKM 1.18.0.

CKM-1980

Right borders on some panels do not display in some screen resolutions/zoom

Right borders on some panels do not display in some screen resolutions/zoom, e.g.

• Revision History - the individual panels

• Data Points Analysis report

CKM-1982

Error message displayed when uploading Template

When following the test case CKM-T26 as part of regression testing for the CKM-1.19.0-RC2 release, a problem was encountered when uploading a Template.

The steps taken were:

1. Navigate to a template

2. Checkout the Template

3. Modify the template with Template Designer

4. Go back to CKM go to Templates Menu > Revise template>Upload modified template

5. Upload the Template

6. The error message will be displayed

Attached is the Template file used after it was modified and a screenshot of the error message displayed when attempting to upload the Template

Error message displayed when attempting to upload Template

Note: This is due to some internally changed behaviour for CKM 1.19.0, was identified during regression testing and thus has never occurred in a production system.

CKM-1983

Comparison on Branch Upload compares with the trunk, not the latest branch

When uploading an archetype or other resource as a revision, a Comparison report is displayed.

This report should compare the uploaded file with the latest revision on the user’s branch, not with the latest trunk revision (such a comparison report should be displayed when committing).

However, due to a regression, the comparison compared the uploaded file with the latest trunk in this case.

Note: This issue was identified during extensive regression testing for the CKM 1.19.0 release and thus has never been an issue in any production system.

CKM-1988

Error messages received when searching for Archetypes, Templates, Order Item, & Knowledge Topics in Template Designer using CKM's REST API

When connecting to CKM via CKM’s REST API in Template Designer, an error message is obtained when searching for:

• Archetypes

• Templates

• Order Item

• Knowledge Topics

This was found when running the Test Case CKM-T111 as part of the regression testing for the CKM 1.19.0 release.

The API URL uses is: https://ckm-dev.oceaninformatics.com/ckm/rest/v1/

Screenshots of the API setup in TD and the error messages are attached.

Note: I have found that clicking on the ‘Clear’ button in the CKM Search and Download dialogue box sometimes allows the Types to be downloaded without any errors displayed which indicates the problem could be intermittent.

Message displayed after opening CKM Search and Download dialogue box

Message displayed when searching for Archetypes in CKM Search and Download dialogue box

Message displayed when searching for Templates in CKM Search and Download dialogue box

Message displayed when searching for Order Item in CKM Search and Download dialogue box

Note: This issue was identified during extensive regression testing for the CKM 1.19.0 release and thus has never been an issue in any production system.

CKM-1990

Adding resources to a release set that have resource documentation of a removed type causes a NullPointerException

Adding resources to a release set where the resource has resource documentation of a removed type (such as “schematron” or “cda-implementation-guide”) causes a NullPointerException.

To reproduce on the test and dev servers:

1. Login as user with role “CKA” or “Release Set Editor”

2. Select Release Sets / Create Release Set

3. Double-click on the left-hand panel’s eReferral template

This causes the following error message to appear.

Note: This is only currently a problem in selected test environments and not known to be a problem in any production system.

CKM-2000

Remove duplicated single quotes from localisations

In a few places, especially in the Catalan localisation, single quotes appear duplicated in CKM. For example in the Catalan version of CKM where "Nom de l''autor" and "Data d''autor original" are shown in the display of an archetype.

CKM-2009

Placeholders in localised texts are not replaced if they are constructed in the CKM backend

Placeholders in localised texts are no longer replaced with actual values if they are constructed from the backend. Such backend functionality is mainly used for archetype validation and archetype comparisons.

For example when uploading a new archetype that has a different licence to the standard licence as configured in the CKM instance.

CKM displays the following text - not replacing the two placeholders

{0} and {1} with the actual licence texts:

Incorrect:

The licence ('{0}') is different to the standard licence for this CKM ('{1}').|

Correct (example):

The licence ('This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/.') is different to the standard licence for this CKM ('This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/.').

Note: This is a regression introduced in CKM-2000: Remove duplicated single quotes from localisations and was never in a production system.

CKM-1586

[Internal] Remove Usage of Apache's deprecated commons.lang.WordUtils

Remove Apache's deprecated commons.lang.WordUtil_s (MailTemplatePreparer) and _org.apache.commons.lang3.text.WordUtils from backend and middle tier.

Replace with CKM's own Utility classes which may reference Apache StringUtils (or possibly org.apache.commons.text.WordUtils) as required.

CKM-1725

[Internal] Rework the Review Recommendation as an enum

Rework the review recommendations constants as an enum ACCEPT, MINOR_REVISION, MAJOR_REVISION, REJECT, ABSTAIN.

CKM-1734

[Internal] Upgrade to GWT 2.10.0 release

Upgrade to the latest GWT 2.10.0 release

CKM-1739

[Internal] Various Code improvements, refactoring, commenting, cleanup

Various code improvements, refactoring, commenting & cleanup related to the following:

• Project related calls

• UsernameSelectTriggerArea and SubdomainMembersOverviewPanel finetuning.

• XSLTTransformer

• various project related panels

• PublicationReport, SubdomainCombobox, InfoTooltipAdder, TemplateValidationsErrorPanel

• Harmonise capitalisation when switching from “Import New Template” to “Upload Modified Template” because the template id already exists - should use title case consistently.

• Remove redundant (old style) word wrap syntax from css

• Streamline css files to remove some no longer needed tags as well as !important markers as well, combine tags where possible, especially for the hierarchical and non-hierarchical elements used to display archetypes and templates.

• Ensure that the ErrorOrSuccessPanelBuilder used in the ResourceSubmitPanel sets the width correctly to the default width, but not to 100% of the width available.

• ResourcesPanel, ArchetypesPanel, TemplatesPanel from the left hand explorer trees: Minor code and comment updates.

• Various updates in preparation for more WCAG ARIA label etc. compliance updates.

• Description improvements to PProject and the SvcProjectsList service in relation to CKM-1815 - Wrong (false positive) Validation Error displayed when changing the archetype ID of a specialised archetype

• Comment improvements, use Optional for Uncommon ontology items HashMap - which often don't exist and use ifPresent syntax to add the uncommon ontology items where required.

• Improvements and clarifications to some Review Round related services and classes.

• Code and comment improvements to the Project Main Panel.

• Code and comment improvements to ReviewsAndInvitationsOverviewCombinedWidget

• Code and comment improvements to WestResourcesExplorerPanel and Resources Panel used in the left hand accordions

• Code and comment improvements of (left-hand) ArchetypesPanel, Termsets, Templates, ResourcesPanel, and the Resource List service

• Cleanup *MainData classes and *MainDataPanels.

• Cleanup PictureServer class

• Correct capitalisation in Advanced Template Search panel

• Correct width of ResourceComparisonPanel's explanation panel to default (instead of 100% / auto)

• Cleanup code and comment of ResourceSimpleHTMLGenerator.

• Minor cleanup of ResourceStatus enum.

• Cleanup and restructure ResourceMainStatisticsPanel

• Cleanup TranslationTreePanel & TranslationReviewTreePanel

• Harmonise the slightly different oi-notes and notes css styles into one and ensure that links are displayed in the same colour as well as other text.

• Cleanup Discussion Widget, ProjectOfResourcePanel, ProjectComboBox

• Clean up jsmind css

• Clean up of StringUtilsCKM, harmonise email checking methods,

• Clean up of NewsGrid comments

• Minor cleanup of ToDosWidget

• ResourceOneRevisionOverviewPanel: avoid extra div just for padding. Introduce new css oi-right-padded instead.

• Cleanup and repackage the Resources Overview Mindmap components in preparation for CKM-1514 Archetypes Overview Mindmap of each project

• Cleanup the code of the one Archetype Mindmap Creator.

• Cleanup code of Resources query panel, Subdomain and project select panel, resource statistics panel, resource status selection grid

• Cleanup of WestResourcesExplorerPanel

• Cleanup of StatisticsPanel and ChartPanel

• Cleanup of WorkflowStatus enum and ButtonOi

• Cleanup of ResourceAdvancedDisplayPanel and TemplateAdvancedDisplayPanel

• Rename and rework, cleanup ArrayUtils -> CollectionUtils and related classes

• Cleanup some Review and Resource related classes in preparation for CKM-1924 Ready For Test

• Simplify getting resource main id and main display name algorithms.

• Add generics to the UniqueMultiLinkedHashMap

• Clean up some Resource Query, Statistics, Archetype and (branchable) resource classes.

• Clean up some of ReosurcesPanel in combination with CKM-1833: Left hand explorer filtering: Very first time when searching for a text that is only available in a specialised archetype, the tree is not expanded automatically.

• Various Code improvements, refactoring, commenting in various Review Round Creation related panels, related to CKM-1823 Ready For Test - Immediate warning that an active review round exists on initiating a new review round.

• Various Code improvements, refactoring, commenting related to the Archetype Comparer and Node Comparer, in preparation of CKM-1911: Consider a change from a non-constrained top-level attribute to an ITEM_STRUCTURE as a non-breaking change for practical purposes.

• Clean up and improve consistency, comments etc. of StringUtilsCore.

• Clean up CKM’s XMLDocMaker

• Clean up various more review related panels and CKM's Panel and FormPanel implementation.

• Rename NoteworthyTypes enum to NoteworthyType for consistency

• Minor cleanup of Config and PConfig classes.

• Cleanup of various Asset Class Binding and classification handler classes related in preparation for CKM-1929: Classification Sort Options cannot be initially set or updated

• Clean up some Archetype Translation related classes in preparation for
  CKM-1942: Empty translation descriptions should be considered as translated

• Email Panel cleanup and rework in preparation for CKM-1957: Move "Email Projects, Reviewers, Users" Menu Item from "Projects" to "Tools" Menu.

• Clean up ResourcesExporter and specialisations in preparation for: CKM-1960 Add ADL2 converted archetypes to a separate folder of the same git export and CKM-1961 Git Export: On first cloning of repository, a file handle may remain open

• Minor cleanup/restructure of the *PrintableViewPanels

• Rework various CKM Statistics Panels as CKM Tabbed Panels for improved consistency, related to CKM-1933: Add REST-like direct links for the various resource statistics.

• Clean up of various mainly backend classes which (may) benefit from cached collections in preparation for CKM-1765: Internal Improve speed of some queries by introducing cached collections for common queries (or query parts)

• Clean up of Projects and Roles Multiple Select Panel and related panels in preparation for CKM-1964: Review Invitations: When inviting project teams and selecting "Show all Projects & Incubators", the same project may be shown twice in the confirmation dialog. Rework a CKM Panel.

• Switch order of lastName and firstName UserDetails params for consistency and minor cleanup.

• DiscussionsPanel minor cleanup in preparation for CKM-1958: Search User Options and Search Discussions Options are breaking too much in Catalan localisation

• Minor cleanup of Internalise Archetype Window: layout and code.

• Consistently prefer MediafluxUtils over StringUtilsCore if related to mediaflux escaping, clean up various other backend classes in particular PComment, in preparation for CKM-1972: Catalan Version Only: Submitting an online translation to the editors shows an error

• Cleanup various comparison related panels and classes in preparation for CKM-1977: CKM 1.19.0 RC1 Message displayed that No changes found in modified file when changing Archetype RM Class

• Minor cleanup of the ResourcesPerProjectPanel

• Here: Clean up some Translation related classes in preparation for reworking CKM-1481: Add appropriate support for TRANSLATION_DETAILS.other_contributors and version_last_translated.

• Cleanup of some Release Set related classes in preparation for future changes.

CKM-1740

[Internal] Upgrade to target Mediaflux version for CKM 1.19.0

Upgrade to new target version for CKM 1.19.0

CKM-1762

[Internal] Improve Implementation of ResourceComparisonPanels and subpanels

Improve Implementation of ResourceComparisonPanels and subpanels by

• Creating a builder design pattern to separate the construction of the complexity of the ResourceComparisonPanel.

• Introducing various static factory methods for the different use cases.

• Various code cleanup and simplification.

CKM-1764

Improve speed, robustness, and susceptibility to error for various checks related to checking the existence of an asset (such as an archetype)

Improve speed, robustness, and susceptibility to error for various checks related to checking the existence of an asset (such an archetype) using a citeable identifier.

CKM-1777

[Internal] Combine SemanticVersionChange and Compatibility enums into one enum

It seems superfluous to have two very similar enums

1. SemanticVersionChange

2. Compatibility

These two should be combined into one enum only, noting the difference in wording (major/minor version vs major/minor revision, one is preferred if seen as a process of change from one to the other, the other is the version as such.

CKM-1798

[Internal] Remove superfluous Tomcat entries within the war file

Remove superfluous Tomcat entries within the war file.

CKM-1837

[Internal] Upgrade commons-io to 2.11 and commons-lang to 3.12

Upgrade commons-io to 2.11 and commons-lang to 3.12

CKM-1838

[Internal] Improve build script to include shared classes as well

Improve build script to include shared classes as well. This is required if a compilation has been deleted completely (for example to avoid any unintentional caches).

CKM-1845

[Internal] Remove browser specific CSS that is no longer necessary to reduce complexity and increase performance

To reduce complexity and decrease the CSS file size: remove browser specific CSS that is no longer necessary in 2023.

And at least to a degree this will some minor speed improvements as well.

This includes but is not limited to

• moz-appearance and webkit-appearance - browsers now fully support “appearance”.

• IE-specific ms-expand expand behaviour for list boxes (hide the arrow in IE as well).

• Usage of @supports ms-ime-align:auto to deal with former Edge version showing extra border and padding around checked checkboxes.

• moz-user-select and ms-user-select are no longer required in addition to user-select. (However the webkit prefix is still required for Safari).

• Usage of @media screen and (-ms-high-contrast: active), (-ms-high-contrast: none)

  • to ensure that svg icons do not have width or height specified or IE cannot cope.

  • For IE because it doesn't properly size it with auto 16px - now if there is NO width/height in the svg.

  • Avoid showing the drop areas becasue IE could not cope.

• Remove border-collapse: collapse; hackery: The “” was required, otherwise the rounded borders won't appear in newer browsers. Otherwise only relevant for old IE versions.

• Webkit animation css: -webkit-animation-duration, -webkit-animation-name: pulsate; -webkit-animation-iteration-count: infinite; -webkit-animation-direction: alternate; -webkit-animation-timing-function: ease;

• Remove no longer required !important declarations for some icon classes for the RichTextToolbar.

• Remove no longer required !important declarations for various icon classes (and make some selectors more specific as required).

• Some additional minor corrections to the css files.

CKM-1900

[Internal] Rework CKM Header Panel and the CKM South Notification Panel to significantly reduce complexity, increase performance and support some modern layouting mechanisms.

• Rework the top-level (north) panel of CKM that contains the logo, the “Clinical Knowledge Manager” text, the main toolbar and the Login Toolbar.

  • Extract as a separate panel

  • Remove the need for various timers to position the Login Toolbar to the right. This can be done easier nowadays taking less resources and panels.

  • Avoid the usage of table structures for layout purposes where not necessary (anymore)

  • To be more flexible with the height depending on what is displayed in the left title (“Clinical Knowledge Manager”) and how much space this needs to take.

  • Various code clean up

  • Move to a new core package that contains the core (main, initial) classes such as the Main toolbar, the login toolbar,

• Rework the CKM South Notification Panel that is used for displaying outage notification, licencing information etc.

  • Restructure, clean up and extract as a separate panel

  • Move to a new core package that contains the core (main, initial) classes such as the Main toolbar, the login toolbar.

• Cleanup and restructure CKM main class

This is to significantly reduce complexity, increase performance and support some modern layouting mechanisms.

CKM-1925

[Internal] Remove no longer required history iframes from static pages

Remove the history iframe from the static pages: These are no longer required without Internet Explorer.

CKM-1946

[INTERNAL] Remove obsolete feedback html page linking to obsolete Jira Collectors

Remove obsolete feedback html page linking to obsolete Jira Collectors.

This is no longer required with the advent of Jira Service Desk

CKM-1948

[Internal] Enable continued support for archetypes with empty strings after upgrade to latest Mediaflux database version

To continue support for storage of empty (but non-null) strings, some changes are required to the document types and a new server setting needs to be set to accommodate the continued use of empty strings.

This is especially relevant for archetypes that have empty fields.

NB: It may be debatable whether empty fields should be supported in archetypes or not, but they are a) legal and b) exist in stored archetypes in CKM. Consequently, such archetypes need to be checked out from trunk or published etc., where storing of empty strings without error is required.

CKM-1952

[INTERNAL] NoSuchElementException on checking for outdated value sets

On checking for outdated value set, a NoSuchElementException may occur internally.

This happens under the following circumstance:

1. The Value Set cannot be found (anymore) on the Terminology Server

2. The locally cached Value Set is NOT to be considered outdated if it cannot be found on the Terminology Server

CKM-1949

[Internal] Harmonise/Streamline the various Resource Checkout Panels and Resource Checkout Buttons and related Submit and Branching panels

Harmonise/streamline the various Resource Checkout Panels and Resource Checkout Buttons and related Submit and Branching panels and their behaviour.

This is a prerequisite for advanced testing of CKM-1948: Internal Enable continued support for archetypes with empty strings after upgrade to latest Mediaflux database version.

From a user perspective, the main change is that error messages if a checkout fails for some reason (such as specified in CKM-1948) are displayed. Under the hood, the source code has been streamlined.

CKM-1950

[Internal] Upgrade Archie to 3.0.0 version as target version for for CKM 1.19.0

Upgrade Archie to 3.0.0 version as target version for CKM 1.19.0

CKM-1962

[Internal] Upgrade all authentication domains to use SHA-512

CKM-1740: Internal Upgrade to target Mediaflux version for CKM 1.19.0 has upgraded to the latest version of the asset management system underpinning CKM.

This version has removed support for the current authentication mechanism requiring all authentication domains to upgrade to use (e.g.) SHA-512.

Without aligning this change to the database upgrade for CKM 1.19.0, new users cannot be created and existing users cannot update their password.