Saturday, February 8, 2025
4 changes · saas-17.2
Miscellaneous changes
In [1] the `params` section was refactored, but removing the `]` was missed. This caused an error, always returning "No encontrado". [1] https://github.com/odoo/enterprise/commit/14c1b2f8b36ade09be021d2ae202da19f88c0b78 Forward-Port-Of: odoo/enterprise#78891
Original PR description
In [1] the `params` section was refactored, but removing the `]` was missed. This caused an error, always returning "No encontrado". [1] https://github.com/odoo/enterprise/commit/14c1b2f8b36ade09be021d2ae202da19f88c0b78 Forward-Port-Of: odoo/enterprise#78891
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view. This request actually reach the server even if Chrome is already closed and the test is cleaning itself (rollbacking the changes made in the database), resulting into a "release savepoint" mismatch on an already aborted transaction (example build's error [1]). This commit is kind of
Original PR description
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view. This request actually reach the server even if Chrome is already closed and the test is cleaning itself (rollbacking the changes made in the database), resulting into a "release savepoint" mismatch on an already aborted transaction (example build's error [1]). This commit is kind of a follow-up of a previous PR [2] where a last step allowing for the spreadsheet to unload was added and adding one more to actually wait to be back on the Document app. [1] https://runbot.odoo.com/runbot/build/74602509 [2] https://github.com/odoo/enterprise/pull/51795 Forward-Port-Of: odoo/enterprise#78797
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view (cf. save). This request actually reach the server even if Chrome is already closed and results into a SQl constraint error. Indeed, the (very basic) form views created for those tours are based on the "res.partner" model and only display the "name" field. This field isn't marked as "
Original PR description
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view (cf. save). This request actually reach the server even if Chrome is already closed and results into a SQl constraint error. Indeed, the (very basic) form views created for those tours are based on the "res.partner" model and only display the "name" field. This field isn't marked as "required" neither in the model, nor the view BUT has a SQL constraint attached to it... which makes it implicitly "required". This commit fixes it by properly marking them as such in the arch to let the client-side validation prevent the ultimate "save" request made during the unload. Forward-Port-Of: odoo/enterprise#78810
Versions -------- - 16.0+ Steps ----- 1. Enable Stripe Express Checkout; 2. go to eCommerce as Public User; 3. pay via express checkout for a deliverable item; 4. in Stripe, set shipping address to somewhere in California; 5. finish payment. Issue ----- The new partner is created with its state set to Cadiz instead of California. Cause ----- When searching for a state using its code, it fetches the first matching item. The problem is that unlike country codes, state codes ar
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Stripe Express Checkout; 2. go to eCommerce as Public User; 3. pay via express checkout for a deliverable item; 4. in Stripe, set shipping address to somewhere in California; 5. finish payment. Issue ----- The new partner is created with its state set to Cadiz instead of California. Cause ----- When searching for a state using its code, it fetches the first matching item. The problem is that unlike country codes, state codes aren't unique, e.g. there are 4 states that match the 'CA' code (only one of them being in the United States). Solution -------- Add `country_id` to the search domain to ensure the fetched state belongs to the relevant country. opw-4396024 Forward-Port-Of: odoo/odoo#196763 Forward-Port-Of: odoo/odoo#196428