The context is dictionary carrying session data that can be used on both the client-side user interface and the server-side ORM and business logic.
On the client side, it can carry information from one view to the next, such as the ID of the record active on the previous view, after following a link or a button, or it can provide default values to be used in the next view.
On the server side, some recordset field values can depend on the locale settings provided by the context. In particular, the lang key affects the value of translatable fields. Context can also provide signals for server-side code.
For example, the active_test key, when set to False, changes the behavior of the ORM's search() method, ignoring the active flag on records, so that the inactive (soft deleted) records are also returned.
An initial context from the web client looks like this:
{'lang': 'en_US', 'tz': 'Europe/Brussels', 'uid': 2}
You can see the lang key with the user language, tz, the time zone information, and uid with the current user ID.
The content in records might be different depending on the current context:
- translated fields can have different values depending on the active lang language
- datetime fields can show different times depending on the active tz timezone
When opening a form from a link or a button in a previous view, an active_id key is added to the context, with the ID of the record we were positioned at, in the origin form. In the particular case of list views, we have an active_ids context key containing a list of the record IDs selected in the previous list.
On the client side, the context can be used to set default values or activate default filters on the target view, using keys with the default_ or default_search_ prefixes.
Here are some examples:
- To set the current user as a default value of the user_id field, we use {'default_user_id': uid}
- To have a filter_my_books filter activated by default on the target view, we use {'default_search_filter_my_tasks': 1}