View source | View content page | Page history | Printable version   

Projects:Enhanced Preferences/Functional Documentation

Contents

Overview

Throughout a system as Openbravo there is a need to store properties and property values. Properties can range from system level properties, module-specific properties to user specific settings. The Property Configuration functionality aims to provide a generic solution: store application/module/user properties in an over-rideable way and make them available to the rest of the system through an easy-to-use api.

As an example consider modularity: A common issue with modularity is how to configure a centralized resource in the system by an optional module. The main point is that the configuration of that centralized resource should support "overwriteable configurations" in order to support configuration by modules. It means that each module can deliver its own configuration and there is a rule/mechanism to define which one prevails.

This project aims to provide tools for a module to define configuration properties so the business logic of that module depends on the value of those properties. Then other modules depending on this one should be able to assign different values to this property in order to change the behavior of the process of the original module. The same toolset should also be used for storing user-specific settings.

Purpose

The purpose of this project is to create a infrastructure to:

This infrastructure will be created by extending existing AD_Preference table.


References

User/developer documentation can be found here ERP/2.50/Developers_Guide/Concepts/AD/Dynamic_Expressions#Preferences

Design Considerations

Assumptions

Dependencies

Constraints

Due to technical limitations, currently it is not supported to maintain data in a single table as source data and reference data at the same time. If a table contains source data, it cannot contain reference data.

Because of this limitation, even the infrastructure is designed to allow properties at any client/organization level, at a first stage it will only be capable to have data at System level.

Glossary

Functional Requirements

User roles & profiles

Business process definition

User stories

Control of customer used credit is a feature provided by core, it is made by a handler in core or in an optional external module. Core would define the property which value would be the implementation of the handler. If any module wants to implement a handler for this feature, it would have to include a value for the property pointing to the handler implementation within this module. The main Control of customer used credit process in core is in charge of reading the value of this property and calling the implementator defined with it. In case of several modules defining values for this property, when trying to obtain the value of the property an error message will be shown prompted the user to solve conflicts. In this case the user will be able to solve them by going to a manual window where all properties with more than one value will be showed and he will be able to select which of them will be used in each case.

Jrxml templates used in core document types. Each document type defined in core has a template to print reports. Core define a property per document with the template location. Typically the format of these documents is different among countries, so localization modules can optionally include a template and a value for document property pointing to this template. In a similar way than described above, the template selection would be made taken into account possible values in this property.

Last clicked menu items: when a user selects entries in the application menu then the system needs to keep track of the last three entries so that they can presented to the user as a shortcut. The last three selected entries are a property for the application menu component which is stored in the property table. The property is stored on role and user level (so when the same user switches role another last click list is shown).

Column width/visibility in a grid: a user can adapt the look and feel of a grid by changing the column and the column visibility. This user preference can be stored in the property table as a user preference on user or role level.

The last two user stories described settings set by user, it is also possible for a module to override or provide default values for these properties. In this way a module can be used to create specific complete system configurations.

Functional requirements based on business processes

User Interface Mockups

Technical Requirements

Non-Functional Requirements

Open Discussion Items

Closed Discussion Items

Testcases

Executed tests

Pending tests

Project status

Project is currently merged back to pi and will be publishes in 2.50MP16.

Some notes for qa:

Configuration Properties to Preferences Migration

In 2.50MP15 Configuration Properties infrastructure was created. It has been deprecated in 2.50MP16 by the Preference Extension.

This deprecated infrastructure is still present in MP16 core but it shouldn't be used by new version of modules. Utilty.getPropertyValue method has been deprecated and the core methods using it has now SupressWarning to prevent warnings when compiling core. ad_get_property_value pl function is still present. When packaging modules, it will not be allowed to have within them records in ad_property_configuration table.

As there is only one module that is using configuration properties, the migration to preferences will be:

Retrieved from "http://wiki.openbravo.com/wiki/Projects:Enhanced_Preferences/Functional_Documentation"

This page has been accessed 8,026 times. This page was last modified on 8 June 2012, at 05:27. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.