Projects:Pick and Execute
- Stage: Released in MP6
- Planned Release: MP6
- Platform Team - Contact: User:Iperdomo
In the application we have several places where the same user case is applied. The user clicks a button, picks some records related to the document he is working with, and executes a process based on the selection. Some examples of this pattern are:
- Copy Lines
- Create From
The code behind this processes is copy/pasted with some minor adjustments for each specific case; resulting in higher maintenance costs. Every time you need to add some new column to the grid or a new filter is painful.
The goals of this project are:
- Support directly from the Application Dictionary (AD) the Pick and Execute pattern, avoiding the boilerplate code
- Reuse the ideas we have already implemented in the AD (with some minor adjustments)
- Provide the framework to support the development of some functional flows like: Return of Materials, Payment Plan edition, etc
Users & use cases
- Mock ups of the "Return of Material" functional flow
Note: Not a definitive UI defintion
1st iteration (MP6)
- The Pick and Execute window is a parameter of the process definition (See: Parameter Windows). Each parameter has a reference and we'll create a new reference type Window. This reference will link to a window definition, reusing the Window - Tab - Field concept.
- A new window type is required: Pick and Execute
- When using Pick and Execute window type, there will be only one tab. This will be enforced with a trigger.
- Will reuse the approach of Table as the datasource.
- The Window defines if a "Preview" tab will be shown
- Define which fields are editable (by default they should be read-only)
- The pick and execute process can also define a new parameter of type Button List, that will define the values and labels of the buttons (actions). Check the mockup https://picasaweb.google.com/115378538831627171883/EditPaymentInPlan#5661856840124734386
- When submitting the data to the server, it will be a JSON object with all the parameters defined in the process plus the 'record' objects in the grid
- We'll use client-side datasource, meaning that the transformation made by the user in the grid are not persisted in database. Editing an amount doesn't affect the records of the datasource (table)
2nd iteration (MPx)
- We'll support custom query (HQL) as datasource, as we do in the Selector definition.
- When adding the support for a custom HQL query, we'll remove the link of AD_Field -> AD_Column, since the fields will refer to properties (or aliases) in the query.
- AD_Field will require reference (AD_Reference_ID)
- AD_Field will require element (AD_Element_ID) to support Centrally Maintained concept
User experience design
- See issue 18763
- How to describe in AD advanced validations, e.g. The sum of the "amount" column in the grid most be X and, it shouldn't be possible to submit the process if the validation fails