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:

Open

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

Open

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.https://ckm-dev.oceaninformatics.com/ckm/templates/1013.26.571/relatedresources

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: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles

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 https://openehr.org/about/logos

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.