INTRODUCTION TO CUSTOMIZATIONS
Compiere Professional Web Application supports the definition of Info Window search fields and table columns in the dictionary. Each Info Window has a search region on top composed of various search fields, and a table region below that shows the results in a tabular format.
In addition to Compiere's ability to customize Smart User Interfaces, Reports and Extensions; Compiere provides additional customization capabilities as follows:
- Preferences allow default and pre-selected choices
- Login preferences Organization, Language, Transaction Date and Printer
- User defined preferences, like specific transaction types.
- The Menu Bar
- The Menu Bar allows the user to save any entry in the menu (Window, Process, and Report) as a shortcut.
- Terminology can be changed. i.e.: users may have 'Items,' instead of 'Products' or a 'Branch' instead of 'Organization,' etc.
- Help Text can be modified and extended by the user to provide hints and help texts.
Customizations are definable on different levels.
- System or implementation wide
- Window, where appropriate (e.g., for preferences)
- Specific User
More specific levels overwrite the settings of more general levels. System level changes are automatically saved and can be defined as customizations if required and reapplied after the installation.
In 3.0, a new entity called InfoWindow was created to store the definition of Info windows for use on the web UI. This can be accessed in the System Administrator role.
The Info Window object and its child tab Info Column allow you to define, for each Info Window, the SQL that should be applicable for retrieving the information to be displayed in the table column, and also indicate which columns should appear in the search region as fields available for the user to search.
You can think of the Info Window and Info Column entities as a way for you to specify the complete SQL statement to use to search and retrieve information presented in Info windows, while letting you specify attributes for each of the columns that are retrieved by the SQL statement.
Note that the Info Window / Info Column construct is not used by the Swing UI.
See below for descriptions of the key fields on each of the two tabs.
Table: This indicates the table to which a particular info window definition should be applicable. In the screenshot above, "C_BPartner_Business Partner" indicates that this Info Window definition will be used when an Info Window needs to be shown for the Business Partner entity.
Validate: This is currently unused.
Customization Default: You would check this box if you want to create an alternative definition of an Info Window without modifying the existing one. For example, if you want to define a completely new Info Window definition but do not want to update the system default, you would copy the existing definition to a new record, and check this box. Then, the system use the record that has this box checked instead of the original definition when showing the Info Window for Business Partner.
Displayed: Indicates whether this field/column should be shown in the tabular output region of the Info Window.
Query Criteria: Indicates whether this field/column should be available in the search region of the Info Window.
Reference: Indicates the data type for the field/column.
Key column: Indicates that this field/column contains the primary key to the entity being shown by this Info Window.
Identifier: Indicates that this field/column contains the "name" of a particular record that is represented by this Info Window.
Range: Indicates that, if this field/column has Query Criteria checked, that the search region should allow for the search of the field using a range (From and To parameters).
Compiere has the ability to dynamically create default field values when a new record is created (SQL, constant, preferences). In addition to this, Value Assignments allow the ability to set values after the user presses save, just before a record is saved. This could be used to create a default value without user intervention or if the user fails to define a value. Another use is to assign a certain value based on other fields. Value Assignments are basically a declarative way to define before-insert/update/delete trigger.
The Value Assignment allows business logic to be added without programming and with no impact on migration to new versions and with that is an ideal Customization tool. It acts like a Trigger and its execution is logged. Value assignment feature is a convenient way to assign rules based values to a data set. A more native approach to this will be to extend the before update class of the method beforeSave(..) of any persistent business/model object, e.g. MProduct or MOrder.
You define the value assignment for a certain table and select the situation the assignment should take place: e.g., when a record is Created and/or Updated. You can add the restriction that the record cannot modified if processed (for documents are assumed to be read/only after processing). For each table, you can define a number of Target columns to be modified. The new value can be a constant or be calculated via SQL. The new value can be always assigned or only if the current value is (not) NULL.
You can add additional Criteria to limit the execution of the assignment. You can compare any column in the record with constants or SQL results. Multiple criteria could be linked via AND or OR logic. The Value Assignment can be defined at System Level, indicating that the assignment will apply to all Tenants in the System or can be defined at Tenant level to allow the assignment to apply to a specific Tenant only.
There are 3 entities used in Value Assignment, the Assignment Set, the Assignment Target and the Assignment Criteria.
- Assignment Set defines the table (e.g C_BPartner) and the timing (event) of the assignment (e.g. Create and Update, Create Only, Update Only, Create and Update if Not Processed and Update if Not Processed). Think of this as the Update Clause of a SQL Query.
- Assignment Target defines the specific field on the table that will be updated, the rule for updating (Always, when Null or when Not Null), the value the field will have either as an fixed value or as derived from executed SQL. This field need not be displayed to the user. Think of this as the Set Clause of a SQL Query
- Assignment Criteria defines the conditions where the value assignment will occur. This supports any column in the table and supports all of the standard SQL operands. Think of this as the Where Clause of a SQL Query.
Value Assignments are used most commonly in passive situations where you may want something to occur or be updated after a record is saved or updated.
- In a Lead assign the sales rep based on the country/region of the lead;
- Update the value of a field on a table that the user does not have access to.
- In Request, update the priority of a request based on the Business Partner Group (this may also be used to route requests)
As with any powerful options there are some considerations.
- When these assignments are executed they have full database access. Any database constraints will be enforced by the database. If an assignment is defined to set an amount field to 0, that will occur.
- The application will verify that the SQL statement used is a Select (e.g. not a Truncate or Drop.)
- The updates that occur are not in the confines of the Security definition of the Role of the user who saved the record. This means that a field could be updated that the user has no access or read only access.