Tuesday, February 18, 2025
39 changes · saas-18.2
Enhancements to existing features
The authentication email component now allows the new connection notification process to be customized. This lets businesses suppress these emails in specific situations, reducing unnecessary messages while keeping the standard security notification flow available.
Original PR description
Purpose ======= Allow extending the "New Notification" email sending, to be able to not sent the notification in some cases.
The authentication email module now makes the “New Connection” notification easier to customize. This lets businesses adapt or skip these emails in specific situations, reducing unnecessary messages while keeping the standard security notification available.
Original PR description
Purpose ======= Allow extending the "New Notification" email sending.
Resolved issues and error corrections
This fix restores the expected display of placeholder kanban cards when they appear inside related record fields. It keeps the server actions form layout tidy without accidentally hiding cards in other areas, improving visual consistency for users.
Original PR description
Since [1] a CSS rule made ghosts kanban cards to never get displayed when the view was rendered through an x2m field. The author (me) only wanted to get rid of the bottom spacing induced by ghosts cards in the `multi` type server actions form view. This commit reverses the introduced diff in [1] and changes the strategy to target only what is needed. [1]: https://github.com/odoo/odoo/commit/45a5562fc41b5a1ab2fb46ba025f191a5401c078#diff-368e56feea5bb220fcafabbf45b40131fdd3d496fe0f2643a9df5cdec61cb190R82-R86
Miscellaneous changes
When adding/using point in ewallet program, the loyalty history was not updated correctly. Steps to reproduce: ------------------- * Create a new ewallet program * Create an ewallet card for customer C * Add some points to the ewallet card * Open PoS and make an order that you pay with the ewallet card * Check the history of the ewallet card > Observation: The transaction made in the PoS does not appear Why the fix: ------------ The required data are already present in `couponData
Original PR description
When adding/using point in ewallet program, the loyalty history was not updated correctly. Steps to reproduce: ------------------- * Create a new ewallet program * Create an ewallet card for customer C * Add some points to the ewallet card * Open PoS and make an order that you pay with the ewallet card * Check the history of the ewallet card > Observation: The transaction made in the PoS does not appear Why the fix: ------------ The required data are already present in `couponData` so we should use it instead of computing it. Also the method `getLoyaltyPoints` is not returning the points for ewallet program so it should not be used in this case. opw-4546985 Forward-Port-Of: odoo/odoo#197765
Before this commit, modifying the price would cause an error due to a refactoring that converted variable names to camelCase. The function `get_taxed_lst_unit_price` was omitted during this update. opw-4574142 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197623
Original PR description
Before this commit, modifying the price would cause an error due to a refactoring that converted variable names to camelCase. The function `get_taxed_lst_unit_price` was omitted during this update. opw-4574142 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197623
Before this PR, if a chatbot's last step is redirecting to a URL, a visitor could be trapped in an infinite loop of redirection. This is because the chatbot always replays the last step of the script when the page loads. This PR updated the livechat_active status when all the steps were done and ensured that the chatbot service doesn't start if livechat_active is false. Task-4518285 Forward-Port-Of: odoo/odoo#196520 Forward-Port-Of: odoo/odoo#195429
Original PR description
Before this PR, if a chatbot's last step is redirecting to a URL, a visitor could be trapped in an infinite loop of redirection. This is because the chatbot always replays the last step of the script when the page loads. This PR updated the livechat_active status when all the steps were done and ensured that the chatbot service doesn't start if livechat_active is false. Task-4518285 Forward-Port-Of: odoo/odoo#196520 Forward-Port-Of: odoo/odoo#195429
When people were in a discuss call, the following crash may happen when discuss app is open: ``` Cannot read properties of undefined (reading 'persona') ``` This comes from template reading `channel_member.persona`, which can be undefined. Indeed, some flow may return channel member data without persona data, thus the persona is unknown (= undefined) in JS. This commit fixes the issue by taking into account persona of member that could be missing in the discuss sidebar call participan
Original PR description
When people were in a discuss call, the following crash may happen when discuss app is open: ``` Cannot read properties of undefined (reading 'persona') ``` This comes from template reading `channel_member.persona`, which can be undefined. Indeed, some flow may return channel member data without persona data, thus the persona is unknown (= undefined) in JS. This commit fixes the issue by taking into account persona of member that could be missing in the discuss sidebar call participant component. Task-4533395 Forward-Port-Of: odoo/odoo#195862
Commit c63d14a introduced new nicer urls to get to Odoo. Commit e44d13dfa9f301d7120cdb8441dfc6ca03d3d5d5 adapted the /mail/view controller for it, allowing people to copy a link to a mail.message and be redirected to it and its corresponding record. Although one case was missing: when the model doesn't contain dots, the string is considered an action's path. So, when opening a record from a mail, there was a crash in odoo because the action could not be found. After this commit, there is n
Original PR description
Commit c63d14a introduced new nicer urls to get to Odoo. Commit e44d13dfa9f301d7120cdb8441dfc6ca03d3d5d5 adapted the /mail/view controller for it, allowing people to copy a link to a mail.message and be redirected to it and its corresponding record. Although one case was missing: when the model doesn't contain dots, the string is considered an action's path. So, when opening a record from a mail, there was a crash in odoo because the action could not be found. After this commit, there is no crash, and the record is opened correctly with a nice url. see router.js: heuristics to discrimate a model name from an action path is the presence of dots, or the prefix m- for models opw-4564257 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#197917 Forward-Port-Of: odoo/odoo#197883
Steps to Reproduce: - Assign a partner a default payment method (e.g., Cash). - In the vendor payment, select that partner and then change the journal to another payment method (e.g., Bank). Then save. The Issue: After saving, the journal field chosen by the user is overridden by the partner's default payment method. Cause: In `account_payment`, the method `_inverse_partner_id` controls the logic to display the default payment method (`journal_id`) for a partner. It also had `@
Original PR description
Steps to Reproduce: - Assign a partner a default payment method (e.g., Cash). - In the vendor payment, select that partner and then change the journal to another payment method (e.g., Bank). Then…
Steps to Reproduce:
- Assign a partner a default payment method (e.g., Cash).
- In the vendor payment, select that partner and then change the journal to another payment method (e.g., Bank). Then save.
The Issue:
After saving, the journal field chosen by the user is overridden by the partner's default payment method.
Cause:
In `account_payment`, the method `_inverse_partner_id` controls the logic to display the default payment method (`journal_id`) for a partner. It also had `@api.onchange('partner_id')` to adjust the `journal_id` in case the user changes the partner ID in the view. However, the inverse method is triggered on a save because `partner_id` is in `vals_list` of `write`, which sets the default `journal_id` instead of the user input.
Solution:
The behavior of the inverse method can be handled instead by the compute of `journal_id` if it depends on `partner_id`.
opw-4478282
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#197309
Forward-Port-Of: odoo/odoo#194490Commit db12319e8b3b662a1498ee9a519fbced457174cc introduced a wrong behaviour for the discounts applied to an order when they are fixed or depending on the number of points. With this commit, the taxes applied would the ones set on the reward product if at least one line in the sale order had these taxes. Disregarding any other taxes applied, or not setting taxes at all. This was done to facilitate the reading of a sale order. Accounting wise, this is wrong. A product is paid less, so less tax
Original PR description
Commit db12319e8b3b662a1498ee9a519fbced457174cc introduced a wrong behaviour for the discounts applied to an order when they are fixed or depending on the number of points. With this commit, the taxes applied would the ones set on the reward product if at least one line in the sale order had these taxes. Disregarding any other taxes applied, or not setting taxes at all. This was done to facilitate the reading of a sale order. Accounting wise, this is wrong. A product is paid less, so less taxes needs to be recorded. It's not optimization, it's regulation. Reverting part of db12319e8b3b662a1498ee9a519fbced457174cc to evaluate how to ease the user life without having them getting on the warpath of their accountant. opw-4486030 TODO in master: take off taxes fields. Forward-Port-Of: odoo/odoo#197648 Forward-Port-Of: odoo/odoo#196252
When creating multiple preparation printers for different pos categories you could have a case where an empty receipt is printed. Steps to reproduce: ------------------- * Create 2 PoS categories CAT 1 and CAT 2 * Create a first preparation printer for CAT 2 * Create a second preparation printer for CAT 1 * Create a product P1 for CAT 1 * Assign the two printers to a PoS * Open PoS and add the P1 to your order * Send the order in preparation > Observation: Two receipts are printed an
Original PR description
When creating multiple preparation printers for different pos categories you could have a case where an empty receipt is printed. Steps to reproduce: ------------------- * Create 2 PoS categories CAT 1 and CAT 2 * Create a first preparation printer for CAT 2 * Create a second preparation printer for CAT 1 * Create a product P1 for CAT 1 * Assign the two printers to a PoS * Open PoS and add the P1 to your order * Send the order in preparation > Observation: Two receipts are printed and one of them is empty Why the fix: ------------ When going over each printer to print the relevant changes, if the first printer in the list has no changes it would always print an empty receipt because `last_preparation_change` would always be empty. To fix this we rely on `changes` to check if there are any changes to print on this printer opw-4462586 Forward-Port-Of: odoo/odoo#197077 Forward-Port-Of: odoo/odoo#196808
Before it was possible to click on "load order" button even when there was no selected order. This commit disables the button when there is no selected order. taskId: 4562723 Forward-Port-Of: odoo/odoo#197206
Original PR description
Before it was possible to click on "load order" button even when there was no selected order. This commit disables the button when there is no selected order. taskId: 4562723 Forward-Port-Of: odoo/odoo#197206
The `require_partner_bank_account` flag on the payment shouldn't require the `allow_out_payment` flag on it when the payment type is `inbound` as it leads to confusion. This generates an issue with the `l10n_it_riba` Ri.Ba. payment method. It requires the bank account, but the money is incoming, not outgoing. Old PR for saas-17.2: odoo/odoo#195312 Enterprise PR: odoo/enterprise#78959 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/o
Original PR description
The `require_partner_bank_account` flag on the payment shouldn't require the `allow_out_payment` flag on it when the payment type is `inbound` as it leads to confusion. This generates an issue with the `l10n_it_riba` Ri.Ba. payment method. It requires the bank account, but the money is incoming, not outgoing. Old PR for saas-17.2: odoo/odoo#195312 Enterprise PR: odoo/enterprise#78959 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/odoo#197141
When an invoice is created, the system will automatically translate the strings into the customer language: - In the backend the user will see the original product name and the label composed by translated name and translated description. - In the printed pdf the customer will see just the translated label However if the user modify the label in the backend, it will be saved prepending the original product name Steps to reproduce: - Have a user using a language [LANG1] - Have a cust
Original PR description
When an invoice is created, the system will automatically translate the strings into the customer language: - In the backend the user will see the original product name and the label composed by translated name and translated description. - In the printed pdf the customer will see just the translated label However if the user modify the label in the backend, it will be saved prepending the original product name Steps to reproduce: - Have a user using a language [LANG1] - Have a customer using a language [LANG2] - Make an invoice to the customer, add a product with both name and description with translation available - Make a small change to the product label - Save - Print Issue: The name of the product is duplicated, it appears in user language and customer language opw-4444773 Forward-Port-Of: odoo/odoo#197788
When a visitor is forwarded to an operator, the chat bot leaves the channel and a message is posted. The notification which indicates than an operator joined the channel is enough. This PR removes the chat bot leave notification. 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 enterprise: https://github.com/odoo/enterp
Original PR description
When a visitor is forwarded to an operator, the chat bot leaves the channel and a message is posted. The notification which indicates than an operator joined the channel is enough. This PR removes the chat bot leave notification. 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 enterprise: https://github.com/odoo/enterprise/pull/79237 Forward-Port-Of: odoo/odoo#197583
Instead of directly notify the invoices link to the transaction in _log_message_on_linked_documents, the invoice return by _get_invoices_to_notify are notified. It allow other modules to exclude some invoice --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197393
Original PR description
Instead of directly notify the invoices link to the transaction in _log_message_on_linked_documents, the invoice return by _get_invoices_to_notify are notified. It allow other modules to exclude some invoice --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197393
Certain nondeterministic JS tests can be more easily reproducible if the browser CPU is throttled. For example: rd-112019 https://github.com/odoo/odoo/pull/196980 Chrome does allow CPU throttling using the command: https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setCPUThrottlingRate An environment variable can also be used to ease the usage in a given dedicated environment. task-4559442 Forward-Port-Of: odoo/odoo#197793 Forward-Port-Of: odoo/odoo#197007
Original PR description
Certain nondeterministic JS tests can be more easily reproducible if the browser CPU is throttled. For example: rd-112019 https://github.com/odoo/odoo/pull/196980 Chrome does allow CPU throttling using the command: https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setCPUThrottlingRate An environment variable can also be used to ease the usage in a given dedicated environment. task-4559442 Forward-Port-Of: odoo/odoo#197793 Forward-Port-Of: odoo/odoo#197007
The composer is disabled when not needed (chat bot steps not requiring user input) or when the live chat has ended. However, the composer is sometimes shown to the visitor even when the composer is disabled. Steps to reproduce the issue: - Go to the /contactus page - Start the chat bot - Composer is shown, while the bot doesn't expect any user input In [1], we enabled the composer for operators even when the chat has ended. To do so, we check that the current user is not the visitor. Ho
Original PR description
The composer is disabled when not needed (chat bot steps not requiring user input) or when the live chat has ended. However, the composer is sometimes shown to the visitor even when the composer is disabled. Steps to reproduce the issue: - Go to the /contactus page - Start the chat bot - Composer is shown, while the bot doesn't expect any user input In [1], we enabled the composer for operators even when the chat has ended. To do so, we check that the current user is not the visitor. However, temporary threads are missing some information such as channel members. As a result, the composer is shown to the visitor even if disabled when the thread is temporary. This PR modify this condition to handle temporary threads. [1]: https://github.com/odoo/odoo/pull/195734 Forward-Port-Of: odoo/odoo#195945
Before this commit, when an IoT device was connected, if you kept typing in the search box, the input would be reset to its previous state with each statusLoop execution. This fix cancels the debounce on re-render, ensuring that the search word is preserved. opw-4562152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197615
Original PR description
Before this commit, when an IoT device was connected, if you kept typing in the search box, the input would be reset to its previous state with each statusLoop execution. This fix cancels the debounce on re-render, ensuring that the search word is preserved. opw-4562152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197615
When the modifier is empty we don't get any error in the fronted. It's just assumed as `False`. Since 6f06420e we have a new mechanism that adds fields to views as long as they are used in an modifier's expression. This unfortunately fails with a syntax error if the expression is empty. OTOH having an empty expression could be useful for development as a placeholder for further changes. The presence of empty expressions causes issues during the upgrade from <17.4 to higher versions. --- I
Original PR description
When the modifier is empty we don't get any error in the fronted. It's just assumed as `False`. Since 6f06420e we have a new mechanism that adds fields to views as long as they are used in an modifier's expression. This unfortunately fails with a syntax error if the expression is empty. OTOH having an empty expression could be useful for development as a placeholder for further changes. The presence of empty expressions causes issues during the upgrade from <17.4 to higher versions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197281
Currently, when searching for products using the searchBar, the results can be different depending on the way you write the same word ('desk', 'DESK', 'Desk') Steps to reproduce: ------------------- * Create 2 products * Product 1: name: "Blue DESK" * Product 2: name: "Work table", reference: 'DESK_01' * Open pos shop * Search "desk" > Observation: "Blue DESK" product is found, not "Work table" * Search "DESK" > Observation: "Work table" product is found, not "Blue DESK" Why t
Original PR description
Currently, when searching for products using the searchBar, the results can be different depending on the way you write the same word ('desk', 'DESK', 'Desk') Steps to reproduce: -------------------…
Currently, when searching for products using the searchBar, the results can be different depending on the way you write the same word ('desk', 'DESK', 'Desk')
Steps to reproduce:
-------------------
* Create 2 products
* Product 1: name: "Blue DESK"
* Product 2: name: "Work table", reference: 'DESK_01'
* Open pos shop
* Search "desk"
> Observation: "Blue DESK" product is found, not "Work table"
* Search "DESK"
> Observation: "Work table" product is found, not "Blue DESK"
Why the fix:
------------
The behavior originates from https://github.com/odoo/odoo/commit/e9a27425a0c0b9da982aeaaec2accfa968ed1816
When doing a search, it looks for exact matches with the fields `barcode` and `default_code` and returns them, without looking for the matches in name. This is what happens when we search for "DESK" (simple example, the searchword should be greater than 5).
When we search for 'desk', no exact match is found as the function `exactMatches` is case sensitive. We then find the product thanks to `fuzzyLookup`.
This fix includes the name of the product in the exact match search and does not make it upper/lower case sensitive.
opw-4532712
Forward-Port-Of: odoo/odoo#197809
Forward-Port-Of: odoo/odoo#197183Since [1] the placeholder of SelectionField has seen its visual style adapted. This adapts the custom base_automation_trigger_selection field too. [1]: https://github.com/odoo/odoo/commit/b6598d9a2f524f37eb1a98f211d6adf027777b47 Description of the issue/feature this PR addresses:  Forward-Port-Of: odoo/odoo#197908
Original PR description
Since [1] the placeholder of SelectionField has seen its visual style adapted. This adapts the custom base_automation_trigger_selection field too. [1]: https://github.com/odoo/odoo/commit/b6598d9a2f524f37eb1a98f211d6adf027777b47 Description of the issue/feature this PR addresses:  Forward-Port-Of: odoo/odoo#197908
Before this commit: ---------------------------------- - Components set as 'highlight consumption' in the BOM of serial-number tracked products were being automatically consumed when serial numbers were generated or via the mass produce option, causing unintended stock reductions. After this commit: ---------------------------------- - Fixed the issue where 'highlight consumption' components were incorrectly consumed during serial number generation. Components are now only consumed when e
Original PR description
Before this commit: ---------------------------------- - Components set as 'highlight consumption' in the BOM of serial-number tracked products were being automatically consumed when serial numbers were generated or via the mass produce option, causing unintended stock reductions. After this commit: ---------------------------------- - Fixed the issue where 'highlight consumption' components were incorrectly consumed during serial number generation. Components are now only consumed when explicitly required by the production process. Task-id: 4373005 Forward-Port-Of: odoo/odoo#197784 Forward-Port-Of: odoo/odoo#189697
Steps to Reproduce: - Install the `l10n_in_hr_holidays` module. - Ensure there is only one company, and its country is set to India. - Sandwich leave feature is not available for common time-off types like Paid, Sick, etc. Cause: - Time off types for common categories (e.g., Paid, Sick) have `company_id` and `country_id` set to False. - In a single-company setup, users cannot change the country in these time-off types due to the lack of multi-company access. Fix: - Adjusted the visib
Original PR description
Steps to Reproduce: - Install the `l10n_in_hr_holidays` module. - Ensure there is only one company, and its country is set to India. - Sandwich leave feature is not available for common time-off types like Paid, Sick, etc. Cause: - Time off types for common categories (e.g., Paid, Sick) have `company_id` and `country_id` set to False. - In a single-company setup, users cannot change the country in these time-off types due to the lack of multi-company access. Fix: - Adjusted the visibility condition for the sandwich leave feature. If the `country_id` for the time-off type is False or India then the sandwich leave feature will now be available. task-4430006 Forward-Port-Of: odoo/odoo#194868
### Issue: The curent compute method of the location_id field of quant packages is not accurate as it is currently set to the first existing quant and not to the only existing quant with a positive quantity for that package. ### Steps to reproduce (issue in barcode): - In the settings enable: Multi-Step Routes, Operations > Packages - Create a storable product - Update the on hand quantity: - 10 units in package PK in WH/STOCK - Inventory > Configuration > Warehouse Management > L
Original PR description
### Issue: The curent compute method of the location_id field of quant packages is not accurate as it is currently set to the first existing quant and not to the only existing quant with a positive…
### Issue:
The curent compute method of the location_id field of quant packages is not accurate as it is currently set to the first existing quant and not to the only existing quant with a positive quantity for that package.
### Steps to reproduce (issue in barcode):
- In the settings enable: Multi-Step Routes, Operations > Packages
- Create a storable product
- Update the on hand quantity:
- 10 units in package PK in WH/STOCK
- Inventory > Configuration > Warehouse Management > Locations
- Create 2 warehouse locations: WH/LOC1, WH/LOC2
- Go to the barcode app and proceed with the scans: i. Scan the internal transfer picking type ii. Scan WH/STOCK as a source location iii. Scan the package name (PK) iv. Scan WH/LOC1 as destination location
- Leave the barcode app without validation
- Go to the barcode app and proceed with the scans: i -> iii, iv'. Scan WH/LOC2 as destination location
- Validate the picking
- Proceed an other picking via the barcode app to follow up: i. Scan the internal transfer picking type ii. Scan WH/LOC2 as a source location iii. Scan the package name (PK)
#### > the package is not found and added. You rather trigger a notification: no package You are expected to scan one or more products or a package available at the picking location
### Cause of the issue:
After the picking validation, the location_id of the package should havebeen updated to WH/LOC2 but it is still WH/Stock since you have a reserved quantity on that quant and it was not cleaned:
https://github.com/odoo/odoo/blob/081215d1220d6a362087aa33c304a452893b1dca/addons/stock/models/stock_quant.py#L1482-L1490
opw-4574169
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#197824
Forward-Port-Of: odoo/odoo#197735More logging is required to track calls to VIES services to enable tracking databases triggering VIES limitations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176677 Forward-Port-Of: odoo/odoo#176602
Original PR description
More logging is required to track calls to VIES services to enable tracking databases triggering VIES limitations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176677 Forward-Port-Of: odoo/odoo#176602
**Current behavior:** Having some product with a subcontract BoM and using the unarchived 'Subcontract' picking type and creating a purchase order to the subcontractor for that product: changing the `scheduled_date` of the generated receipt will improperly set the start/end date on the subcontracting MO which was generated alongside the receipt. Specifically, the `scheduled_date` of the receipt should correspond to the `date_finished` of the MO- however currently it is incorrectly modifying
Original PR description
**Current behavior:** Having some product with a subcontract BoM and using the unarchived 'Subcontract' picking type and creating a purchase order to the subcontractor for that product: changing the…
**Current behavior:** Having some product with a subcontract BoM and using the unarchived 'Subcontract' picking type and creating a purchase order to the subcontractor for that product: changing the `scheduled_date` of the generated receipt will improperly set the start/end date on the subcontracting MO which was generated alongside the receipt. Specifically, the `scheduled_date` of the receipt should correspond to the `date_finished` of the MO- however currently it is incorrectly modifying the MO `date_start` instead. **Expected behavior:** Modifying `scheduled_date` on the receipt will in turn modify the `date_finished` of the MO. **Steps to reproduce:** *Unarchive the Subcontract picking type operation* 1. Create a final product with a subcontract type BoM, on the BoM set some positive value for Manuf. Lead Time (in miscellaneous tab) 2. Create a purchase order to the subcontractor for that product 3. Confirm the PO -> observe that on creation, the scheduled date of the receipt matches the end date of the MO 4. Change the scheduled date of the receipt (for example, 10 days in the future) -> observe that after saving, the MO date correspondence is inverted (end date = scheduled date + lead time) instead of the start date being set with respect to the end time (like on creation), the end date gets set with respect to the start date **Cause of the issue:** It's an inconsistency with how the fields (start, end) are calculated and when. **Fix:** Make this case behave the same as the creation does- that is, end date is informed by the receipt's scheduled date and the start date of the MO is set by subtracting the lead time from there. opw-4231548 Forward-Port-Of: odoo/odoo#193868 Forward-Port-Of: odoo/odoo#188389
Steps to reproduce: - Run helpdesk tour. - Change the language - Proceed with the tour Isuse: - The tours fails. Problem: - It is due to the triggers using english text in :contains. Fix: - Replace all the :contains with concrete triggers. Also changed some tour steps pointer orientation as it doesnt sit right in some conditions(gets broken/ partially invisible) task-4479518 Forward-Port-Of: odoo/enterprise#79339 Forward-Port-Of: odoo/enterprise#77398
Original PR description
Steps to reproduce: - Run helpdesk tour. - Change the language - Proceed with the tour Isuse: - The tours fails. Problem: - It is due to the triggers using english text in :contains. Fix: - Replace all the :contains with concrete triggers. Also changed some tour steps pointer orientation as it doesnt sit right in some conditions(gets broken/ partially invisible) task-4479518 Forward-Port-Of: odoo/enterprise#79339 Forward-Port-Of: odoo/enterprise#77398
Change the "up to this date" to "before this date", to specify that its upper limit is excluded. Otherwise, when you set 31/12/24 in this field and Odoo cancels all the entries up to 30/12/24 and leave the 31/12/24 entries, you'll be disappointed. Task [link](https://www.odoo.com/odoo/project/967/tasks/4447369) task-4447369 Forward-Port-Of: odoo/enterprise#79240 Forward-Port-Of: odoo/enterprise#79105
Original PR description
Change the "up to this date" to "before this date", to specify that its upper limit is excluded. Otherwise, when you set 31/12/24 in this field and Odoo cancels all the entries up to 30/12/24 and leave the 31/12/24 entries, you'll be disappointed. Task [link](https://www.odoo.com/odoo/project/967/tasks/4447369) task-4447369 Forward-Port-Of: odoo/enterprise#79240 Forward-Port-Of: odoo/enterprise#79105
The require_partner_bank_account flag on the payment shouldn't require the allow_out_payment flag on it when the payment type is inbound as it leads to confusion. This generates an issue with the l10n_it_riba RiBa payment method. It requires the bank account, but the money is incoming, not outgoing. Community PR: odoo/odoo#197141 Old Enterprise PR: odoo/enterprise#77901 Task [link](https://www.odoo.com/odoo/project/967/tasks/) task-4497749 Forward-Port-Of: odoo/enterprise#78959
Original PR description
The require_partner_bank_account flag on the payment shouldn't require the allow_out_payment flag on it when the payment type is inbound as it leads to confusion. This generates an issue with the l10n_it_riba RiBa payment method. It requires the bank account, but the money is incoming, not outgoing. Community PR: odoo/odoo#197141 Old Enterprise PR: odoo/enterprise#77901 Task [link](https://www.odoo.com/odoo/project/967/tasks/) task-4497749 Forward-Port-Of: odoo/enterprise#78959
task-4410808 community: https://github.com/odoo/odoo/pull/197583 Forward-Port-Of: odoo/enterprise#79237
Original PR description
task-4410808 community: https://github.com/odoo/odoo/pull/197583 Forward-Port-Of: odoo/enterprise#79237
Scenario ======== the subscription cron that automate the payment, start a payment transaction get the response and post process the the payment. In the meanwhile, the webhook receive also the response and try to post a message on the invoice in _log_message_on_linked_documents This lead to concurrent update on the invoice Solution ======== use _get_invoices_to_notify to remove the invoice currenctly handled by the invoice cron from the payment notification. The notification won
Original PR description
Scenario ======== the subscription cron that automate the payment, start a payment transaction get the response and post process the the payment. In the meanwhile, the webhook receive also the response and try to post a message on the invoice in _log_message_on_linked_documents This lead to concurrent update on the invoice Solution ======== use _get_invoices_to_notify to remove the invoice currenctly handled by the invoice cron from the payment notification. The notification won't appear on the invoice in this flow, that's not a problem. Payment notification is also set on the sale order Forward-Port-Of: odoo/enterprise#79125
Before this commit: Total weight sent for a multipackage shipment was sum of all the weights of packages in the shipment. After this commit: Average weight of all the packages is sent as total weight. Sendcloud in the backend use average weight for the multipackage shipping request and multiplies it by the number of packages. *checked with sendcloud support. opw-4260104 Forward-Port-Of: odoo/enterprise#79001
Original PR description
Before this commit: Total weight sent for a multipackage shipment was sum of all the weights of packages in the shipment. After this commit: Average weight of all the packages is sent as total weight. Sendcloud in the backend use average weight for the multipackage shipping request and multiplies it by the number of packages. *checked with sendcloud support. opw-4260104 Forward-Port-Of: odoo/enterprise#79001
An error occurs when triggering a cron job for posting all pending posts. ```ValueError: Expected singleton: social.post(14, 13)``` A singleton error occurs when the system tries to get a value of 'post_method' from multiple records at [1]. Link [1]: https://github.com/odoo/enterprise/blob/5e968dfce025102bc27f01ba9b07304477835b47/social_push_notifications/models/social_post.py#L26 To avoid the singleton error, we can use the ```mapped()``` function to retrieve a list of values from a
Original PR description
An error occurs when triggering a cron job for posting all pending posts. ```ValueError: Expected singleton: social.post(14, 13)``` A singleton error occurs when the system tries to get a value of 'post_method' from multiple records at [1]. Link [1]: https://github.com/odoo/enterprise/blob/5e968dfce025102bc27f01ba9b07304477835b47/social_push_notifications/models/social_post.py#L26 To avoid the singleton error, we can use the ```mapped()``` function to retrieve a list of values from all the records and check the condition across them. Sentry-6055370689 Forward-Port-Of: odoo/enterprise#74698
The use of the parameters date_start and date_end in the url is not always correct in the planning gantt model. For instance, if date_start and date_end are given and are in the same week, the range selected has one day more than expected and does not start on the first day of the week. Here we fix/improve the usage of those parameters by removing the extra day (if any) and localizing appropriately the ranges. Task ID: 4500939 Forward-Port-Of: odoo/enterprise#79412 Forward-Port-Of: odoo/ente
Original PR description
The use of the parameters date_start and date_end in the url is not always correct in the planning gantt model. For instance, if date_start and date_end are given and are in the same week, the range selected has one day more than expected and does not start on the first day of the week. Here we fix/improve the usage of those parameters by removing the extra day (if any) and localizing appropriately the ranges. Task ID: 4500939 Forward-Port-Of: odoo/enterprise#79412 Forward-Port-Of: odoo/enterprise#79362
Before this commit, the test was relying in "today's" date for creating the recurring invoices. Since the time period for generating them was too short, the expected deliveries were not being generated. After this commit, we give a fixed date to the start date of the subscriptions and then generate the recurring invoices with a time distance of a month, solving the issue. Issue-from: OPW-4166852 Related PR: odoo/enterprise#73397 Forward-Port-Of: odoo/enterprise#78300 Forward-Port-Of: odo
Original PR description
Before this commit, the test was relying in "today's" date for creating the recurring invoices. Since the time period for generating them was too short, the expected deliveries were not being generated. After this commit, we give a fixed date to the start date of the subscriptions and then generate the recurring invoices with a time distance of a month, solving the issue. Issue-from: OPW-4166852 Related PR: odoo/enterprise#73397 Forward-Port-Of: odoo/enterprise#78300 Forward-Port-Of: odoo/enterprise#76336
Since deductions are negative in the total, we need to invert accounts for them to be properly posted in the inverse credit and debit accounts. Forward-Port-Of: odoo/enterprise#79423
Original PR description
Since deductions are negative in the total, we need to invert accounts for them to be properly posted in the inverse credit and debit accounts. Forward-Port-Of: odoo/enterprise#79423
Forward-Port-Of: odoo/enterprise#79261
Original PR description
Forward-Port-Of: odoo/enterprise#79261
We remove unnecessary blackbox call in preSyncAllOrders method. Before we were calling the blackbox every time we were syncing orders with the server, even if it was not useful when there was no line change. Now we only call the blackbox when there is at least a line change. Forward-Port-Of: odoo/enterprise#76132 Forward-Port-Of: odoo/enterprise#75981
Original PR description
We remove unnecessary blackbox call in preSyncAllOrders method. Before we were calling the blackbox every time we were syncing orders with the server, even if it was not useful when there was no line change. Now we only call the blackbox when there is at least a line change. Forward-Port-Of: odoo/enterprise#76132 Forward-Port-Of: odoo/enterprise#75981