Projects:Pick and Execute

Contents 1 Status 2 Team 3 Definition 3.1 Feature overview 3.2 Users & use cases 4 Design 4.1 Functional specification 4.2 Technical specification 4.2.1 1st iteration (MP6) 4.2.2 2nd iteration (MPx) 4.3 User experience design 5 Planning 6 Development 6.1 Implementation 7 Resources 7.1 Open Topics

Status

• Stage: Released in MP6
• Planned Release: MP6

Team

• Platform Team - Contact: User:Iperdomo

Definition

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

Feature overview

Users & use cases

Design

Functional specification

• Mock ups of the "Return of Material" functional flow

Note: Not a definitive UI defintion

https://picasaweb.google.com/115378538831627171883/ReturnMaterial?authkey=Gv1sRgCNr7jbql6cHNJw#

Technical specification

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

Planning

Development

Implementation

• See issue 18763

Resources

Open Topics

• 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