Thursday, January 2, 2025
12 changes · master
Enhancements to existing features
Removed an unused piece of WhatsApp messaging code that was left over after a related interface change. This has no expected change for users, but keeps the codebase simpler and easier to maintain.
Original PR description
Since odoo/odoo#186084, the `hasSendButtonNonEditing` getter has been removed from the composer template. This commit removes that getter, as it's now dead code. Related to odoo/odoo#192103
The Field Service Tasks Analysis report was adjusted to match recent changes that removed an inactive-task filter. This keeps reporting views working correctly without requiring broader changes to field service or task analysis reports.
Original PR description
- Removed the inactive filter in the Tasks Analysis report, so we need to update the xpath accordingly. Technical: - If the `inactive` filter is added in the `project_task_view_search_fsm_base` view, it will require the removal of both the Task Analysis report and the FSM report. Hence, we should not include the `inactive` filter in the `project_task_view_search_fsm_base`. Related : https://github.com/odoo/odoo/pull/175518 task-4037091
Resolved issues and error corrections
When a quotation or sales order is deleted, its custom spreadsheet is now removed as well. This prevents order-specific spreadsheets from being reused accidentally in quotation templates, keeping sales documents cleaner and more accurate.
Original PR description
Currently, when deleting a quotation/SO with a custom `sale.order.spreadsheet`, the latter will see its field `order_id` empty and will become available to be linked to a quotation template. Since it's a custom spreadsheet for that specific SO, it makes no sense to keep it. opw-4385254
Code cleanup and technical improvements
This internal update aligns the Documents Kanban view with a related platform change by making required setup information explicit. Users should not notice a feature change, but it helps keep the Documents interface stable and easier to maintain.
Original PR description
This commit is the counterpart of odoo/odoo#191307.
Miscellaneous changes
To be more clear, we add the original amount from the statement we are to reconciliating on the open balance line. task-4194671 Forward-Port-Of: odoo/enterprise#76146 Forward-Port-Of: odoo/enterprise#70785
Original PR description
To be more clear, we add the original amount from the statement we are to reconciliating on the open balance line. task-4194671 Forward-Port-Of: odoo/enterprise#76146 Forward-Port-Of: odoo/enterprise#70785
This commit's purpose is to add a test for the full flow of the creation of a BOM/MO when they are linked to a project. This is to ensure that the aal generated are generated correctly and that the project profitability is then computing them into the correct section. community pr: https://github.com/odoo/odoo/pull/186607 task - 4184226 affetced version 18.0 - master Forward-Port-Of: odoo/enterprise#76157 Forward-Port-Of: odoo/enterprise#74398
Original PR description
This commit's purpose is to add a test for the full flow of the creation of a BOM/MO when they are linked to a project. This is to ensure that the aal generated are generated correctly and that the project profitability is then computing them into the correct section. community pr: https://github.com/odoo/odoo/pull/186607 task - 4184226 affetced version 18.0 - master Forward-Port-Of: odoo/enterprise#76157 Forward-Port-Of: odoo/enterprise#74398
When the `l10n_be_hr_payroll_sepa_salary_payment` context option is passed, an extra `<Ustrd>` gets generated with the Urgency SEPA flag. After the refactoring in odoo/enterprise#60393, when there is no recognized reference type in the default `_get_RmtInf()` generation[^1], we end up with 2 Ustrd elements like this: ```xml <RmtInf> <Ustrd>SPLIP/1234</Ustrd> <Ustrd>/A/ SPLIP/1234</Ustrd> </RmtInf> ``` The SEPA file then gets rejected by banks as invalid. Instead we should detect
Original PR description
When the `l10n_be_hr_payroll_sepa_salary_payment` context option is passed, an extra `<Ustrd>` gets generated with the Urgency SEPA flag. After the refactoring in odoo/enterprise#60393, when there is no recognized reference type in the default `_get_RmtInf()` generation[^1], we end up with 2 Ustrd elements like this: ```xml <RmtInf> <Ustrd>SPLIP/1234</Ustrd> <Ustrd>/A/ SPLIP/1234</Ustrd> </RmtInf> ``` The SEPA file then gets rejected by banks as invalid. Instead we should detect the pre-existing element and update it. [^1]: https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/account_iso20022/models/account_journal.py#L324-L326 Forward-Port-Of: odoo/enterprise#74692
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the `_action_done`: https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/stock/models/stock_picking.py#L918 https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/delivery/models/stock_picking.py#L192-L196 However, since a UserError of any of the picking
Original PR description
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the…
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the `_action_done`: https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/stock/models/stock_picking.py#L918 https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/delivery/models/stock_picking.py#L192-L196 However, since a UserError of any of the picking will cause a rollback of the entire batch on Odoo's side, pikcings might end up being processed on the carrier side but non validated on Odoo's side during batch validation. ### Steps to reproduce: - Configure sendcloud shipping method + website + payment providers - In your sendcloud configuration select sendcloud shipping product to not be able to handle products with a weight exceeding 10 kg e.g; bpost @home (0-10kg). - Create 2 storable products with respective weigth 1 and 100 kg. - Publish them on the website for sale. - Open a private window, make an order via the website for the 1kg product by filling your cart and use sendcloud as carrier. - Repeat the operation with the other product to generate a seconde SO. - Back to your main window > Inventory Overview > Delivery Orders - Select both deliveries > Action > Validate (in batch) #### > While the first delivery order was processed on carrier side (can be checked on sendcloud's website) #### > the UserError of the second DO rollbacked its validation in Odoo. ### Fix: As such, and since the carrier requests needs to happen after we have validated the pickings in Odoo, we should avoid any rollback of the transaction once any requests has already been successfully treated on the carrier side. ### Note: It is not possible restructure the code to use `senf.env.cr.savepoint` in a loop in order to reset the validation of pickings that are not valid on the carrier side because savepoints can't be used more than 64 times before the server crashes and hence can't be used in record loops. community: https://github.com/odoo/odoo/pull/190320 opw-4357325 Forward-Port-Of: odoo/enterprise#76244 Forward-Port-Of: odoo/enterprise#75502
Before this commit: Only `companyName` is included in shipping requests sent to FedEx. After this commit: `personName` is added to the request, same as `companyName`. According to FedEx documentation, it is not required if the address is `buisness` but we get an error if the `deliveryAddress` and `soldTo` address are different. Checked with FedEx support, and they said it is required to send the `personName` field always. opw-4415536 Forward-Port-Of: odoo/enterprise#76307
Original PR description
Before this commit: Only `companyName` is included in shipping requests sent to FedEx. After this commit: `personName` is added to the request, same as `companyName`. According to FedEx documentation, it is not required if the address is `buisness` but we get an error if the `deliveryAddress` and `soldTo` address are different. Checked with FedEx support, and they said it is required to send the `personName` field always. opw-4415536 Forward-Port-Of: odoo/enterprise#76307
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice and export it as XML. - Upload the XML file as a vendor bill. - The vendor bill incorrectly shows two "8% taxes" instead of one. ## Solution: - The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to
Original PR description
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice…
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice and export it as XML. - Upload the XML file as a vendor bill. - The vendor bill incorrectly shows two "8% taxes" instead of one. ## Solution: - The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to `17.0` https://github.com/odoo/enterprise/commit/56a2b66d84d8398ea870d559cd55cfeae44019d8 - In `17.0` we introduced this Extract method `_l10n_mx_edi_import_cfdi_get_tax_from_node` to refactor the `_l10n_mx_edi_import_cfdi_fill_invoice_line`. - We should have add the Exento checks in the new method however we mistakenly pushed code from `saas-16.4` to `17.0` without adapting it. - I removed the extra code introduced during the forward-porting. - Refactored the related code to ensure compatibility with the new changes in `17.0`. OPW-4198016 Forward-Port-Of: odoo/enterprise#76209 Forward-Port-Of: odoo/enterprise#74602
Issue: After posting content through Social Marketing on Instagram, the generated link redirects to a non-existent post or page. Steps to Reproduce: 1. Install the Social Marketing tool. 3. Set up an Instagram account connection. 3. Create a post and attempt to click on the generated link for redirection to the post on Instagram. Solution: The issue stems from using Instagram's internal post_id, which does not work for direct URL access to the post. To resolve this, we need to requ
Original PR description
Issue: After posting content through Social Marketing on Instagram, the generated link redirects to a non-existent post or page. Steps to Reproduce: 1. Install the Social Marketing tool. 3. Set up an Instagram account connection. 3. Create a post and attempt to click on the generated link for redirection to the post on Instagram. Solution: The issue stems from using Instagram's internal post_id, which does not work for direct URL access to the post. To resolve this, we need to request the permalink associated with the post rather than relying on the internal link. This will ensure accurate redirection. While using the shortcode is an alternative, requesting the permalink directly is a more reliable approach. opw-4243329 Forward-Port-Of: odoo/enterprise#72725
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4.…
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7. The document should be accepted, but TipoCambio has a rate of 1.000000. ### Explanation: During the creation of the Global Invoice, the rate is retrieved during `pos.order._prepare_tax_base_line_values` and, since no value is given through POS, the default value is used. https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1242 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1212-L1213 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1188-L1193 ### Fix reasoning: Adding test to make sure Foreign Currency can be used in Global Invoice for `pos.order` and rate is correctly set as well. Fix in Community opw-4302180 Forward-Port-Of: odoo/enterprise#75185