...
Issue | Background information | Found in version | Fix version |
---|
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. | 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 |
|
Expand |
---|
title | Click here for the solved/closed known issues... |
---|
|
Issue | Background information | Found in version | Fix version |
---|
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 | 16.4 | 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 | 16.3 | 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.0 | 16.3 |
|
...
Unexpected model valiation errors at the Case-Engine
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 |
|
...
Issue | Background information | Found in version | Fix version | 15.13 / 16.0 |
|
Expand |
---|
title | Click here for the solved/closed known issues... |
---|
|
16.2.1 / 15.13.5 | 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.0 | 16.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.0 | 16.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.0 | 16.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.0 | 16.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.0 | 15.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.0 | won't fix |
|
...