How it works...

The context dictionary is populated from several sources. First, some values from the current user's record (lang and tz, for the user's language and the user's timezone) are read; then, there are addons that add keys for their own purposes. Further, the UI adds keys about which model and which record we're busy with at the moment (active_id, active_ids, active_model). Also, as seen earlier, we can add our own keys in actions. Those are merged together and passed to the underlying server functions, and also to the client-side UI.

So, by setting the lang context key, we force the display language to be French. You will note that this doesn't change the whole UI language, which is because only the list view that we open lies within the scope of this context. The rest of the UI was loaded already with another context that contained the user's original language. However, if you open a record in this list view, it will be presented in French too, and if you open some linked record on the form or press a button that executes an action, the language will be propagated too.

By setting default_lang, we set a default value for every record created within the scope of this context. The general pattern is default_$fieldname: my_default_value, which enables you to set default values for partners newly created in this case. Given that our menu is about customers, it might have made sense to also set default_customer: True to have the Customer field checked by default. However, this is a model-wide default for res.partner anyway, so this wouldn't have changed anything. For scalar fields, the syntax for this is as you would write it in Python code—string fields go in quotes, numbers just like that, and Boolean fields are either True or False. For relational fields, the syntax is slightly more complicated; refer to Chapter 7, Module Data, for how to write those. Note that the default values set in the context override the default values set in the model definition, so you can have different default values in different situations.

The last key is active_test, which has very special semantics. For every model that has a field called active, Odoo automatically filters out records where this field is False. This is why the partner where you unchecked this field disappeared from the list. By setting this key, we can suppress this behavior.

This is useful for the UI in its own right, but even more useful in your Python code when you need to ensure that some operation is applied to all the records, not just the active ones.
..................Content has been hidden....................

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