Context and domain

We have stumbled on context and domain several times. We have also seen that window actions are able to set values on them, and that relational fields can also use them in their attributes. Both concepts are useful to provide richer user interfaces. Let's see how.

Session context

The context is a dictionary carrying session data to be used by client-side views and by server processes. It can transport information from one view to another, or to the server-side logic. It is frequently used in window actions and relational fields to send information to the views opened through them.

Odoo sets some basic information about the current session on the context. The initial session information can look like this:

{'lang': 'en_US', 'tz': 'Europe/Brussels', 'uid': 1}

We have information on the current user ID and the language and time zone preferences for the user session.

When using an action on the client, such as clicking on a button, information about the currently selected records is added to the context:

  • the active_id key is the ID of the selected record on a form,
  • the active_model key is the model of the current record,
  • the active_ids key is the list of IDs selected in the tree/list view.

The context can also be used to provide default values on fields or to enable filters on the target view. To set on the user_id field a default value corresponding to the session's current user we would use:

{'default_user_id': uid}

And if the target view has a filter named filter_my_tasks, we can enable it using:

{'search_default_filter_my_tasks': True}

Domain expressions

Domains are used to filter data records. Odoo parses them to produce the SQL WHERE expressions that are used to query the database.

When used on a window action to open a view, domain sets a filter on the records that will be available in that view. For example, to limit to only the current user's Tasks:

domain=[('user_id', '=', uid)]

The uid value used here is provided by the session context.

When used on a relation field, it will limit the selection options available for that field. The domain filter can also use values from other fields on the view. With this we can have different selection options available depending on what was selected on another field. For example, a contact person field can be made to show only the persons for the company that was selected on a previous field.

A domain is a list of conditions, where each condition is a ('field', 'operator', value) tuple.

The left-hand field is where the filter will be applied to, and can use dot-notation on relation fields.

The operators that can be used are:

  • The usual comparison operators: <, >, <=, >=, =, and != are available.
  • =like to match against the value pattern where the underscore symbol matches any single character, and % matches any sequence of characters.
  • like for case-sensitive match against the '%value%' SQL pattern, and ilike for a case insensitive match. The not like and not ilike operators do the inverse operation.
  • child_of finds the direct and indirect children, if parent/child relations are configured in the target model.
  • in and not in check for inclusion in a list. In this case, the right-hand value should be a Python list. These are the only operators that can be used with list values. A curious special case is when the left-hand is a to-many field: here the in operator performs a contains operation.

The right-hand value can be a constant or a Python expression to be evaluated. What can be used in these expressions depends on the evaluation context available (not to be confused with the session context, discussed in the previous section). There are two possible evaluation contexts for domains: client side or server side.

For field domains and window actions, the evaluation is made client-side. The evaluation context here includes the fields available in the current view, and dot-notation is not available. The session context values, such as uid and active_id, can also be used. The datetime and time Python modules are available to use in date and time operations, and also a context_today() function returning the client current date.

Domains used in security record rules and in server Python code are evaluated on the server side. The evaluation context has the fields of the current record available, and dot-notation is allowed. Also available is the current session's user record. Using user.id here is the equivalent to using uid in the client side evaluation context.

The domain conditions can be combined using the logical operators: '&' for "AND" (the default), '|' for "OR", and '!' for "negation."

The negation is used before the condition to negate. For example, to find all tasks not belonging to the current user: ['!', ('user_id', '=', uid)]

The "AND" and "OR" operate on the next two conditions. For example: to filter tasks for the current user or without a responsible user:

['|', ('user_id', '=', uid), ('user_id', '=', False)]

A more complex example, used in server-side record rules:

['|', ('message_follower_ids', 'in', [user.partner_id.id]),
      '|', ('user_id', '=', user.id),
           ('user_id', '=', False)]

This domain filters all records where the followers (a many to many relation field) contain the current user plus the result of the next condition. The next condition is again the union of two other conditions: the records where the user_id is the current session user or it is not set.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset