Dynamic Expressions

Contents 1 Introduction 2 Session values 2.1 Types 2.1.1 Session global variables 2.1.2 Columns 2.1.3 Preferences 2.1.3.1 Definition 2.1.3.2 Visibility 2.1.3.3 Getting/setting preference values 2.1.3.4 Conflicts 2.1.3.5 Modularity 2.1.4 Auxiliary inputs 2.2 Accessibility 3 Syntax and types in Dynamic Expressions 3.1 Using session values 3.2 Dynamic expressions types 3.2.1 Constant 3.2.2 SQL 3.2.3 WhereClause 3.2.4 Checks 4 Dynamic Expressions used in Application Dictionary objects

Introduction

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.

Types

Session global variables

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

Columns

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

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.

Definition

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

• Property. (Property List checked). The preference can be taken from a fixed list. It is a list reference named Property Configuration. Modules can add new items to this list with the purpose that other modules can set values to them.
• Attribute. (Property List unchecked). The preference is defined by the Attribute field, which is a free text input box.

Visibility

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:

• Client. Defines the client, if it is empty or System the preference will be visible from any client.
• Organization. Defines the visibility from the organization that has been logged in the session. Note that the organization is not the document organization but the one used during the login. So if a role has access to organization A and B, both organization has a value for the same preference and the user logs in the application with that role and organization A, the value defined for that organization will be used, even when creating a document (for example an invoice) in organization B. If it is empty or * it will be visible from all the organizations. Visibility for organizations is calculated taking into account organization tree; this is, if the organization tree looks like A with a child organization A1, preferences defined for A will be visible from A and A1 in case A1 has not a value for them.
• User and Role. Which is the user/role that will be able to use the preference.
• Window. From which window the preference will be visible.

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.

Conflicts

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.

Modularity

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.

Accessibility

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:

Constant

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.

Examples:

1

@#AD_User_ID@

SQL

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

Example:

@SQL=SELECT DOCSUBTYPESO 
       FROM C_DOCTYPE 
      WHERE C_DOCTYPE_ID = @C_DOCTYPETARGET_ID@

WhereClause

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

Checks

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

Its syntax is Javascript but the comparators are:

• = instead of ==
• ! instead of !=
• & instead of &&
• | instead of ||

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

Category: Concepts