Projects:Select and Process UI Pattern Generation/Functional Specifications old
This is the initial project specification, it has been redone.
Contents
|
Select and Process UI Pattern - Functional Specifications
Overview
A typical pattern for process in Openbravo ERP consists in a window that allows filtering, this filtering returns a set of data that is shown in a grid, it is possible to select some lines from this grid and to add some additional parameter, and this information is taken as parameters for a process.
Currently these process are manually implemented because Openbravo ERP platform does not support this pattern.
Purpose
The purpose of this project is to allow to define the process type described above within Openbravo ERP application dictionary making possible to not have to implement it as manual code.
Scope
The scope of this project is to allow the definition of "Select and Process" objects and its implementation.
There are some other elements that will be used by these objects that will be taken as they currently are, and will not be enhanced by this projects. One of this elements is the grid, as currently is not editable these processes will not be able to edit data in the grid.
Design Considerations
Dependencies
- "Select and Process" objects depend on Openbravo's ERP grid, future enhancements on grid will enhance also these objects (3059).
- The way processes will be called depends on how they are implemented for Background process management project (4147).
Constraints
- Some of the currently manually developed "Select and Process" processes allow to edit some of the data displayed in the grid they show, as current grid does not support this feature, they will not be ported to the new pattern.
- The current grid implementation doesn't allow to have a check box to select a row, the way to select multiple records is by pressing control key while selecting the rows in the grid with the mouse. This approach is used in multiple selectors.
Functional Requirements
User roles & profiles
- Consultant/Developer
- This type of users have a high level of professional education, have a deep knowledge of the business processes and some basis on programming. They will be able to create or modify "Select and Process" objects and use them.
- Final user
- The final user will only see small differences (if any) between the current approach and the new one.
Business process definition
Creation
Consultant/developer role will be in charge of creating and maintaining "Select and Process" objects. The creation includes the following steps.
- New Select and Process object: Header for these objects will be a new type for the current processes. Thus it will be possible to be used as process (insert into a button, call from menu...).
- Define table: "Select and Process" objects will query a single table, this table will be used to obtain data taking into account the values in the filters. A where clause can be defined for this table in order not to show all the rows in the table but only those ones matching a criteria. As currently this objects are manually implemented it is possible to query to more than a single table depending on the values in the filter (for example "Select from shipments" selects data from invoices or orders), to generalize it this will not be allowed, the case in the example can be solved using a view that contains orders and invoices.
- Define process. A java process must be defined. This process will take as parameter the selected values as well as the parameter ones and will perform a process with them.
- Define columns. After selecting the table to be used it is possible to select a number of columns of this table. The purposes of using them can be:
- Filter: Filter columns are used to set a filter to restrict the data that will be shown in the grid.
- This filter can be obtained (at least its default values) from the window that has called the object.
- Filter columns can be editable or not. Non-editable filter columns will be useful for fixed filters that cannot be changed by user. For example the shown data for "create from shipment" is for sales or purchase orders/invoices depending on the purchase/sales value in the shipment header. in this case this value will not be editable.
- Mandatory. Filter columns can be required or not.
- Non-editable filter columns can be also non-visible.
- A filter sequence must be defined in order to define the position of the fields in the filter.
- Field group for these fields may be useful to be able to group fields in groups.
- Grid: Depending on this check it will be decided whether the field is going to be shown in the grid.
- A grid sequence must be defined in order to define the position of the fields in the grid.
- Edit, when the editable grid is prepared, some columns in the grid should be possible to be editable in order to pass this value as parameter.
- Filter: Filter columns are used to set a filter to restrict the data that will be shown in the grid.
- Parameters: Additionally to the rows selected in the grid the process can receive some parameters to be used in all the rows. These parameters will be defined as currently parameters for processes are done. An example of this kind of parameters is the "warehouse position" in the "create from shipment" process.
- Mandatory. Parameters can be required or not.
Once the "Select and Process" object is defined it can be associated to a column within a table to be called from as a button or assigned directly to a menu entry.
Usage
Final user will use these objects. The appearance for them will be pretty similar (in most of the cases) as the current one for the manual processes.
It will be a popup window called from a button in a tab or directly from the menu. This window will be splitted in 4 parts, only two of them (grid and actions) will always be shown, the rest will be shown depending on the object's definition:
- Filters: Will show the filters for the object. It will contains a "search" button to apply them
- Grid: After clicking the "search" button the grid will be populated with the obtained data.
- Parameters: If parameters are defined the will be displayed to make the user possible to fill them.
- Actions: Two buttons will be displayed.
- OK: will call the associated java process, passing as parameters the selected rows in the grid and the parameters fields.
- Cancel: will close the window making no action.
Functional requirements based on business processes
1st. Iteration: Implement Select and Process UI Pattern
| Num | Requirement | Importance | Status | Estimated time | Comments |
|---|---|---|---|---|---|
| 1.1 | Add to application dictionary the required element to support this pattern | Must have | To be started | 5d | |
| 1.2 | Implement the communication between UI and java process | Must have | To be started | ?? | This implementation will depend on the process invokator (for background processes) implementation |
| 1.3 | Implement WAD management for this new element | Must have | To be started | 3w | Depending on if it is decided to be static or dynamic code the effort can significantly vary. |
2nd. Iteration: Move current manual process to the new pattern
| Num | Requirement | Importance | Status | Estimated time | Comments |
|---|---|---|---|---|---|
| 2.1 | Move the current manual "select and process" objects to the new pattern and depracate old processes and classes. | Nice to have | To be started | 2w |
User Interface Mockups
User interface is divided in filters, grid, parameters and action sections. Currently using the standard grid is not possible to show check boxes to select rows.
Open Discussion Items
- ALO: In this documentation the process to be executed has been defined as a java process. This is because the process that can be executed is so generic that it is very difficult to design a way to define it within application dictionary. But on the other hand, this definition makes necessary to have (at least basic) programming skills to be able to create "select and process" objects, in fact, the only element that will not be manually developed is the UI.
- ALO: Selector UI pattern (issue 4191) can be considered as an specific case of this pattern which process consists on putting the selected element(s) in the tab that called it.
- ALO: This implementation could be a good candidate not to generate WAD code but to having a generic servlet that composes the UI dynamically and performs the call to the process.
- ALO: Is it necessary to define the possibility of having calculated fields? This field to be displayed in filters (as read only) or in grid would be calculated based on other columns values increasing the definition difficulty because expressions should be used. Another approach is not allow them and in case they are necessary define a view that includes them (not valid for filters).