Tuesday, April 30, 2024
25 changes · 17.0
Resolved issues and error corrections
This fix ensures that when creating a new invoice, the payment method automatically inherits from the customer's configured payment method instead of defaulting to "Por definir" (undefined). This improves workflow efficiency by eliminating the need to manually set the payment method for each invoice when the customer already has a preferred payment method configured.
Original PR description
- When creating a new invoice the payment method is "Por definir" by default, so it is necessary to check the l10n_mx_edi_payment_method_id of the customer used in the invoice before checking the…
- When creating a new invoice the payment method is "Por definir" by default, so it is necessary to check the l10n_mx_edi_payment_method_id of the customer used in the invoice before checking the l10n_mx_edi_payment_method_id of the invoice and replacing it if the customer has this value assigned or use the corresponding payment method. Description of the issue/feature this PR addresses: 1. Configure the Payment way and the Usage in the partner.  2. Create a new invoice and select the partner configured in number 1.  The payment way doesn't change, it is "Por definir" by default. Desired behavior after PR is merged: After this is merged the invoice payment method will be the same as assigned in the partner. 
A previous update incorrectly applied line grouping to all intrastat reports. This fix restricts the grouping feature to Belgian intrastat reports only, where it's needed. Users can now control this grouping behavior through report filters, with the setting defaulting to off for most countries and on for Belgium.
Original PR description
In this commit [1], we changed the way we display intrastat report lines by grouping them. We did it for all the intrastat report, it was wrong. Actually, we should only do it for the belgian report. The aim of this commit is adding a key in options to know if lines should be grouped or not. By default the option is set to False except for the Belgian report. Since version 16.4, users can change the value by using the filter. task-3892823 [1]: https://github.com/odoo/enterprise/commit/217594fe8ba00329b3eb5c68e3eca3b556127cde Forward-Port-Of: odoo/enterprise#61455
Fixed a critical error that occurred when generating the Spanish Tax Report (Model 347) with large numbers of partners having small transactions. The issue happened because the system tried to process an extremely long list of excluded partners, causing the report to fail. The fix optimizes how excluded partners are handled, allowing the report to generate successfully even with thousands of partners.
Original PR description
Summary ----- When you try to display the spanish tax report, model 347, if you have too much partners with few small transactions (the sum is lower than 3005.06€), an error is raised. Steps to reproduce ----- 1. Install the l10n_es module 2. Create 30,000 invoices with an amount of 1€, and each having a distinct partner linked 3. Open the model 347: Accounting > Reporting > Tax Report, and select the report called "Tax Report (Mod 347)(ES)" and a date range large enough 4. Observe the very long UserError Cause ----- Too much partners must be excluded and the list of this partners are added to a domain which becomes very long and an error is raised when we use the function ast.literal_eval on it. Fix ----- The list of the excluded partners are passed in the "forced_domain" options. Like that, the ast.literal_eval function is not applied on it and the error is not raised. opw-3770944 Forward-Port-Of: odoo/enterprise#61452
Fixed an issue where the sign template editing popover would remain open even after clicking away or leaving the app. The fix ensures the popover closes appropriately when clicking outside of it, while still staying open when you're actively working with role settings in a modal dialog.
Original PR description
Before this commit: when editing a sign template and opening the sign item popover, it remained open when clicking away even when leaving the sign app. This commit addresses this issue by refining the `closeOnClickAway` to close the popover only if the click is not within an active modal, ensuring that the popover stays open when the role modal is displayed. Task: 3861496 _______________________________________________________________ Bug was introduced in this PR: https://github.com/odoo/enterprise/pull/49900 in attempt to keep the popover open when updating the sign item role. Forward-Port-Of: odoo/enterprise#60613
This fix corrects an issue where employee names were appearing twice instead of showing the employee's avatar and name in the timesheet page when viewing shared projects on mobile. The problem was caused by a previous update that accidentally duplicated the employee field. Now the employee avatar displays correctly alongside their name.
Original PR description
Steps: - Install timesheet app. - Create a project and task in that project. - Add timesheet in that task. - Share that project. - Open that project in project sharing in mobile. - Open task form and go to timesheet page. Issue: - Employee field is displayin twice instead of displaying avatar and it's name. Cause: - PR-https://github.com/odoo/odoo/pull/95971 here it suposed to add employee avatar in portal but it added same employee that why employee name is showing twice in kanban. Fix: - Added kanban avatar instead of employee field twice to display employee avatar properly. task-3716784 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 removes warning messages that appear when Odoo starts by replacing outdated code instructions in the web interface templates. The change modernizes the underlying code without affecting how the web interface looks or functions for users.
Original PR description
**Description of the issue this PR addresses:** On start of Odoo, warnings are present in the console log. These warnings point to webclient_templates.xml using the deprecated directive `t-esc` and suggests replacing with `t-out` **Current behavior before PR:** Warnings are logged to console **Desired behavior after PR is merged:** No warnings logged to console --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where unit prices would revert to default values when editing purchase orders on mobile devices. The problem occurred because a required discount field was missing from the mobile view, causing the system to recalculate prices incorrectly. The fix adds the discount field to the mobile view and displays it when applicable, ensuring price changes persist correctly.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have `purchase` and `sale_timesheet` installed; 2. go to purchase; 3. make browser window narrow enough to trigger mobile view; 4. create an RFQ; 5. add…
Versions -------- - 17.0+ Steps ----- 1. Have `purchase` and `sale_timesheet` installed; 2. go to purchase; 3. make browser window narrow enough to trigger mobile view; 4. create an RFQ; 5. add product; 6. change the unit price. Issue ----- The unit price changes back to default. Cause ----- When changing the `price_unit` field, the `_compute_amount` method gets triggered, which depends on the `discount` field. As this field wasn't present in the mobile view, its compute method was called, which is the same method that computes `price_unit`. Normally this method skips recomputing `price_unit` if it was modified, but because `sale_timesheet` makes `uom.group_user` an implied ID of `base.group_user`, it can now access the `product_uom` field, and assumes a change from `_origin` as there is no `_orgin.product_uom` to compare it to if the PO hasn't been saved yet. Solution -------- Add the `discount` field to the mobile kanban view. Also display the discount on mobile if its value is non-zero. opw-3767765
This fix resolves an error that occurred when saving a product with a project property in the HR Timesheet module. The issue happened because the system was not properly handling cases where context information was missing during the save process. Users can now successfully create and save products with project properties without encountering errors.
Original PR description
**Steps** - Install hr_timesheet. - Create a new product. - Add a property to the product, type many2one, model Project. - Chose any project. - Save the product. ** Traceback error ** **Issue** When the product is saved, the product.template model is flushed and the context keys are all set to None. https://github.com/odoo/odoo/blob/3c7db87ade7e99eafb44228bd038fa39429fdabc/odoo/models.py#L6352 Which causes a problem when computing the display_name of project.project **Fix** Handle the case where context=None. opw-3885370
Fixed an issue preventing customers from paying with Razorpay wallet in India. The payment system now allows customers to select their preferred payment method from all available options when using wallet, ensuring transactions are properly recorded in the system. This resolves errors that occurred when attempting wallet payments.
Original PR description
Steps: - Install and configure Razorpay provider. - Install sales app. - Enable wallet india PM. - Create quote and try to pay it via wallet india. Issue: - User error when trying to pay via wallet…
Steps: - Install and configure Razorpay provider. - Install sales app. - Enable wallet india PM. - Create quote and try to pay it via wallet india. Issue: - User error when trying to pay via wallet india. Cause: - `orders` API does not take `wallet_india` as method key of payload also I tried other like `wallet` and `wallets` but they are not also working even though Razorpay response with method `wallet` when we pay via wallets so `wallet` is right value but `orders` API does not count it as one. Fix: - Do not pass any method in payload when user select `wallet` and open Razorpay form with all PM so user can pay via whichever method they want and if selected method exist in the odoo then set that PM to transaction. For master: - Add `Pay later` payment method so we can store all transaction with proper payment method in odoo. - Change code of wallet PM from `wallets_india` to `wallet` so when razorpay fix code issue it'll work automatically without any issues and we don't need to pass mapping to get proper PM via `_get_from_code`. opw-3867594
This fix resolves an error that occurred when users tried to add Spanish electronic invoicing certificates to their company settings. Previously, the system would crash with an error when attempting to save certificate information. The fix enables proper handling of Spanish certificates for electronic invoicing compliance.
Original PR description
Description of the issue/feature this PR addresses: Using an spanish certificate in res.company (field -> l10n_es_edi_facturae_certificate_id) returns error none field. Current behavior before PR:…
Description of the issue/feature this PR addresses: Using an spanish certificate in res.company (field -> l10n_es_edi_facturae_certificate_id) returns error none field.
Current behavior before PR: When trying to save the changes you get the error:
`RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1765, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/17.0/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1792, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1996, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/17.0/addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/home/odoo/src/odoo/17.0/addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 468, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/addons/web/models/models.py", line 73, in web_save
self = self.create(vals)
File "<decorator-gen-364>", line 2, in create
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 414, in _model_create_multi
return create(self, [arg])
File "/home/odoo/src/odoo/17.0/addons/l10n_es_edi_facturae/models/l10n_es_edi_facturae_certificate.py", line 54, in create
if fields.datetime.now() > certif.not_valid_after:
AttributeError: 'NoneType' object has no attribute 'not_valid_after'`
Desired behavior after PR is merged: Save the certificate.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix corrects an issue where refunded invoices were incorrectly being added to the total amount when re-invoicing a sales order. Previously, when a credit note was created for a partial invoice and the remaining amount was re-invoiced, the down payment amount was being added instead of subtracted, resulting in incorrect invoice totals. This fix ensures refunded invoices are properly excluded from calculations.
Original PR description
Steps to reproduce: 1) Create a quotation and confirm it 2) Invoice a first down payment (fixed amount) and validate it 3) Invoice the rest of the SO amount and validate it 4) Create a credit note for the last invoice created (at step 3)) 5) From the SO, re-invoice the rest of the SO amount Issue: the amount of the downpayment is added to the total, not subtracted opw-3817440 Forward-Port-Of: odoo/odoo#161350
This fix resolves an issue where users were incorrectly redirected to an error page when saving SEO optimization settings on course pages. The update ensures users remain on the same course page after saving, improving the user experience and preventing confusing navigation errors.
Original PR description
**Description of the issue/feature this PR addresses:** This PR address the issue of redirecting to courses page with /invite_error when trying to update the optimize seo. **Current behavior before PR:** Previously, when editing Optimize SEO and clicking "Save," it redirected to /invite_error in Courses instead of remaining on the same URL after saving, which was caused due to not receiving seoName. **Desired behavior after PR is merged:** Now after saving, we stay on the same course URL without being redirected to /invite_error. This fix includes checking if the seoContext doesn't have a seoName , in which case we redirect to seoNameDefault to prevent redirection to /invite_error on the Courses page. **Task**-3688285 Forward-Port-Of: odoo/odoo#161029
This fix resolves an issue where table row and column editing controls were not displaying properly in the To-Do application. The controls were being hidden due to overflow restrictions. The fix adjusts the padding in the editor area to ensure these controls are fully visible when users hover over table cells, improving the table editing experience.
Original PR description
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to…
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to reproduce the issue: ============================= - Go to to-do - add a table on top the editable - Hover on the top left cell - The row and col ui boxes doesn't show correctl Origin of the issue: ==================== Since we forced the mentioned commit that `overflow-x` should be hidden, then the ui elements which overflows the visible area of the html field will be hdden too that's why only a small part of them appear. Solution: ========= To conserve the same ui and not add extra padding , we add padding to the `note-editable` to make it possible to display the ui elements fully (needs 16px) and decrease the padding of the padding of the formView sheet. Before: ======  After: =====  task-3861784 Forward-Port-Of: odoo/odoo#162029
This update resolves timing-related failures in the automated testing suite for the base automation module. The tests were running too quickly, causing steps to execute before previous actions completed. The fix adds proper wait conditions to ensure each test step completes before the next one begins, making the tests more reliable and stable.
Original PR description
fixes for following runbot errors: - 62449 - 62452
This fix resolves an issue where newly created contacts were not showing their assigned pricelist information until after saving and reopening the record. The problem was particularly noticeable in version 17.0 where the system creates and reads records in a single operation. The fix ensures pricelist data displays correctly immediately when creating a new contact.
Original PR description
To reproduce the problem: - Enable pricelist feature - Create a new Contact > no pricelist shown (all versions affected) - Save > still no pricelist shown (>= 17.0 versions affected) - Exit and go back to the Contact: the pricelist is set The _compute_product_pricelist() doesn't work properly for new record, then we create a new contact, pricelist is empty (until the save for version < 17.0, until save/exit/return on the record for version >= 17.0). In 17.0, we introduced web_save, which makes create() and read() in the same request. This is why the version >= 17.0 is more problematic and more confusing for the user. Prior to 17.0, it was not great either, but was never considered a bug (some effort has been made in https://github.com/odoo/odoo/pull/153326/files). So this fix targets versions >= 17.0. Fix the issue by taking care of new ids in the _get_partner_pricelist_multi() method. Also, add a Form test case for every possible case. opw-3872299
This fix resolves an issue where calendar reminders were being duplicated for recurring daily events. The system was incorrectly creating multiple reminder notifications for the same event due to a logic error in how it determined when the next reminder should be sent. Users will now receive only one reminder per event occurrence instead of duplicate notifications.
Original PR description
Before this commit, alarms were always being set up when there was no 'next_date' specified, creating an undeterministic behavior since inside the 'get_next_alarm_date' function we check if the 'call_at' attribute from the trigger happens before 'now'. If this condition is false, i.e. if there is already an alarm set up for the future, we were returning a falsy value for the next alarm date and setting up the alarm anyway (using the current date inside '_setup_alarms', since the context was None), thus generating a new alarm with the wrong call date. After this commit, we make an extra check for recurrences in the 'get_next_alarm_date' function in order to get the correct next date for the next alarm from the next recurrent event. Additionally, if there is no next date to be called in the in the future, we skip the 'send_reminder' function which was wrongly creating another alarm using 'now' as time. Issue-from: odoo/odoo#147914 Forward-Port-Of: odoo/odoo#161941
This update corrects a misspelling in the Spanish language translation for Latin America. The country name "República Doiminicana" has been fixed to the correct spelling "República Dominicana". This ensures customers see the accurate country name when using the system in Spanish.
Original PR description
Description of the issue/feature this PR addresses: This got error on wrong translate, customer can't find the correct name. Current behavior before PR: República Doiminicana Desired behavior after PR is merged: República Dominicana --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects how rounding precision is applied in the manufacturing and inventory management systems. The system was using incorrect parameters when calculating rounded values, which could have led to inaccurate quantity calculations in bills of materials and stock movements. This fix ensures rounding is applied correctly across these critical business processes.
Original PR description
Versions -------- - 16.0+ Issue ----- `precision_rounding` values were being passed incorrectly as `precision_digits` parameters. Solution -------- Pass them as named `precision_rounding` parameters instead. Forward-Port-Of: odoo/odoo#163154
This fix resolves an issue where extra down-payment invoice lines with zero price were being automatically created when taxes were removed from the initial down-payment invoice. The solution improves the down-payment calculation logic to properly exclude down-payment lines and only consider actual sales order product lines, preventing duplicate entries in subsequent down-payment invoices.
Original PR description
… when remove the tax on first downpayment invoice Issue: ====== Extra down-payment line is creating Steps to reproduce the issue: ============================= - create an SO, then create…
… when remove the tax on first downpayment invoice
Issue:
======
Extra down-payment line is creating
Steps to reproduce the issue:
=============================
- create an SO, then create downpayment with 30% percent, remove the tax in generated INV and post the invoice.
- go back to SO create another downpayment with 30%
Solution:
=========
Typically, when calculating the value of down-payment lines,
we only consider sales order lines for products, not down-payment lines.
This is because, according to the Odoo workflow, down-payment lines are
created based on product lines in the sales order, not on down-payment
lines themselves. Therefore, I am filtering out those lines here.
closes odoo/odoo#163699
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-prThis fix resolves an issue where extra down-payment invoice lines with zero price were being automatically created when removing taxes from the first down-payment invoice. The solution ensures that down-payment calculations only consider actual sales order product lines, not previously created down-payment lines, preventing duplicate entries from being generated.
Original PR description
…erated when remove the tax on first downpayment invoice Issue: ====== Extra down-payment line is creating Steps to reproduce the issue: ============================= - create an SO, then create…
…erated when remove the tax on first downpayment invoice
Issue:
======
Extra down-payment line is creating
Steps to reproduce the issue:
=============================
- create an SO, then create downpayment with 30% percent, remove the tax in generated INV and post the invoice.
- go back to SO create another downpayment with 30%
Solution:
=========
Typically, when calculating the value of down-payment lines,
we only consider sales order lines for products, not down-payment lines.
This is because, according to the Odoo workflow, down-payment lines are
created based on product lines in the sales order, not on down-payment lines themselves.
Therefore, I am filtering out those lines here.
closes odoo/odoo#163699
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-prThe Kitchen Display app was causing testing failures when its conditional menu interacted with other applications, resulting in log errors and system failures. This fix skips the problematic menu during testing to prevent these cascading failures and improve system stability.
Original PR description
The Kitchen Display app uses a conditional menu that can leads to the frontend. In some situation, other apps are tested again during the Kitchen Display test leading to a mess in the logs and a epic failure. As no viable solution was found, the menu is now skippep with this commit.
The portal's mobile navigation menu was extending beyond the navbar boundaries on mobile devices, which could cause unwanted horizontal scrollbars in certain configurations. This fix removes an unnecessary negative margin that was causing the overflow, improving the mobile user experience and preventing layout issues.
Original PR description
The portal mobile navbar menu was overflowing its parent (the navbar) on the left and right once opened. This is because of a combination of commits [1] and [2]. Indeed, [1] added a negative margin…
The portal mobile navbar menu was overflowing its parent (the navbar) on the left and right once opened. This is because of a combination of commits [1] and [2]. Indeed, [1] added a negative margin on that menu to compensate the parent navbar's padding. However, [2] later forced that parent padding to 0 with a class. This commit removes the negative margin compensation to fix the issue. Note: the design may not seem that broken without this fix. But in custo it could look very bad as it could introduce a horizontal scrollbar: just make the portal layout use a fluid container and have `$navbar-padding-x` be higher than `$grid-gutter-width`. Also, note that the design is not perfect as the inner padding of that menu also relies on the navbar padding value... which is ok in Odoo but only because we change the default of Bootstrap, which is 0. It was chosen to ignore that problem in stable. In master, the navbar padding will be left back to the BS default (0) and another spacing value will thus be used for the portal menu. [1]: https://github.com/odoo/odoo/commit/f8940943592b696b4f27c0013f837a6cdecb0433 [2]: https://github.com/odoo/odoo/commit/df8535fbd40e1e5c09dbe616a3332c76c23525c8 Related to https://github.com/odoo/odoo/pull/163996 | Before | After | | -------- | -------- | |  |  |
This update temporarily suppresses warning messages that appear when using timezone functions in Python 3.12. While a more comprehensive solution is needed in the future to properly handle all timezone references throughout the codebase, this fix prevents unnecessary warnings from appearing to users now. The team plans to implement a complete solution in a future version.
Original PR description
This is a temporary fix to avoid warnings when using uctnow in python 3.12. A proper fix should be to localize all timezone using datetime.now(timezone.utc) instead of datetime.utcnow(). Unfortunately this is not as straightforward as it seems, since those naive timezones are localize in the code conditionally, but not always. It may take time and an in depth review to fix all occurrence. Not sure yet in witch version we should fix it properly. While in netsvc file, removes the encoding suppress warning Forward-Port-Of: odoo/odoo#163872 Forward-Port-Of: odoo/odoo#163794
This update modernizes how Odoo handles Python code analysis to align with Python 3.12+ standards. The changes remove deprecated code patterns that will stop working in Python 3.14, ensuring the system continues to function properly as Python evolves. This is a maintenance fix that keeps Odoo compatible with current and future Python versions.
Original PR description
Since 3.8, some ast object and parameters changed, with backward compatibility. They are now deprecate in 3.12 and will be removed in 3.14. Keeping a compatibility between both solutions is possible but hard to do with python > 3.7, the solution was to mute the warning in odoo 15.0 since it is unlikely to make it compatible with python 3.14, but we can fix it a cleaner way in 16.0 since the minimal python version is higher than 3.8. see #162438 for 15.0 suppress warning fix part of #162438 , adaptations for ubuntu noble Forward-Port-Of: odoo/odoo#163487
This fix resolves a system error that occurred when creating sales orders with products from different company branches. The issue was in how the system validated company access, and this update corrects the validation logic to check companies individually rather than as a group, allowing sales orders with mixed-company products to save successfully.
Original PR description
Issue: A traceback error is raised when a sales order is saved with products with varying company ids. Was trying to lookup a list of ids rather than a singular id which triggered the traceback. Purpose of this PR: To check accessible company branches on a individual company rather than a recordset of companies. Steps to Reproduce on Runbot: 1) Create branch of main company. 2) Create products one with company id of the branch and the other of company id in the main company. 3) Create sale order, order lines with each of the products. 4) On save, a traceback error is raised. Notes: opw-3810770 Forward-Port-Of: odoo/odoo#162547