Versions Compared

Old Version 27

changes.mady.by.user Deny Raatgever

Saved on

compared with

New Version 28

changes.mady.by.user Deny Raatgever

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

IssueBackground informationFound in versionFix version

DCM_CaseList and DCM_WorkList

always filter on application-id

Filtering on application-id might not make sense to do when the containers are being used in a dashboard model. Therefore the dependency will be removed in a future version. In a mean time, the property to filter on application id can be ignored by adding this to the application.properties of the Runtime:

No Format
blueriq.processlist.default-app-id-ignore-mode=all
15.13 / 16.0

DCM_ReadCase service does not throw right exceptions

When the read-case fails, it sometimes does not flow through the right exit nodes (CaseNotFound, CaseCouldNotBeLoaded). Workaround is to make sure after loading the case that is has successfully done so, by checking on some property to be loaded correctly, and failing in the flow when it has not.

15.13 / 16.0

Development Toolbar is not available on the execute task widget.

When using DCM-Dashboarding, the development tools are not available for the global session and Blueriq sub-sessions. Separate DCM-Widgets can be started using the development dashboard, the developement tools are available there. However, the execute task is a special type of widget, that cannot be started separately.

15.13 / 16.0

Searching cases is not possible

Searching cases is not possible yet. In the old situation, the "AQ_Aggregate_Search" service could be used to search for cases. However, this returns aggregateId's. A new service will be added to search for cases, returning caseId's.

15.13 / 16.016.3

Unexpected model valiation errors at the Case-Engine

Since the Case-Engine runs the same models as the Runtime, it tries to load all services and containers. However, it does not have these definitions in scope, since it is a Case-Engine. At the development dashboard, it will show validation errors. These can be ignored. When the Runtime component shows no errors at the development dashboard, the model can be considered valid.

15.13 / 16.0
Expand
titleClick here for the solved/closed known issues...
IssueBackground informationFound in versionFix version

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.

15.13 / 16.016.2

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.

15.13 / 16.016.2

DCM_CaseList and DCM_WorkList and DCM_ReadCase

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).

15.13 / 16.016.1

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

15.13 / 16.016.1

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).

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.

15.13 / 16.015.13.2 / 16.1

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.

15.13 / 16.0won't fix

...