summaryrefslogtreecommitdiff
path: root/odoo/addons/test_testing_utilities/menu.xml
AgeCommit message (Collapse)Author
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-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-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
2018-02-01[FIX] base: correctly handle non-normalised domains in SSFxmo-odoo
Turns out I'd kinda skipped that bit. Fixes #22711
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