Page History

DCM_CaseList sorting (user and model) does not work

Adding a sorting at the column in the container, or clicking on one of the columns as a user, does not work.

DCM_CaseList and DCM_WorkList

Dossier Metadata does not work

In the new container, a new feature is implemented, the "Dossier Metadata". This is case-type specific data which can be used in lists. However, in this version, the Runtime behaviour is not yet implemented.

DCM_CaseList and DCM_WorkList

always need a process module in the project scope

The containers always need a process module to work. ALso when used in a (main) dashboard application. This does not always make sense. You can use the process module to filter/show columns, but in many cases, you could also use the metadata for that. Therefore the dependency will be removed in the future (it's only needed when process profile is selected in columns). Workaround is to model a process module in each project using this containers (it may be an empty "dummy" module).

DCM_CaseList and DCM_WorkList

always filter on application-id

AQ_File_Upload and AQ_Generate_Document

do not store the case-id

The uploaded or generated documents should contain the case-id in scope when used. In the Case-Modelling setup, the attribute system.caseid will be used when documents are uploaded during task execution. In the first release this does not work properly, and will be fixed in a future release

--- Fixed / Closed ---

All Runtime models should also be available in the Case-Engine

The case-engine relies on Runtime models to work. Since it will load the model when requests are sent to the Case-Engine, you have to make sure that all Runtime models, are also available in the Case-Engine. In a future state, only a subset of the models might be relevant (or even subset of the modules), but for now, the models should be kept the same for both components (either by using exports or the publisher).

AQ_File_Upload and AQ_Generate_Document

do not store the case-id

The uploaded or generated documents should contain the case-id in scope when used. In the Case-Modelling setup, the attribute system.caseid will be used when documents are uploaded during task execution. In the first release this does not work properly, and will be fixed in a future release

Fix: Only the case-type model has to be shared between Runtime and Case-Engine (containing necessary modules for both components). Other projects, like MainDashboard is no longer needed in the Case-Engine.

DCM_Lists containers imported/migrated from pre 15.13 versions do not work properly.

In Blueriq 15.13 and higher, changes have been made in the way the lists containers work. ProcessId/CaseId has been changes in CaseId of type Text. New column types have been added for searching the metadata.

It seems that containers that the migrated DCM_ containers from previous versions sometimes do not work in Studio/Encore. This can be fixed to reinitiate the container (change types and back, or create a new one). Since most containers will be build from scratch anyway (aggregate list needs to be changed to caselist), the impact is minimal.