The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This commit description is in three parts: a generic explanation, a real
use case and the solutions
**Explanations**
1. When getting an odoo `Environment`, we first generate a tuple used as
an environment identifier:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L446
Then, there are two possibilities:
1. If such environment already exists in the environments list of the
transaction, we reuse it:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L448-L452
2. Else, we create a new one and store it in the transaction:
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L454-L464
2. The `company` attribute of an `Environment` object is a lazy property
https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L537-L538
It means that its value won't be recomputed unless we delete it
https://github.com/odoo/odoo/blob/083c70bbb63f27839b2c9a4b549e216947bc4dd1/odoo/tools/func.py#L12-L17
3. When running a `SavepointCase` test class, the `setUp` method ensures
that, after each test, we do cleaning:
https://github.com/odoo/odoo/blob/a50a65be19b682201fc010d33c1b1f0b90cdf4d3/odoo/tests/common.py#L652-L662
The functions are added in a stack. So, in the execution order, we
will
1. Clear the current environment and the registry
2. Reset the environments list with the ones that were existing
before the executed test
4. Suppose a test class TC that inherits `SavepointCase`. TC has a
special `setUpClass`:
1. We create a new user U and replace the environment with a new one,
E1, based on U. This user has a company Comp_U. Because of [1], the new
environment E1 is added to the environments list of the transaction.
2. For some reasons, we need to do some operations in `sudo` mode:
again, because of [1], a new environment E2 (same as E1 but with the
`su` flag to `True`) is created and added to the environments list of
the transaction
5. TC contains a first test T1. In that test, we create a company
Comp_tmp and set it as default one to U. Therefore, E1 and E2 are
updated (their `company` attribute is now Comp_tmp)
6. At the end of T1, because of [3]:
1. E1 is reset (but its lazy properties are not deleted)
2. The environments list of the transaction is reset and still
contains E1 and E2 as they have been created in the class setup (i.e.
before the test setup)
7. In a second test T2, there will be an inconsistency: both E1 and E2
have an incorrect value for their field `company`: Comp_tmp, which is
not the value defined on `self.env.user.company_id` (the value Comp_tmp
does not even exist anymore)
**Real use case**
- The class `AccountTestInvoicingCommon` is an inheritance of
`SavepointCase`. In its class setup, we create a user and set it on the
current environment. Later on, we create a company (the sudo mode will
be activated during the company creation process)
https://github.com/odoo/odoo/blob/1e69c4fe5f8dd8a92d92f350b6d6a9539157f206/addons/account/tests/common.py#L38-L52
- The class `TestPurchaseOrder` inherits `AccountTestInvoicingCommon`
- The test `:TestPurchaseOrder.test_06_on_time_rate` creates a company
and sets it as the one of the current user
https://github.com/odoo/odoo/blob/87ffe5983be7f0f4a926b458c4bd1f13001048ec/addons/purchase_stock/tests/test_purchase_order.py#L313-L316
- Therefore, all next tests will have an issue with the environment
(unless we force the writing of the company on the current user to
bypass the issue)
```py
self.assertEqual(self.env.user.company_id, self.env.company) # will fail
self.assertTrue(self.env.company.exists()) # will fail
```
**Solution**
The above issue has been fixed from Odoo 15 on, thanks to commit C1.
Thanks to that diff, at step [3.1] in the above explanations, the lazy
properties of E1 are deleted (so, because of [2], the `company`
attribute of E1 will be correct again). However, once C1 is applied, we
can still add some lines in T2 to fail the test:
```py
sudo_env = self.env.user.sudo().env
self.assertEqual(self.env.user.company_id, sudo_env.company) # will fail
self.assertTrue(sudo_env.company.exists()) # will fail
```
The reason: at the end of the test T1, we reset the environments list of
the transaction ([6.2]). However, E2 has been created before the test
setup (it was in the class setup, see [4.2]). So, after the list reset,
E2 is still in that list and still has the value Comp_tmp for its
`company` attribute.
So... first we can conclude that C1 is not enough. Second, once the
environments list of the transaction is reset ([3.2]), we also have to
reset each environment to ensure that their lazy properties are correct.
We can then remove [3.1] since it will be included in that new step.
C1 a40511cd29closesodoo/odoo#106952
X-original-commit: a685f17ec9b0663d3632c903f4f0304d9a58f103
Signed-off-by: Raphael Collet <rco@odoo.com>
Steps to reproduce:
- install sale_management module;
- go to settings of sale_management and check "Automatic invoice" parameter;
- in debug mode, we can see the template selected (do not change it);
- save the settings;
(This is just one example)
Issue:
The parameter is not added to the "ir_config_parameter" table.
Cause:
The improvement which consists in comparing the settings which one wishes to record with those which already exist in order to set the parameters which are different creates a problem.
Indeed, the current settings are retrieved directly from the model with their default value if there is one.
These are the values that will be used for the comparison.
Because of this, when we want to save a parameter which is set to its default value (on first save), the logic will not notice a difference.
Therefore, the parameter will not be saved in the "ir_config_parameter" table.
Consequence:
In the code, when we wanted to look up the value of a parameter, if it is not saved, we use its default value instead of saving it with its default value.
Example:
```
field_example = fields.Integer(string='Example', default=1000, config_parameter='model.field_example')
value_field_example = params.get_param('model.field_example', default=1000)
```
The default value is repeated.
Solution:
To know whether or not we add a new parameter in the "ir_config_parameter" table, we must look at what already exists in the table and not in the settings defined in the model.
opw-3057306
closesodoo/odoo#106188
X-original-commit: d881dfaaa163b409a94494e35afa2cbda7cf2aa2
Related: odoo/enterprise#34258
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Intended to cleanup qweb xmls:
- remove blank (empty) nodes and/or nodes with whitespace text
- fix indentation
- remove indentation (needed for some xml signatures)
closesodoo/odoo#91006
X-original-commit: b7d7adb4f5a9873350511c227d5fbf54c8f38ce8
Signed-off-by: William André (wan) <wan@odoo.com>
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
Because the `savepoint` and `clear` calls are nested inside the
`assertRaises` context, if one of them happens to throw *the exception
we're looking for* the interpreter will jump back to the `with`, the
`assertRaises` will swallow the exception (and count it as a success)
and the function will end having not gone through a `yield`.
This is rather frustrating to debug as it's easy to forget that a
`with` is a control flow structure, leading to a seemingly impossible
error.
We can fix this by initializing and `__enter__`-ing the savepoint
first, but doing this by hand is a bit iffy and not really
future-proof as the addition of more fallible steps during the
initialization phase of `_assertRaises` could lead to the savepoint
not being properly disposed of. Furthermore once in the scope of the
"actual" assertRaises we want the savepoint to unwind first (otherwise
the savepoint won't be rolled back when the exception *we are
expecting* gets raised).
As it turns out `ExitStack` offers the solution to our woes though
it's a bit tricky at first glance: while modifying the cleanup queue
in-place is haram, `pop_all` allows moving cleanup callbacks from one
queue to the next.
This means we can first add the savepoint to one stack and get its
errors (if any) correctly reported, cover the rest of the
initialization, then move the savepoint from one stack to an other, in
order to correctly order the coverage of the `yield` (and the userland
code).
closesodoo/odoo#87733
X-original-commit: b1cd4e4e3c918b4b08d27b30b1017fc898d4b08a
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit fix the "Unsupported M2M command 1" raised `Form` helper.
The `onchange()` method will in fact emit UPDATE command for many2many
fields when the value submitted an the one in database has changed
(this is the case for example for nested m2m in form views)
OPW-2044631
closesodoo/odoo#59943
X-original-commit: 76bd8208a416cefab6becff9f2d7204c7d196201
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Xavier ALT <xavieralt@users.noreply.github.com>
The Form class already handles cases for attrs that contain boolean
values, e.g.:
`attrs="{'readonly': True}"`
But it doesnt for integers, e.g.:
`attrs="{'readonly': 1}"`
This commit changes the expected non-domain value from boolean to
integer, because both are valid cases and the former is a subset of the
latter.
[1] https://github.com/odoo/odoo/blob/b3d4938ba6b1/addons/repair/views/repair_views.xml#L54closesodoo/odoo#56612
X-original-commit: 782534a429f10e7b114c838687d38aa4080a920c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Luis González [Vauxoo] <luisg123v@users.noreply.github.com>
When creating a new record, the client calls `default_get()`, completes
the returned values with `False`, and calls `onchange()` to apply the
onchange to the defaults.
Optimize the double round-trip by integrating `default_get()` inside
`onchange()` for the first call. The method is called with an empty
list of fields, and usually no field values, except for records in a
one2many field. In this case, `onchange()` does both steps above.
Task 2261084
Issue is specifically in the case of an onchange removing a record in
an o2m in an o2m (so a sub-o2m) if loading an *existing* record in the
SSF: since the server pretty much only returns a REMOVE_ALL followed
by the records to keep or create, conserving the removal information
requires diffing the value currently stored in the form and the result
fo the onchange.
Diff which was properly done for top-level o2ms, but not for the ones
below that (apparently forgot this bit when improving support for
nested o2ms earlier this year).
X-original-commit: 177d009541cca589c6ebb85fc051b893ec001536
Search the xsd files from in the database.
To enable this option, the Environment should be passed to the optional
`env` parameter. Both the XSD root and the XSD imported by the root and
the recusrively imported files will be searched in the database.
X-original-commit: 06a35f2e11230db81b8c21696d228097b31cf649
The SSF had pretty much punted on nested o2m as that's... not usually
a concern because few people are insane enough to put o2ms in their
o2ms in their views. And also because even if somebody did, sometimes
nothing would break because it turns out to be pretty difficult to
actually get into *using* those things.
MRP managed to do it though, and repro-ing required copying over parts
of mrp.production and then understanding why it didn't fail:
* obviously needs an o2m (f1) which contains an o2m (f2), in the
view (an invisible tree inside a visible tree)
* needs an onchange which somehow updates the sub-o2m
* needs to actually trigger an onchange on the root form for f1,
meaning f1 must be a dependency of a compute field or something (here
I just marked every damn field as on_change as the optimisation of
"don't call onchange when there's no need to" doesn't matter)
Also needs to be working on an existing record with existing
lines *and sublines* as the issue occurs with records to update.
The issue here is that `_onchange_values` would clean up f1 e.g. send
nothing for unmodified entries, and only send modified fields
otherwise, but it would only do so for the toplevel, meaning the
sub-level would not go through this step, and could send UPDATE
commands with an `id` field (set to the original value but
still). This would then proceed to blow up while loading the record,
as id fields are not writeable.
The fix is to perform `_onchange_values` recursively. Do that using a
separate helper in order to avoid blowing up on override and whatnot,
or faffling about with weird branching to get the "default" values in
case they're not provided, the root function can get all the relevant
bits and call the helper with them, then the helper does that setup
internally and calls itself directly.
An other issue I stumbled upon when investigating is a similar problem
on *save*, due to an implementation detail of the SSF: UPDATE commands
are fetched lazily.
`_values_to_save` took care of "hydrating" all update commands (and
validating and filtering them) of modified o2m fields, but as it would
not do so recursively a modified f2 would not get properly hydrated
and filtered, and could try to write `None` onto existing records.
closesodoo/odoo#51350
X-original-commit: 3dfb4cfad849936748cc6a5b8f712e100461a86f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In the SSF, o2m updates get initialized with no values (1, id,
{}). The record data is only fetched when the "record" gets updated
explicitly from which updates will hopefully get properly tracked &
saved.
However if the "record" was first initialized through an onchange
values which are updated by the onchange (diverging from the db) those
would not get tracked and thus wouldn't get saved when the record is
saved.
* use more specific placeholder (None) for "o2m records to update but
we don't have values yet"
* once we have values, always store them as an update-tracking dict
* if we don't have values yet for an o2m and an onchange is trying to
write to it, initialize with values from database first (might
eventually be a good idea to initialize upfront though there's the
question of what happens for default values and recursive views)
* mark anything coming back from the onchange and differing from local
values as changed (so they get sent out on save)
* properly reify parent values for onchange instead of sending them
as-is
* the evaluation context for contexts (and domains) needs properly
formatted values so use `_values_to_save` to get them, however it
cares about neither required-ing nor filtering out e.g. unmodified
fields, therefore add an awful toggle to handle this
Task 2150302
Probably todo in the future:
* better UI for change-tracking dict, should have "snapshot"
support (to freeze / discard previous changes)
* cleanup save, it's unclear that it properly resets the form
closesodoo/odoo#43235
X-original-commit: 6c99fe3ffec3aeb8d210e3b943ccef81d62d44ce
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
m2ms are internally represented as "6" commands, however in domains
it's possible to compare an m2m value to a list of ids (to
investigate: whether this is an artifact of internal webclient repr or
part of the real contract).
Add a workaround in SSF modifier computation to convert the m2m
command storage to a simple ids list.
A better fix would probably have been to represent the m2m as a list
of ids internally (and only convert on load / save) however it not
completely trivial as it has to be done recursively in order to
properly handle an m2m inside an o2m. So it's a complete change of the
internal data model (which should probably go alongide more
fundamental changes e.g. properly handling parent refs, etc...)
Also add very minor support for widgets (mostly so it's possible to
set widget=many2many on an o2m field).
closesodoo/odoo#39467
X-original-commit: 927979beff9e5d4f6c88078862779eaa88f4e07d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Because the sub-record values would not necessarily get fetched
ever (whether default or stored), the computation of modifiers might
blow up if it relied on one of the un-fetched un-specified fields.
One such situation is trying to create a partner with child partners
if base_address_city is installed: the module adds a readonly attr
predicated upon the parent_id, without explicitly providing such the
field would be missing from the O2M record's values.
Closes#37176closesodoo/odoo#37452
X-original-commit: 184d1b69eac2b78c72228c81c5c6cf8cc4a56eb4
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
A required boolean accepts two values, True and False, however the SSF
and the web-client assume False to be equal to NULL and treat them
interchangeably.
In the SSF, we verify that a required field is filled by checking that
its value is different from False, however False is a valid value for a
boolean, this means that setting a required boolean to False would never
work in the SSF.
This commit overcomes this issue by simply skipping the check for fields
of type boolean.
closesodoo/odoo#34729
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The SSF would correctly filter out readonly fields when saving a
toplevel form, however it could not remove readonly values when saving
o2m pseudo-records to the parent form (as these would be expected to
remain available for reading upon the next edition and whatnot), so
these values would get sent in 0/1 commands.
Filter out these fields during the parent / toplevel save call.
Complexity notes:
* evaluating readonly modifiers requires the entire record, so
unchanged fields still have to be written back to the parent form
and be filtered out when *it* is set up for save, an alternative
would be to store the `changed` and `readonly` flags alongside the
record dict, and have the post-process only override the
pre-computed readonly flag using force_save
* had to fix a test to match the new behaviour, the post-edition
states turns out to be in line with the client's behaviour (or how
it looks anyway)
Fixes#32019
The extra setup probably affects any o2m whose edition view itself
contains an o2m, but most likely to blow up entirely on models with
some sort of tree structure (parent/child relationship): the SSF
eagerly loads and setups the o2m's view, and the o2m's o2m's, ... ad
infinitam.
A better / cleaner fix would be to set up the subview on-demand (and
possibly cache it), but the rest of the o2m stuff is unlikely to work
correctly recursively so just don't recurse the o2m view setup at all
for now.
fixes#31458
PRs #28645 and #31494 were not applied to 12.0, but there's no reason
not to, they should only fix things (make behaviours more in-line with
the regular client), and since o2m is an area where more fixes are
needed and it would be nice to have them in 12.0...
This widget was exactly the same as a `one2many` and was kept for backward
compatibility reasons. It can be safely removed in master.
Related to task 1918327
The SSF would properly mark its own records as deleted, but it would
not properly handle deletion requests coming from an onchange, and it
would not necessarily convert DELETE_ALL commands (5) into the proper
sequence of individual (2)s matching existing records.
closesodoo/odoo#31431
* Form would entirely mis-interpret the server's response to some
results: for unmodified o2m records the server sends a (4), which was
un-interpreted by Form, leading to the o2m record being lost entirely
(as it rebuilds the entire o2m on setting)
* on record creation, every field (except id) is considered modified not
just the fields set by default_get
* Form diverged from actual client in that it would send (1, id, {}) for
unmodified o2m records, actual client sends (4, id, False)
* datetimes should be sent stringified
* onchange should not be triggered when none of the modified fields is
flagged as an onchange trigger
* the default value for numerical fields is 0 not False
* convert m2m onchange results to (6, False, ids) instead of (6, 0, ids)
for ease of diffing with actual client's data
There are still a few odd divergences in the actual invocation of
onchange when attempted on an SO, but they look to be of low relevance
/ risk.
Note: making integer fields "required" has pretty much no effect
anymore. This is in line with (my understanding of) the client's
behaviour, but required the alteration of test models as the
specific test on required... was using an integer field.
closesodoo/odoo#31064
The feature was not tested, and as it turns out completely broken:
* the non-raw string means the "backrefs" were really interpreted as
octal literals
* the second backref was entirely wrong
Also add all loaded views to the field descriptor in case we might
have a use for it (and because inline sub-views are always stored on
the descriptor).
closesodoo/odoo#28194
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
In the normal course of saving-action, readonly fields are stripped
out when sending data to the server. The SSF would reuse the same code
when "saving" O2M lines to the parent record however that is not
correct and would lead to misbehaving views as readonly (non-stored)
fields used as "transients" (storing data within the extent of a
record's edition session) would not behave properly.
Fix by overriding the O2M Form's save so that readonly fields are
kept and stored in the parent record.
Closes#23620
Useful to better test business flows & replace yaml test files:
instantiating records & calling onchanges by hand is very
error-prone (it's easy to miss onchanges, or to manually set fields
which can't be set through the view we're interested in, ...)
odoo.tests.common.Form implements the basic *creation*
flow (fields_get, default_get, onchange) up to saving the record,
including proper handling of the required and readonly modifiers &
their domains.
* edition of existing records, including filtering out unmodified
fields when saving
* possibly buttons
* ensuring the API is convenient
Raphael Collet