CKM Release 1.17.0
Release Notes
Date: October 2021
New & Improved Functionality
Key | Summary | Description |
|---|---|---|
CKM-561 | Ability to attach an archetype to change requests for archetypes and enable editors to import this archetype to a branch | When creating a change request for an archetype, the submitter of the change request should be able to upload an archetype containing the suggested change in addition to describing the change. This way, the submitter can upload the change they suggest directly as part of an archetype. This may be clearer than just a description of the suggested change and may save the editor’s time. This includes functionality to
|
CKM-1257 | Improve the related resource panel of a template to reveal more relevant information on the state of included archetypes | Improve the related resource panel of a template to reveal more relevant information on the state of any archetypes included in the template. Currently the panel lists basic information for each archetype, including the Resource Status of the latest revision of the archetype (which is slightly misleading and may be interpreted as the status of the resource revision used by the template). Therefore, provide the following information for each archetype used by a template:
for each of the following archetype revisions:
For the latest and latest published version, also explicitly display the semantic change type (e. g. patch) from the currently used revision next to the SemVer Revision Number. For example:
This information can directly be derived from looking at the two SemVer Revision Numbers, however, this makes it easier to see. Also, add the ability to compare the archetype revision used by the template with its latest version as well as its latest published version via the Details Toolbar button (as applicable), which has been renamed to “Compare / Details”. 
|
CKM-1265 | For each archetype of a template, add the archetype's semantic version to the Template File Set manifest | For each archetype included in the Template File Set manifest, the semantic version (SemVer) should be stated when available (in addition to the asset version). For example: <revision>0.0.1-alpha</revision> (The manifest is included in the zipped download of each Template File Set.) |
CKM-1413 | Rework Template Upload Error and Warning Display/Grouping | When uploading a new or updated template, the display of errors, warnings and information is somewhat repetitive. Instead of repeating the same error texts over and over again (for larger templates with various problems), group errors and warnings by their type and introduce new headings for each of them. This way the generic explanation text needs to be displayed only once. New Headings for Errors/Warnings include:
|
CKM-1417 | Template Upload Error Display: If no conforming canonical hash exists or no integrity hash is specified in the template, the Semantic Version should be stated as part of the validation | When uploading a new or revised template to CKM as an editor: The template validation error that no conforming canonical hash exists (“Archetype Canonical Hash Mismatch”) should be augmented with the display of the Sematic Version (e. g. 1.0.1), if available. In addition, if no integrity hash is specified in the template at all for an archetype that is used, this “No Integrity Hash” error should also display the Semantic Version for the latest / latest published revision, if available. |
CKM-1422 | Template Upload Previous Revision Warning: Add latest published revision & show the resource status and the semantic change type between the referenced and the latest as well as latest published archetype revision | When uploading a template there may be warning messages that a template is not referencing the latest CKM archetype revisions for one or more archetypes. This “Previous Revision” warning is enhanced in the following ways:
|
CKM-1451 | Increase speed of assembling larger revision histories with many branches | Larger revision histories take a longer time to compile, especially if there are many branches. This issue improves the speed of loading for each revision on the trunk and in each branch by
In total, this nearly halves the time required for backend calculation of typical large revision histories with many branches. (Transfer and actual display in the user’s browser require additional time independent of backend calculation.) |
CKM-1456 | Template Upload Error Display: For Archetype Canonical Hash Mismatch errors display the Hash in the latest as well as the latest published archetype revision | When uploading a template with canonical hash mismatches, we currently only display the Hash of the latest archetype revision. |
CKM-1459 | Publication vs. Development Revision History Views | CKM’s Revision History tab for each resource is currently focussed on providing a development view of its resource, i. e. the revision history displays all revisions - published as well as unstable development revisions - and all branches. This display is very useful when coming from a development perspective and thus must be maintained. The purpose of this issue is to enhance the revision history so that users can switch between
This enhanced revision history only needs to be available for any resource that has already been published at least once. The user is provided with a toolbar button to quickly switch between both views and a message panel clearly indicates the currently displayed view. Users more likely to be interested in the development of the resource are being presented with the Development View. This applies to all members of the resource’s owning project as well as Clinical Knowledge Administrators. Others are presented with the Publication View by default. 
|
CKM-1462 | Change Requests Report: For projects, optionally include Change Requests for resources referenced by the selected project as well | In the Change Request Report it should be possible to also display the Change Requests for resources referenced by a selected project (or a subdomain) in addition to Change Requests for resources owned by a selected project (or by any project within a subdomain, if a subdomain is selected). For this purpose, add a checkbox to “include referenced resources” to the Change Requests report. In the general Change Requests report (available from the Reports menu), this checkbox is only active if either a project or a subdomain has been selected. In the Change Request report tab of each Project, the option is always enabled. |
CKM-1464 | Add number of Priority Change Requests to the Change Request Report | In the Change Requests Reports, the number of Priority Change Requests should be added to the report as well. For each row (as requested) of
CRs, the number of priority Change Requests is added afterwards in brackets. This is so that it is more easily possible to identify all resources with Priority Change Requests. |
CKM-1473 | When internalising an archetype, add an additional line break after the "Derived from" part in the references | When an archetype that is currently referenced from remote via a remote subdomain and the archetype is internalised, the editor can add a “Derived from” note with a link to the original archetype. This “Derived from” statement is added to the top of the References in the archetype. Currently, this is separated by a line break from any pre-existing references. This change adds an additional line break between the two parts so that one empty line is displayed in between. When such an archetype is converted to ADL2, the archetype lists all references separately (ignoring any empty lines). |
CKM-1474 | When manually changing to a 'Team review' status, add a warning message that this is usually an automated changed upon initiating a review round | For the benefit of some (edge) use cases, it is possible to directly (manually) change the status of a resource to "Team review" or "Reassess (team review)". However, doing so manually is usually neither necessary nor desirable. Therefore, add a warning message when manually updating to a Team review state that this is usually done automatically on initiating a review round and thus likely unnecessary. |
CKM-1476 | Translation Editors should get an earlier error message if trying to commit a branch to the trunk that does not only contain translation changes | A translation editor can commit branches to the trunk only if the branch contains translation changes only. Currently, the editor can always start the commit process and only at the end when pressing the commit button, it is checked that the branch cannot be committed by a translation editor. This issue improves this behaviour in the following ways:
(Includes some display finetuning, mainly widths and paddings) |
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 | Translation editors should only be able to commit translation-only branches if
As before, translation editors cannot commit an archetype if the archetype contains any content changes (not only translation updates). |
CKM-1478 | Instance-wide configurable ability to prevent editors from assigning other editors and translation/terminology editors to a project/incubator | For some CKM instances, it is important that project/incubator editors can assign the role of editor, translation editor or terminology editor to other users (this is the way it has been up to now). However, for other CKM instances with a stricter governance model implemented, it is important that this is not possible. Therefore, a new instance-wide configuration option is being introduced that controls whether editors of a project/incubator can or cannot delegate editorship rights for the project/incubator to other users. In detail:
Customers that would like to configure this to NOT delegate editorship rights, please contact Ocean. |
CKM-1482 | Ability to a) view a translation in the translation tree and b) start editing the translation from the translation "donuts" on the Resource Status Tab | Ability to
directly from the translation donuts on the Resource Status Tab of each archetype. |
CKM-1483 | Change code for episodic composition from 435 to 451 following erratum issued for RM 1.1.0 | https://openehr.atlassian.net/browse/SPECRM-89 introduced the episodic composition category by assigning code 435 to it. However, unfortunately, it appears that this code is used in some systems to mean laboratory instead (see https://openehr.atlassian.net/browse/SPECPR-367 ) Therefore, an erratum was issued for RM 1.1.0 and the openEHR RM spec was updated. The new code assigned for episodic compositions is 451. This code (451) is now used by CKM as well. |
CKM-1485 | Add additional meta data for archetypes to the REST webservice to improve external revisioning | Add the following additional meta data to REST API calls for archetypes:
|
CKM-1492 | Upgrade to latest Archie version for ADL2 conversion (1.0.2) | Upgrade to latest Archie version for ADL2 conversion. Most notably, this includes conversion fixes
|
CKM-1494 | Improve resource revisioning and status indication in the resource main heading, the drop down to switch between latest and latest published revision, the archetype references display, the Resource Tab Tooltip, and the left-hand explorer tooltip | Improve resource revisioning and status indication in the resource main heading (where the resource's main display name is displayed together with the status icon, remote icon, and branching and revisioning information), the drop down to switch between latest and latest published revision, the archetype references display, the Resource Tab Tooltip, and the left-hand explorer tooltip. In detail:
|
CKM-1495 | Warn the user before closing a tab with an actively edited translation tree | Currently, it is possible to just close the tab if a translator has made changes to the translation of an archetype using CKM's translation facility. |
CKM-1505 | Collapse Closed Change Requests by default | The Closed Changed Requests subpanel for a resource should be collapsed by default unless a closed change request has explicitly been requested to be shown. This is consistent with behaviour for tasks on the To-Do List. This is especially useful when accessed from the information/warning that there are open change requests - as displayed during revisioning activities such as committing or publishing a resource. |
CKM-1510 | Preview archetype mind map for archetype proposals and change requests | If an archetype has been attached to an archetype proposal or change request, add the ability to preview its archetype mind map directly from the proposal or change request. This is to support editors by visualising the overall structure of the archetype in a better way than this is possible via the already available Tabbed Preview of the archetype. |
CKM-1512 | The Semantic Revision of an archetype should be shown for currently or previously published archetypes even if they are opened from the Find resources tab | CKM-1459: Publication vs. Development Revision History Views improved the Resource Revisioning and Status Indication in the Resource Main Heading, the drop down to switch between latest and latest published revision, archetype references display, the Resource Tab Tooltip, and the left-hand explorer tooltip. For consistency, this issue extends CKM-1459 in the following way: |
CKM-1517 | Various minor display improvements | Various minor display improvements, including the following:
|
CKM-1519 | Ability to export various grid data as CSV for further analysis and reporting for example in Excel | For some of the grid panels (tables) used in CKM, it is sometimes useful to be able to export the data for further analysis and reporting. |
CKM-1520 | Ability to export the core data of various charts as CSV for further analysis and reporting for example in Excel | For some of the presented charts, it is sometimes useful to export the chart’s core data for further analysis and reporting. |
CKM-1524 | When inside a discussion thread, the "Show All Topics" button should be moved further down to the left of the Reply button | It is essential functionality to go back to all discussions when looking at one particular discussion thread. The existing “Show All Topics” button does exactly this, but is placed next to the search box and is thus easy to miss. Therefore: Move the button further down and to the left of the (upmost) Reply button. Includes some minor display tweaking. |
CKM-1526 | Editor should be warned before deleting a task from a resource's to-do list | Currently, when a user clicks on the button to delete a task from a resource’s to-do list, the task is deleted immediately. |
CKM-1527 | Upgrade LOINC to Version 2.71 • Released 2021-08-23 | LOINC as the international standard for identifying health measurements, observations, and documents, is internally used by CKM to resolves LOINC term bindings in archetypes. This issue upgrades the LOINC version used by CKM to version 2.71 (released 2021-08-23). |
CKM-1528 | Ability to export the Publication Report as CSV | In addition to typical grid panels (CKM-1519) and various charts (CKM-1520), the Publication Report available from the Reports menu, should also be made available as a CSV file. |
CKM-1531 | Display a pre-constrained magnitude status (e. g. ~ for approximate) for DV_QUANTIFIED datatype subclasses | Display a pre-constrained magnitude status for datatypes subclassed from DV_QUANTIFIED (cp. https://specifications.openehr.org/releases/RM/latest/data_types.html#_quantity_package ). In some cases, it may be desirable to constrain the magnitude_status in the archetype (rather than just setting it in runtime data). Data types Spec DV_QUANTIFIED itself introduces the concepts of magnitude and magnitude_status. The magnitude attribute is guaranteed to be available on any DV_QUANTIFIED, carrying the effective value, regardless of the particular subtype. The optional magnitude_status attribute can be used to provide a nonquantified indication of accuracy, and takes the following values:
If not present, meaning is "=". Cp. magnitude_status and the discourse discussion at: In cases, where the magnitude_status is explicitly constrained in an archetype, e. g. ELEMENT[at0003] occurrences matches {0..1} matches { -- DV_DATE_TIMEtest
value matches {
DV_DATE_TIME matches {
value matches {yyyy-mm-ddTHH:MM:SS}
magnitude_status matches {"~"}
}
}
}the magnitude_status should then be displayed in CKM as well. Note that in cases where the magnitude_status is not constrained, data instances can use any magnitude_status, defaulting to the exact (point) value. NB: The fact that CKM now displays the magnitude_status when it is constrained in an archetype, does not imply that this is an attribute that is considered to be commonly constrained in an archetype. In most cases, the correct magnitude_status is just set on runtime if it is different to the default “=” exact value, for example if all that is available is an approximate (~) date of birth. |
CKM-1543 | Add additional image to the CKM Dashboard's "Become a Part of our Online Community" Widget | Add additional image to the CKM Dashboard's "Become a Part of our Online Community" Widget in addition to the current four images - with one randomly chosen on loading CKM. (This widget is only displayed on the dashboard when the user is not logged in.) |
CKM-1546 | Implicitly used parent archetypes should be included in Template File Sets | If a specialised archetype is used in a template, but its parent is not directly used in the template as well (at a different location), the parent archetype is NOT needed for constructing the Operational Template. The specialised archetype is (in its 1.4 flat form) already includes all the relevant information for this. However, for modelling tools, the parent archetype may still be valuable to have, for example to construct diffs and adl2 source format. There, as a best effort, CKM now provides the revision of the parent archetype that was available in CKM at the time of uploading the revision of the specialised archetype used by the exported template. If no parent archetype existed in CKM at that point in time, its first revision is provided. To clarify this behaviour CKM adds the following note to the template file set's readme file in such cases.
|
CKM-1548 | Enable support for a special logo that can be used in the configurable email prefix if neither the configured customer's header logo nor the configured big version of the logo in the CKM's AboutPanel are suitable for this purpose | Enable support for a special logo that can be used in the configurable email prefix if neither the configured customer's header logo nor the configured big version of the logo in the CKM's AboutPanel are suitable (e.g. transparent, email client dark mode, ...) Compare with Release Notes from 1.16.0:
Customers that would like to configure these styles, please contact Ocean to discuss the configuration details. |
CKM-1568 | When opening a user for viewing via the context menu of a user grid in a window, the user profile should be displayed in a window on top of it rather than a CKM tab half-hidden underneath | When opening a user for viewing via the context menu of a user grid in a window, the user profile should be displayed in a window on top of it rather than a ckm tab half-hidden underneath. For example:
-> The User Profile and the user's "Domain, Profession & Language" should be displayed in a Window on top of the current window. It should no longer open a CKM tab in the background which depending on screen real estate may not or barely be noticeable. |
37 issues
Bug Fixes
Key | Summary | Description |
|---|---|---|
CKM-448 | Improved error message when trying to use a direct link where a discussion topic has been deleted in the meantime | CKM should provide a better error message when trying to open a direct link to a discussion topic when that discussion topic has been deleted. One example is when the direct link to the discussion topic has been posted on e. g. Twitter or sent via email or posted on some website and the (complete) discussion topic has been deleted afterwards in CKM. In this case, an error should be shown: “The requested discussion topic could not be found. It may have been deleted in the meantime.” Also, all available discussion topic for the resource should then be displayed. |
CKM-1452 | Increase the width of the select box to set a new Resource Status so that "Reassess (Review suspended)" does fully fit | On the Resource Status page for a resource (archetype, template), an editor can select a new status for the resource (e. g. Team Review or Published). For Reassess (Review suspended) the expanded list width is insufficient so that it is cut off. Therefore: Increase the width of the select box to properly fit Reassess (Review Suspended) as well as its translations (in German it is currently longest) |
CKM-1453 | Missing and outdated icons during Release Set creation process | When creating a new Release Set, the following icons were missing or outdated
|
CKM-1454 | If an archetype is not (no longer) parsable, the Validation Report for a group of archetypes should not fail to continue the validation and thus display | For an archetype that exists in CKM but is not or no longer parsable (for whatever reason), requesting the Validation Report for a group of archetypes via the Tools menu or via the corresponding project's page should not completely stop the validation with an error. Because non-parsable archetypes cannot be imported into CKM in the first place, this is only relevant for archetypes that were uploaded using a more lenient previous parser, for example one that allowed “NO” as language. |
CKM-1460 | Dictionaries for cached terms from a terminology cannot be accessed after upgrade to latest database version | After upgrade to the latest database version, the dictionaries used to store cached terms from external terminologies cannot be accessed due to (changes in plugin service permission handling). Anytime when users want to display an archetype that has terminology bindings (to e. g. LOINC), an error message is displayed that the dictionary does not exist. NB: This issue is a consequence of upgrading to the latest database version and has never been an issue in a production system. |
CKM-1463 | A project's or subdomain's change request tab shows too many change requests once options are changed | On a project's or subdomain's Change Request Report tab shows unrelated Change Requests if options are changed. For example:
-> Change Request for Resources that are not related to the current project are erroneously shown. |
CKM-1465 | Improve/correct VDFAI validation | The VDFAI implementation seems to be not 100% correct in the Java Reference Implementation. VDFAI Archetype identifier validity in definition. Any archetype identifier mentioned in an archetype slot in the definition section must conform to the published openEHR specification for archetype identifiers
Requires changes to the VDFAI validation check following the discussion at and integrating this into CKM. |
CKM-1466 | Listing active branches can sometimes be very slow with the originally targeted database version for CKM 1.17.0 (and sometimes is very fast) | Listing Active Branches can sometimes (not always) be very slow. This manifests itself in several places, including:
Note: This is a problem that was never in a production system - although the change now implemented will likely increase the speed further. |
CKM-1470 | The "Import from Remote" functionality may miss that some newer archetypes have been updated remotely | CKM's "Import from Remote" functionality available to CKAs from the Archetypes menu, may miss some newer archetypes that have previously been imported and which can now be updated to a newer revision. This happens only when a large number of archetypes have previously been imported from remote. |
CKM-1471 | Import from Remote: When updating to newer revisions of - now - rejected or deprecated archetypes, all revisions are listed | Importing Archetypes from Remote: For example, if a local CKM currently used revision 8 of a remote archetype and this archetype is now in revision 10 and set to Rejected, CKM should only list revision 9 and revision 10, but not any previous revisions. Also fix trivial display oddity for the link to the archetype (space before the link icon looks underlined due to link) |
CKM-1472 | Interval of Duration Icon is rendering wrongly | The Interval of Duration datatype icon is corrupted in that it specifies a wrong size. |
CKM-1479 | A Translation Editor can see the Revise/Commit... archetype menu, but then cannot select any archetype | A (Project) Translation Editor sees the Revise/Commit... archetype menu, but then cannot select an archetype. When a translation editor uses the functionality, the tab opens, but for any archetype the translation editor is given a “You do not have the rights to commit” error message - even if the user is translation editor of the project of this archetype. See 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” for more details on when a translation editor should be able to commit a branch archetype to the trunk. |
CKM-1480 | A Translation Editor should not be able to update the content contributors on the branch, because then the translation branch cannot be committed by the Translation Editor anymore | Currently, a translation editor can update the content contributors on a branch, but then is not able to commit the branch anymore without the help from an editor or Clinical Knowledge Administrator (CKA), even if it contains only translation changes otherwise. A translation editor should not have the functionality to update contributors (via the context menu of the branched archetype). Note that this is not functionality required for managing translations because the contributors here refer to the content of the archetype, not the translations. Meta data about the translations is kept separately and can be managed by the translation editor. |
CKM-1484 | Correctly parse DV_DURATION interval constraints where lower and upper is specified and > and/or < is used to indicate that lower or upper are non-inclusive | An archetype with a DV_DURATION interval constraint like
causes a parsing error due to the “<“ in it. While this is logically equivalent to
it should still be supported as well. Example ADL extract: ELEMENT[at0018] occurrences matches {0..1} matches {
value matches {
DV_DURATION matches {
value matches {PD/|P1D..<P1000D|}
}
DV_INTERVAL<DV_DURATION> matches {
lower matches {
DV_DURATION matches {
value matches {PD/|P1D..<P1000D|}
}
}
upper matches {
DV_DURATION matches {
value matches {PD/|P1D..<P1000D|}
}
}
}
}
} |
CKM-1486 | Correct produced media type to text/plain for retrieving the md5 hash via the REST API | Correct the produced media type to text/plain for retrieving the md5 hash via the REST API. |
CKM-1488 | Year 1970 modification time (mtime) retrieved for assets in a certain range of creation when retrieving via xpath query | A defect of the underlying database system caused modification times not to be retrieved correctly for a certain range of assets created from 2015-08-15 to 2018-01-08 on the openEHR CKM instance. This only happens under very specific query retrieval conditions (when the modification time is explicitly requested, rather than retrieved as part of the asset as a whole. The one place where this has a visible effect in CKM 1.16.x is on the timeline displayed on the status page for a resource. If the resource was created (not: last modified) during the above time period, the date of the “Latest revision” is shown as 01-Jan-1970 in the timeline. |
CKM-1489 | For users with a large number of project roles: Increase speed of various calls such as retrieving the revision history of archetypes | CKM users with a large number of different project roles experience performance issues for some calls. Previously, a user with many project roles (e. g. editor for 30 projects and reviewer for another 10 projects) would have seen a huge loading time difference between being logged in and logged out when opening the revision history. While this is ultimately related to an inefficiency of the underlying database system, it was possible to restructure the role handling in CKM to mitigate the effect of this inefficiency, so that the performance has been improved considerably for such users. |
CKM-1491 | Revision History Panel may display a "latest published" label for a wrong revision if there are specific translation status changes afterwards | Revision History Panel may display "latest published" for a wrong revision if specific status changes were made afterwards. For example:
In this case, the correct LATEST PUBLISHED version is 5 (and not 3 as displayed erroneously by CKM 1.16.x). (Only in version 6, the archetype content is not immediately republished, and thus the state is changed to REASSESS_DRAFT.) |
CKM-1497 | UCUM validation leads to a false positive error for units with annotations that contain a . or an / | UCUM validation leads to a false positive error for units with annotations that contain a “.” or an “/” According to the grammar the annotations can contain any 7bit ASCII-char which includes “.” and “/” One example in practical use is See common code 437: milligram per day per 1.73 square meter in UCUM TableOfExampleUcumCodesForElectronicMessaging The above example is correct, however CKM 1.16.x claims this to be incorrect. |
CKM-1498 | Role of a user within a project may still be displayed as "null null" if the user has been deleted without revoking the role first | A role of a user within a project may still be displayed as "null null" in the project members grid if the user has been deleted without revoking the role first. Therefore:
|
CKM-1499 | Template Hierarchy Display: Tooltips on archetypes that are used by the template in a previous/outdated revision show a trailing "]" after the archetype id | In the Template Hierarchy Display (Org Chart like diagram) of a template: |
CKM-1500 | When switching between revisions of a resource and opening the initially used version a second time may lead to some display problems | When switching between revisions of a resource and opening the initially used version a second time may lead to some display problems such as that the mind map or the simple view of the resource is not properly displayed or switches to the wrong tab instead of opening the correct revision of the resource. One way to reproduce this behaviour is to follow the following steps:
→ This activates the first archetype tab again (with the latest revision), instead of opening the correct (outdated) revision used by the template. This may also cause one of the archetype mind maps to layout incorrectly (everything more or less on top of each other). Another way:
→ This opens the latest revision again, instead of switching to the already opened latest revision. |
CKM-1501 | RichTextAreas such as the comment box for an archetype may not be editable in the latest Firefox Release | When commenting on an archetype or other resource, the RichTextArea is no longer editable in the latest release of Firefox. This means users cannot participate in the discussion for a resource using the latest release of the Firefox browser. They’d need to use either an older release of Firefox or a different browser such as for example the Chromium-based Vivaldi browser. This issue provides a workaround for this problem only encountered in Firefox, so that users are able to participate in discussions again. NB: This issue does NOT relate to reviews conducted in CKM by invited reviewers. It only relates to comments in the discussion space of a resource or the General Discussion. |
CKM-1511 | Review invitation not retrieved error | When a user is opening a review to conduct a review, the review invitation may fail to display and an error message stating that the review invitation was not retrieved is being displayed. NB: This is not an error that was ever in a production system. |
CKM-1515 | The Lookup User functionality may miss a user with primary email in "Search" mode | When looking up a user (as a Clinical Knowledge Administrator) via Tools/Lookup User:
|
CKM-1516 | Avoid duplicating untranslated markers when translating directly in CKM and the primary/original language contains "untranslated" markers already | In CKM's translate archetype functionality, select an archetype that has untranslated markers in the original language (for whatever reason) - for example
For this archetype, select a completely new translation language (i. e. one where the archetype has not yet been translated into at all), partly translate the archetype and save. On saving, CKM duplicated the * ...(en) markers if the already * (en) marked original language text had not been set during the translation at all. While on the one hand this could be regarded as consistent in a way, this is not really desirable and rather unnecessary. Therefore, existing markers should no longer be duplicated from the original to translation language in CKM in this case. (Note this issue is related to the previous issue "CKM-1242 - Avoid duplicating untranslated markers when editing the archetype directly in CKM via the translation functionality", however not exactly the same.) |
CKM-1523 | Reports/Review Reporting shows null as translation language in grid tooltip |
Instead of "null", the ISO language (e. g. de) should be displayed in the tooltip. |
CKM-1525 | Terminology & Translation Editors are shown the button to delete a task, but the task is not deleted when clicking on it | For any archetype that has a task in the to-do list, Terminology & Translation Editors are shown a button to delete each task. To rectify this inconsistency that the delete button is shown but not usable: |
CKM-1534 | Certain users may be missing from the list of invited users in the review round summary email sent out to editors | Certain users may be missing from the list of invited users in the review round summary email sent out to the editors of the archetype/template after the review round has been created. This happens if the editor invites users by BOTH of the following ways at the same time:
AND one of the following
CKM will correctly invite all users exactly once, no matter how many times they have been explicitly or implicitly invited using the selection mechanisms above. However, CKM 1.16.x is overeagerly removing users from the final combined list of reviewers to be displayed in the review summary email sent out to the editors of the archetype/template, which then in many cases may list no or only a limited number of invited reviewers. |
CKM-1535 | NullPointerException when inviting only projects to a review round (no explicit users) | When an editor initiates a new review round and ONLY selects projects to be invited - but no other users for example via the “More Users” tab - CKM may fail to create the review round with a NullPointerException. |
CKM-1537 | [Internal] No permission to cache concept from terminology if using the internal manager account | When a user is logged in using a special admin account and opens an archetype (e. g. Blood Pressure), the user may be presented with an error message like: {{Null executing oi.terminology.terms.get: arc.mf.server.Services$ExServiceError: call to service 'oi.terminology.terms.get' failed: call to service 'dictionary.entry.add' failed: No permission to modify dictionary within global dictionary namespace. }} This would only happen if
To reproduce:
NB: This is not an issue any normal CKM user (including CKAs, editors, etc.) would ever have experienced. |
CKM-1541 | New Adoption Emails to Editors contain %{email-style}% placeholders | When a user adopts an archetype or template during an active review round, the editors are being sent a new adoption notification email to be able to add the user to the current review round if desired. In this email, the email-style and email-prefix placeholders (as introduced in CKM 1.16.0) are not properly replaced:
|
CKM-1545 | On opening a template's Related Resources panel an error of the form "XPath asset-version (value=null) is not an integer." may occassionally be displayed | When opening a template’s related resources panel, the following error message may occassionally be displayed: XPath asset-version (value=null) is not an integer.This can best be reproduced when quickly opening several templates via CKM’s left hand panel.
|
CKM-1549 | Some circles in charts are no longer displayed circular but only elliptical in recent versions of Chromium browsers | OrgCharts have a layout problem in Chromium-based browsers if TableNG (Background information: ) is turned on (as is now the default in Chrome 91+, or via chrome://flags/ ) If TableNG is turned on, an example layout is
Note that two of the three "circles" aren't round and the connector is not properly centered. There are various examples of this. Previously - or if the TableNG flag is set to false - the layout is correct, i.e. all 3 circles and that the connector are properly centered and circles:
The only change required is to switch the tableNG flag on or off in Chrome. |
CKM-1551 | Swagger UI to REST-API should use JSESSIONID if specified via the Authorize Button/Form | Currently, the Swagger UI for CKM’s REST API provides the facility to authorize via "Api key authorization" using JESSIONID. Steps to Reproduce:
|
CKM-1569 | Destroyed users still holding a project role may cause an error message when inviting the project role to a review round | Destroyed users still holding a project role may cause an error message when inviting the project role to a review round. Example:
This is due to a change in the underlying database system, now preserving and listing roles for deleted users unless explicitly revoked before deleting the user. Therefore, check if a user has been destroyed before trying to invite the user to a review round (and as detailed in CKM-1498 above) revoke any roles explicitly on deleting a user account. |
CKM-1572 | When uploading a revision of an archetype where the only change is the Build UID, this should be reported as unchanged during the upload process as per CKM-606 | When a user checks out an archetype and then uploads a revision to this branch where nothing has changed except for the build uid, this should be reported as unchanged during the upload process of the archetype. This is functionality that was introduced as CKM-606 in CKM 1.8.0 - but due to an obscure bug did not kick in properly in production. One example where this functionality is useful is where the trunk revision and the first branch revision are identical except for the build uid. This is always the case, because the build uid is updated by CKM automatically. If the user then directly uploads the - unchanged - trunk revision to this branch, there is no point in showing this as a change because the build UID is overwritten each time by CKM anyway, so that this should not be presented as a change on upload and the uploader be warned directly that there are no (real) changes at all. (When comparing two revisions in CKM, this would however be shown as a change of course. Also when committing the archetype to the trunk, this change would be shown even if it is the only one.) |
CKM-1577 | Value Sets referenced in templates pointing to an external terminology server are not displayed inline under a specific circumstance | FHIR® Value Sets referenced in templates pointing to an external terminology server are not displayed inline if the following condition is met: AFTER the value set and still within the exact archetype there is a SLOT filled (for example a reused CLUSTER archetype). |
CKM-1582 | Under certain conditions, reactivating a deprecated template may show the option to select a new resource status of either DRAFT or DEPRECATED | Under certain conditions, reactivating a deprecated template may show the option to select a new resource status of either DRAFT or DEPRECATED. Neither DRAFT nor DEPRECATED are possible next states when reactivating a DEPRECATED template. Steps to reproduce:
Similarly if the the template is first updated once with a new revision between step 1 and step 2 above, the next possible state would be "DRAFT". This happens where the template is deprecated (i.e. status changed from a PUBLISHED or REASESS_* state to DEPRECATED) without any revisioning of the template in between. Correct this behaviour so that the available next steps are always a selection of PUBLISHED and the REASSESS_ states as required. |
CKM-1583 | User roles could not be retrieved error displayed upon login | When a user logs in, the user is presented with a "User roles could not be retrieved" error message". This happens only if the user has been part of a project that was deleted without revoking the user's roles in this project first. This may have happened if another user that held the same role for the same project was deleted before the project was deleted as well. Example steps to Reproduce:
-> Previously, user A would now experience the "user roles could not be retrieved" error. |
41 issues
General Tasks / Under the Hood
Key | Summary | Description |
|---|---|---|
CKM-1457 | [Internal] Upgrade to target Mediaflux version (4.12.017) for CKM 1.17.0 | Upgrade Mediaflux asset management system to 4.12.017 version. |
CKM-1467 | [Internal] Some clean-up of css files | Clean up some css stylesheet files, including
|
CKM-1487 | [Internal] New Target Mediaflux version use LATEST as a reserved keyword which requires changes to some queries | Mediaflux versions greater than 4.12.001 use LATEST as a reserved keyword. Queries using the native label "LATEST" need to be updated to reflect this. |
CKM-1502 | [Internal] Update SameSite Cookie policy to deal with changed standard on cookie policy for SameSite attribute | Standards related to the Cookie "SameSite" attribute recently changed, see e. g. In particular:
Login Cookies set by CKM need to be updated accordingly to avoid browser warnings and - in the future - errors. |
CKM-1518 | [Internal/Search Engine] Add Project name, link and remote status to the archetypes list available via retrieveResources?list=true and also add a list of all projects with direct links to the project | Add Project name, link and remote status to the archetypes list available via retrieveResources?list=true This is useful for search engine linking and also to know the project and its remote status directly from the list. The remote status is prepended to the project name in square brackets. Also add a list of all projects to this report. |
CKM-1529 | [Internal] Remove dependency on GWT-internal (outdated) Jetty for development, replace with Tomcat as local external servlet container | The GWT plugin has a dependency on the GWT embedded Jetty server. The version of it is outdated though and it is recommended to replace it with an external servlet container, e. g. an external (up-to-date) Jetty or a Tomcat. This is important to be future-proof in this regard and to support Java 11+ syntax for the CKM middle tier as well. Since Tomcat is usually used in production, this is regarded as the best choice locally as well. |
CKM-1532 | [Internal] Rework the Project Select Combobox using a Builder | The Combobox to select a Project and/or Incubator from all or a selected subdomain, public or private only, excluding some projects, with extra selections for all projects, incubators, both, etc. has various constructors with many different ways to configure what is displayed. Rework this using a Builder for more flexible and explicit construction. |
CKM-1538 | [Internal] REST API: Upgrade Swagger to 1.6.2 | Swagger UI is used by CKM's REST API to expose the API. |
8 issues