summaryrefslogtreecommitdiff
path: root/odoo/addons/test_testing_utilities/models.py
AgeCommit message (Collapse)Author
2020-10-14[FIX] core: add UPDATE as valid many2many command in SSFXavier ALT
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 closes odoo/odoo#59937 X-original-commit: 76bd8208a416cefab6becff9f2d7204c7d196201 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com> Signed-off-by: Xavier ALT <xavieralt@users.noreply.github.com>
2020-07-20[FIX] core: fix handling of removals in sub-o2mXavier Morel
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
2020-01-13[FIX] core: saving of o2m value init'd via onchangeXavier Morel
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 closes odoo/odoo#43235 X-original-commit: 6c99fe3ffec3aeb8d210e3b943ccef81d62d44ce Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
2019-10-28[FIX] SSF: modifier based on m2m valueXavier Morel
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). closes odoo/odoo#39467 X-original-commit: 927979beff9e5d4f6c88078862779eaa88f4e07d Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
2019-07-10[FIX] tests: allow False as value for required booleans in SSFAdrian Torres
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. closes odoo/odoo#34729 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
2019-04-03[FIX] core: don't send readonly fields in o2m in SSFXavier Morel
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
2019-04-03[FIX] core: infinite recursion in SSF on self-recursive modelsXavier Morel
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
2019-04-01[FIX] core: backport changes in 12.1/master to 12.0Xavier Morel
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...
2019-02-26[FIX] core: handling of o2m record deletion in SSFXavier Morel
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. closes odoo/odoo#31431
2019-02-15[FIX] core: various issues & deviations from client's behaviour in FormXavier Morel
* 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. closes odoo/odoo#31064
2019-01-22[IMP] core: add force_save support to server-side formXavier Morel
Cf 3b3f6f04af79d7dcc4461262e14e05096d76180b for basic feature description. Task 1931580 closes odoo/odoo#30428
2018-09-21[IMP]various: Improvement in model descriptionNimesh Jethva
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
2018-04-03[FIX] testing utilities: o2m should not strip readonly fieldsLaurent Smet
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
2017-12-04[ADD] base: server-side formviewXavier Morel
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