Tuesday, April 30, 2024
29 changes
4 changes
Resolved issues and error corrections
Updated the subscription checkout test setup so the website and sales order use the same company. This prevents currency access mismatches during automated testing, making subscription checkout validation more dependable without changing customer-facing behavior.
Original PR description
Modifies `test_cart_update_so_recurrence` to use a consistent company for both sale.order and website, resolving access issues to `company_id.currency`. Previously, the test encountered a scenario where `compute_all` could not access the correct currency, as it depended on the company from the sale.order, which differed from the website's company. By aligning the company across both entities, the test now correctly accesses the necessary currency, ensuring reliable test outcomes. Related: odoo/odoo#144389 task-2596416
Manufacturing users who do not have PLM access can now create Bills of Materials with lines without being blocked by a permissions issue. This helps manufacturing managers complete setup work without needing extra PLM permissions.
Original PR description
Currently, creation of BoMs with lines triggers a search of MrpEco records. This breaks BoM creation for non-PLM users (e.g. MRP managers). This commit fixes the issue by using `sudo().search()`.
Removed two unintended lines that were accidentally left in an accounting reports calculation method. This keeps the reporting code cleaner and helps reduce the risk of unexpected behavior in financial report processing.
Original PR description
This commit introduced 2 lines of unwanted code: https://github.com/odoo/enterprise/commit/e72b8dd7c48385cd189319938bbe40a886e9ea53
A bug in accounting reports was corrected so report groupings are validated using the report itself rather than looping through records incorrectly. This helps prevent report errors in affected accounting report configurations and keeps financial reporting behavior reliable.
Original PR description
Introduced in odoo/enterprise@e72b8dd7c48385cd189319938bbe40a886e9ea53
21 changes
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.