CKM-1461

Instance-wide Translation Administrators (per Language)

To manage translations, CKM features the project-based role of “translation editor”. A translation editor can manage all translations of archetypes owned by the project.

However, unlike the development and management of the content of archetypes, that is often organised along project boundaries, there is a need for a role to:

• Manage the translations for all archetypes in all projects (as well as incubators) without assigning a project-based role to the user for each project.

• Manage the translations per translation language, not necessarily for all translation languages.

Therefore, this release introduces a new CKM instance-wide role, the role of “Translation Administrator”.

The role Translation Administrator is assigned (by Clinical Knowledge Administrators or Technical Administrators) per translation language, so that a CKA instance can have separate Translation Administrators for - say - Norwegian Bokmål, Catalan, Farsi and German.

The role of Translation Administrators enables the holder of the role to

• Checkout and translate archetypes (relevant if the CKM is configured to restrict resource checkout to user’s with special roles).

• Conduct Translation Reviews (only in the assigned translation language). NB: Reviews are a feature of projects only, not incubators. the user has full access to Translation Reviews of the language.

• Be notified if a new or updated translation (in that language) is submitted by a user to the editors. (Note: In case an archetype owned by a private incubator is translated, the Translation Administrator must be able to view the incubator to be notified)

• Commit an archetype from branch to trunk if the archetype only has changes to translation languages the user is a translation administrator for. (Typically this will be one language, but can be multiple as well). For this to be allowed, there must neither be any other active branches for the archetype, nor must the translation branch to be committed be an outdated branch (i.e. another branch was committed after the translation branch has been checked out. (This is behaviour aligned with the recent restrictions of CKM-1477: Translation editors should only be able to commit translation-only branches if there are no other active branches for that archetype and if the branch is not outdated).

• Set the status of an archetype’s translation.

• View the Editors' Task List for the archetypes and make changes to To Dos from the Task List if it explicitly mentions the translation language (either the ISO code or the translation language in server localisation). This is to mark the automatically generated “commit the translation” tasks as completed.

• See the “Editor’s Review Rounds” Dashboard widget and related review round overviews.

• See the Active Branches report.

NB: The above is similar to the behaviour and rights of translation editors of a project, but for all archetypes visible to the user, and only for one (or selected) translation languages.

NB: This role does NOT give the user access to private incubators. If however, the user is a member of a private incubator, the translation administrator can use this role to manage translations of the archetypes in this private incubator as well.

The user interface for CKA or technical admins to grant and revoke user roles (in the User Profile) has been revamped to deal with translation administrators by selecting the appropriate language from a combo box. As part of this rework, the Multiselect boxes with the currently assigned and unassigned user roles) have been removed in favour of combo boxes to grant or remove user roles.

The Translation Administrator role for a specific translation language is created (automatically) on demand only - this is to avoid cluttering systems with hundreds of roles where only a few are currently needed.

Translation Administrators have also been added to the “Users per Role” overview available from the Tools menu for CKAs and technical administrators. A Translation Administrators role is only listed here if at least one user has this role for a particular translation language. This is to avoid cluttering the overview with hundreds of empty roles.

Also see discussion at Request to join project as translation editor .

CKM-1707

Data Points Report per Project

Add a data point report per project, available directly as a tab from the project.

For normal users, this should be the second last entry, just before the Download of Project Files.

CKM-1807

Support REST-like URLs for direct links to resource centre documents and add the links of these Associated Assets to the Release Set manifests

Direct links to documents are currently only accessible via a query string, e.g.

https://ckm.openehr.org/ckm/document?cid=1013.17.14

https://ckm.openehr.org/ckm/document?cid=1013.17.14&version=1

It should be possible to access the documents via a REST URL, for example:

https://ckm.openehr.org/ckm/documents/1013.17.14

https://ckm.openehr.org/ckm/documents/1013.17.14/1

ckm/documents/<cid-document>

ckm/documents/<cid-document>/<version>

In addition:

• Display this URL in the resource centre instead of the query-based URL.

• Add this URL to any Associated Assets in both the XML based and the markdown based release set manifest.

  • If the associated asset is versioned, use the URL including the version (e.g. https://ckm.openehr.org/ckm/documents/1013.17.14/1)

  • If the associated asset is not versioned, use the URL excluding the version (e.g. https://ckm.openehr.org/ckm/documents/1013.17.14)

CKM-1828

Ability to Add OMOP Mappings to Archetypes and Templates

It is increasingly recognised that openEHR and OMOP can and should be used in combination, cp e.g. OHDSI - and openEHR . For this to be supported, it is paramount to create detailed mappings from commonly used openEHR archetypes and templates to OMOP CDM where and to the extent possible.

For this purpose, a new Tab has been added for each archetype and template, dubbed “Mappings & Queries” where mappings from openEHR to FHIR can be uploaded and maintained.

There are various approaches to mappings ranging from simple spreadsheets to formally defined YAML files based on the OMOP Conversion Language (OMOCL), a declarative mappings language for mappings between openEHR archetypes and templates to the OMOP CDM.

Since the need is very clear, but the exact formalism is not as of now, CKM at this stage will enable the upload of various file types including YAML and Spreadsheets and remain agnostic to the formalism used.

To display the mappings, some generic syntax highlighting has been added to CKM as well: cp. CKM-2128.

Projects have a new role of Mappings and Queries Editor enabling the management of these artefacts on a project-level. Clinical Knowledge Managers and Project Editors also hold these rights.

With this role, an OMOP mapping file can be uploaded to an archetype or template by providing the file, a title and optionally description, the archetype or template revisions this mapping file applies to, and whether the mapping file is to be versioned. All uploaded mappings files are displayed. If a mapping file is NOT applicable to the currently displayed revision of the archetype or template (typically: the latest or latest published), a warning is displayed for this mapping. Each (text-based) mapping file can be viewed and each mapping file can be downloaded. Mappings and Queries Editors can edit and delete as required.

Note: This work is intended to cater for an immediate need expressed by various parties while some details remain unclear as of now. Depending on uptake this can be extended and finetuned as required in future releases of CKM (e.g. extract meta data from the file if the format and the meta data is agreed upon, provide more detailed governance, provide and overview of all mapping within a project, ability to download of all mappings, …).

Cp. CKM-2104, CKM-2119, CKM-2132 for related functionality.

Example OMOCL mapping file: medical_data/action/Medication_v1.yml

CKM-1926

Complete Rework of the Review Rounds view of each resource

The Review Overview of each resource currently consists of two grids (“Completed Reviews”, “Review Rounds Overview” (collapsed)), and a section to “Open Review Summary”.

This review panel is being revamped as part of this card guided by the idea that review round can be displayed and managed much more intuitively if grouped primarily by Review Round.

Therefore display each review round as one collapsible panel, starting with the newest review round and going down to review round 1.

For each review round, display some core statistics and facts for each review round prominently, such as

• the number of completed reviews,

• the status of the review round (open or closed),

• the initiator of the review round,

• the initiation date,

• the deadline.

In addition, show

• a donut chart of the recommendations of the submitted reviews, and

• a donut chart of the review invitations

for each review round.

Also - depending on the user’s rights - buttons to

• open the review round summary with the consolidated view of all submitted reviews.

• view the review invitations,

• close or reactivate the review round, respectively,

• modify an open review round (opens the known review round panel with the resource already selected), and

• delete an open review round (as CKA).

For user with appropriate rights as CKA or within the resource’s project, an additional grid is displayed to display and manage the individual reviews of the review round.

CKM-1981

Add validation for missing at code on LOCATABLEs

Add a validation check for missing at code on LOCATABLEs - such as ITEM_TREE:

Missing at code in ITEM_TREE

This should report a VACSI validation error (which seems to be the best match), with a specialised message clarifying that a LOCATABLE mandates an archetype_node_id.

CKM-1985

Clone a Release Set

Ability to duplicate/clone a release set and set back initial state, so that the previous Release Set can be used as a basis for the new release set.

Use Case: A new version for a CDR with an updated set of archetypes and templates. There should be no need to start completely from scratch each time, even with the strict governance mode introduced in CKM-1996 (see below).

In more detail, functionality is introduced to clone a release set from the following places (assuming rights to edit release sets):

• Release Sets/View All Release Sets: click on Release set and select “Clone Release Set”

• Release Sets/Revise Release Set: click on Release set and select “Clone Release Set”

• In the Revision History of a Release Set, click on the Details button of the latest revision and select “Clone Release Set”

Once selected, a prompt appears for the user to provide a new Release Set Identifier (such as myreleaseset.v1).

If the provided release set identifier is valid and not yet in use, the release set is cloned and opened directly to be able to immediately start making changes to it.

CKM-1986

Add a Release Candidate state for Release Sets

Add a Release Candidate state for Release Sets. This is so that release sets can be rejected or accepted in testing stage. If the Usage of the Release Sets fails in the testing environment, then editors would reject the release set and create another RS.

If testing turns out to be ok, editors can then formally publish the release set, otherwise reject it.

It would be helpful to have a “Release Candidate (RC)” state to identify a Release Set that has been integrated in the CDR but is still in the pre-production phase. Once this Release set has been approved for production, the state would be set to “Published”, in the case of being rejected the state would change to “Rejected”.

CKM-1992

Improve the Related Resources Display for "Release Sets Using This Archetype" and "Release Sets Using This Template"

In the Related Resources page of an archetype or template, all release sets that contain the archetype or template (in this exact revision) are listed.

This view should be improved in the following ways:

• Add an icon showing the status of the Release Set in the same way as this is currently already done for archetypes. This refers to the most recent version of the release set using the resource in the currently displayed revision.

• Properly style the “latest revision” etc. indicators as this is currently already done for archetypes.

• Add the Release Set Icon in the header.

• Add right hand top comparison menu button (“Compare/Details) with latest and latest published revision of the release set (as applicable). (Similar for other resource types).

If an archetype or template is contained in various revisions of a Release Set:

• List all release set versions where the archetype or template is being used in.

• Explicitly add the LATEST REVISION or LATEST PUBLISHED indication.

• If the LATEST REVISION or LATEST PUBLISHED is not containing the archetype or template (any more), indicate this as well with a reference to these special revisions.

This results in the following example displays:

Example, if the current revision of the release set does NOT contain this archetype or template anymore in the specified revision:

CKM-1994

Fully enable REST-like Direct Links for Release Sets and use them consistently everywhere for all links

REST-like direct links for release set exist in principle.

They take the form of e.g.

<ckm-server-base-url>/ckm/release-sets/1013.10.30

However, they currently are not displayed like this in e.g.

• emails about a new or updated release set,

• tweets about a new or updated release set, and

• the Release Set Manifest file.

(Up to CKM 1.19.1, the link would have been e.g. #showReleaseSet_1013.10.30)

CKM-1996

Introduce an option for a strict Release Set Governance mode, where Release Sets are locked once in Release Candidate or Published state

This card introduces a new configuration of CKM to support a stricter governance mode for Release Sets.

If this stricter governance mode is enabled in a CKM instance, the following restrictions are enforced:

Once a Release Set has been set to Release Candidate or Published state, (or has been rejected or deprecated), it is no longer possible to make any more changes to the Release Set (i.e. it is not possible to Revise the Release Set). I.e. if a Release Set is in status RELEASE_CANDIDATE, PUBLISHED, REJECTED, or DEPRECATED, the Release Set cannot be revised but is eternally locked.

The states and transitions between states are also reduced, so that it is only possible to transition in the following ways once the Release Set is a Release Candidate or has been published.

• RELEASE_CANDIDATE → PUBLISHED

• RELEASE_CANDIDATE → REJECTED

• PUBLISHED → DEPRECATED

It must not be possible to return to a state that allows modifications to the release set. Thus it is not possible to transition from REJECTED → DRAFT.

The intention of this is that, once a Release Candidate, a Release Set can then either be published (if all subsequent tests with it succeed) or rejected (if any test fails or it needs to be modified in any way for whatever reason), but it can never be modified.

It is however possible to transition from DEPRECATED → PUBLISHED and REJECTED → RELEASE_CANDIDATE. This is to be used only to correct accidental transitions to an inactive state. Note that it is not possible to modify the release set in any of these states in strict governance mode.

CKM-2003

Use "latest revision (unstable)" instead of just "latest revision" to make it clearer that this is not an officially published version

In some places in CKM it is useful to use the wording "latest revision (unstable)" instead of just "latest revision" to make it clearer that this is not an officially published version.

This is most useful for headings and tooltips related to resources that are currently in a REASSESS_* status, waiting to be republished.

(Note: While “latest draft” probably sounds best, we also have the resource states of “DRAFT” and “REASSESS_DRAFT” which would make its use for an overlapping concept somewhat problematic/inconsistent.

CKM-2004

Improve Display of Resource Revisioning in a Release Set's Resources Grids - in particular include the semantic revision number where available

The various resource grids used as part of displaying or creating/modifying a release set should display more information about the revision of the included resource.

This is particular useful for archetypes where the semantic revision number such as 1.10.1 or 1.11-0.alpha can be displayed directly in the revisioning column as well as in the tooltip.

In the revisioning column, use the typical labelbox - also to give another visual indication what is the latest, latest published or a previous revision.

CKM-2006

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

Various code improvements, refactoring, commenting & cleanup

• Minor cleanup of ResourcesGridPanels in preparation for Release Set changes.

• Cleanup of ReleaseSetsOverviewPanel before Release Set rework.

• Various Code improvements, refactoring, commenting, cleanup - 1.20.0 Minor clean up of OPTServiceClient and some minor logging improvements.

• Harmonise usage of throwing error if error element from mediaflux in UserHandlerImpl and ProjectHandlerImpl. Minor cleanup of ReviewFunctionalityController and ClassificationHandlerImpl.

• Cleanup in preparation for CKM-1992 - Improve the Related Resources Display for "Release Sets Using This Archetype" and "Release Sets Using This Template"

• Minor clean up of ReleaseSetsOverviewPanel, ReleaseSetHeaderPanel, GridPanelOi in preparation for CKM-2040 Improve Display of Overview of Release Sets and the Display of each Release Set.

• Minor clean up of UserTooltipRenderer and FullTextAsTooltipRenderer in combination with CKM-2040 - Improve Display of Overview of Release Sets and the Display of each Release Set.

• Minor cleanup for ReviewInvitation model in combination with CKM-2040 Improve Display of Overview of Release Sets and the Display of each Release Set.

• Some code and comment cleanup of Object creators, html generators, review field enum and the review feedback history window in preparation for CKM-2046: Error message displayed when Review Feedback History cannot be retrieved (1.19.1)

• Cleanup and improve ArchetypeHTMLPanel in preparation for CKM-2033 On clicking on "Show technical", the panel gets a bit larger and the bottom buttons moved down

• Minor cleanup related to the OPTServiceClient related to CKM-2012 OPT generation fails when an explicit CDATA segment is present (1.19.1).

• Cleanup and finetuning of AssociatedAssetsGridsPanel in relation to CKM-1991 Removing a template from a Release Set may cause the "Recalculating" Wait Dialog to never disappear

• Various rework related to Resource Main Data records and their usage for Release Set modification

• Minor cleanup of code re Rich Text Area and its toolbar

• Clean up service to reactivate a review round in preparation for CKM-2020 - Terminology and Translation Review Rounds should not be able to be reactivated if the main status of the archetype itself is an inactive state (i.e. deprecated or rejected).

• Clean up Statusable, Notifiable interfaces, and some comment finetuning of PResource and subclasses in preparation for CKM-1994: Fully enable Direct Links for Release Sets

• Clean up of DocumentationHandler* classes, AllResourcesPerProjectPanel and services related to transforming operational templates and listing resource documentation in preparation for CKM-2068: Show Project-based OPTs from the Project Resource Centre on the Project Dashboard as well

• Minor clean up of change requests and revision history services

• Minor cleanup of user login and opt classes.

• Minor cleanup of RichTextArea and related classes related to CKM-2062 - Improve Consistency of Formatting when editing in RichTextAreas, especially for the Review Mail Invitation

• Some cleanup of Role Manager and internal user classes in preparation for CKM-1461: Instance-wide Translation Editors

• Some cleanup of various OPT and Value Set Injection classes related to CKM-2087 Transform Changes required to support templates where the same code is used in different 'terminologies'

• Minor cleanup of the Archetype Validation Manager.

• Cleanup/finetune/streamline some backend classes related to CKM-2086 Improve and streamline the query syntax for queries with the main identifier of a resource, CKM-2088 Manually triggered regeneration of OPTs only regenerates 100 OPTs, CKM-2089 Slot fills where no archetype from CKM fits are no longer validated.

• Minor cleanup of ArchetypeSimplifiedHierarchyItem, ArchetypeSerialisedObjectCreator and the Resource Queryer Impl.

• Minor cleanup of UserHandlerImpl in relation to CKM-2086 Improve and streamline the query syntax for queries with the main identifier of a resource.

• Rework ReviewAndReviewRoundDetails to be converted from a Record and use accordingly. Various other finetuning related to CKM-1461: Instance-wide Translation Administrators and CKM-1926: Complete Rework of the Review Rounds view of each resource.

• Clean up of GeneralSpecialQuestionsSpecifyPanel and Clean up of ArchetypeHTMLGeneratorTwoLanguages

• Minor cleanup of Active Branches Report Panel and wordsmithing.

• Cleanup of Resource Documentation related classes/services.

• Minor cleanup of some Change Request and Project related classes/services.

• Clean up ResourceExportPanel (incl. introduction of flex layout) in preparation for CKM-2110 - Resource Mirrored in Git Repository should not be shown for Incubator resources

• Rename title case method for consistency

• Fix potentially/theoretically leaking termset input stream when updating a termset.

• Harmonise colour order in theme.

• Finetune/correct and streamline the css for toolbar, including finetuning of the colour when selected.

• Clean up of General mf Object.

• Clean up Change Request service classes in preparation for: CKM-2134 - Error on Creating a Change Request for a Release Set in any status beyond INITIAL

• Minor Cleanup of Comparison, and Submit Panels related to CKM-2034 - Comparison Report: On upload/commit state the comparison basis: "trunk" or "branch <branchname>".

• Title capitalisation for Order templates in the Project Dashboard and other minor cleanup

• Minor cleanup of mail with recovery sending service and the core String Utils, the frontend String Utils and the logins list service.

• Finetune title capitalisation and general harmonisation of Email headers

• Correct stylesheet errors and ensurer Loading panel is not selectable

• Code improvements and clean up for Template and other Resource related services in preparation for CKM-2141 - OPT generation should honour a language explicitly stated in the oet file over CKM's configured resource display locale

• Code improvements and clean up Resource related services in preparation for CKM-2142 - Prevent reverting a resource if the version is the requested version for reversion is equal to the current version

CKM-2019

Icon Improvements and Additions 1.20.0

• New icon for review invitations used in a variety of places

• Improved icons for the Revision indication in Release sets (latest, latest published, latest and latest published, previous revision)

• New Save icon used for release sets.

• Rework the adoption, watching, not watching, start adopting icons as SVGs

• Rework the Editor's summary of adoptions icon as SVG

• Rework the Resource Centre icon as SVG

• Finetune discussion and classification icons for visibility (especially when selected in the toolbar).

• Rework the Printable View icon as SVG

• Rework the Related Resources icon as SVG

• Rework All Resources and All Order Templates Icons for the left hand explorer.

• Rework as SVG and and improve the various Review type related icons.

• Minor update to the template “org chart” icon

• Rework of translation, translation submit and translation upload icons as SVG

• (Re)move some old icons no longer in use.

• Rework Archetype Proposal Icons as SVGs.

• Rework the three magnifier search/find icons + latest search as SVGs

• Rework Audit Log icon as SVG

• Rework left-hand explorer Expand/Collapse all icons as SVGs

• Rework Projects, Incubators and Projects & Incubators menu / select box icons as SVGs.

• Rework export, import, bulk-export, bulk-import icons as SVGs

• Rework Revise Resource icon as SVG

CKM-2020

Terminology and Translation Review Rounds should not be able to be reactivated if the main status of the archetype itself is an inactive state (i.e. deprecated or rejected)

Terminology and Translation Review Rounds should not be able to be reactivated if the main status of the archetype itself is an inactive state (i.e. deprecated or rejected).

In total, the expected behaviour is the following:

• No resource with an inactive main resource status should have an active review round of ANY kind. In practice this applies to terminology and translation review rounds for archetype. Independent of the status of the terminology or translation, respectively, if the main (content) status of the archetype is inactive, review rounds should not be able to be reactivated.

• Terminology and translation review rounds should also not be able to be reactivated if the status corresponding to the terminology (e.g. Snomed CT) or translation (e.g. Norwegian) is in an inactive state.

• Either way only the latest review round of its kind can be reactivated.

CKM-2022

Review Rounds Overview Panel Finetuning

Various improvements to the review round overview panel available from Reviews/Review round overview with appropriate rights.

1. Change double-click behaviour to open the Review Round Overview (instead of the invitations of the review round which are easily accessible from that panel after CKM-1926: Rework the Review view of each resource.)

2. Adapt the explanatory text accordingly

3. Add an action arrow to the grid for the context menu to be found more easily and also show this on a normal click on the action arrow.

4. Restructure the context menu to use an additional separator. Reorder according to the above and some wordsmithing.

CKM-2029

Localise some components for Norwegian Bokmål and Catalan

Additional localisation of relevant components into Catalan and Norwegian.

Grid menus and Grid groupings for example have not been localised to Norwegian Bokmål and Catalan because this uses a different internationalisation mechanism based on the framework.

Also Framework buttons like Yes, No, OK, Cancel were not translated.

CKM-2030

User Roles Panel: Subdomains and Projects/Incubators should be sorted by name, case-insensitively

In the User Roles Panel available from the User Profile (as a CKA or Technical Admin), the subdomain and then project/incubators should be sorted by their name, case-insensitively. For subdomains, also use the remote or local or customised icon.

CKM-2034

Comparison Report: On upload/commit state the comparison basis: "trunk" or "branch <branchname>"

Resources such as archetypes are compared for example when

• a new revision of a resource is uploaded to a branch, or

• a branch is committed to the trunk.

In the first case, the resource is compared with the latest revision on the branch, whereas in the second case, the final branch revision is compared with the latest trunk revision. This is the case even if the resource was checked out from a previous revision (in which case a warning is displayed and the user must have appropriate full editing rights to continue).

While this is the natural comparison to be executed, for the avoidance of any doubt, the resulting comparison report (“Changes”) should clearly indicate the basis of its comparison such as the branch name or the trunk latest revision.

CKM-2036

Better visual way to close the South Panel Notification

The South Panel with the upgrade notification etc. can be closed by clicking on the tiny arrow in the border between center and south panel.

This is useful, but naturally very easy to miss. Using a right-hand X to close that highlights itself on hover seems appropriate here.

To reopen, the small arrow in the middle can be used, on hover it is also highlighted a bit.

Also, if the notification is a temporary one like an imminent outage to due a CKM upgrade, the right-hand x is of darker colour, whereas for a permanent notification such as a small licencing message, this is lighter.

CKM-2040

Improve Display of Overview of Release Sets and the Display of each Release Set

This issues relates to a series of many improvements to the Display of Release Sets, in particular:

• Improve various height and width and paddings, including the various grids the overview grid, the various grid panels and the header form to make better use of the available space for larger release sets.

• Naming the “Release Set ID” as such (instead of just “release set”)

• Menu on click: Ensure that “Revise” is before Export if it exists. This is because that is the main functionality of the form then.

• Add action column to the grid (or switch the icon to the default action arrow icon).

• Finetune distance between the status and the release set id, and remove the explicit “Status: ” that does not align with the rest of the form

• Show warning on incompatible change that may require a new release set version also if the release set is currently deprecated, i.e. always when it has ever been published.

• Add resource type icons to the resource tabs of the release set.

• Add Save icon to the buttons and the Save tab.

• Add icons for Associated Assets and Secondary Assets tabs.

• Use coloured instruction panels for explanations.

• Improve widths, heights, paddings, capitalisation for Release Set Comparison

• Change button type for incompatible change.

• Improve title casing and display various titles as the grid header instead of as a separate heading.

• Improved icons for the Revision indication in Release sets (latest, latest published, latest and latest published, previous revision)

• Internal Extract ResourceTooltipRenderer and ResourceRevisionTooltipRenderer for reuse and consistency in a few places - also in the left hand panel.

• Internal Extract and use TextInCombinationWithBooleanAsCheckboxRenderer for the SecondaryAssetsGridPanel

• Add title for ReleaseSetOverviewPanel

• Finetune resource status icon alignment

• Add ReleaseSet icon to grid in ReleaseSetOverviewPanel

• Add icon for validation tab

• Remove Export as bold context menu entry (still available as a normal context menu entry)

• Harmonise some method names and add various javadoc comments.

• Add initial explanation instruction panel

• Add main display name to Release Set Modify Panel heading (not only "Revise Release Set")

• Add icon to Context menu of an archetype/template: “Remove Archetype” or Remove Template”

• Only show context menu to remove the resource or select a different revision if it is not a resource that has automatically been included (where it does not make a lot of sense as the validation will fail in the end anyway if the wrong revision is selected).

• If view only, or if the resource is automatically included, use the normal Resource Context Menu instead for easier navigation.

• Finetune explanation text and when it is shown and adjust heights accordingly.

• Hide the “previous” and “next” button in the toolbar completely if disabled because it is the first or last tab.

• When modifying a release set and adding two templates: Any archetypes used by both templates in the exact same asset version should only be displayed once in the “Automatically included archetypes” grid. (NB: If they are included in different asset versions, then the do need to be displayed twice of course.)

CKM-2042

The Overall Change Requests Report should list the total number of Change Requests per Resource Type

Currently, the Overall Change Requests Report lists the total number of archetypes and templates with one or more change requests.

It is however not possible to easily see the total number of Change Requests. Therefore, the Overall Change Requests Report should list the total number of Change Requests per Resource Type in addition to the total number of resources with one or more change requests.

Therefore, add a summary panel that lists the following information PER RESOURCE TYPE:

• Total number of open Change Requests

• Total number of open PRIORITY Change Requests

• Total number of in process Change Requests

• Total number of in process PRIORITY Change Requests

• Total number of closed Change Requests

• Total number of closed PRIORITY Change Requests

Do not report zero values.

The same information should also be listed for the project-based Change Request reports.

CKM-2048

Bulk Create/Update Users via CSV File Upload: Clarification in the tooltip of the password field to clarify that this password will only be set for new users.

In CKM’s Bulk Create/Update Users via CSV File Upload, the tooltip explaining the password functionality is not clear that the password only applies to new users, not to users that are updated. Therefore, clarify in the tooltip of the password field to clarify that this password will only be set for new users.

CKM-2053

Ensure that the Norwegian "Konseptbeskrivelse" does not break on the last character in the Archetype Header tab

The Norwegian "Konseptbeskrivelse" is too long to fit on one line in the Archetype Header tab. This should be properly broken up between Konsept and beskrivelse.

Likewise, the German localisation should use the same mechanism to properly break “Konzeptbeschreibung”.

CKM-2055

Stop users saving Review Round Mail Invitation Templates without any text in them

As a user with the role CKA or Techincal Administrator, I create Review Round Mail Invitation Templates as required.

When I create these Invitation Templates, I need to enter the text that will be displayed in the mail invitation emails sent to users.

When we leave the text blank when creating a Mail Invitation Template, we see an error message which is technically correct because it does not make any sense to store an empty invitation template.

When saving an existing Mail Invitation Template, and removing the text, we see a message the changes have been successfully saved, however, upon reviewing the Mail Invitation Template, no changes were made to the text.

In both of these cases, in order to improve the user experience, we should consider improvements such as:

1. Stopping the user save the Mail Invitation templates with no text by greying out the buttons to save the Templates and providing an information message as to what is missing being at least one letter in the text field

OR

1. Stopping the user from saving the Mail Invitation Templates with no text in them and displaying a message advising the user that the Mail Invitation Template cannot be saved as there is no text entered in the Template.

Message displayed when saving new Mail Invitation Template with no text in it

CKM-2059

Show at codes of runtime name constraints in the Technical View of an Archetype

The at codes of runtime name constraints should be shown in the Technical View of an archetype.

For example in Cluster Archetype: Imaging examination of an anomaly [openEHR Clinical Knowledge Manager], the runtime name constraints related to Dimension (Length, Width, height, …) should be shown when the Technical View of the Archetype is chosen.

Also, this needs to work for the Volume Element of Observation Archetype: Spirometry result [openEHR Clinical Knowledge Manager] which has runtime names and bindings to the (coded) runtime names:

The at code should also be displayed in the the technical view for all possible coded runtime names.

CKM-2060

Don't allow user to click 'OK' on Add Task dialogue Box in Review Summary when no text is entered or provide a more user-friendly error message

As an Editor, I may want to add a Task to a resource through a review by clicking the Editor Feedback field in the Review Summary and selecting the button Add Task

When I don’t enter any text in the dialogue box that is displayed when I click on Add Task, a message is displayed effectively advising the task could not be created as no text was entered in the Add New Task dialogue box.

A user may not be able to interpret that message should they see it and may raise this a bug in CKM.

It would be ideal if this could be improved such as disabling the OK button until at least 1 character is entered in the Add New Task dialogue box or making the message that is displayed more user friendly.

Review Summary: Add New Task dialogue box displayed when Editor clicks on Add Task button in Editor Feedback field

Message displayed when no text is entered in Add New Task dialogue box

CKM-2062

Improve Consistency of Formatting when editing in RichTextAreas, especially for the Review Mail Invitation

Improve Consistency of Formatting when editing in RichTextAreas.

RichTextAreas are used for example to provide review invitation details and review mail invitation templates.

They are also used for discussions in CKM or when composing emails within CKM directly.

Currently there are some consistency problems with the display during editing in a RichTextArea and when displaying the result - either in CKM or in an email.

For example:

• Depending on user browser settings, it is likely that some text that was supposed to be “smaller” is actually displayed larger than the default.

• When “Remove Format” is used from the Toolbar above the RichTextArea, the default styles are also removed in the RichTextArea. This leads to a ugly styles in the RichTextArea which are replaced again with the default styles on saving. However, this is then inconsistent with the display.

The aim is to provide a more consistent appearance of what is displayed in the RichTextArea on editing and then in the emails and inline in CKM.

1. When the text is for an email only (review invitation email, composing email), just add the default email styling to ensure that the email is a (somewhat) faithful representation. Note that due to differences in support, this is never 100% accurate across all email clients.

2. If it is for both email and inline (e.g. discussions), add the typical CKM styles to the iframe of the RichTextArea, so that the display after editing is faithful to what is displayed when editing the text.

3. Remove Format button: The default format should not be removed (e.g. font) from the RichTextArea, just reset.

To support this several changes have been made under the hood.

CKM-2065

Release Sets Creation and Modification: Fetch and Display Semantic Revision Number when changing the version of an archetype included in a release set

During the creation or modification of a Release Sets:

If the editor changes the asset version of an archetype included in the release set (via right-click on the archetype in the “Selected Archetypes” grid), the corresponding semantic revision number should be fetched and updated in the archetypes grid as well.

CKM-2067

Replace the existing free text manifest of a Release Set with a markdown manifest

Release Sets currently have two manifest files.

1. An xml manifest file

2. A free text txt manifest file

The latter is not very well structured and suffers from various layout and naming problems.

Therefore, this free text manifest has been replaced by a markdown manifest.

This markdown manifest:

• is localised,

• is included in the Release Set File Set as manifest.md,

• can be displayed as a separate tab of the release set, and

• can be downloaded from the release set’s export tab.

CKM-2068

Show Project-based OPTs from the Project Resource Centre on the Project Dashboard as well

It is possible to upload Operational Templates to the Resource Centre of any Project. This is for example useful to showcase examples of how an archetype could be used or to just quickly show the end result of a template rather than having to upload and sort out all dependencies of the template.

For direct access, these Operational Templates should also be listed on the Project Dashboard and a note displayed in the Project Resource Centre that uploaded OPTs will also be displayed on the Dashboard.

CKM-2069

Link the Usernames displayed in Change Requests and Tasks and Archetype Proposals to the User Profile

Change Requests, Archetype Proposals and also Tasks are a frequently used feature in CKM.

Change Requests and Archetype Proposals can be submitted by any registered user - and it happens regularly that users register to CKM in order to create a new Change Request for an archetype (or template).

Therefore, it is very useful to be able to directly navigate from the various usernames (creator, modifier, commenter) of Change Requests, Tasks and Archetype Proposals to the user profile in the way as this is already implemented for discussions in CKM. If a user is no longer registered with CKM, the user’s original username is displayed without a link to the non-existing user’s profile.

CKM-2070

Add concept description placeholder for review invitation templates

While the recently introduced Review Invitation Templates are very helpful in organising review rounds, a frequent use case is to be able to display the archetype’s concept description in the review invitations as well.

Therefore, add support for a new placeholder, named
%{resource-description}%.

This should use the same “most appropriat