View source | Discuss this page | Page history | Printable version   
Main Page
Upload file
What links here
Recent changes

PDF Books
Add page
Show collection (0 pages)
Collections help


Dynamic Expressions



Dynamic Expressions are used to obtain values that can depend on session values. For example they can be used to to filter the records that appear in a tab by the ones that were created by the user that has logged into the application.

Session values

Depending on how they are defined, there are different kinds of session values.

It is possible to check (as System Administrator) all current values loaded in session in General Setup || Application || Session Variables window.


Session global variables

These values are generated by Java classes and are accessible from anywhere in the application.


Values for all columns used in a tab are accessible as session variables within that tab.

Additionally it is also possible to set explicitly a column a session value by setting its Stored in Session attribute. This will make this value accessible not only for its tab but also for all the tabs in that window.


Preferences allow to define session values. It is possible to define preferences for a single window or for all of them (leaving blank the window field) and for one user or for all of them. Preferences are defined in General Setup || Application || Preference window.

When the attribute value matches with a column name, it will be used as default value for that column overwriting the standard default value for that column.

Preferences can be defined for a window and user. If no window is selected, the preference applies globally to the whole application; if one is selected, it will only be applied in that window. In a similar way, in case the user is blank, the preference will be shared among all users, other case the preference will be applied just to the selected user.

For a list of current system preferences see this wiki page.


There are two ways of defining a preference, it can be switched by using the Property List check field:


Preference visibility defines in which cases the preference will be used. It can be defined at different levels. All of them can be set or left blank, in case a visibility level is empty, it is not applied so it is visible from any value of that level; for example if the user parameter is empty, any user will be able to see that preference. In case the same preference has values at different levels, it will be used the most specific one. The levels are the following:

Getting/setting preference values

When logging in the application or changing role, preferences visible for that user/role/client/org are stored in session, that values can be obtained using the org.openbravo.erpCommon.utility.Utility.getContext method.

Additionally, it is possible to look for the value of a preference querying to database using the org.openbravo.erpCommon.businessUtility.Preferences.getPreferenceValue method. This method throws an exception in case the property has not a value defined visible from the current visibility level (passed as parameters), it also raises an exception in case of conflict (more than one value defined for the property at the current visibility level).

Preferences can be set programatically through org.openbravo.erpCommon.businessUtility.Preferences.setPreferenceValue method.


A conflict for a preference occurs in case the same preference is defined with different values at the same visibility level. When this happens, one of them will be stored in session when login in the application or changing the role. If the preference value is tried to be obtained using org.openbravo.erpCommon.businessUtility.Preferences.getPreferenceValue method, a PropertyConflictException will be thrown.

Conflicts can be manually resolved by user, checking the selected field of the preference. In this case the selected value preference will prevail over the rest.


Preferences can be optionally assigned to a module. In this case they will be exported as part of the module. This makes sense in case it is wanted to define in a module general settings that will be reused.

Auxiliary inputs

Auxiliary Inputs are used to create a session value for a concrete tab. This value can be calculated using a Dynamic Expression and it purpose is to use it in other Dynamic expressions within the tab it is defined for.

Auxiliary Inputs are defined in Application Dictionary || Setup || Auxiliary Input tab.


It is possible that there are different session values types with the same name that are accessible at the same point, in this case (unless it is explicitly specified to take the value in a global session value) the value will be taken following the next approach:

  1. Try to get a preference with the specified name for the current window.
  2. If no value has been obtained, try to get a value associated to the current window
  3. If no value has been obtained, look for a global session value.

Syntax and types in Dynamic Expressions

Using session values

In Dynamic expressions session values are obtained by their name surrounded by at symbols (@). Thus to get the content of a session value called myValue, it would be done typing @myValue@. Doing it in this manner it would follow the accessibility described above, but it is possible to explicitly obtain the global value (if exists) not taken into account the other ones, to do so the value would have a sharp symbol (#) as prefix. In the previous example it would be @#myValue@.

Dynamic expressions types

There are different types for Dynamic Expression, each type can be used depending on the Application Dictionary object it is defined in. A complete list of all the objects and which kind of expression can use is defined in the next section.

The types are:


It can a constant value or a value in stored in session, this type can be used by all the objects. To set this type no prefix is needed.




Some objects accept SQL expressions. This type must have a @SQL= prefix followed by the SQL clause. It also accepts session values.




It is a SQL where clause, in this case it is not necessary to add the @SQL= prefix.


It is used to obtain a boolean value. It does not have any prefix.

Its syntax is Javascript but the comparators are:

Dynamic Expressions used in Application Dictionary objects

AD Column Type
AD_AlertRule.FilterClause WhereClause
AD_AuxiliarInput.Code SQL
AD_Column.ReadOnlyLogic Check
AD_Dataset_Table.WhereClause WhereClause
AD_Field.DisplayLogic Check
AD_Ref_Table.OrderByClause WhereClause (order by clause)
AD_Ref_Table.WhereClause WhereClause
AD_Tab.FilterClause WhereClause
AD_Tab.OrderByClause WhereClause (order by clause)
AD_Tab.WhereClause WhereClause
AD_Val_Rule.Code SQL

Retrieved from ""

This page has been accessed 3,952 times. This page was last modified on 12 July 2011, at 08:09. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.