Page History
The beta version will be a first version which can be used by everyone on a development or test environment. Some items will need attention before the new architecture can be used in a production environment. A list of issues or points of improvements is This is a list of known issues in the current setup. It will be kept up-to-date below. Some issues will be blocking for any production environment, some will be improvements which might be added later in time.with the coming releases, until the first customers use the new setup, or migrated to the new setup in a working environment,
Known issues
| Issue | Background information | Found in version | Fix version | Severity | ||
|---|---|---|---|---|---|---|
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 | Low | |||
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). | 15.13 / 16.0 | Low | |||
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:
| 15.13 / 16.0 | Low | |||
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). | 15.13 / 16.0 | Low | |||
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 |
Limitations or different behaviour
...
Overview
Content Tools