Daily updates from Odoo
Navigate
Branch
Thursday, August 22, 2024
60 changes
26 changes
Resolved issues and error corrections
Users no longer see an error after leaving chat or WhatsApp discussion channels. The system now safely stops processing channel updates when the user's channel membership has already been removed, improving reliability during normal messaging use.
Original PR description
Issue --> Traceback appears after a user leaves a discuss channel of type `chat` or `whatsapp`. Cause --> `action_unfollow` unlinks the channel member from the `discuss.channel.member` table. When handling new message notification to show "_ has left the channel", method `channel_fetched` attempts to execute a query with an empty `discuss.channel.member` record, which raises a Postgres type mismatch error (`integer` vs ` boolean`) when setting `fetched_message_id`. Solution --> Check if the channel member exists, if not, then exit the method `channel_fetched`. opw-4069813
This change adjusts an internal performance test so it produces consistent results on the stable version. It helps reduce false failures in automated checks, supporting smoother maintenance without changing customer-facing behavior.
Original PR description
Method was refactored in master to get more consistent results. Stable can just get a temporary extra query. runbot-70182
Miscellaneous changes
Version: 17.0+ Current behavior: The default account for Deferred Expense on res.config.setting is "inappropriate". A new account should be established according to account codes by SAT mexico, http://omawww.sat.gob.mx/fichas_tematicas/buzon_tributario/Documents/codigo_agrupador.pdf Purpose of this PR: To introduce an appropriate account to be used for Deferred expenses and automatically selected upon l10n_mx installation. Steps to reproduce on Runbot: 1) install l10n_mx 2) Accoun
Original PR description
Version: 17.0+ Current behavior: The default account for Deferred Expense on res.config.setting is "inappropriate". A new account should be established according to account codes by SAT mexico, http://omawww.sat.gob.mx/fichas_tematicas/buzon_tributario/Documents/codigo_agrupador.pdf Purpose of this PR: To introduce an appropriate account to be used for Deferred expenses and automatically selected upon l10n_mx installation. Steps to reproduce on Runbot: 1) install l10n_mx 2) Accounting Settings > incorrect account selected for Deferred Expense opw-4105993 Forward-Port-Of: odoo/odoo#176681
Improving tax scopes and EC sales tax report tags for `l10n_at` Old PR: odoo/odoo#171606 Info: @wt-io-it Ticket link: https://www.odoo.com/odoo/project.task/3916300 opw-3916300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177074 Forward-Port-Of: odoo/odoo#171702
Original PR description
Improving tax scopes and EC sales tax report tags for `l10n_at` Old PR: odoo/odoo#171606 Info: @wt-io-it Ticket link: https://www.odoo.com/odoo/project.task/3916300 opw-3916300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177074 Forward-Port-Of: odoo/odoo#171702
This feature is not available in mobile OS at the time of this commit [1]: - Safari on iOS 17.5 - Chrome for Android 127 - Firefox for Android 127 Therefore the button should not be shown, otherwise it mistakenly gives the impression that user could make it work by enabling screen-sharing permission which is not possible on mobile OS. opw-4108833 [1]: https://caniuse.com/mdn-api_mediadevices_getdisplaymedia <img width="333" alt="Screenshot 2024-08-21 at 13 26 13" src="https://gi
Original PR description
This feature is not available in mobile OS at the time of this commit [1]: - Safari on iOS 17.5 - Chrome for Android 127 - Firefox for Android 127 Therefore the button should not be shown, otherwise it mistakenly gives the impression that user could make it work by enabling screen-sharing permission which is not possible on mobile OS. opw-4108833 [1]: https://caniuse.com/mdn-api_mediadevices_getdisplaymedia <img width="333" alt="Screenshot 2024-08-21 at 13 26 13" src="https://github.com/user-attachments/assets/ead3281d-2ef4-412e-8d4f-edab4a85b1e9"> Forward-Port-Of: odoo/odoo#177372
Backport of odoo/odoo#166532 Forward-Port-Of: odoo/odoo#177090 Forward-Port-Of: odoo/odoo#177052
Original PR description
Backport of odoo/odoo#166532 Forward-Port-Of: odoo/odoo#177090 Forward-Port-Of: odoo/odoo#177052
A Factur-X XML generated in Germany should not falsely claim to be compliant to the KoSIT XRechnung. Forward-Port-Of: odoo/odoo#177330
Original PR description
A Factur-X XML generated in Germany should not falsely claim to be compliant to the KoSIT XRechnung. Forward-Port-Of: odoo/odoo#177330
Ticket: 1239 Adhoc-task: 41734 Description of the issue/feature this PR addresses: This task was created to modify the demo data for Uruguay, to avoid using real partner information. 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#176807
Original PR description
Ticket: 1239 Adhoc-task: 41734 Description of the issue/feature this PR addresses: This task was created to modify the demo data for Uruguay, to avoid using real partner information. 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#176807
Simple patch that prevent the prefetch of the oauth token Forward-Port-Of: odoo/odoo#177259
Original PR description
Simple patch that prevent the prefetch of the oauth token Forward-Port-Of: odoo/odoo#177259
Steps to reproduce: - Open website menu editor - Add a child menu to a menu - Delete the parent menu - Save Old behavior: a traceback appears New behavior: no traceback, parent and children menus are correctly deleted. This commit fixes the issue by properly deleting children menus recursively before deleting the parent. opw-4119441 Forward-Port-Of: odoo/odoo#177243
Original PR description
Steps to reproduce: - Open website menu editor - Add a child menu to a menu - Delete the parent menu - Save Old behavior: a traceback appears New behavior: no traceback, parent and children menus are correctly deleted. This commit fixes the issue by properly deleting children menus recursively before deleting the parent. opw-4119441 Forward-Port-Of: odoo/odoo#177243
Steps to reproduce: - Install module 'France - Adding Mandatory Invoice Mentions' - Switch to FR company - Contacts > Create french company - Sales & Purchase tab > set SIRET value - Create an invoice for this company > Print it The SIRET number does not show up anywhere on the invoice, despite the conditions being met. The SIRET number has been mandatory since July 1st 2024 in France This sometimes happens because the xpath only edits one of the 3 possible address tags added in 16.
Original PR description
Steps to reproduce: - Install module 'France - Adding Mandatory Invoice Mentions' - Switch to FR company - Contacts > Create french company - Sales & Purchase tab > set SIRET value - Create an invoice for this company > Print it The SIRET number does not show up anywhere on the invoice, despite the conditions being met. The SIRET number has been mandatory since July 1st 2024 in France This sometimes happens because the xpath only edits one of the 3 possible address tags added in 16.0. There is no need to edit the margin because the address already has mb-0 in its classes. opw-3865644 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177060
Steps to reproduce the bug: - Enable by-porduct option in manufacturing settings - Create a storable product “P1” with a BoM: - Components: C1 - by-product: C2 tracked by serial number - Create a manufacturing order (MO) to produce one unit of P1. - Confirm the MO. - Click on the detailed operation to select the serial number for C2. Problem: the field "lot_id" should be displayed instead of "lot_name". because we should be able to create and use existing SN with byproduct mov
Original PR description
Steps to reproduce the bug: - Enable by-porduct option in manufacturing settings - Create a storable product “P1” with a BoM: - Components: C1 - by-product: C2 tracked by serial number - Create a manufacturing order (MO) to produce one unit of P1. - Confirm the MO. - Click on the detailed operation to select the serial number for C2. Problem: the field "lot_id" should be displayed instead of "lot_name". because we should be able to create and use existing SN with byproduct moves. opw-[4113887](https://www.odoo.com/web#id=4113887&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#177361 Forward-Port-Of: odoo/odoo#177061
This commit restores the context passing that was lost in the rework of `calendar.event` quick create #114827. Current behavior before PR: Action context is not passed to the `calendar.event` form view when accessed via the calendar popover `View` button. The `New` button above the calendar view passes the context as expected. For example: this button opens the calendar view but the keys `example_context`, `active_id` and `active_model` are not available in the context when an existing cal
Original PR description
This commit restores the context passing that was lost in the rework of `calendar.event` quick create #114827.
Current behavior before PR:
Action context is not passed to the `calendar.event` form view when accessed via the calendar popover `View` button. The `New` button above the calendar view passes the context as expected.
For example: this button opens the calendar view but the keys `example_context`, `active_id` and `active_model` are not available in the context when an existing calendar event is then viewed in a form. `<button name="calendar.action_calendar_event" type="action" context="{'example_context': True}"/>`
Desired behavior after PR is merged:
Action context is available in the `calendar.event` form view when the form is accessed via the calendar popover form.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176896
Forward-Port-Of: odoo/odoo#176130### Steps to reproduce: - Activate developer mode - Go in Accounting > Configuration > Accounting > Account Groups - Create 4 account groups in a specific λ configuration, for example: ``` 2 \ 21 / \ 210 211 ``` - Go in Accounting > Reporting > Audit Reports > Trial Balance - In options, select "Hierarchy and Subtotals" to see the hierarchy - The hierarchy might be wrong or not, but each time recreating the 211 group, the hierarchy will switch between these two tre
Original PR description
### Steps to reproduce: - Activate developer mode - Go in Accounting > Configuration > Accounting > Account Groups - Create 4 account groups in a specific λ configuration, for example: ``` 2 \ 21 / \…
### Steps to reproduce:
- Activate developer mode
- Go in Accounting > Configuration > Accounting > Account Groups
- Create 4 account groups in a specific λ configuration, for example:
```
2
\
21
/ \
210 211
```
- Go in Accounting > Reporting > Audit Reports > Trial Balance
- In options, select "Hierarchy and Subtotals" to see the hierarchy
- The hierarchy might be wrong or not, but each time recreating the 211 group, the hierarchy will switch between these two trees:
```
2 2
\ / \
21 <--> 210 21
/ \ \
210 211 211
```
### Cause:
The way the `parent_id` field is computed is by doing a [SQL query](https://github.com/odoo/odoo/blob/5c39004a1e37b35a47ed95933060c0aa5dd83803/addons/account/models/account_account.py#L954C9-L975C33) that will:
1. retrieve all combinations of (parent group, child group) for each child, for example [(2, 210), (21, 210)]
2. sort them in decreasing order of parent code_prefix_start length, for example [(21, 210), (2, 210)]
3. select only the first one : [(21, 210)]
4. change the `parent_id` field of the child according to the values retrieved
But a [performance improvement](https://github.com/odoo/odoo/commit/82714afa463adda2b404b4dae81a27423880e499) was applied that only selected the combinations that had `child.parent_id IS DISTINCT FROM parent.id` to avoid updating if nothing changed. This caused the retrieve combinations at step 2 to only be [(2, 210)] in the example. So when updating it breaks the hierarchy.
### Solution:
Filter the records to be updated in the UPDATE.
opw-4066976
Forward-Port-Of: odoo/odoo#176945Before this commit, the user would get a UserError when multiple attachments are merged for export and one of them is corrupted. The error message did not contain information helping the user identify the problematic records. After this commit, the user will get a RedirectWarning stating the number of corrupted files and a link to a form view (if single) or a list view (if multiple) of problematic record(s). ### Example workflow: 1. Go to Accounting > Vendors > Bills. 2. Create a bill wi
Original PR description
Before this commit, the user would get a UserError when multiple attachments are merged for export and one of them is corrupted. The error message did not contain information helping the user…
Before this commit, the user would get a UserError when multiple attachments are merged for export and one of them is corrupted. The error message did not contain information helping the user identify the problematic records. After this commit, the user will get a RedirectWarning stating the number of corrupted files and a link to a form view (if single) or a list view (if multiple) of problematic record(s). ### Example workflow: 1. Go to Accounting > Vendors > Bills. 2. Create a bill with a corrupted attachment. 3. Select the corrupted bill amongst other bills with valid attachments. 4. Click on Print > Original Bills. 5. The error is: "Odoo is unable to merge the generated PDFs." ### Cause: Errors raised by instantiating a PdfFileReader of a corrupted file were handled with a UserError with a static error message. ### Solution: In `_merge_pdfs` method signature, add an optional callback to define the way errors are handled. The default callback reproduces the default behavior. In `_render_qweb_pdf`, a custom callback is defined to keep track of the corrupted streams and log them in the RedirectWarning popup. opw-4067992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177228 Forward-Port-Of: odoo/odoo#174701
Steps to reproduce the issue: ============================= - Install website and events - Go to events page and enable editor - Click on customize and enable sidebar - enable Follow us option - Select a social media icon and enable open in a new window option - Save - Click on the updated icon, it still opens in the same page => the changes aren't saved. Origin of the issue: ==================== The `target` attribute was ignored when saving and `arch_section`. Solution =======
Original PR description
Steps to reproduce the issue: ============================= - Install website and events - Go to events page and enable editor - Click on customize and enable sidebar - enable Follow us option - Select a social media icon and enable open in a new window option - Save - Click on the updated icon, it still opens in the same page => the changes aren't saved. Origin of the issue: ==================== The `target` attribute was ignored when saving and `arch_section`. Solution ======== Add `target` attribute to the allowed root attrs. opw-4077657 Forward-Port-Of: odoo/odoo#177269 Forward-Port-Of: odoo/odoo#177035
This PR aims at improving batch generation support in mail -- Add / Improve configuration parameters support for email queue Ease email queue configuration with better support of two parameters * 'mail.mail.queue.batch.size' which is the email queue size that will be used to search for outgoing emails (matching optional filters and IDs) and then given to 'send'; * 'mail.session.batch.size' which is the batch size of a given segment of email to send using a specific s
Original PR description
This PR aims at improving batch generation support in mail -- Add / Improve configuration parameters support for email queue Ease email queue configuration with better support of two parameters *…
This PR aims at improving batch generation support in mail
-- Add / Improve configuration parameters support for email queue
Ease email queue configuration with better support of two parameters
* 'mail.mail.queue.batch.size' which is the email queue size that will
be used to search for outgoing emails (matching optional filters and IDs)
and then given to 'send';
* 'mail.session.batch.size' which is the batch size of a given segment of
email to send using a specific server, used when splitting emails to send
based on configuration (see '_split_by_mail_configuration');
-- Better email queue usage for mail composer
Current situation
* post a message on a document
* emails are sent in the same transaction if less than 50 followers and
are postponed otherwise (using post-commit hook);
* emails are generated by batch of 50;
* use composer in mass mailing mode
* emails are always sent in the same transaction;
* emails are generated by batch of 500 (configurable using configuration
parameter "mail.batch_size");
What we want: mass mail mode should have the same kind of behavior and force
usage of email queue if number of recipients is more than a threshold, and
use the same parameter for emails generation batch.
Changes
* force_send threshold is now set to 100, and configurable using
"mail.mail.force.send.limit" configuration parameter. It is used in both
main flows: posting a message (and notifying followers), and sending a
mailing.
* emails generation in both flows is done by batches of 500, configurable
using "mail.batch_size" configuration parameter. For notification emails
it was done by batches of 50 but 500 seems acceptable, behaving like
the mail composer;
-- Performance
When possible create mails in batch, using configurable parameters when
iterating on large number of records.
Task-3768123: Mail: Configurable cron queue size
Task-3164278: Mail: Batch send: ensure limit, avoid force
Part of Task-3084943: Event: Improve communication scheduler scalability
Forward-Port-Of: odoo/odoo#177276
Forward-Port-Of: odoo/odoo#177046Currently, the editor uses the bootstrap grid system for the column layouts and the editor CSS rules changes the paddings and the margins of the columns. When the user prints a document, the columns can go one under the other but the paddings and margins set are still applied. As a result, the columns appear off-centered on printing devices. To fix that issue, we will scope the CSS rules that adjust the paddings and margins of the columns to the screen devices. This way, the rules won't be ap
Original PR description
Currently, the editor uses the bootstrap grid system for the column layouts and the editor CSS rules changes the paddings and the margins of the columns. When the user prints a document, the columns can go one under the other but the paddings and margins set are still applied. As a result, the columns appear off-centered on printing devices. To fix that issue, we will scope the CSS rules that adjust the paddings and margins of the columns to the screen devices. This way, the rules won't be applied when printing the document. task-3664950 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168814
The technical refactor in [1] renamed the tax amount in currency from `amount_tax` to `tax_amount_currency`. However, in some instances, it was mistakenly renamed to `tax_amount`, including in the commit description. This commit corrects this minor oversight. [1]: https://github.com/odoo/odoo/commit/68fbdc96 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177318
Original PR description
The technical refactor in [1] renamed the tax amount in currency from `amount_tax` to `tax_amount_currency`. However, in some instances, it was mistakenly renamed to `tax_amount`, including in the commit description. This commit corrects this minor oversight. [1]: https://github.com/odoo/odoo/commit/68fbdc96 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177318
- Intall website_sale_product_configurator - Create a product A with price 3 999.00 € - Add an optional product on product A - Go to shop page - Go to product A - Add to cart - A modal popup appear - Finelize cart --> Issue the price send to datalayer is 3. Because "3 999,00" is send in the json, endead 3999.00. Co-Authored-By: "Louis (loti)" <loti@odoo.com> Forward-Port-Of: odoo/odoo#177387 Forward-Port-Of: odoo/odoo#167962
Original PR description
- Intall website_sale_product_configurator - Create a product A with price 3 999.00 € - Add an optional product on product A - Go to shop page - Go to product A - Add to cart - A modal popup appear - Finelize cart --> Issue the price send to datalayer is 3. Because "3 999,00" is send in the json, endead 3999.00. Co-Authored-By: "Louis (loti)" <loti@odoo.com> Forward-Port-Of: odoo/odoo#177387 Forward-Port-Of: odoo/odoo#167962
Issue ----- Changing the color of the product's ribbon to a custome one in eCommerce has no effect outside of the editor (after clicking "Save", the background color of the ribbon returns to the default one). Change ----- Since the bg-primary class is now set on the ribbon HTML at creation. https://github.com/odoo/odoo/blob/56fd8440707a0f3f2ba298f8bf016577ca08796b/addons/website_sale/static/src/js/website_sale.editor.js#L180 Remove the bg-primary class from the ribbon. opw-4069818
Original PR description
Issue ----- Changing the color of the product's ribbon to a custome one in eCommerce has no effect outside of the editor (after clicking "Save", the background color of the ribbon returns to the default one). Change ----- Since the bg-primary class is now set on the ribbon HTML at creation. https://github.com/odoo/odoo/blob/56fd8440707a0f3f2ba298f8bf016577ca08796b/addons/website_sale/static/src/js/website_sale.editor.js#L180 Remove the bg-primary class from the ribbon. opw-4069818 Forward-Port-Of: odoo/odoo#175687
Export routes ('/web/export/csv' and '/web/export/xlsx') are marked as read-only, but the _export_rows() can actually create ir_model_data rows in the database. If import-compatible export is enabled and you export a row without an external ID, you will get a traceback if the readonly replica feature is enabled. The fallback mechanism of the readonly transaction to retry the current request doesn't work because the `except Exception as exc` in export routes changes the exception type (=> trac
Original PR description
Export routes ('/web/export/csv' and '/web/export/xlsx') are marked as read-only, but the _export_rows() can actually create ir_model_data rows in the database. If import-compatible export is enabled and you export a row without an external ID, you will get a traceback if the readonly replica feature is enabled.
The fallback mechanism of the readonly transaction to retry the current request doesn't work because the `except Exception as exc` in export routes changes the exception type (=> traceback).
=> Remove the readonly flag from export routes.
Forward-Port-Of: odoo/odoo#177262Summary ----- Normally, in the load.py method, when there is an error in creating the recordset to be imported, the records are then created one by one. The following commit prevents this behavior in case of a failure to create the recordset in one go: https://github.com/odoo/odoo/pull/173094/commits/ced1ec251d361d8a3ca32ad51e8516668447ca0e. Steps to reproduce ----- Create a module that redefines the create method of the res.users model to throw an error if vals_list contains at least 2
Original PR description
Summary ----- Normally, in the load.py method, when there is an error in creating the recordset to be imported, the records are then created one by one. The following commit prevents this behavior in case of a failure to create the recordset in one go: https://github.com/odoo/odoo/pull/173094/commits/ced1ec251d361d8a3ca32ad51e8516668447ca0e. Steps to reproduce ----- Create a module that redefines the create method of the res.users model to throw an error if vals_list contains at least 2 elements. Import a file containing at least 2 users (by adding the suffix /web#model=res.users&action=import to the URL). Cause ----- The global error message has been logged since the commit cited in the summary. However, a rollback is performed if there are error messages. Fix ----- If we see that there are no errors when creating the records one by one, we then remove the logged error messages. opw-4102745 Forward-Port-Of: odoo/odoo#176901
Some pot files were out of date, at least 1 had a duplicate msgid in it Some modules weren't translated Note that dead pot files (and their associated .po files) were not removed in this PR because 🦥 and removing them doesn't add any value --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Some pot files were out of date, at least 1 had a duplicate msgid in it Some modules weren't translated Note that dead pot files (and their associated .po files) were not removed in this PR because 🦥 and removing them doesn't add any value --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This commit ensures that creating an invoice PDF always uses the invoice company paperformat. Invoice PDF could be generated in one of 2 ways (after clicking the invoice `send & print` button): 1. Non-cron: Either use a single invoice, or multiple invoices with the `download` option checked. 2. Cron: Create PDFs for multiple invoices with no `download` option. The 2 ways would generate differently styled PDFs if the default company had a different paperformat from that of the invoice com
Original PR description
This commit ensures that creating an invoice PDF always uses the invoice company paperformat. Invoice PDF could be generated in one of 2 ways (after clicking the invoice `send & print` button): 1. Non-cron: Either use a single invoice, or multiple invoices with the `download` option checked. 2. Cron: Create PDFs for multiple invoices with no `download` option. The 2 ways would generate differently styled PDFs if the default company had a different paperformat from that of the invoice company. This happened because the paperformat for cron-generated PDFs would be retrieved from the default company and not from the invoice company. task-4046055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176947
**Versions:** 17.0 **Steps to reproduce:** 1. Enable debug mode. 2. Go to the calendar. 3. Create an event using the quick create form. 4. Click on the Odoo meeting link. 5. Try to clear the meeting. **Issue:** A traceback occurs when attempting to clear a meeting in debug mode. **Cause:** The 'CopyButton' component expects the content to be a string but receives `false`. **Solution:** In the form controller, set `videocall_location` to an empty string instead of `false
Original PR description
**Versions:** 17.0 **Steps to reproduce:** 1. Enable debug mode. 2. Go to the calendar. 3. Create an event using the quick create form. 4. Click on the Odoo meeting link. 5. Try to clear the meeting. **Issue:** A traceback occurs when attempting to clear a meeting in debug mode. **Cause:** The 'CopyButton' component expects the content to be a string but receives `false`. **Solution:** In the form controller, set `videocall_location` to an empty string instead of `false` in `beforeExecuteActionButton`. Task-4091314 Forward-Port-Of: odoo/odoo#177447 Forward-Port-Of: odoo/odoo#175496
23 changes
Enhancements to existing features
The barcode testing tools were modernized to make automated checks clearer and easier to maintain. Test failures now stop immediately, reducing noisy follow-up errors and helping teams identify issues faster.
Original PR description
- switch to individual exports, named functions, and namespaced import - make `fail` fail immediately, otherwise the tour continues running until the python kills everything, which generates a bunch of additional and unhelpful errors[^1] - fix up a few jsdocs [^1]: https://runbot.odoo.com/runbot/build/67090511
Manufacturing shop floor completion now records consumed materials and by-products at the right moment, helping quantities and costs stay aligned with what was actually produced. Barcode manufacturing forms also avoid unnecessary lot or serial number change warnings caused by an incorrect comparison.
Original PR description
That's a splited version of this PR -> https://github.com/odoo/enterprise/pull/60954 ## mrp_workorder: adapt shop floor to match WO behavior Marking components and byproducts as consumed inside the button_finish method, instead of before calling it, will allow updating the value for each product proportionally to qty_producing when the WO is completed. Also add a test to ensure that shop floor "consumed in operation" behavior stays correct. ## stock_barcode_mrp: correctly do lot/SN change check in form view Before this commit, the condition inside saveFormView for checking if the lot name changes was always returning True, because it was compared 2 different types. task: 3810344
URLs used in WhatsApp-related flows and supporting website/studio test scenarios were updated to a cleaner, more human-readable format. This improves clarity for users and aligns automated checks with the newer link style without changing core business behavior.
Original PR description
*= test_web_studio, test_website_sale_full, whatsapp This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
Time off types created by country-specific payroll localizations are now linked to the correct country. This helps employees see only relevant leave options for their location, reducing confusion when requesting time off.
Original PR description
Currently, when you try to take a time off, you'll have the list of all time off types, cause there is no field "country" on the leave type. So, if you have "sick leave" in belgium, "sickness" in US and "sick holiday" in India, you'll see the three of them. For every L10N that creates a time off type, this commit assigns the right country to the time off type task-3978260
This update prepares manufacturing planning to distinguish products that share the same variant but have different non-variant options, such as pizza toppings or supplements. It supports more accurate stock, purchase, and manufacturing flows, though the user-facing display of these options will be handled separately.
Original PR description
As for now, it was not possible to differentiate products variants with different attributes that did not create a variant. Let's take a pizza as an example. The product template is a pizza, with an…
As for now, it was not possible to differentiate products variants with different attributes that did not create a variant. Let's take a pizza as an example. The product template is a pizza, with an attribute "type" with "margherita, veggie, bbq" which create variants. We also have another attribute "supplements" with values "extra cheese" and "extra peperoni" that do not create variants. As for now, it was not possible to differentiate stock moves with the same pizza variant but with different values for the 'no_variants' attributes (i.e. no difference between two pizza of same type with different supplements). The same applies to purchases, but also to manufacturing orders. The community pr addresses the technical part and thus the never attribute values are not displayed on the different views, and this pr only updates some function signatures. Another commit/PR will take care of making it accessible for the user task-id: 4017183 community: https://github.com/odoo/odoo/pull/171727
When a field service project is moved to another company, its worksheet template now updates automatically to the appropriate template for that company. This helps keep project paperwork aligned with the correct company settings and reduces manual adjustments.
Original PR description
- Update worksheet template based on company change on project form: if moving to Company another company, switch to the template with the lowest sequence with that company. task-3689394
Resolved issues and error corrections
This update changes automated tests to use Odoo's own time-freezing helper instead of an external decorator. It improves test cleanup and reduces the risk of unreliable test results, with no expected impact on end users.
Original PR description
As using freezegun.freeze_time decorator on test classes is discouraged, a custom freeze_time object can be used as a replacement that properly manage the cleanup. With this commit, the problematic usages are replaced by the custom object.
Miscellaneous changes
Steps to reproduce 1. Go to the users, click on Marc Demo 2. apply empty groups for documents 3. Create an activity from the chatter of a document 4. Assign it to Marc Demo for instance 5. As Marc Demo, click on the "view document" button in the notification email 6. The user will arrive on AppSwitcher Technical Reason: With commit https://github.com/odoo/enterprise/commit/8e13e68d8a6dcff3da61c60b108e4583860cfcbe, the user clicks on the link will redirect them to the document preview u
Original PR description
Steps to reproduce 1. Go to the users, click on Marc Demo 2. apply empty groups for documents 3. Create an activity from the chatter of a document 4. Assign it to Marc Demo for instance 5. As Marc Demo, click on the "view document" button in the notification email 6. The user will arrive on AppSwitcher Technical Reason: With commit https://github.com/odoo/enterprise/commit/8e13e68d8a6dcff3da61c60b108e4583860cfcbe, the user clicks on the link will redirect them to the document preview using 'ir.actions.act_url'. This later appears on the AppSwitcher because the user does not have access to the document group. After this Commit: Users who have no document groups will access the form view of the document via the link. Task-4052827 Forward-Port-Of: odoo/enterprise#66966
**Before this PR:** The style of some knowledge templates was broken when attempting to export or print, lacking proper formatting as per the templated structure. It seemed like there was an issue with the template's responsiveness. **After this PR:** Now, the issue has been addressed, and now the template is appropriately formatted and styled, ensuring correctness during export. **Task**-3664950 Forward-Port-Of: odoo/enterprise#56221
Original PR description
**Before this PR:** The style of some knowledge templates was broken when attempting to export or print, lacking proper formatting as per the templated structure. It seemed like there was an issue with the template's responsiveness. **After this PR:** Now, the issue has been addressed, and now the template is appropriately formatted and styled, ensuring correctness during export. **Task**-3664950 Forward-Port-Of: odoo/enterprise#56221
Step to reproduce: - Activate analytic accounting in the Accounting settings - Create an analytic account - Create an invoice with this new analytic account - Create a horizontal group, for example on the product_id field. - Enable the Profit and Loss report on the horizontal group - Open the P&L report and activate both the analytical and the horizontal groupby filters. => no result is displayed in the column of the analytical filter. Cause of the issue: When activating the an
Original PR description
Step to reproduce: - Activate analytic accounting in the Accounting settings - Create an analytic account - Create an invoice with this new analytic account - Create a horizontal group, for example…
Step to reproduce: - Activate analytic accounting in the Accounting settings - Create an analytic account - Create an invoice with this new analytic account - Create a horizontal group, for example on the product_id field. - Enable the Profit and Loss report on the horizontal group - Open the P&L report and activate both the analytical and the horizontal groupby filters. => no result is displayed in the column of the analytical filter. Cause of the issue: When activating the analytic groupby, it creates a shadowing of the move lines based on the analytic lines. This shadowing loses most of the data of the move lines, which can therefore no longer be of use to create more advanced filters. Proposed solution: When doing the shadowing, if the account.analytic.line does not have the column present in the account.move.line, then takes the value of the related move line, instead of setting the value to NULL as it was done before. opw-4048157 Forward-Port-Of: odoo/enterprise#67364 Forward-Port-Of: odoo/enterprise#66980
Before this commit, users could encounter an access error when attempting to connect to Google Calendar. If a user was removed from an appointment but an existing calendar event still belonged to that user, all attendees of that event would be unable to sync their calendar with Google, resulting in an access error. The error message displayed was: Sorry, Marc Demo (id=6) doesn't have 'read' access to: - Appointment Type, Test Demo (appointment.type: 3). opw-4109304 Forward-Port-Of: odoo/
Original PR description
Before this commit, users could encounter an access error when attempting to connect to Google Calendar. If a user was removed from an appointment but an existing calendar event still belonged to that user, all attendees of that event would be unable to sync their calendar with Google, resulting in an access error. The error message displayed was: Sorry, Marc Demo (id=6) doesn't have 'read' access to: - Appointment Type, Test Demo (appointment.type: 3). opw-4109304 Forward-Port-Of: odoo/enterprise#68673
Steps to reproduce: - open consolidation - Select one of the consolidation - Smart button > Consolidated balance - Change the unit currency and put e.g. `In K€` Issue: Keyerror Cause: When opening the consolidated balance, the line does not take into account all the keys ghenerally present in other reports https://github.com/odoo/enterprise/blob/saas-17.2/account_consolidation/report/builder/abstract.py#L272-L278 Solution: Using get to be more defensive. No change is made in the
Original PR description
Steps to reproduce: - open consolidation - Select one of the consolidation - Smart button > Consolidated balance - Change the unit currency and put e.g. `In K€` Issue: Keyerror Cause: When opening the consolidated balance, the line does not take into account all the keys ghenerally present in other reports https://github.com/odoo/enterprise/blob/saas-17.2/account_consolidation/report/builder/abstract.py#L272-L278 Solution: Using get to be more defensive. No change is made in the consolidation module as it will be deperecated in 18.0. opw-4089130 Forward-Port-Of: odoo/enterprise#68436
As per section 34(2) of CGST Act 2017, credit notes for invoices from the financial year cannot be included in GSTR after November 30th. With this PR, if a credit note is created after November 30th of the financial year, an alert will be displayed to remind users to exclude the tax, as it cannot be included in GSTR. POT file also added for `l10n_in_gstr_reports` **task**-3915664 Forward-Port-Of: odoo/enterprise#68702 Forward-Port-Of: odoo/enterprise#66713
Original PR description
As per section 34(2) of CGST Act 2017, credit notes for invoices from the financial year cannot be included in GSTR after November 30th. With this PR, if a credit note is created after November 30th of the financial year, an alert will be displayed to remind users to exclude the tax, as it cannot be included in GSTR. POT file also added for `l10n_in_gstr_reports` **task**-3915664 Forward-Port-Of: odoo/enterprise#68702 Forward-Port-Of: odoo/enterprise#66713
Purpose of this PR: CoA Report trial balance test adjusted to accommodate for the new account, 173.01 Deferred expenses Community PR that adds new account: #176681 opw-4105993 Forward-Port-Of: odoo/enterprise#68578
Original PR description
Purpose of this PR: CoA Report trial balance test adjusted to accommodate for the new account, 173.01 Deferred expenses Community PR that adds new account: #176681 opw-4105993 Forward-Port-Of: odoo/enterprise#68578
before this commit: Service type `FEDEX_INTERNATIONAL_CONNECT_PLUS` was not available the list 'fedex_service_type'. After this commit: Missing service type is added in the list. reference fedex doc: https://developer.fedex.com/api/en-us/guides/api-reference.html#servicetypes opw-4061797 Forward-Port-Of: odoo/enterprise#64250
Original PR description
before this commit: Service type `FEDEX_INTERNATIONAL_CONNECT_PLUS` was not available the list 'fedex_service_type'. After this commit: Missing service type is added in the list. reference fedex doc: https://developer.fedex.com/api/en-us/guides/api-reference.html#servicetypes opw-4061797 Forward-Port-Of: odoo/enterprise#64250
We need to comply with DIAN validations for Credit/Debit notes that do not reference an invoice, by sending "Invoice Period". For now, send the invoice period start date and end date as invoice date for Credit/Debit notes without reference to the invoice. task-3926204 Forward-Port-Of: odoo/enterprise#68364
Original PR description
We need to comply with DIAN validations for Credit/Debit notes that do not reference an invoice, by sending "Invoice Period". For now, send the invoice period start date and end date as invoice date for Credit/Debit notes without reference to the invoice. task-3926204 Forward-Port-Of: odoo/enterprise#68364
"Colony code" translation changed from: "Código postal" => "Código de colonia" Forward-Port-Of: odoo/enterprise#68600 Forward-Port-Of: odoo/enterprise#68566
Original PR description
"Colony code" translation changed from: "Código postal" => "Código de colonia" Forward-Port-Of: odoo/enterprise#68600 Forward-Port-Of: odoo/enterprise#68566
**Current behavior:** There are several related bugs when operating in a multi-company environment with the barcode app: *Given:* we have three companies in the selector (A, B, C) where company A is the first/default/primary of the three. ***Case 1: (CompanyB and CompanyC are checked, either can be focused)*** 1) Scanning the barcode for CompanyC's manufacturing operation and then, within the barcode view, scanning a product which belongs exclusively to CompanyB will make it impossib
Original PR description
**Current behavior:** There are several related bugs when operating in a multi-company environment with the barcode app: *Given:* we have three companies in the selector (A, B, C) where company A is…
**Current behavior:** There are several related bugs when operating in a multi-company environment with the barcode app: *Given:* we have three companies in the selector (A, B, C) where company A is the first/default/primary of the three. ***Case 1: (CompanyB and CompanyC are checked, either can be focused)*** 1) Scanning the barcode for CompanyC's manufacturing operation and then, within the barcode view, scanning a product which belongs exclusively to CompanyB will make it impossible to use the back button (despite the product correctly not being added as a line in the operation). 2) Repeating the setup with a different operation type (e.g., receipt) *will* add the product to the picking but it will not be possible to validate/take out of draft from either the barcode app nor from the backend. ***Case 2: (only CompanyC checked and focused)*** 1) Scanning the barcode for CompanyC's manufacturing operation type will open the barcode operation view for CompanyA's manufacture operation. Products available to CompanyC can be added. Trying to validate the order will cause an access error, however the MO is still created in the backend. 2) Scanning the barcode for either CompanyB or CompanyA's non-manufacturing operations will show an access error dialog, but an (empty) transfer will still be created in the backend for the respective company. --- **Expected behavior:** In case 1, scanning a product which is not available to the current company should not trap the user in the barcode operation view. It should also not add these inaccessible products to a picking thereby making them unable to be validated. In case 2, we should respect the company defined on a manufacturing operation type which corresponds to a scanned barcode. Additionally, it should not be possible to create empty transfers for companies which are not currently checked/active. --- **Cause of the issue:** Problem 1: production records (unlike pickings) cannot be created until a product is added in the barcode view. Because of this different flow, they are created with less context than other operation types and there was no mechanism by which their `company_id` could be inferred. This caused them to use the default value as defined in the `MrpProduction` model (`self.env.company`)- which is problematic in the barcode app, as this field does not actually correspond to the focused/active company. Problem 2: when scanning a picking type from the main menu of the barcode app, the company of the picking type was not getting respected which would cause a new picking record to be created even when the current user/environment did not have permission. --- **Fix:** 1. Create production records using a default `company_id` value informed by their `picking_type_id` rather than the environment 2. In the main_menu barcode scan route, use the current user's allowed company ids (from their cookies) to restrict searchable records 3. When scanning products in a barcode operation view, use the company_id of the opened operation type to restrict the domain of searchable records. opw-3999622 Forward-Port-Of: odoo/enterprise#67902 Forward-Port-Of: odoo/enterprise#65433
This commit fixes a small bug in the SQL. It removes an unused join with company_id to avoid adding unnecessary lines. Additionally, it uses fields_id instead of ir_prop.name and adds fallback options for ir_prop. If the res_id is not found in the database, the ir_prop without a res_id or company_id will be used. To test it, simply open the production analysis, create a BOM, and verify that the expected fields are correctly populated. Forward-Port-Of: odoo/enterprise#67819
Original PR description
This commit fixes a small bug in the SQL. It removes an unused join with company_id to avoid adding unnecessary lines. Additionally, it uses fields_id instead of ir_prop.name and adds fallback options for ir_prop. If the res_id is not found in the database, the ir_prop without a res_id or company_id will be used. To test it, simply open the production analysis, create a BOM, and verify that the expected fields are correctly populated. Forward-Port-Of: odoo/enterprise#67819
Customers redirected from email have the access_token of invoice while subscription is expecting order access_token so it can not be paid for, and redirection on json url causes infinite loading and frozen screen. Steps to reproduce the issue: 1. Create a new subscription and confirm it 2. Create the invoice and confirm it 3. Send the invoice by email so the customer pay it 4. Select the payment method CARD by Stripe. 5. Select the option "Automate payments for this subscription" (
Original PR description
Customers redirected from email have the access_token of invoice while subscription is expecting order access_token so it can not be paid for, and redirection on json url causes infinite loading and frozen screen. Steps to reproduce the issue: 1. Create a new subscription and confirm it 2. Create the invoice and confirm it 3. Send the invoice by email so the customer pay it 4. Select the payment method CARD by Stripe. 5. Select the option "Automate payments for this subscription" (Automatically the option save my payment details will be selected) How this commits fixes the issue: Replace invoice access_token by the subscription access_token. opw-4080536 Forward-Port-Of: odoo/enterprise#67777
### Steps to reproduce the issue: 1. Create a Batch of Payments 2. Create a Bank Statement Line and reconcile it with one of the Payments in the Batch 3. Go on any other Bank Statement Line and go to the Batch section 4. The amount shown on the line of the batch did not change ### Explanation: If a Batch is partially reconciled with Bank Statement Lines, `_compute_from_payment_ids_`, which would recalculate `amount_residual`, is not called. ### Fix reasoning: `is_matched` updat
Original PR description
### Steps to reproduce the issue: 1. Create a Batch of Payments 2. Create a Bank Statement Line and reconcile it with one of the Payments in the Batch 3. Go on any other Bank Statement Line and go to the Batch section 4. The amount shown on the line of the batch did not change ### Explanation: If a Batch is partially reconciled with Bank Statement Lines, `_compute_from_payment_ids_`, which would recalculate `amount_residual`, is not called. ### Fix reasoning: `is_matched` updates on every reconciliation between a Bank Statement Line and a Payment. Adding it to the dependencies of `_compute_from_payment_ids` will make reconciliations trigger the method. opw-4062387 Forward-Port-Of: odoo/enterprise#68547 Forward-Port-Of: odoo/enterprise#67519
Versions: ------------ 17.0 Steps to reproduce: ------------------------- 1. Send a sign request with 2 signers, setting a reminder to be sent every day. 2. Two emails will be sent to different signers. 3. Change the local date to 2 days ahead. 4. Run the "Send: Sign Reminder" cron. - Two more emails will be received, and one signer will complete their sign request. 5. Change the dates again and run the cron job. - One email will be sent to the remaining signer. 6. From the
Original PR description
Versions:
------------
17.0
Steps to reproduce:
-------------------------
1. Send a sign request with 2 signers, setting a reminder to be sent every day.
2. Two emails will be sent to different signers.
3. Change the local date to 2 days ahead.
4. Run the "Send: Sign Reminder" cron.
- Two more emails will be received, and one signer will complete their sign request.
5. Change the dates again and run the cron job.
- One email will be sent to the remaining signer.
6. From the old sign request email, copy the link and try to resend it.
- The user should not be able to resend the new link.
Issue:
-------
Resending the link does not check the state of the sign request and items, allowing multiple sends.
Solution:
-----------
Resending the link is only possible if the request and items are not already completed, canceled, or refused.
task: 4002440
Forward-Port-Of: odoo/enterprise#68481
Forward-Port-Of: odoo/enterprise#65853Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency: All - Create a manufacturing order: - Product: P1 - Quantity: 20 - Confirm the MO - Set the qty producing 12 - click on the quality check: - Button Fail - Quantity: 5 - Valide the Mo and create a backorder - click on the quality check:
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency:…
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component: C1
- Create a quality point:
- Product: P1
- Operation: Manufacturing
- Control per: Quantity
- Control Frequency: All
- Create a manufacturing order:
- Product: P1
- Quantity: 20
- Confirm the MO
- Set the qty producing 12
- click on the quality check:
- Button Fail
- Quantity: 5
- Valide the Mo and create a backorder
- click on the quality check:
- Button Fail
- Quantity: 1
Problem:
A traceback is triggered:
```
File "/home/odoo/odoo V16/enterprise/quality_control/models/quality.py", line 370, in _move_line_to_failure_location
if not check._can_move_line_to_failure_location():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/enterprise/quality_mrp/models/quality.py", line 49, in _can_move_line_to_failure_location
self.move_line_id = self.production_id.finished_move_line_ids.filtered(
^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 1321, in __set__
write_value = self.convert_to_write(value, records)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 3118, in convert_to_write
return value.id
^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.move.line(96, 98)
```
When we validate the MO to create the backorder, the `_split_productions`
function is called. This results in two move lines:
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1837
The first one has a quantity of 15, which is the remaining quantity
to be processed, and the second line has a quantity of 5, which is the
quantity that has definitely failed. However, these two move lines are
supposed to be ordered first by the failed ones and then by the others.
Because, in the current situation, we take the move line with the
quantity of 15, reduce it by the 12 units processed in this MO,
leaving 3. As a result, we will have two remaining move lines:
3 + 5 (already failed), and both will be used in the backorder.
But if they were ordered by the failed ones first, we would subtract
12 from 5, resulting in -7, and then reduce the line with 15 - 7 = 8
in the move line that will be used in the backorder."
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1848-L1858
opw-4064656
Forward-Port-Of: odoo/enterprise#68580
Forward-Port-Of: odoo/enterprise#6747411 changes
New functionality added to Odoo
This update adds a new module specifically designed to support the unique requirements for printing checks in the Philippines. This allows businesses using Odoo to accurately generate and manage Philippine check formats, ensuring compliance with local regulations and improving financial reporting.
Original PR description
Add a new module that supports printing to the Philippine check format Task id # 3576570
A new module has been added to support Colombian e-commerce requirements by enhancing the checkout form with country-specific fields including City, Identification Type, Fiscal Regimen, and Obligation Type. The module validates these fields appropriately and relabels the VAT field as "Identification Number" to match Colombian terminology, improving the checkout experience for Colombian customers.
Original PR description
Add the Colombian E-Commerce localization module that includes: * Add fields to the checkout form: City, Identification Type, Fiscal Regimen, and Obligation Type. * Validate new fields. * Change the label name for 'Vat' to 'Identification Number' * Show obligation type and fiscal regimen blocks only when the identification type is 'NIT'. * Take into account the identification type when validating the VAT in the checkout form. related: https://github.com/odoo/odoo/pull/169205 task-2856566
Enhancements to existing features
The IoT module now includes a fallback option for long-polling connections. When long-polling fails, the system can now seamlessly switch to alternative connection methods like WebSocket without displaying error popups to users. This improves the reliability and user experience of IoT device connections by reducing unnecessary error notifications.
Original PR description
If longpolling fails, it displays a fail popup with help messages. We added a `fallback` parameter allowing to prevent this popup from displaying if we want to fallback on other methods (e.g. websocket).
This update adds support for CAR (Código de Anotación de Registro), a Peruvian payment voucher identifier, to the general ledger reports. The change ensures the accounting system properly formats and displays payment voucher information including RUC numbers, document types, series, and folio numbers in compliance with Peruvian tax regulations.
Original PR description
The CAR (Código de Anotación de Registro) is an alphanumeric identifier composed of payment voucher data. It includes: - RUC number of the issuer: 11 numeric digits. - Type of payment voucher: 2 numeric digits. - Payment voucher series: 4 alphanumeric digits. - Payment voucher number: 10 alphanumeric digits.  Previously, support for SIRE reports was added. This change updates the general ledger to ensure compatibility. Adjusted the format of the 'book' field to include zero-padded and truncated document types, series, and folio numbers. Legal reference: https://www.sunat.gob.pe/legislacion/superin/2021/anexo-112-2021.pdf  Resolutions: [Resolución de Superintendencia N.° 112-2021](https://drive.google.com/file/d/19iWgqTeTn5WNIg3RpfAyHtF6xSIFL2rH/view?usp=sharing)
Resolved issues and error corrections
Fixed a bug where WhatsApp messages were not triggering browser push notifications. Users who have WhatsApp configured and enabled notifications will now receive push alerts when WhatsApp messages arrive, improving communication visibility and responsiveness.
Original PR description
Performs test of a related commit in communiy: [FIX] mail: include whatsapp in webpush notifications There are couple of components in the notification architecture. For the sake of illustration let's simplify it with the following: Sender -> Queuer -> Receiver Queuer is an FMC backend, so we should only be concerned about the other two. Receiver which is just a frontend service worker that will generate notifications as soon as he receives an event. The issue (before this commit) was in the Sender part, which was skipping whatsapp type message generation. [Reproduce] - Configure Whatsapp account, include user A in "Notify users" - Allow notifications in your browser (chat icon/ OdooBot suggestion) - Send a whatsapp message to the configured whatsapp number - BUG: Push notification not showing up opw-3720699
This fix ensures that employee service rates are properly adjusted based on customer tax settings, just like product prices. Previously, when a customer had a fiscal position that changed tax treatment (e.g., from tax-inclusive to tax-exclusive), the service charges would calculate incorrectly while product charges calculated correctly. Now both are handled consistently.
Original PR description
### Steps to reproduce: - Create a fiscal position that converts 19% tax-inclusive into 19% tax-exclusive. - Create a product with 19% tax inclusive. - Create a contact and assign the above fiscal…
### Steps to reproduce: - Create a fiscal position that converts 19% tax-inclusive into 19% tax-exclusive. - Create a product with 19% tax inclusive. - Create a contact and assign the above fiscal position. - Navigate to a field service project and add an employee with a tax-included rate in the employee mapping. - Create a new field service task for the customer with the assigned fiscal position and add one hour for the employee in the mapping. - Add the product with 19% tax included to the task. - Mark the task as done. #### Current Behavior: - The product unit price is calculated excluding tax. - The service unit price remains calculated as tax-included. #### Expected Behavior: Both product and service unit prices should be calculated consistently as tax-excluded when the tax is set to 19% exclusive. ### Cause of the issue: When creating a new sale order line if the unit price is not specified "product_id_change" is called which set the correct unit price after applying the fpos by calling `_update_taxes` on the line: https://github.com/odoo/odoo/blob/a09e0c651ea54faa3b41e6012b6d62f143519f07/addons/sale/models/sale_order_line.py#L617-L628 But in our case we are setting the `unit_price` to the employee rate here: https://github.com/odoo/enterprise/blob/e23e01337faeec652d400618cf14aaf3d6d47ef2/industry_fsm_sale/models/project_task.py#L408-L412 and the taxes are not taken into account. ### Fix: The unit price of the employee rate should be updated to reflect the changed taxes from fpos. However, since `_update_taxes` relies on the unit price of the product rather than on the one given to the line: https://github.com/odoo/odoo/blob/a09e0c651ea54faa3b41e6012b6d62f143519f07/addons/sale/models/sale_order_line.py#L685 we can not call the `_update_taxes` directly to update the sol. opw-3853196 Co-authored-by: waha <waha@odoo.com> Forward-Port-Of: odoo/enterprise#67730
This fix resolves an issue where employee identification numbers (INSZ) for people born after 2000 were incorrectly rejected as invalid. The validation logic has been updated to properly handle the different calculation method required for post-2000 birth dates, ensuring all employees can have their identification numbers correctly registered in the system.
Original PR description
If you were born after 2000 your insz number wouldn't be recognized as valid. Steps to reproduce: ------------------- * Install pos_blackbox_be module and HR module * Create an employee with a birth date set after 2000 * Generate an insz number for a person born after 2000 https://www.rsolution.be/rijksregister-nummer-generator.RSolution * Set the number on the employee and remove all `.` and `-` > Observation: When saving the insz wouldn't be recognized as valid Why the fix: ------------ When trying to validate a insz number for a person born after 2000, the calculation is a bit different. You need to add a `2` before `partial_number` to make it work. Explanation can be found on wikipedia here: https://fr.wikipedia.org/wiki/Num%C3%A9ro_de_registre_national opw-4077545
This fix resolves an error that occurred when updating quantities in manufacturing work order steps on the shop floor. The issue was caused by operation notes not being properly recognized in the system, leading to crashes. The fix ensures operation notes are correctly registered so users can update work order information without encountering errors.
Original PR description
## Analysis Since a recent commit (https://github.com/odoo/enterprise/commit/25f72c0b716d5fdc15493b74375106e3d6f580fa), the operation_note is fetched independently from the other fields to avoid…
## Analysis
Since a recent commit (https://github.com/odoo/enterprise/commit/25f72c0b716d5fdc15493b74375106e3d6f580fa), the operation_note is fetched independently from the other fields to avoid performance issues.
This causes issues as, when computing data context (e.g. during `onChange`), we assume that all fields in data are available in config:
```
_computeDataContext() {
...
const data = toRaw(this.data);
for (const fieldName in data) {
const value = data[fieldName];
const field = this.fields[fieldName]; // field == undefined
if (field.relatedPropertyField) { // traceback
continue;
}
...
}
```
## Steps to reproduce
- Create a product "TEST"
- Create a BoM For product "TEST", with a new product "TEST Component".
- Add 1 Operation OP1 (keep default value), set a description
- Add 1 step to OP1, with type "Register Production"
- Create MO for "TEST", Confirm, Plan,
- Start operation OP1
- On ShopFloor, go to MO, select workcenter, open step
- Update quantity: Error
## Solution
We make a way for manually fetched fields (most probably, all HTML fields which can contain base64 images) and add it to the fields to avoid them being undefined and causing tracebacks.
## References
opw-4103712
--
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)Fixed a bug where sales and purchase receipts were not being included in Spanish VAT Record books reports, causing the system to crash when generating these reports. Receipts are now treated the same as invoices, ensuring complete and accurate VAT reporting for Spanish companies.
Original PR description
Currently, receipts are not take into account when generating the VAT Record books ### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * enable sales (or purchase) receipts in the settings * create and confirm a sales receipt * open the generic tax report * select the dates for the receipt. * attempt to generate the VAT Record books You will be met with a traceback. ### Fix Include receipts and treat them as invoices. (confirmed with JCO) opw-4053187 Comunity PR: odoo/odoo#175002
This update fixes a bug in the Knowledge module where rapidly clicking to expand articles in the sidebar could cause errors and display duplicate articles. The fix prevents multiple simultaneous requests from loading the same child articles, ensuring a smoother and more reliable user experience when navigating the article hierarchy.
Original PR description
Purpose: ------- Currently, clicking several times quickly on the caret to unfold an article in the sidebar may throw an error and show the child articles several times in the sidebar. This commit fixes the issue by preventing to make a new request to load the child articles if one has already been made. Task-4099133
Fixed an issue that prevented users from signing field service reports when no worksheet template was configured. Now users can sign and send reports as long as they contain products and timesheets, making the worksheet template optional rather than required.
Original PR description
### Steps to Reproduce: - Create a field service task > switch the worksheet template to false > add products and timesheets > sign report > error because there is no worksheet template set. ### After this PR: - Allow signing the report when there is no worksheet template, it will be possible to sign and send the report as long as there is content to populate the report with ( products and timesheets). task-3974170