Daily updates from Odoo
Friday, April 19, 2024
37 changes
7 changes
Resolved issues and error corrections
The preparation display is now shown in the main menu when the restaurant point-of-sale module is installed. This makes the kitchen display easier for restaurant staff to find and access during daily operations.
Original PR description
In this commit: =============== The `pos_preparation_display` (preparation display) will be visible in the main menu if the `pos_restaurant` module is installed." task-3725031
The Mail app now tells the web interface which chat types support seen-status tracking. This avoids unnecessary work for chats where the feature does not apply, providing a small performance improvement without changing user workflows.
Original PR description
This info was only available to python/server code. This is now provided to JS/client code, so that it can avoid computing fields related to seen feature on threads that do not support this feature. This very slightly helps performance. https://github.com/odoo/odoo/pull/162445
Users without marketing-related permissions will no longer see campaign menus or email marketing options they cannot access. This prevents confusing navigation and avoids permission errors when social users open restricted campaign features.
Original PR description
User has only the access rights for social poster and, no access rights for email marketing, marketing automation and sms marketing, is still able to see the email marketing icon similarly this issue is for social manager rights. Which leads to record rule error. In social module the campaigns menu shows without any access rights. this commit solve this issue, i.e. the email marketing icon will not shown if user dont have any access rights. and also campaigns menu is hidden if user dont have any access related to that menu. **TaskID - 2417993**
This fixes an issue where cancelling an appointment too close to the allowed cancellation deadline could fail instead of showing the expected result. The appointment flow now keeps the needed customer information during cancellation, improving reliability for website bookings.
Original PR description
Fix following up : https://github.com/odoo/enterprise/pull/17141
Manufacturing users can now record partial quantities across work orders without getting stuck or needing to create a backorder just to continue. The tablet view also shows more accurate quantities for remaining work and component consumption, reducing confusion during production.
Original PR description
When processing production across various work orders, if after the first work order, less quantity is produced in any of the work orders, Odoo locks the WO and it is not possible to go back to it and treat the remaining quantity again (as in V12/V13). The only way to treat the remaining quantity is to create a backorder from the source MO. Also a misleading message appears when this under production is recorded : https://drive.google.com/file/d/1NppBavfj30IjkhbCwBcIMrsw_ohDrec1/view?usp=sharing FIX : If the user only records partial quantity, leave the field open and let the user record the rest.
When users open Studio from a form with multiple tabs, the same tab now stays open instead of switching back to the first one. This makes editing smoother by preserving the user's context and avoiding extra navigation.
Original PR description
currently, When enabling studio on a form view, it reset the notebook page and activate the first page instead of the currently activated page. this commit fixes the issue by adding autofocus on the activated node and therefore enabling studio on a form view, it will display the currently activated page instead of the first page. TaskID-2416755
Creating a custom stat button in Studio no longer fails because of invalid generated field names. This restores the expected ability for users to add stat buttons without encountering a naming error.
Original PR description
currently, when try to create state button, it raise error 'Custom field names cannot contain double underscores' this is happening because, we give explicitly '__' while creating field_name in commit- 3ee34f4b869998d8a6f5f29b1792bc70add9da00 and before we did not check for '__' in field_name so error does not raise. we start to check for '__' after Task-2060257. after this commit, replace '__' with '_' so now The stat button is created. Task - 2475554
30 changes
Resolved issues and error corrections
A technical error in the Indian payroll system has been corrected by removing an incorrect minus sign that was preventing salary calculations from working properly. This fix ensures that payroll processing runs smoothly without errors.
Original PR description
This commit removes the unnecessary "-" (minus) that was mistakenly added before `inputs['ATTACH_SALARY'].name`. This addition was causing a traceback error. task-3794116
This fix ensures that recurring tasks are created consistently regardless of who confirms a sale order. Previously, customer portal users couldn't create recurring tasks because they lacked specific user permissions, even though the sale order and product were configured for recurring tasks. The fix removes this unnecessary permission check, allowing both internal users and customers to generate recurring tasks properly.
Original PR description
…ating recurrent tasks Steps to reproduce: - Create a new recurring prepaid service product, and Create on Order: Project & Task or Task. - Enable "Recurring Tasks" in the setting and grant the…
…ating recurrent tasks Steps to reproduce: - Create a new recurring prepaid service product, and Create on Order: Project & Task or Task. - Enable "Recurring Tasks" in the setting and grant the current user "Use Recurring Tasks" access in the user configuration. - Create a new sale order, select that recurring product and a "Recurring Plan", confirm the sale order with the current user and check the task. - Duplicate the same sale order, confirm the sale order with the customer portal user in the portal view and pay. Current behaviour: The task created by the current user is recurring. However, the other task that the customer created in the portal view is not recurring. Both of them should be recurring since the sale orders are the same. The person who confirms the sale order should not affect the status of the task. Cause It is checking if the user has the access right to create recurrent tasks. Where in this case, customers will always be portal users, and they will not have that access right. Solution Remove the check, since the recurrent attributes are already defined in the SO and Product.
This fix resolves a synchronization problem in account reports where user-selected grouping preferences were not properly aligned with the actual report grouping. The correction ensures that when users customize how their financial reports are organized, those preferences are consistently applied throughout the report display.
This update fixes two issues with warning messages in tax reports. First, it ensures that draft entry warnings properly exclude tax closing entries across all tax reports, not just the generic one. Second, it restores a warning about inactive tags that was accidentally removed. These fixes improve the accuracy of financial reporting alerts.
Original PR description
[FIX] account_reports: skip the 'draft entries' warning for tax closings properly for all tax report Some specific code was added by https://github.com/odoo/enterprise/commit/649960d66eaf0c1cdf0c81b86a6226d77d244b98 in order to ignore the tax closing entries in the warning stating there are draft entries in the period, if on the tax report. However, this was badly forward-ported, and only worked for the generic tax report. With this fix, every tax report will benefit from it, as originally intended. [FIX] account_reports: re-enable the warning about inactive tags in period for tax reports This warning was dropped by mistake when introducing the new warning mechanism for accounting reports. Forward-Port-Of: odoo/enterprise#60774
This update adds a clear description to the Worldline payment integration settings to specify that it is only available in Benelux countries. This matches the existing documentation for Ingenico and helps users understand the geographic limitations of this payment method option.
Original PR description
This PR adds the same description for Worldline as we already do for Ingenico to clearly state that our Worldline intergration is only available in Benelux. task-3866802 Forward-Port-Of: odoo/enterprise#60676 Forward-Port-Of: odoo/enterprise#60649
This fix resolves an issue where XML validation for Mexican accounting documents was attempting to download validation rules from the internet, causing test failures when internet access is unavailable. The validation rules are now stored locally, making the system more reliable and independent of external connectivity.
Original PR description
Currently, the xsd validation tries to fetch a part of the xsd from internet. There is no need for it, we should just have it (as the others). It causes issues when running the tests if you can't make the request. (reproducible if you have no internet). Linked to runbot error 30521 Forward-Port-Of: odoo/enterprise#60964
This fix resolves an issue where the wrong package was being assigned to a product line during barcode scanning in warehouse operations. When scanning a lot number for a product that exists in multiple locations with different packaging, the system was incorrectly selecting a package from a different location. The fix ensures the correct package is matched based on the actual source location being scanned.
Original PR description
Package is wrongly set on product line in barcode scan Steps: - Have a product P tracked by lot - Set 2 stock quant in 2 locations: 1st in loc1 with lot L and package P 2nd in loc2 with lot1 and no package - Create a picking (Customer delivery) for P with source loc2 - With barcode make the delivery, scan the lot number -> The pack P is set on the product line, even if the package P is in loc1 We pass the location id through the context in order to adapt the domain in `prefilled_owner_package_stock_barcode()`, doing that we ensure we also cover the case where we have 2 stock quant with one with no package and the other with package. opw-3746608 Forward-Port-Of: odoo/enterprise#61057 Forward-Port-Of: odoo/enterprise#59342
Fixed an issue where the helpdesk module was not sending confirmation emails to internal users when tickets were created by submitting an email to the system. The fix ensures that confirmation emails are sent for email-submitted tickets while maintaining the existing behavior of not sending emails for tickets created through the web interface.
Original PR description
Steps to reproduce: - Install helpdesk - Add an alias domain to send ticket - Send a mail to add a ticket, with the mail of the demo user Error: No mail is sent to the user confirming the reception of the ticket. This is due to condition here https://github.com/odoo/enterprise/blob/1502f8b3e519d41f4a58e2acc846f315f6f5eeda/helpdesk/models/helpdesk_ticket.py#L789-L790 This was done to prevent mail being sent if we created the ticket through the frontend. Desired behaviour as checked with PO is to keep this behaviour in frontend but to send a mail back if we submitted ticket through mail. By looking at the context we can the origin of the ticket (frontend or mail) and send a mail if it came from an email. Context key we used is set here https://github.com/odoo/enterprise/blob/1502f8b3e519d41f4a58e2acc846f315f6f5eeda/helpdesk/models/helpdesk_ticket.py#L742 opw-3786152 Forward-Port-Of: odoo/enterprise#59776
This fix corrects an issue where delivery address information was incorrectly pulled from the company's address instead of the actual delivery address when generating Mexican tax documents (CFDI) for international trade invoices. This ensures that tax documents accurately reflect where goods are being delivered, which is critical for proper compliance with Mexican external trade regulations.
Original PR description
Steps to reproduce: - Install Contacts, Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to company form and configure its address (*) - Create a US…
Steps to reproduce: - Install Contacts, Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to company form and configure its address (*) - Create a US customer (e.g. Foreign Customer) (*) - In Accounting settings: * activate "Customer Addresses" * use Mexican Bank for automatic currency rates (*) - Configure a product for external trade (e.g. Office Chair) (*) - Create an invoice: (*) * Customer: Foreign Customer * Delivery Address: [different than customer] (e.g. Deco Addict) * Journal in: USD * Usage: Without fiscal effects * Product: Office Chair * Incoterm: EX WORKS * External Trade: Definitive - Confirm the invoice - Try to generate CFDI via "Send & Print" button (it will probably fail) (*) https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade Issue: Check the generated CFDI in CFDI tab. The data for element `<cce20:Destinatario><cce20:Domicilio /></cce20:Destinatario>` are incorrect. "Calle", "NumeroExterior", "NumeroInterior", "Pais" and "CodigoPostal" are coming from the current company instead of the delivery address. opw-3715960 Forward-Port-Of: odoo/enterprise#60829
This fix resolves an issue where toggling the all-day field on calendar events was not properly syncing changes to Google Calendar. The problem occurred because Google Calendar requires different date formats for all-day events versus timed events, and the system was not clearing the unused field when switching between these types. Users can now successfully toggle events between all-day and timed formats with changes reflecting correctly in Google Calendar.
Original PR description
Before this commit when we have a synced event with google and then we toggle the all-day field changes didn't reflect on google side This happened because google uses two separate fields for…
Before this commit when we have a synced event with google and then we toggle the all-day field
changes didn't reflect on google side
This happened because google uses two separate fields for start/end.
1. dateTime (used for normal events)
2. date (used for all-day events)
when one of them is set, the other must be null.
Before this commit when we did a patch update, we set only one, but forget about the other which raises an error.
Task: 3681668
==============================
I couldn't find it in google calendar api documentation supporting my claim. But I based my conclusion on these facts:
1. when sending a get request to google API for all-day events it would look like this, we can observe that for both start/end it doesn't have a `dateTime` but only `date`.
```js
{
"kind": "calendar#event",
"etag": "\"3420874125486000\"",
"id": "11qeiguv96iei6nkd4helg421b",
"status": "confirmed",
"htmlLink": "https://www.google.com/calendar/event?eid=MTFxZWlndXY5NmllaTZua2Q0aGVsZzQyMWIgYWxhaEBvZG9vLmNvbQ",
"created": "2024-03-14T10:39:50.000Z",
"updated": "2024-03-14T17:24:22.743Z",
"summary": "all day from google",
"creator": {
"email": "alah@odoo.com",
"self": true
},
"organizer": {
"email": "alah@odoo.com",
"self": true
},
"start": {
"date": "2024-03-20"
},
"end": {
"date": "2024-03-21"
},
"transparency": "transparent",
"iCalUID": "11qeiguv96iei6nkd4helg421b@google.com",
"sequence": 2,
"reminders": {
"useDefault": false
},
"eventType": "default"
}
```
2. When doing the same for an event that is not marked as all-day. we would get this
```js
{
"kind": "calendar#event",
"etag": "\"3420880154840000\"",
"id": "6ngnlju6nofaa0h478nkqgrhna",
"status": "confirmed",
"htmlLink": "https://www.google.com/calendar/event?eid=Nm5nbmxqdTZub2ZhYTBoNDc4bmtxZ3JobmEgYWxhaEBvZG9vLmNvbQ",
"created": "2024-03-14T18:14:37.000Z",
"updated": "2024-03-14T18:14:37.420Z",
"summary": "aaa",
"creator": {
"email": "alah@odoo.com",
"self": true
},
"organizer": {
"email": "alah@odoo.com",
"self": true
},
"start": {
"dateTime": "2024-03-14T15:00:00+02:00",
"timeZone": "Africa/Cairo"
},
"end": {
"dateTime": "2024-03-14T16:00:00+02:00",
"timeZone": "Africa/Cairo"
},
"iCalUID": "6ngnlju6nofaa0h478nkqgrhna@google.com",
"sequence": 0,
"reminders": {
"useDefault": true
},
"eventType": "default"
}
```
so on google side, it's either `date` or `dateTime` but not both. Hence when doing a patch update for either `date` or `dateTime` we should unset the other.This fix resolves an issue where product images uploaded from external URLs would disappear after saving in the e-commerce shop editor. The problem occurred when browsers couldn't fetch image data due to CORS restrictions. The solution now allows the server to fetch the remote image data when the client browser cannot, ensuring images are properly saved and displayed.
Original PR description
### Steps to reproduce: - Install **E-commerce** app - Go to **Website** > **Shop**, and open a product - Click on **edit** on the upper right corner. - Double click the product image to change it. A…
### Steps to reproduce:
- Install **E-commerce** app
- Go to **Website** > **Shop**, and open a product
- Click on **edit** on the upper right corner.
- Double click the product image to change it. A popup is shown.
- In the popup, click on Add URL and place this URL [1]
- Click **Save**. The image disappears!
### Investigation:
- The issue was introduced here [2]
- As URL now starts with `/web/image/` which will be later used here [3]
- The condition to enter this line is `url_object.path.startswith('/web/image')`
- `item[field]` is used which equals to `attachment[datas]`
- But actually `datas` is empty as the image upload fails because of **CORS**
- `add_url` is called [4] saving attachment without `datas` but with type URL
### Fix
- The commit solves the issue by fetching the remote data from the server if the url is a remote redirection, which still happens when the image data cannot be fetched by the client browser at upload time.
[1]: https://lowendbox.com/wp-content/uploads/2022/09/odoo_logo_1200.png
[2]: https://github.com/odoo/odoo/commit/943944dd249c15de870d6800d89e48d54a422e5a#diff-0897c80484208197b0aff67f2b06509e864c3976de1589e3cebad2788eef008fR49
[3]: https://github.com/odoo/odoo/blob/f72968561acec164697a7a9ee0965ec304854dd5/addons/web_editor/models/ir_qweb_fields.py#L473
[4]: https://github.com/odoo/odoo/blob/f72968561acec164697a7a9ee0965ec304854dd5/addons/web_editor/controllers/main.py#L268
opw-3746245This fix resolves an issue where lot numbers entered in the Point of Sale were being created but not properly assigned to inventory stock movements. When customers purchase tracked products and enter a new lot name at checkout, the lot will now be correctly linked to the order's inventory records, ensuring accurate stock tracking in the inventory app.
Original PR description
Current behavior: When entering a lot name that doesn't exist in the PoS, the lot is being created. But the lot is not being assigned to the stock move line. Steps to reproduce: - Create a product with tracking by lot - Open PoS and make an order for this product - Enter a lot name that doesn't exist - Validate the order - Close the session - Go to the order picking in the inventory app - The lot is not assigned to the stock move line opw-3710125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a bug where the payment registration wizard for employee expense reimbursements was incorrectly using the company's bank account instead of the employee's bank account. Now when processing expense reimbursements, the system will properly route payments to the employee's designated bank account, ensuring accurate and timely reimbursements.
Original PR description
To reproduce: * Add a bank account to Employee, and a bank account to your company. * Set the company on the employee's contact to yours. * Create an expense to be reimbursed to the employee, submit it and try to "Register Payment". Current behaviour: the recipient bank account in the wizard is set to the company's. Expected behaviour: the bank account in the wizard should be set to the employee's bank account. This commit solves this. task-3837305
This fix ensures the website checkout page works correctly for customers who upgraded during a recent transition period. When the checkout layout was updated, an HTML element type was changed, which caused issues for some users. The fix now supports both the old and new element types, ensuring a smooth experience for all customers regardless of when they upgraded.
Original PR description
While updating the checkout page an element was changed from div to t To handle the intermediate value used by users who installed this version a new selector was added to the xpath to account for both cases Previous commit that was fixing the same issue 12e5296c1d4dbfe202ad2dcb2690c2e60828f6e1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where printing ZPL labels for multiple lots of the same product would fail when sent to IoT devices. The system was incorrectly formatting the label identifiers as nested lists instead of a simple flat list, causing errors during processing. After this fix, labels print correctly to IoT devices.
Original PR description
## Steps to reproduce:
1. Go to IoT > Devices
2. Select a device and add the report "Lot/Serial Number (ZPL)"
3. Create a product tracked by lots
4. Purchase 5 units of this product
5. Validate the reception (with a lot)
6. Print labels > Lot/SN Labels
- Quantity to print: One per unit
- Format: ZPL Labels
## Before this commit:
When printing labels for multiple lots of the same product, the wizard was incorrectly generating the docids as a `list[list[int]]`. It works correctly as the ids are joined thanks to JavaScript magic. However, when sending the report to an IoT device, the ids are sent as-is in the context, which raises an error when calling `browse()`.
## After this commit:
The docids are now generated as a flat list of integers, which is correct and works as expected.
opw-3850631
Forward-Port-Of: odoo/odoo#161932This update fixes the printer icon display in the Point of Sale system so it only appears when a printer is actually configured. Previously, the icon may have been visible even without a printer setup, which could confuse users. This ensures a cleaner interface that accurately reflects available hardware.
Original PR description
In this commit: =============== printer icon will visible based on printer configuration task - 3869678
This fix resolves an access error that occurred when users with restricted access to specific company branches attempted to open the POS QR Menu. The issue was caused by an unused color field that triggered unnecessary permission checks. By removing this unused field, branch-restricted users can now access the QR Menu without errors.
Original PR description
Current behavior: If you create a user that only have access to a branch of a company. If this user try to access the QR Menu of any PoS he will get an access error. Steps to reproduce: - Create a branch B for company A - Change access of user U to only have access to branch B - Login with user U, and try to open any PoS QR Menu - You get an access error opw-3745256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the ability to create new contacts directly when adding attendees to a course. Previously, users couldn't see the "Create and edit" option when typing a new recipient's name. The feature now works again with a requirement that users must enter a valid email address during contact creation.
Original PR description
How to reproduce: 1. Go to any course 2. Click on the button 'Add attendees' 3. Type the recipients name "Create and edit ..." should be displayed but is not. To reenable this feature, we remove the option no_create_edit on partner_ids of the slide_channel_invite_view_form form to enable the creation of partner when adding attendee to a course. As the support for the force_email context has been discontinued, we don't reenable the quick_create as it can create partner without email (if the user enter a non-valid email). But we reenable the "create edit" option with a view that force the user to enter an email: base.view_partner_simple_form (like done on some views in odoo/odoo#149806). Task-3868824
This fix resolves an issue where expense amounts were not displaying on the journal dashboard, showing only the count of expenses. The problem occurred because the system was not correctly calculating the total amount to pay for expenses when viewing the dashboard summary. After this fix, users will now see both the number of expenses and their corresponding amounts on the journal dashboard.
Original PR description
Video to reproduce on runbot odoo: https://github.com/odoo/odoo/assets/56789189/3e63fb2c-11b6-40f5-99e9-9c4f98f9ba60 STEP TO REPRODUCE: -Create some expenses, create sheet for them and approve and…
Video to reproduce on runbot odoo: https://github.com/odoo/odoo/assets/56789189/3e63fb2c-11b6-40f5-99e9-9c4f98f9ba60 STEP TO REPRODUCE: -Create some expenses, create sheet for them and approve and then post journal entry. -Go to journal dashboard to view the expense summary info and see only the number of the expense is display without the amount on it REASON: since [1] the amount of the method '_count_results_and_sum_amounts' will take the total_amount base on 'amount_total_company' if we have same currency else it takes the 'amount_total' to sum. Because at 'hr.expense.sheet' doesn't have amount_residual_signed like account.move has so we will use only 'amount_residual' to consider it as 'amount_total_company' 1: d8627c4e38ce9310197979dfbd5307810edf8201 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 fix resolves a crash that occurred when users tried to open a stock move line from a newly added product in a receipt that hadn't been saved yet. The system now properly handles this scenario by saving the receipt first and then correctly locating the stock move record, preventing the "Cannot read properties of undefined" error.
Original PR description
Steps to reproduce ================== - Create two new storable products tracked by USN - Create a new RFQ with one of the created product - Confirm the order - Open the receipt - Add a new line with the other product - Click on the open move button in the new line - Add a new SN - Save & close => Cannot read properties of undefined (reading 'resId') Cause of the issue ================== When calling openRecord, if the record is dirty, it is saved before proceeding. After saving, we call super.openRecord with the old record. Since that record is no longer linked to the root record (the stock.picking), when we try to save it, it won't match an existing id. Solution ======== If the record is new, we don't save as there would be no way of knowing which of the returned line would come from this one. If we are opening an existing record, we find the new datapoint by matching it's ID. opw-3777615
This fix resolves a problem where refunds in the Point of Sale system were being rounded differently than the original order payments, causing discrepancies in refund amounts. Now, full refunds will match exactly what the customer originally paid, while partial refunds will be based on the base price of selected items. This ensures customers receive accurate refund amounts that align with their original transactions.
Original PR description
Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund. This also happens when the…
Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund. This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund. Steps to reproduce: ------------------- * Setup a rounding method with a precision of 5.0 * Create a product with a price of 138.0 * Open the POS and add the product to the order * Pay the order with 2 payments, one bank of 55 and one cash that will be rounded to 80. * Validate the order * Go in the backend and refund the order * The refund will be rounded to 135.0 Why the fix: ------------ The new behavior after this fix: * When refunding the entire original order, the amount to refund should be equal to what the customer paid on the original order (thus taking into account the rounding). * When doing a partial refund, the amount that should be refunded correspond to the base price of the article(s) selected. The issue was about the fact that refunds differed in prices compared to the original order. With this fix, there could still be a difference in the prices if a customer comes multiple times to do a partial refund and end up refunding the total order. This difference exists only if the original order was paid with rounding and will be maximum the rounding defined. Since this is a rare event, we consider this difference to be acceptable. Post-fixup: ----------- The function `_get_rounded_amount()` was modified as we are not computing cash rounding when refunding anymore. opw-3701574 Forward-Port-Of: odoo/odoo#162280 Forward-Port-Of: odoo/odoo#161564
This update resolves an issue where the Point of Sale system would fail to load if the browser cache contained invalid orders from a previous database version. After system upgrades, cached unpaid orders may become incompatible with new field structures. The fix automatically removes these problematic cached orders, allowing the PoS to load successfully without manual intervention.
Original PR description
Prior to this commit, the presence of an invalid order in the browser cache could prevent the PoS from loading. This issue typically arises after a database upgrade, where changes in fields can render unpaid orders in the cache unloadable. This commit resolves this issue by discarding any problematic unpaid orders that can no longer be loaded. opw-3874858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a bug where reserved inventory quantities were calculated incorrectly when users changed the unit of measure (e.g., from dozens to individual units) during stock transfers. The system now properly recalculates reserved quantities to reflect the new unit of measure, ensuring accurate inventory tracking and preventing discrepancies in stock levels.
Original PR description
### Steps to reproduce the issue: 1. Create a Storable Product and give it a UOM 2. Create an On Hand stock in a certain location 3. Go to Barcode and create a new Internal Transfer 4. Add the…
### Steps to reproduce the issue: 1. Create a Storable Product and give it a UOM 2. Create an On Hand stock in a certain location 3. Go to Barcode and create a new Internal Transfer 4. Add the Product and with any quantity and click on Confirm (not Validate) 5. Edit the line of the Product (pencil icon), change the quantity and the UOM and click on Confirm 6. Validate the Transfer 7. Go back to the Product and click on the "On Hand" or the "Update Quantity" button 8. The reserved quantity is not null ### Explanation: When you change `stock.move.line.product_uom_id`, `stock.quant.reserved_quantity` (using `product.product.uom_id`) is not changed to reflect the new `uom.uom.factor`. You then have two routes: - In `stock_barcode`, `stock.move.line.product_uom_id` changes first, `stock.move.line.quantity` change is triggered through `stock.move.line._inverse_qty_done` afterwards. https://github.com/odoo/enterprise/blob/d04b69ba03877a9b4aae82fb061dca23b1bfc4bc/stock_barcode/models/stock_move_line.py#L58-L61 When calling `stock.move.line._synchronize_quant`, `stock.move.line.quantity_product_uom` will use the new `stock.move.line.product_uom_id` while `stock.quant.reserved_quantity` still reflects the old `uom.uom.factor`. https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/stock_move_line.py#L421-L422 (e.g.: going from `1 Dozens` to `2 Units` would give you `1.09 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`) - There is a similar issue in _Inventory > Transfers > Internal_, where `stock.move.line.product_uom_id` changes at the same time instead. In that case, the whole operation will be done using the previous `stock.move.line.product_uom_id`, and changing `stock.move.line.product_uom_id` before changing `stock.move.line.quantity` would cause the same issue as in `stock_barcode`. (e.g.: going from `1 Dozens` to `2 Units` would give you `2 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`) ### Suggested fix: The fix is made to be as simple as possible, the two conditions will be reduced to simple assignations: - The first one will be `product_uom_id`, with which `uom.uom._compute_quantity` will be called. - The second condition will be `quantity`, which will be set in a `vals.get` in the `qty` parameter of the compute. To make everything uniform, there will be no exception where `stock.move.line.quantity_product_uom` is used. opw-3798046 Forward-Port-Of: odoo/odoo#162169 Forward-Port-Of: odoo/odoo#160656
Fixed an issue where attachments added to the Survey Invite email template were not appearing when sending survey invitations. The fix ensures that any attachments configured in the email template are now automatically included and displayed in the survey invite form, improving the user experience when sending surveys with supporting documents.
Original PR description
**Current behavior:** Adding an attachment to a mail template record associated with the survey invite wizard will not cause the attachment to populate the relevant field when actually sending a new…
**Current behavior:**
Adding an attachment to a mail template record associated with
the survey invite wizard will not cause the attachment to
populate the relevant field when actually sending a new survey
invite email.
**Expected behavior:**
The attachments linked in the email template which is used by
the survey invite wizard will appear in the form when sending a
survey invite.
**Steps to reproduce:**
1. In settings, go to the email templates management page
2. Select the Survey: Invite template and upload some
attachment
3. Go to the Survey application and click on one of the surveys
listed, observe the lack of attachments despite having the
email template with the attachment selected
**Cause of the issue:**
The survey invite wizard never uses its template's attachments
to modify/update its own attachment_ids field.
**Fix:**
Make the attachment_ids field a stored computed field.
opw-3709830
Forward-Port-Of: odoo/odoo#162273
Forward-Port-Of: odoo/odoo#152728This update improves error handling when generating EMV QR codes on invoices. Previously, users would see a confusing error message when a bank account wasn't configured. Now the system provides clearer feedback to help users understand what needs to be set up correctly before EMV QR codes can be generated.
Original PR description
Description of the issue/feature this PR addresses: Improved error handling for EMV QR generation for invoices Current behavior before PR: Currently, if EMV QR is selected on the invoice where the country does not support EMV QR an error is raised. Desired behavior after PR is merged: However, this error is also raised if EMV QR is selected but the bank account is not set. The following error is raised `No EMV QR Code is available for the country of the account False.` This commit adds a check to ensure the bank account is set and it raises a better error message. Task# 3868467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162319
This update adds and corrects missing Romanian translations for the CRM module. Romanian language support was not previously available in the translation system for this version, so these translations are now being added to ensure Romanian-speaking users have proper language support in the CRM application.
Original PR description
Some parts of the translation were missing and Romanian isn't available as a language in Transifex for this version. Therefore we add it in now. English grammar mistakes of original string are left untouched. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162418
Fixed a confusing error message that appeared when users tried to register payments for both customer invoices and vendor bills simultaneously. The new message is clearer and more accurately describes the issue, helping users understand why the action cannot be completed.
Original PR description
When registering payment for customer invoices and vendor bills at the same time, a misleading error message appears"You can't register payments for journal eithers being both inbound and outbound". Replacing it with a clear message "You can't register payments for both inbound and outbound moves at the same time." Task id: 3638740 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162224 Forward-Port-Of: odoo/odoo#162101
This update fixes errors in the Spanish language labels for withholding tax invoices in the Ecuador localization module. The corrections ensure that tax-related documents display accurate and properly translated text to users in Ecuador, improving the clarity and professionalism of financial documents.
Original PR description
Fix errors in some of the spanish invoice_labels for withholding taxes. Thanks to @AlmustafaNET #147867
This fix improves the clarity of payment information in Point of Sale sales reports by adding the session name to payment entries. When generating reports that span multiple POS sessions, users can now easily identify which session each payment belongs to, eliminating confusion when reviewing multi-session reports.
Original PR description
Current behavior: When generating a sale report for multiple pos sessions, the payment name is not clear which session it belongs to. Steps to reproduce: - Open PoS and make some sales - Close the session, and do the first step again. - Go in reporting and generate the report for a period that includes the two sessions. - In the payments table you will see the payment name, but you won't know which session it belongs to. opw-3684937 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160369
This fix removes a duplicate "no sales orders" message that was appearing twice in the customer portal after a recent redesign. Users will now see only one clear message when they have no orders, providing a cleaner and less confusing experience.
Original PR description
Description of the issue/feature this PR addresses: After the portal redesign, messages for no quotations or sale orders were moved before the portal_table template, which is called when there are entries of quotations or sale orders. However, the previous version of the message for sale orders was left after the template call. This commit removes the previous version of the message to avoid having duplicated messages. Current behavior before PR: Two similar messages are displayed in the portal when there are no sale orders. - There are currently no sales orders for your account. - There are currently no orders for your account. Desired behavior after PR is merged: Only one message is shown in the portal when there are no sale orders, as it happens for the quotations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr