Tuesday, March 25, 2025
55 changes · 18.0
New functionality added to Odoo
Adds a new Point of Sale mobile module to support a better POS experience on mobile devices. This helps businesses use Odoo POS more effectively in mobile workflows, improving flexibility for staff on the move.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
Odoo now checks Peppol registration activation much sooner after a company signs up, reducing the wait before invoice receipt can be enabled. It also checks sent invoice status shortly after sending, improving visibility and helping on-premise users who cannot rely on webhooks.
Original PR description
Currently, registering as a receiver on Peppol via Odoo has a poor user experience due to the long delays in activation. The activation process requires a DNS lookup, which is performed on the IAP side every 6 hours. Additionally, the client db queries IAP for the user state every 6 hours before enabling the receipt of invoices, resulting in a typical delay of over 8 hours—often spanning more than a full workday. This commit, together with https://github.com/odoo/iap-apps/pull/989 tries speed things up by - fetching the activation status 1h after registration from IAP (client-db side) - fetching sent invoice status 5 minutes after having sent the invoice This is also a replacement for webhooks for on-prem users who won't be able to use webhooks from this PR: https://github.com/odoo/iap-apps/pull/1008 task-4395265
Resolved issues and error corrections
The Sales app now calculates the uninvoiced balance correctly when discounts are applied to sales order lines. This prevents discounted amounts from being reduced twice, giving users a more accurate view of what still needs to be invoiced.
Original PR description
Steps to reproduce: - Create SO with two products. - Apply 10% discount to both lines. - Confirm SO and create an invoice. - Confirm invoice for only one SOL. - Go to 'Orders to Invoice' and add uninvoiced-balance field to the view using Studio. - Check value of the uninvoiced-balance field. Issue: - The uninvoiced-balance field is not calculated correctly. Cause: - line.price_total already includes the discount, so applying the discount again results in an incorrect calculation. Fix: - Remove price_reduce and directly multiply unit_price_total by qty_to_invoice to ensure the correct calculation of amount_to_invoice. opw-4567563 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
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#202455 Forward-Port-Of: odoo/odoo#202230
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202455 Forward-Port-Of: odoo/odoo#202230
Editing product attributes on product forms is now faster for databases with very large numbers of product attribute lines. The change reduces waiting time when adding or changing attributes, improving day-to-day productivity for users managing large product catalogs.
Original PR description
When there are lots of `product_template_attribute_lines` the computation of the `product_tmpl_ids` field of `product.attribute` can take a bit of time. This in turn slows down the editing of attribute/attribute_values on product.template's FormView. This commit changes the compute method by first doing a `_read_group` to retrieve the templates by attribute. This skips the `__get__` call on `product_attribute.product_attribute_line_ids`. A compound index on `product_template_attribute_line` is also added to speedup the `_read_group` mentioned above. #### speedup Customer database with close to 900 000 product_template_attribute_lines and an average of 100 000 product_template_attribute_lines by attribute_id. Adding a new attribute in a template FormView: 3s -> 500ms. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Hong Kong payroll payslip report has been refined to show updated legal names for Hong Kong office employees and remove sensitive information from payslips. Demo payroll data was also corrected, improving reliability for examples and testing.
Original PR description
Minor improvements on HK payroll: - Update legal name for hk office employees - Remove several sensitive data on payslip - Fix demo data error
UrbanPiper online orders no longer earn loyalty points or rewards in Point of Sale. This prevents customers from receiving duplicate benefits when delivery platforms already provide their own reward programs.
Original PR description
Before this commit: ====================== Loyalty points were awarded for all orders, including those from UrbanPiper (online orders). This allowed customers to earn loyalty points both for dine-in and online orders, leading to earning loyalty points twice. Since online food delivery platforms have their own reward systems, loyalty points should not be granted for these orders. After this commit: ==================== Loyalty points and rewards are now excluded for UrbanPiper orders. Task-4585821
This fixes an issue where accounting document numbers could fail to continue correctly when multiple users or processes created documents at the same time. It helps keep invoice and journal entry numbering consistent and prevents disruptions in accounting workflows.
Original PR description
When looping inside of the `while True` loop because of concurrency, the `sequence_prefix` was not correctly set. This was breaking the behavior of `sequence.mixin` because we were not able to get the last number. Partial revert of 10565c6968a5d0f285f93c4bdc610350999a88e3
Odoo now correctly reads mail server capabilities needed to detect the maximum allowed email size. This helps prevent email sending issues caused by missing size-limit information.
Original PR description
The automatic detection of maximum email size was not working anymore. After this commit, the `esmtp_features` attribute is added, to ensure reliable detection of the email's size. opw-4673107 cc: @Julien00859 @Abridbus
Product images in kanban views now keep the same browser cache URL when the image field comes from the same record. This avoids repeatedly downloading the same images after opening a product and returning to the list, making navigation faster and reducing unnecessary network usage.
Original PR description
Steps to reproduce ================== - Go to the products kanban view - Open a record - Go back to the kanban view => Every product image is downloaded again Cause of the issue ==================…
Steps to reproduce
==================
- Go to the products kanban view
- Open a record
- Go back to the kanban view => Every product image is downloaded again
Cause of the issue
==================
There is a unique query param in the url as the browser doesn't fetch twice the same image from the same url in the same session.
For non related fields, we use the last record update as a unique timestamp.
For related fields, since we don't have the information about the last update, we generate a unique timestamp when instanciating an ImageField component.
It can happen that a related field points to the same model.
This is the case here where the product kanban view uses the "image_128" field.
```py
image_1920 = fields.Image("Image", max_width=1920, max_height=1920)
image_128 = fields.Image("Image 128", related="image_1920", max_width=128, max_height=128, store=True)
```
Solution
========
When a field is related but the relation points to the same model, we can still use the last record update
We can try to detect this by checking if there is a dot in the related path.This update adds automated coverage to ensure Point of Sale orders can be validated when the currency does not use decimal places. It helps prevent checkout issues in countries or setups using whole-unit currencies.
Original PR description
Before this commit, there was no test to ensure that orders could be validated correctly when using a currency with zero decimal places. This commit adds a test to validate an order with a zero decimal places currency, ensuring that the system handles such cases without errors. opw-4595028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users assigned to a child company in a Belgian company structure can now open the Point of Sale without running into an access error. This matters because shops operated under branch or subsidiary companies can use POS normally even when accounting setup is managed at the parent company level.
Original PR description
Some users are encountering access error when opening the pos from a child company Steps to reproduce: ------------------- * Create a child company for "My Belgian Company" * Register this company for the user Marc Demo * Create a shop in the brach * Now connect as Marc Demo * Try to open the PoS > Observation: Access error Why the fix: ------------ Account chart template are only defined in the parent company. opw-4644042
This fixes issues where employees or resources with flexible working hours could still be treated as having standard attendance hours. It prevents Attendance from failing with a division-by-zero error when a working schedule is changed to flexible hours.
Original PR description
## [FIX] resource: make sure flexible resource don't use attendances This commit makes sure the resource calendar attendance is not used for a flexible resource even if that resource has a working…
## [FIX] resource: make sure flexible resource don't use attendances This commit makes sure the resource calendar attendance is not used for a flexible resource even if that resource has a working schedule with hours per day equals to 0 hour. ## [FIX] hr: recompute is_flexible when working schedule becomes flexible Before this commit, when the user sets a working schedule to an employee and convert that working schedule into a flexible working schedule, the employee is not considered as working with flexible hours. This commit makes sure the `_compute_is_flexible` method defined in `hr.employee` model is triggered when the `flexible_hours` field of the working schedule linked to the employee is altered. Steps to reproduce the issue: ----------------------------- 0. Install Attendance app (`hr_attendance` module). 1. Set a working schedule A to employee E 2. Go to the form view of the working schedule A and check `Flexible Hours` field to convert the working schedule as flexible working schedule. 3. Go to Attendance app Expected Behavior: ----------------- The Attendance app should loaded without any issue. Current Behavior: ---------------- A traceback is occurred saying we have a division by zero. opw-4492625
Users who do not have permission to interact with comments will no longer see emoji reaction buttons. This prevents confusing error screens and creates a smoother experience on product and course review pages.
Original PR description
Before this PR: - A user with no access attempts to react with emojis on a comment, resulting in a traceback. After this PR: - The buttons for adding emoji reactions to comments will be hidden for that users. Task-4452408
This fixes a document layout issue where long customer address details could overlap with the shipping address on DIN 5008 quotation PDFs. Businesses using this German document format will get clearer, more professional printed quotes when customer addresses contain many lines.
Original PR description
The aim of this commit is to fix a display bug where the shipping adress is overlapping the address element when too many address lines are present Steps to reproduce: - Install l10n_din5008_sale - Configure the document to use the din5008 layout - Create a UK customer with all the adress fields filled + phone - Create a quotation for that customer and Print the PDF Quote opw-4575257  Becomes  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Installing the Point of Sale event module no longer fails if the default Event Registration product was previously deleted. This helps businesses recover cleanly from product cleanup actions without blocking module installation.
Original PR description
Currently a `ParseError` is arising when the user installs the `pos_event` module after deleting `Event Registration` product from the products. Steps to reproduce: --- - Install `event_product`…
Currently a `ParseError` is arising when the user installs the `pos_event` module after deleting `Event Registration` product from the products.
Steps to reproduce:
---
- Install `event_product` application (without demo data).
- Delete `Event Registration` from products
- Now install `pos_event` module
Traceback:
---
```
Exception: Cannot update missing record 'event_product.product_product_event'
ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/pos_event/data/event_product_data.xml:4, somewhere inside <record id="event_product.product_product_event" model="product.product">
<field name="available_in_pos">True</field>
<field name="pos_categ_ids" eval="[(6, 0, [ref('pos_event.pos_category_event')])]"/>
</record>
```
The error occurs because the user deleted the product, and then tried to install the other module.
This commit solves the above issue by using `forcecreate="False"` to bypass record creation if it violates checks.
https://github.com/odoo/odoo/blob/f5378fadf910d193cbb44a4d1c10a5a15d8b9a51/odoo/tools/convert.py#L364
sentry-5731062091
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix ensures loyalty history only counts activity tied to the correct sale order type. It prevents eWallet or loyalty amounts from being inflated when point-of-sale and online orders happen to share the same internal ID.
Original PR description
Description of the issue/feature this PR addresses: - Setup an eWallet for POS and website - Place an order of eWallet top up from POS - Place an order of eWallet top up from ecommerce - Make sure both has the same ID, or any POS order that has the same ID with sale.order ID - You will see the loyalty issued becomes the sum of the unrelated model Current behavior before PR: - The loyalty showed in Portal / Odoo will be wrong if it clashes with other model ID Desired behavior after PR is merged: - Only consider the order that comes from the sale order model --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The wording of an error message in the Point of Sale loyalty flow was corrected when a gift card has already been sold. This makes the message clearer and more professional for staff using the system.
Original PR description
Before this commit, the error message shown when a gift card had already been sold contained incorrect grammar: "This Gift card is already been sold." opw-4656131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves Odoo IoT display handling so connected displays can be detected and rotated correctly when running under Wayland. It helps point-of-sale and IoT display setups remain reliable on newer Linux display environments.
Original PR description
This commit is a backport of the display driver changes from commit 078533b. These changes allow displays to be detected and rotated correctly under Wayland. task-4657986 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents errors when a user manages time off allocations but has no employee record in the current company. The system now checks for an available employee calendar before loading allocation data, improving reliability for HR workflows.
Original PR description
Issue: if user does not have employee in the current company in managment the allocation will try to load his employee calendar which raise the error Fix: check if there is an employee for the user before trying to fetch the data Task: 4660184 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update bundles several bug fixes across Odoo, including faster loading of image-heavy kanban views, corrected invoice dating for Argentina, improved checkout handling for Brazil, and compliance updates for German e-invoicing. It also resolves smaller issues in messaging, POS loyalty flows, inventory route searches, and spreadsheet styling, reducing user friction and business process errors.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where reopening the website editor could fail after a user removed every tab from a Tabs block. The editor now handles that empty-tab situation gracefully, helping users continue editing without an error screen.
Original PR description
**Problem**: After commit [https://github.com/odoo-dev/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c](https://github.com/odoo/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c), if all tabs…
**Problem**: After commit [https://github.com/odoo-dev/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c](https://github.com/odoo/odoo/commit/80fde992370e4474c27a383a61814ce1159f550c), if all tabs in a "Tabs" block are removed and saved, the next time the editor is opened, there is a traceback because `navEl` is `null`. **Solution**: Use the first value from `possibleValues` in case `navEl` is `null` this will prevent traceback in that case but does not prevent reaching the no tab situation (Still able to remove all tabs). **Steps to Reproduce**: 1. Add a **"Tabs"** block. 2. Click inside the first tab to edit its content. 3. Press **Backspace** repeatedly until the tab is completely removed. 4. Repeat for all remaining tabs until none are left. 5. Save and exit the editor. 6. Open the editor again. - **Issue**: A traceback occurs due to `navEl` being `null`. **opw-4608389** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in the HTML editor where clicking text above a large image could unexpectedly scroll the page to the image, making the text difficult to edit. The editor now only scrolls when most of the selected content is out of view, keeping editing stable and predictable.
Original PR description
**Problem**: When adding text followed by **"Shift+Enter"** and a long image, clicking to edit the text triggers `scrollTo`, causing the view to jump to the image instead. This makes it impossible to edit the text, as the selection keeps switching to the image. This happens because, on `pointerdown`, the selection changes to text, triggering a scroll. On `pointerup`, the target becomes the image, changing the selection again. **Solution**: Scroll only if more than half of the content is not visible. **Steps to Reproduce**: 1. Add text and press **"Shift+Enter"**. 2. Insert a long image below the text. 3. Try to edit the text: - **Issue**: View scrolls to the image, making text uneditable. opw-4606741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the Time Off allocation form from crashing when a user opens it in a company where they do not have an employee record. The system now uses a safe fallback for hours per day, allowing managers to create allocations without interruption.
Original PR description
Steps to reproduce the bug: - Install Timeoff app - Switch to a company that has no employee linked to loggedInUser - Open Timeoff, Management then Allocation and create a New allocation Issue: _compute_number_of_hours_display is called due to onChange of number_of_days when opening the form view. The compute hours function displays as the initial value the number of hours/day of the employee of the allocation. The allocation defaults to the employee linked to loggedInUser, but since the company has none, the allocation form employee is set to empty, causing the compute hours function to fail and throw a traceback. opw-4648319 opw-4652752 opw-4649177 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes how Odoo checks the version of a key web component so it works correctly on newer Debian systems. It prevents startup or runtime errors caused by a deprecated version field in newer Werkzeug releases.
Original PR description
The werkzeug version is parsed by using the `__version__` attribute which is deprecated since 3.0.0. This leads to an error when running Odoo in Debian trixie that provides werkzeug 3.1.3. See - pallets/werkzeug#2772 - https://packages.debian.org/trixie/python-werkzeug-doc > Also remove the unused import of `warning`
Leave approvers without full HR access can now see employee profile images when reviewing leave requests or allocations. This fixes a display issue while keeping access limited to the public employee information they are allowed to view.
Original PR description
- add option to `image` widget to accept a relation for preview_image to enable fetching images from `hr.employee.public` Task: 4626795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The attendance Gantt view now calculates progress correctly for employees with flexible working schedules. This prevents weekly attendance progress from being understated due to the displayed end date being excluded from the calculation.
Original PR description
This commit adds a test to make sure the progress bar of employee fetched in gantt view of attendance returns the expected values without any issue. opw-4492625
This fix prevents module updates from overwriting the trusted Dutch tax authority bank account data, avoiding failures caused by fraud-prevention checks. The account is treated as trusted by default because it matches the official payment details published by the Dutch tax authority.
Original PR description
When updating the module, the bank data is reloaded. When the account is already trusted (`allow_out_payment == True`), the write fails due to checks to prevent fraud. To fix this, we wrap the data in a `noupdate` to prevent further writes from happening. If ever the account number changes, a new record will be created instead of updating the existing one. Since this account is the default one stipulated on the official belastingdienst site, it can be trusted by default. https://www.belastingdienst.nl/wps/wcm/connect/bldcontenten/belastingdienst/business/payroll_taxes/you_are_not_established_in_the_netherlands_are_you_required_to_withhold_payroll_taxes/when_you_are_going_to_withhold_payroll_taxes/filing_payroll_tax_returns_and_paying_payroll_tax/payment similar: d4595b856045fe9d35a4ac0f28faf12f0d19cd88
This fix prevents an error when selling combo products in the German POS certification flow. Combo products are handled correctly without requiring tax settings that should not apply to them, helping sales proceed smoothly.
Original PR description
Before this commit, attempting to sell a combo product resulted in an error due to a missing tax configuration. However, combo products are not supposed to have taxes assigned, leading to an unintended issue. opw-4555159
Restaurant staff can now split POS orders without triggering a system error after a browser refresh. This improves checkout reliability and reduces disruptions during service.
Original PR description
Before this commit, in the restaurant, splitting an order could result in an `IndexError: list index out of range`. This issue occurred due to incorrect handling of order lines during the split process. This fix ensures proper validation and handling of order lines to prevent such errors, improving the stability of the POS system. Steps to reproduce: - Create an order - Refresh browser - Attempt to split the order. - Observe the `IndexError: list index out of range` traceback. opw-4451836
Payment links can no longer be created or used for orders that have already been renewed. This prevents old renewed orders from being reopened by a payment, avoiding duplicate active subscriptions for the same customer.
Original PR description
Before this commit, it was possible to pay payment links linked to renewed orders. It would cause issues as the renewed order would be reopened once the transaction was set to done. Two subscription in progress would live side by side. This commit ensure that such links can't be created and existing links can't be used. taskid: 4607315
German Point of Sale sessions using Fiskaly certification no longer send an extra blank receipt to the printer when automatic receipt printing is enabled. This prevents confusing printer errors and avoids wasting paper during checkout.
Original PR description
When automatically sending the receipt in a DE PoS, there was 2 receipt sent to the printer, one of them was empty and showing an error. Steps to reproduce: ------------------- * Setup a fiskaly PoS * Activate the automatic receipt printing * Open PoS and make an order * Pay the order > Observation: Two receipt are sent to the printer, one of them is empty and showing an error. Why the fix: ------------ We were calling the `super` method twice. This was causing the receipt to be printed twice. We now call the `super` method only once. opw-4520201
Fixes a display issue in the bank reconciliation widget where very long partner names could disrupt the alignment of dates and amounts. This keeps key transaction details easy to read and compare during reconciliation.
Original PR description
When the name of the partner is too long, we truncate the name but we should have added text-no-wrap on the date and amount. opw-4502699
Refund invoices are now treated as negative amounts when calculating sales commission achievements. This prevents refunded sales from incorrectly increasing commission totals, improving payout accuracy.
Original PR description
Version: 18.0 When the invoice is a refund, it should reduce the achievement's amount and not increase it. opw-4610960
Refreshing an open Sign document or template now returns users to that same item instead of sending them back to the overview list. This preserves context and reduces disruption when working with signed documents or templates.
Original PR description
This commit fixes the redirect to the documents view when reloading the page of an opened document by restoring the client action context and setting the document name as the display name of the document. task-4323698
Long signature request names are now shortened on employee contract cards so they no longer overlap other information. This keeps the kanban view tidy and makes contract status indicators stay visually consistent.
Original PR description
- after having long name of signature request linked to the contract, it's conflicting the visual of kanban view - with same path, kanban state can not stable on their position - because of that, to make stability of kanban state changed path too - Before fix: - for long name of signature request, overwrite the kanban view  - After fix - perfectly fit the name in kanban view, - only show the limited character and appending `...`  - OPW-4590161
This fix prevents the Documents app from crashing when upgraded databases contain older document records with incomplete linked-record information. Users can open the Documents app normally even if some legacy records have missing reference fields.
Original PR description
For databases upgrading to v18 if any `documents.document` records have `NULL` value i.e, `res_id` is present but `res_model=NULL` similarly `res_id=NULL` but `res_model` is present While accessing…
For databases upgrading to v18 if any `documents.document` records have `NULL` value i.e, `res_id` is present but `res_model=NULL` similarly `res_id=NULL` but `res_model` is present
While accessing the documents app by default kaban view is loaded which has `res_id` in its arch after this commit: odoo/enterprise@a32825e
If such records exist it will lead to traceback during `web_search_read` calls while accessing the documents app
```py
File "/home/odoo/odoo/odoo/addons/web/models/models.py", line 46, in web_search_read
values_records = records.web_read(specification)
File "/home/odoo/odoo/odoo/addons/web/models/models.py", line 186, in web_read
co_record = self.env[record[field.model_field]].browse(record[field_name])
File "/home/odoo/odoo/odoo/odoo/api.py", line 596, in __getitem__
return self.registry[model_name](self, (), ())
File "/home/odoo/odoo/odoo/odoo/modules/registry.py", line 240, in __getitem__
return self.models[model_name]
KeyError: False
```
Previously, these types of records did not cause any issues due to the absence of res_id in the Kanban view.
OPW - 4527152This fixes an issue where users could not cancel certain Mexican payments after a related CFDI document had been sent to the government. The change prevents an error during cancellation, helping accounting teams correct or reverse payments without manual technical intervention.
Original PR description
When canceling a payment linked to an entry, we try to unlink the entry, but we end up in the following constains: `ir_attachment._unlink_except_cfdi_document` Steps: - Create, confirm an invoice and sent cfdi - Register a payment with `Por Definir` as payment method - Click on `Update Payments` - On CFDI tab, click on `Force CFDI` on payment line - Go to the payment - Reset it to draft and cancel it -> Error: `You can't unlink an attachment being an EDI document sent to the government.` Fix: Backport of https://github.com/odoo-dev/enterprise/commit/6f21aedf1a107acb4c89f7a8264171597068e102 opw-4644528
Batch payment totals are now calculated using the best available amount source, including the related invoice or bill amount when needed. This helps ensure payment batches show accurate totals in the correct currency, reducing reconciliation and payment processing errors.
Original PR description
This commit change the way amount are computed in batch payment: Amount are now computed in this order: 1 - amount of journal entry (old) 2 - amount of account move (new) 3 - amount of payment (old) opw-4574834
Since [1] the widget displayed on a server action form view when it is set up as "Update a o2m field on a record" was not displaying the fields in the proper way. Before: the value field was a text field expecting the user to input the record id by hand. After: the value field is now a many2one selector. [1]: https://github.com/odoo/odoo/commit/0a744accc2aaa965d5353e854317895d822ad954 Forward-Port-Of: odoo/odoo#203156 Forward-Port-Of: odoo/odoo#202930
Original PR description
Since [1] the widget displayed on a server action form view when it is set up as "Update a o2m field on a record" was not displaying the fields in the proper way. Before: the value field was a text field expecting the user to input the record id by hand. After: the value field is now a many2one selector. [1]: https://github.com/odoo/odoo/commit/0a744accc2aaa965d5353e854317895d822ad954 Forward-Port-Of: odoo/odoo#203156 Forward-Port-Of: odoo/odoo#202930
When we have an Analytic Plan being Mandatory, confirming an invoice from the form view, if it has a line without an Analytic distribution, correctly raises a ValidationError. Confirming invoices from the list view does not raise the same error, yet it should. To replicate: 1. [Activate](https://www.odoo.com/documentation/18.0/applications/finance/accounting/reporting/analytic_accounting.html) Analytic accounting: a. Install `accountant` b. In Settings, activate Analytic Accounting
Original PR description
When we have an Analytic Plan being Mandatory, confirming an invoice from the form view, if it has a line without an Analytic distribution, correctly raises a ValidationError. Confirming invoices…
When we have an Analytic Plan being Mandatory, confirming an invoice from the form view, if it has a line without an Analytic distribution, correctly raises a ValidationError. Confirming invoices from the list view does not raise the same error, yet it should. To replicate: 1. [Activate](https://www.odoo.com/documentation/18.0/applications/finance/accounting/reporting/analytic_accounting.html) Analytic accounting: a. Install `accountant` b. In Settings, activate Analytic Accounting c. Create an Analytic plan (with an Analytic account associated) 2. Set its default applicability to mandatory 3. Create two invoices, remove the analytic distribution from one of the lines in one invoice. 4. In the invoices list view, select both newly created invoices, click on Actions > Confirm Entries 5. Click Confirm 6. The invoices were posted, even though they have no analytic distributions. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4603919) opw-4603919 Forward-Port-Of: odoo/odoo#203153 Forward-Port-Of: odoo/odoo#201560
Before this commit: When sample data was visible in the view, the pager was also displayed, showing a record count, which could be misleading. After this commit: Now, when sample data is visible, the pager is hidden. Task-4489033 Forward-Port-Of: odoo/odoo#203174 Forward-Port-Of: odoo/odoo#200624
Original PR description
Before this commit: When sample data was visible in the view, the pager was also displayed, showing a record count, which could be misleading. After this commit: Now, when sample data is visible, the pager is hidden. Task-4489033 Forward-Port-Of: odoo/odoo#203174 Forward-Port-Of: odoo/odoo#200624
**Problem**: When copying text from the editor that contains `nbsp`, pasting it into a code editor results in invalid characters, causing issues like compilation errors. **Solution**: Replace `nbsp` with normal spaces when copying text. **Steps to Reproduce**: 1. Add text: `"a b"` (with double spaces). 2. Copy the text. 3. Paste it into a **code editor**. - **Issue**: The invisible `nbsp` causes compilation errors. **opw-4645678** --- I confirm I have signed the CLA and re
Original PR description
**Problem**: When copying text from the editor that contains `nbsp`, pasting it into a code editor results in invalid characters, causing issues like compilation errors. **Solution**: Replace `nbsp` with normal spaces when copying text. **Steps to Reproduce**: 1. Add text: `"a b"` (with double spaces). 2. Copy the text. 3. Paste it into a **code editor**. - **Issue**: The invisible `nbsp` causes compilation errors. **opw-4645678** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202904
**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm" **Cause:** When printing the original bill, we try to add a banner on the PDF. If the PDF is encrypted, PyPDF2 (2.12.1) will only try to decrypt
Original PR description
**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded…
**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm" **Cause:** When printing the original bill, we try to add a banner on the PDF. If the PDF is encrypted, PyPDF2 (2.12.1) will only try to decrypt it if "PyCryptodome" library is installed. Otherwise, it will raise a "DependencyError", which is not handled in the "except" clause. As "PyCryptodome" library is not part of Odoo requirements, we should handle the raised "DependencyError". **Solution:** Try to import "DependencyError" from "PyPDF2.errors" and catch that exception when adding the banner to the PDF. Our own "DependencyError" exception should be created because version 1.26.0 of PyPDF2 doesn't declare "DependencyError" and therefore the import will fail. "NotImplementedError" is used instead in version 1.26.0 and is already handled. opw-4634417 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203005 Forward-Port-Of: odoo/odoo#202129
### Steps to reproduce: - In Accounting create a new Payment Term with an early discount set on "Always(upon invoice)" - Create a new Contact and add the payment term to this contact - Open POS and create an order - Select the new contact as the customer - Go to payment, select the option to create an invoice and validate - The receipt and the generated invoice have different amounts: the payment terms were applied on the invoice but not on the receipt ### Cause: POS does not consider
Original PR description
### Steps to reproduce: - In Accounting create a new Payment Term with an early discount set on "Always(upon invoice)" - Create a new Contact and add the payment term to this contact - Open POS and create an order - Select the new contact as the customer - Go to payment, select the option to create an invoice and validate - The receipt and the generated invoice have different amounts: the payment terms were applied on the invoice but not on the receipt ### Cause: POS does not consider at any point the payment terms so the total to be paid does not include the payment terms. Payment terms were included in invoices from POS with this [commit](https://github.com/odoo/odoo/pull/100100/commits/c1cd62f0b207b3f3bbf5a03009bd8e34ee9b479f) ### Solution: Remove the payment terms on invoices from POS. opw-4458036 Forward-Port-Of: odoo/odoo#202147 Forward-Port-Of: odoo/odoo#199385
Steps to reproduce: - add a payment reference on a vendor bill - confirm - register a payment - see the memo takes the payment reference value - update the payment reference on the invoice, register (no matter if you reset the invoice into draft or not) - register a payment Issue: see the memo takes the same vale as the initial payment reference Cause: We use the `line.name` which is not wrong as when we update the payment reference the it will be updated. But whenever we update th
Original PR description
Steps to reproduce: - add a payment reference on a vendor bill - confirm - register a payment - see the memo takes the payment reference value - update the payment reference on the invoice, register (no matter if you reset the invoice into draft or not) - register a payment Issue: see the memo takes the same vale as the initial payment reference Cause: We use the `line.name` which is not wrong as when we update the payment reference the it will be updated. But whenever we update the payment reference again, the `line.name` will not be updated https://github.com/odoo/odoo/blob/0bec22df0a34c6bc201d2627cf1123509d272a6d/addons/account/models/account_move_line.py#L482-L483 Solution: We prioritize the payment reference for the communication as it is the case in 18.0 opw-4405999 Forward-Port-Of: odoo/odoo#198826 Forward-Port-Of: odoo/odoo#196611
Invalid values were not being validated before sending to the FedEx REST API. Some values were longer than allowed and some states were not using the correct codes. Length limits were found from the FedEx REST API docs and the correct Indian state codes were provided by FedEx support directly. Added a mapping for Mexican states and one Indian state that did not have the correct state codes. State codes for Mexico were from the API specifications page and updated state codes for India were p
Original PR description
Invalid values were not being validated before sending to the FedEx REST API. Some values were longer than allowed and some states were not using the correct codes. Length limits were found from the FedEx REST API docs and the correct Indian state codes were provided by FedEx support directly. Added a mapping for Mexican states and one Indian state that did not have the correct state codes. State codes for Mexico were from the API specifications page and updated state codes for India were provided from FedEx support. opw-4461150 Forward-Port-Of: odoo/enterprise#81977 Forward-Port-Of: odoo/enterprise#79617
Since changes made in https://github.com/odoo/enterprise/pull/75552 that changes the semantic of the field 'private_car_missing_days', we need to adapt the value used for simulations from 0 to 20 days (average nb of days in a month) Forward-Port-Of: odoo/enterprise#81943
Original PR description
Since changes made in https://github.com/odoo/enterprise/pull/75552 that changes the semantic of the field 'private_car_missing_days', we need to adapt the value used for simulations from 0 to 20 days (average nb of days in a month) Forward-Port-Of: odoo/enterprise#81943
Steps to reproduce: - With an ES company setup - Create and confirm invoice with: - Spanish partner - Amount > 3005.06 (mod347 threshold) - Type for mod 347: Regular operation - Create and confirm a jounral entry with: - Payable account, debit 4000 - Receivable account, credit 4000 - Type for mod 347: Regular operation - Check Mod 347 Tax Report Issue: 'Total number of persons and entities' shows 0 This occurs because some lines of mod 347 report need to be grouped by
Original PR description
Steps to reproduce: - With an ES company setup - Create and confirm invoice with: - Spanish partner - Amount > 3005.06 (mod347 threshold) - Type for mod 347: Regular operation - Create and confirm a jounral entry with: - Payable account, debit 4000 - Receivable account, credit 4000 - Type for mod 347: Regular operation - Check Mod 347 Tax Report Issue: 'Total number of persons and entities' shows 0 This occurs because some lines of mod 347 report need to be grouped by partner, only keeping the partners whose balance for the line is above 3005.06€, so we first get all the partners that match the domain but don't reach the threshold. We exclude these partners with a 'NOT IN' clause. However, when the partner is not set, a NULL values is retrieved causing the clause to be evaluated NULL instead of False and the total count will be 0 opw-4544950 Forward-Port-Of: odoo/enterprise#81954 Forward-Port-Of: odoo/enterprise#81687
Fixed the `Request Owner` field to list all users in the selected companies. The previous domain was based on `company_id`, which was computed from the selected `category_id`. However, if no category was selected (`category_id` was null), no `request_owner_id` was listed. The new fix computes all selected companies from `self.env`. task-4637199 Forward-Port-Of: odoo/enterprise#81096
Original PR description
Fixed the `Request Owner` field to list all users in the selected companies. The previous domain was based on `company_id`, which was computed from the selected `category_id`. However, if no category was selected (`category_id` was null), no `request_owner_id` was listed. The new fix computes all selected companies from `self.env`. task-4637199 Forward-Port-Of: odoo/enterprise#81096
### Issue: Currently, the `use_create_components_lots` of the manufacturing picking type is not used in barcode to allow/forbid the creation of new lots. ### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Operation Types - Manufacturing > uncheck: Create New Lots/Serial Numbers for Component - Create a product tracked by SN and put one SN in stock. - Create and confirm an MO for an other product using your tracked product as component. - Go to the barcode a
Original PR description
### Issue: Currently, the `use_create_components_lots` of the manufacturing picking type is not used in barcode to allow/forbid the creation of new lots. ### Steps to reproduce: - Inventory >…
### Issue: Currently, the `use_create_components_lots` of the manufacturing picking type is not used in barcode to allow/forbid the creation of new lots. ### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Operation Types - Manufacturing > uncheck: Create New Lots/Serial Numbers for Component - Create a product tracked by SN and put one SN in stock. - Create and confirm an MO for an other product using your tracked product as component. - Go to the barcode app > Manufacturing > your MO - Click on the component line and scan a string that do not correspond to an existing SN of your tracked product. > The Scanned string is added as a "lot_name" on a new line. In particular, at validation a new move line without lot and with a set lot_name will be created. This line without lot will be used in all the `pre_button_mark_done` checks like: `_check_sn_uniqueness` which btw will fail if you scanned 2 non-existing lots. And, if you manage to pass all check for instance by scanning a non-existing lot and the initially reserved one, the validation of the new move line will create the lot. Cause of the issue: Scanning the non existing lot will correctly fail to find a match via the barcode parser: https://github.com/odoo/enterprise/blob/026a5b8a83bd6b94588baa9a35530495d9e067cd/stock_barcode/static/src/models/barcode_model.js#L963 As such and since a line is selected, you will end up setting the barcode as a lotName: https://github.com/odoo/enterprise/blob/026a5b8a83bd6b94588baa9a35530495d9e067cd/stock_barcode/static/src/models/barcode_model.js#L1018-L1034 This happens notably because you `this.canCreateNewLot` is always set to `True` on productions but should not: https://github.com/odoo/enterprise/blob/026a5b8a83bd6b94588baa9a35530495d9e067cd/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L126-L128 opw-4618963 Forward-Port-Of: odoo/enterprise#81681 Forward-Port-Of: odoo/enterprise#81272
Issue ===== When validating an uncompleted return in Barcode, an error is raised. How to reproduce ================ - Open Barcode app > Operations > Receipts and create a new receipt; - Scan at least two times the same product's barcode; - Validate. - Re-open the same receipt and click on "Return Products"; - Scan one product then validate -> The return is correctly validated but an "Invalid Operation" error is raised. Cause of the issue ================== The return's move is d
Original PR description
Issue ===== When validating an uncompleted return in Barcode, an error is raised. How to reproduce ================ - Open Barcode app > Operations > Receipts and create a new receipt; - Scan at…
Issue ===== When validating an uncompleted return in Barcode, an error is raised. How to reproduce ================ - Open Barcode app > Operations > Receipts and create a new receipt; - Scan at least two times the same product's barcode; - Validate. - Re-open the same receipt and click on "Return Products"; - Scan one product then validate -> The return is correctly validated but an "Invalid Operation" error is raised. Cause of the issue ================== The return's move is done but `_split` is called and calling this method on a done move is forbidden. How to fix ========== In the `split_uncompleted_moves` move's method, done and cancel move are skipped. Also, the JS method who call `post_barcode_process` will now doesn't call it if operation is done or cancelled or if there is no moves (to avoid to do useless RPC.) [OPW-4535205](https://www.odoo.com/odoo/project/49/tasks/4535205) [OPW-4535257](https://www.odoo.com/odoo/project/49/tasks/4535257) Forward-Port-Of: odoo/enterprise#81531 Forward-Port-Of: odoo/enterprise#81312
# HOW TO REPRODUCE: - Create products FNS & CMP - Set available quantity of CMP to 2 - Create MO of 1 FNS and 2 CMP -> Confirm - Open MO in barcode - Set FNS quantity to 1 - Set CMP quantity to 1 (1/2 of the demand) -> Produce MO => The CMP move has 2 lines of 1 unit, so 2 unit have been consumed instead of the 1 put on the barcode. https://github.com/user-attachments/assets/237c81bc-f342-4293-bc76-008b5c7cf876 OPW-4517284 Forward-Port-Of: odoo/enterprise#81912 Forward-Port-Of
Original PR description
# HOW TO REPRODUCE: - Create products FNS & CMP - Set available quantity of CMP to 2 - Create MO of 1 FNS and 2 CMP -> Confirm - Open MO in barcode - Set FNS quantity to 1 - Set CMP quantity to 1 (1/2 of the demand) -> Produce MO => The CMP move has 2 lines of 1 unit, so 2 unit have been consumed instead of the 1 put on the barcode. https://github.com/user-attachments/assets/237c81bc-f342-4293-bc76-008b5c7cf876 OPW-4517284 Forward-Port-Of: odoo/enterprise#81912 Forward-Port-Of: odoo/enterprise#81343
Steps to reproduce: 1. In recruitment app, generate an offer for an applicant. 2. Send the offer by email and sign it by both parties. Bug: The generated sign request is not linked to the offer using the reference_doc field. Fix: Link the offer to the sign request upon creation in the submit endpoint. task-4607475 Forward-Port-Of: odoo/enterprise#80391
Original PR description
Steps to reproduce: 1. In recruitment app, generate an offer for an applicant. 2. Send the offer by email and sign it by both parties. Bug: The generated sign request is not linked to the offer using the reference_doc field. Fix: Link the offer to the sign request upon creation in the submit endpoint. task-4607475 Forward-Port-Of: odoo/enterprise#80391
Steps to reproduce the bug: - create a storable product “P1” and “C1” - create a quality point for C1: - Operation type: Manufacturing - Control per: quantity - Control Frequency: all - Partial Test: 10% - Type: pass-fail - Create a manufacturing order: - Finished product: 2 units of P1 - Components: C1 -> 10 units - Confirm the MO - go to the quality check Problem: A quality check is created, but the quantity to test is based on the manufacturin
Original PR description
Steps to reproduce the bug:
- create a storable product “P1” and “C1”
- create a quality point for C1:
- Operation type: Manufacturing
- Control per: quantity
- Control Frequency: all
- Partial Test: 10%
- Type: pass-fail
- Create a manufacturing order:
- Finished product: 2 units of P1
- Components: C1 -> 10 units
- Confirm the MO
- go to the quality check
Problem:
A quality check is created, but the quantity to test is based on the manufacturing order's produced quantity instead of the stock move line quantity linked to the quality check.
opw-4527413
Forward-Port-Of: odoo/enterprise#81773