Thursday, December 14, 2023
18 changes · 17.0
Resolved issues and error corrections
Automated actions now skip read-only fields when choosing a default field to update. This prevents errors when users create actions on records such as stock move lines, making setup more reliable.
Original PR description
Before this commit, the default update_path even if the field was readonly, it weas returned. So, if you try to create an automated action on the stock.move.line model and try to add an action, the button return a traceback because the field is readonly. After this commit, the method that get the default update_path will also check if the field is not readonly. Bugfix Task-Id: 3624328 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The self-ordering settings no longer include an empty option in the mode selector. This prevents an unnecessary validation error when saving settings and makes configuration clearer for users.
Original PR description
In this pr we remove the blank choice in the self-ordering mode select. It's unnecessary and throws a validation error on saving settings. Task 3599144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change updates automated tests across several Odoo apps so they no longer depend on optional demo data being present. This helps make quality checks more consistent and reduces false failures during development and release validation.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Editing supplier information views in Studio from a product form no longer triggers an error. The product filtering logic was adjusted so the setup is simpler and works reliably in that editing context.
Original PR description
How to reprodruce: 1) Go to product.template view form 2) Open Studio 3) Go to tab 'Purchase' tab 4) Edit list/form view of the seller_ids (supplierinfo) Before this commit, the domain on product_id of supplierinfo was using 'parent' as if already doing the filter on the view. Because of the complex domain in the string, a traceback was throw when editing supplierinfo view with studio on the product.template. After this commit, the domain on the python side is simpler. The domain for the view has been changed to not be dependent of the parent view, but of the context. Bugfix Task-ID: 3615851 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a warning that was appearing at the end of the Field Service tour due to the final step being skipped. The fix ensures the last step is properly executed by adding a trigger attribute, improving the tour experience and eliminating error messages for users.
Original PR description
Before this commit, a warning is raised at the end of `industry_fsm_tour` tour because it ignores the last step because it is auto action. This commit adds `run` attribute in the last to trigger click event to avoid considering the last step has `auto`. runbot-24582 Forward-Port-Of: odoo/enterprise#51610
Documentation and clarification updates
This pull request adds an individual Contributor License Agreement signature record. It helps keep contribution records complete and supports the project's legal compliance process.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
When the pos was loading only a part of the products, the request should follow those rules order: - product is a favorite - product is a service - product had stock moves soon - product update But this request didn't take into account consumables products and if there was no stock move, the value was null and postgres consider null values first when ordering desc. Now with that changes, the order is correctly set based on the rules above. --- I confirm I have signed the CLA and read
Original PR description
When the pos was loading only a part of the products, the request should follow those rules order: - product is a favorite - product is a service - product had stock moves soon - product update But this request didn't take into account consumables products and if there was no stock move, the value was null and postgres consider null values first when ordering desc. Now with that changes, the order is correctly set based on the rules above. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#129227 Forward-Port-Of: odoo/odoo#124223
Currently, if you switch to a right-to-left language and open the POS, the numpad will look like this: 3 2 1 6 5 4 9 8 7 The numpad should stay the same even in RTL languages: 1 2 3 4 5 6 7 8 9 opw-3623228 Forward-Port-Of: odoo/odoo#145886
Original PR description
Currently, if you switch to a right-to-left language and open the POS, the numpad will look like this: 3 2 1 6 5 4 9 8 7 The numpad should stay the same even in RTL languages: 1 2 3 4 5 6 7 8 9 opw-3623228 Forward-Port-Of: odoo/odoo#145886
Issue: Invoice move lines' quantities reset to 1 on the second page when the customer is changed after pagination. Steps to Reproduce: 1. Create an invoice with over 40 move lines (requiring pagination). 2. Navigate to the second page of move lines and observe quantities. 3. Change the Partner (e.g., Azure -> My Company). 4. Save changes. 5. Notice that quantities on the second page are reset to 1. Solution: Identified the issue as stemming from the `flush_model` method, which is ca
Original PR description
Issue: Invoice move lines' quantities reset to 1 on the second page when the customer is changed after pagination. Steps to Reproduce: 1. Create an invoice with over 40 move lines (requiring…
Issue: Invoice move lines' quantities reset to 1 on the second page when the customer is changed after pagination. Steps to Reproduce: 1. Create an invoice with over 40 move lines (requiring pagination). 2. Navigate to the second page of move lines and observe quantities. 3. Change the Partner (e.g., Azure -> My Company). 4. Save changes. 5. Notice that quantities on the second page are reset to 1. Solution: Identified the issue as stemming from the `flush_model` method, which is called on creation and triggers re-computation. This process calls the `compute` method for the quantity field, leading to an erroneous reset of quantities to 1. Modified the compute method to only reset values to 1 if they are initially 0 or False, thereby resolving the issue of unwanted quantity reset during pagination when customer details are updated. opw-3483851 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143812
Previously, when updating and re-sending a snailmail through the chatter, it would re-send every snailmail letters with an error status in the DB. This behavior lead to users mistakenly sending dozens of unwanted snailmails, expecting to be re-sending the one they were currently on. This commit fixes that by only sending the relevant letter(s). Forward-Port-Of: odoo/odoo#145988
Original PR description
Previously, when updating and re-sending a snailmail through the chatter, it would re-send every snailmail letters with an error status in the DB. This behavior lead to users mistakenly sending dozens of unwanted snailmails, expecting to be re-sending the one they were currently on. This commit fixes that by only sending the relevant letter(s). Forward-Port-Of: odoo/odoo#145988
This commit correctly aligns certain header elements when the CTA button has a larger vertical padding. Steps to reproduce the issue: - Install 'eCommerce' on your website. - In Website edit mode, click on the 'THEME' tab. - Adjust the vertical padding of buttons to 25px. - Click on the header in the page. - In the 'STYLE' tab, select the 'Menu - Sales 1' header. - Bug: The 'logo" and the 'menu items' are not aligned with the CTA button. - In the 'STYLE' tab, select the 'Menu - Sales
Original PR description
This commit correctly aligns certain header elements when the CTA button has a larger vertical padding. Steps to reproduce the issue: - Install 'eCommerce' on your website. - In Website edit mode,…
This commit correctly aligns certain header elements when the CTA button has a larger vertical padding. Steps to reproduce the issue: - Install 'eCommerce' on your website. - In Website edit mode, click on the 'THEME' tab. - Adjust the vertical padding of buttons to 25px. - Click on the header in the page. - In the 'STYLE' tab, select the 'Menu - Sales 1' header. - Bug: The 'logo" and the 'menu items' are not aligned with the CTA button. - In the 'STYLE' tab, select the 'Menu - Sales 2' header. - Bug: The 'menu items' are not aligned with the CTA button. - In the 'STYLE' tab, select the 'Menu - Sales 4' header. - Bug: Bug: The 'cart' button is not aligned with the CTA button. task-3478334 ------------- - **Menu - Sales 1** header _Before_  _After_  ------------- - **Menu - Sales 2** header _Before_  _After_  ------------- - **Menu - Sales 4** header _Before_  _After_  Forward-Port-Of: odoo/odoo#145230
Steps to reproduce: - Install ecommerce and rental (so we get products for rent). - Now go to the shop website and search for a renting product. - Get the mobile view and try to use the daterangepicker. The issue is that until 17.0 where we started using our own component (see #134263 for reference) the daterangepicker responsiveness was handled through the `web/static/src/legacy/scss/daterangepicker.scss` which for some reason in saas-16.3 and saas-16.4 was moved from the web manifest t
Original PR description
Steps to reproduce: - Install ecommerce and rental (so we get products for rent). - Now go to the shop website and search for a renting product. - Get the mobile view and try to use the daterangepicker. The issue is that until 17.0 where we started using our own component (see #134263 for reference) the daterangepicker responsiveness was handled through the `web/static/src/legacy/scss/daterangepicker.scss` which for some reason in saas-16.3 and saas-16.4 was moved from the web manifest to the `website_slides` manifest, making the daterangepicker to be broken in mobile for other modules like rental. ## Before:  ## After:  fw-bot up to 17.0 opw-3593099 Forward-Port-Of: odoo/odoo#142976
Overflowing search facets do not wrap making them disappear from view when too long. This can happen when searching a single field for multiple values (as they are bundled in the same facet). The problem is fixed by adding actual breakable spaces around the "or" instead of recreating the spacing with margins (which visually looks OK but is actually unreadable as every terms are glued together). Steps to reproduce: * Open a view with a search (kanban, list, ...) * Add many, many long terms
Original PR description
Overflowing search facets do not wrap making them disappear from view when too long. This can happen when searching a single field for multiple values (as they are bundled in the same facet). The problem is fixed by adding actual breakable spaces around the "or" instead of recreating the spacing with margins (which visually looks OK but is actually unreadable as every terms are glued together). Steps to reproduce: * Open a view with a search (kanban, list, ...) * Add many, many long terms search for the same field => BUG the search overflow outside the search bar opw-3581553 Forward-Port-Of: odoo/odoo#146034 Forward-Port-Of: odoo/odoo#141449
NOTE: This fix was in 17.0 but not yet in 16.4. This is a backporting Before this commit, adding column in a report added a line instead because columns were too large. After this commit, the created columns are not "lg" anymore, so column creation does make a column. task-id-3457404 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143299
Original PR description
NOTE: This fix was in 17.0 but not yet in 16.4. This is a backporting Before this commit, adding column in a report added a line instead because columns were too large. After this commit, the created columns are not "lg" anymore, so column creation does make a column. task-id-3457404 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143299
The aim of this commit is to correct the date of the payment. Context: When creating a PoS session and a PoS order on date X The customer gets its invoice on date Y the payment date is printed on the invoice Before this commit: The payment date will always be the date of the invoice After this commit: The payment date will always be the date of the order, the date at which is was really paid. Corner case not taken care of in this commit: Claiming the invoice after the `fiscalyea
Original PR description
The aim of this commit is to correct the date of the payment. Context: When creating a PoS session and a PoS order on date X The customer gets its invoice on date Y the payment date is printed on the invoice Before this commit: The payment date will always be the date of the invoice After this commit: The payment date will always be the date of the order, the date at which is was really paid. Corner case not taken care of in this commit: Claiming the invoice after the `fiscalyear_lock_date`. In such a case, the payment date will be set to today (the invoice_date) again. This should be really rare as setting that lock date in short time frame is quite unusual. task-id: 3629054 Forward-Port-Of: odoo/odoo#145771
Before this commit, clickall was clicking on an app that redirect to a tablet mode view. The issue with this is that clickall don't know how to exit the view, so it was stuck in the view. This commit adds that view on the blacklist of clickall. Also, this commit adds an error message when clickall is stuck in a view. Forward-Port-Of: odoo/odoo#146174
Original PR description
Before this commit, clickall was clicking on an app that redirect to a tablet mode view. The issue with this is that clickall don't know how to exit the view, so it was stuck in the view. This commit adds that view on the blacklist of clickall. Also, this commit adds an error message when clickall is stuck in a view. Forward-Port-Of: odoo/odoo#146174
Before this commit, when the user tried to quick create a record in a grouped kanban view (by clicking on the "+" icon of a column, for instance), and then clicked on the "Edit" button of the quick create, if the name_create rpc failed, the webclient switched to the form view and an error was displayed. The displayed error was about a destroyed component trying to do an rpc, namely the kanban controller. This is because it does 2 things when the name_create failed: it opened the form view in
Original PR description
Before this commit, when the user tried to quick create a record in a grouped kanban view (by clicking on the "+" icon of a column, for instance), and then clicked on the "Edit" button of the quick…
Before this commit, when the user tried to quick create a record in a grouped kanban view (by clicking on the "+" icon of a column, for instance), and then clicked on the "Edit" button of the quick create, if the name_create rpc failed, the webclient switched to the form view and an error was displayed. The displayed error was about a destroyed component trying to do an rpc, namely the kanban controller. This is because it does 2 things when the name_create failed: it opened the form view in a dialog and it also switched to the form view. The latter was unwanted: in case of errors, we don't want to switch to the form view but rather to quick create from a dialog. The error was actually caused by a small mistake: we use the record variable to determine if the quick create succeeded and if we can switch to the quick created record. However, that same variable was already set before, for another purpose. OPW 3620671 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145981 Forward-Port-Of: odoo/odoo#145877
Before this commit, when browsing the "Events" part of website on Safari (both macOS and iOS/ipadOS), the page could be loaded only once and returns a "FetchEvent.respondWith received an error: NotSupportedError: The operation is not supported." error message on afterward, completely blocking access to everything under the `/event` path. This error is actually thrown from the ServiceWorker's `fetch` event's listener, and more specifically, from the storage availablity check. Since Saf
Original PR description
Before this commit, when browsing the "Events" part of website on Safari (both macOS and iOS/ipadOS), the page could be loaded only once and returns a "FetchEvent.respondWith received an error:…
Before this commit, when browsing the "Events" part of website on Safari (both macOS and iOS/ipadOS), the page could be loaded only once and returns a "FetchEvent.respondWith received an error: NotSupportedError: The operation is not supported." error message on afterward, completely blocking access to everything under the `/event` path. This error is actually thrown from the ServiceWorker's `fetch` event's listener, and more specifically, from the storage availablity check. Since Safari 17.0, the Storage API - and in this case its `estimate()` function - has been enabled in WebKit's builds for Apple platforms (see WebKit PR [1]). But even if this feature should be available in Web Workers (cf. MDN [2] and the spec [3]), it returns a NotSupportedError error when called from the ServiceWorker on Safari 17.0+ (but works fine in the global scope). This commit works around that issue by wrapping this call in a try/catch, acting as if not supported when an error happens. Steps to reproduce (on Safari iOS): - Install website_event_track module - Navigate to the `/event` page - Reload the page => Browser level error page "FetchEvent.respondWith received an error..." Note: due to the browser's engine restriction on iOS/ipadOS, this issue also affects all browsers on these platforms. [1]: https://github.com/WebKit/WebKit/pull/10973 [2]: https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/estimate [3]: https://storage.spec.whatwg.org/#ref-for-dom-storagemanager-estimate opw-3553880 opw-3570730 opw-3610167 opw-3629039 opw-3547759 Forward-Port-Of: odoo/odoo#145731