The simplest form of a domain is a list of 3-tuples that contain a field name of the model in question as string in the first element, an operator as string in the second element, and the value the field is to be checked against as the third element. This is what we did in the first action, and this is interpreted as "All those conditions have to apply to the records we're interested in." This is actually a shortcut, because the domains know the two prefix operators—& and |—where & is the default. So, in normalized form, the first domain will be written as:

['&', '&', ('customer', '=', True), ('user_id', '=', uid),
           ('lang', '!=', 'fr_FR')].

While a bit hard to read for bigger expressions, the advantage of prefix operators is that their scope is rigidly defined, which saves you from having to worry about operator precedence and brackets. It's always two expressions: the first & applies to '&', ('customer', '=', True), ('user_id', '=', uid) as the first operand and ('lang', '!=', 'fr_FR') as the second. Then, the second & applies to ('customer', '=', True) as the first operand and ('user_id', '=', uid) as the second.

In the second action, we have to write out the full form because we need the | operator.

There is also a ! operator for negation, but, given logical equivalences and negated comparison operators such as != and not in, it is not really necessary. Note that this is a unary prefix operator, so it only applies to the following expression in the domain and not to everything that follows.

Note that the right operand doesn't need to be a fixed value when you write a domain for a window action or other client-side domains. You can use the same minimal Python as described earlier for contexts, so you can write filters such as changed last week, my partners, and more.