Projects:Report Pattern/Technical Specifications
Contents |
WAD Hints Generation - Technical Specifications
Implementation
Change the way process and report types are defined
Reports and processes are defined in the same table: AD_Process. To distinguish among the different types of processes and reports that exists this table has a number of boolean columns, the number of rows means how many of this records are defined in core product:
- IsReport: Report (118 rows).
- IsBackground: Used for background processes (3 rows)
- IsJasper: Used for jasper reports (5 rows)
- IsExternalService: Currently used for Pentaho (1 row)
The problem of this approach is that it's possible to define non-consistent processes (for example a process can be checked as Jasper and external service).
This can be solved in two different manners:
A list of values defines the process type
This would require to create a new processType column for AD_Process table, in this column a different value depending on the process type would be stored. Additionally existent columns would be deprecated.
- Pros:
- It's more clear from a user perspective: a process has only a type that must be selected from the list of values.
- If new process types are added they wouldn't require new type columns in AD_Process, just a new value in the list.
- Cons: It is necessary to reimplement the way processes are managed to take into account this new column.
- Backwards compatibility. This column would have an onCreateDefault that would insert the correct value for each existent row. For non consistent processes a value would be taken (it can make not to work as they was working before).
Add constraints
Database constraints can be added not to allow non-consistent processes.
- Pros: It is easier to implement.
- Cons: It is not so clear as the previous approach
- Backwards compatibility: In case non-consistent processes are defined the constraint could not be enabled.
Menu entries
When a report is assigned to a menu it should not be defined as process but report.
Check the format is correct for parameters before submitting the page
This is applicable for reports and processes. A Javascript validation must be added for fields that must be checked (dates, numbers...) and it would not allow to submit the parameters in case they do not fit the checks.
Move manual reports to application dictionary
The reports that which user interface to request parameters is currently manually coded should be moved to application dictionary.
Constraints
- Those ones that use non-standard references (most of them multiple selectors) cannot be moved (multiple selectors should be solved within the selectors project).
- Reports that perform some logic cannot be moved. Only those ones that can be expressed as a SQL query.
- Reports that make actions that Jasper does not allow cannot be moved. For example those ones that contain links to Openbravo ERP elements.
Steps
The steps to do the movement are:
- Define the reports as Jasper Report
- Add the parameters they currently are receiving to the parameter list
- Modify the jasper report template to manage these parameters
- Deprecate the old files that were used to manage the user interface.