Thursday, November 30, 2023
25 changes · 17.0
Resolved issues and error corrections
Fixed an issue that could cause the online shop to show an error page when customers selected a product category after setting a duration. This helps keep shopping navigation reliable and prevents interrupted browsing sessions.
Original PR description
This traceback arises when the user selects a product in website. To reproduce this issue: 1) Install `website_sale` 2) Open `website` and click on `shop` 3) Set `duration` and click on any product…
This traceback arises when the user selects a product in website.
To reproduce this issue:
1) Install `website_sale`
2) Open `website` and click on `shop`
3) Set `duration` and click on any product category `(eg: desk)`
4) A traceback appears
Error:
```
UnboundLocalError: local variable 'all_tags' referenced before assignment
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1873, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/website_sale/controllers/main.py", line 481, in shop
values.update({'all_tags': all_tags, 'tags': tags})
```
On `shop` method `all_tags` was referenced before `assignment` form here
https://github.com/odoo/odoo/blob/5ba7e9e16c45ba618bb728f336102454d844d144/addons/website_sale/controllers/main.py#L480-L481
sentry-4680583793This fixes when the Mass Produce option is shown so it remains available in standard manufacturing screens while respecting Shop Floor restrictions. Businesses can continue using bulk production actions in the backend without disrupting Shop Floor lot and serial number controls.
Original PR description
Shop Floor introduces a restriction on how the show_serial_mass_produce flag is computed : the components cannot consist of more than 1 lot/serial. However, this has a side effect on backend views where it is still required to have full 'Mass Produce' functionalities. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mail chatter now loads its data and messages only once when a record is opened. This prevents the same invoice attachment from being registered multiple times and sent repeatedly to OCR, reducing duplicate processing and potential confusion.
Original PR description
Basing RPC purely on OWL rendering cycle is a bad idea, as anything can happen at any time, outside of our control in a complex application. Controls to (re)load is completely moved up to the form controller, which is closer to functional changes. This will fix an issue where `register_as_main_attachment` is called multiple times, sending the same invoice to OCR multiple times. https://github.com/odoo/enterprise/pull/51670
This fixes how the Point of Sale reads monetary values in payment, discount, restaurant tip, and cash details flows. It prevents localized decimal settings from causing incorrect amounts when the server expects a dot as the decimal separator.
Original PR description
pos*: point_of_sale, pos_discount, pos_restaurant Prior to this commit, parseFloat was used in formatStrCurrency method used only in the money details popup. The problem is that the method use the parseFloat method from the web module and not the built-in. This parseFloat method takes into account the localization settings and thus the decimal separator is not always a dot but in the server, the dot is always used as the separator. This commit fixes this by using the built-in parseFloat method. This commit also adapts some parts of the code where we used the parseFloat method from the web module incorrectly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects an issue in Belgian payroll where remaining holiday pay from the previous year was being incorrectly deducted multiple times across payslips. When an employee used recovery days in one month, the system was still deducting the associated holiday amount in subsequent months. The fix ensures that once recovery days are used and deducted in a payslip, they are properly marked as consumed and not deducted again.
Original PR description
Steps to reproduce : 1 - Set 10 paid time off to an employee 2 - Set 10000 euros in recovery amount holiday n-1 3 - Set 3 days in recovery day holiday n-1 4 - Employee takes 3 paid time off in october and 3 in november 5 - Do one payslip for this employee for october (the holiday n-1 amount will be deducted on payslip) 6 - Do one payslip for this employee for november Current behaviour : the holiday n-1 amount is deducted on payslip for november too Expected behaviour : The 3 days in recovery day holiday n-1 are already counted in october's payslip. 0 recovery days holiday n-1 are remaining so the holiday n-1 amount should be equal to 0 task : 3576940 Forward-Port-Of: odoo/enterprise#51251 Forward-Port-Of: odoo/enterprise#50156
Fixed a bug in the VoIP phone system where clicking numbers or the backspace button on the numpad would ignore the cursor position in the phone number field. This ensures that users can now edit phone numbers at the correct location when using the on-screen numpad.
Original PR description
Fixed the issue when click on the numpad (number or backspace), cursor position is always ignored.
This update fixes a display issue in the HR Appraisal module where canceled appraisals were shown with hard-to-read status labels. The fix applies proper styling to ensure the text is clearly visible and uses a more appropriate color (red/danger) to better indicate that an appraisal has been canceled, rather than appearing as a draft.
Original PR description
This PR fixes a readability issue about a ribbon having a `bg-secondary` class rather than a `text-bg-secondary` one, inside the `hr_appraisal` module. If we do not set a text color on the ribbon, it will get the default one which is black, making it barely readable. To avoid any contrast issue, we replace the `bg-secondary` class with a `text-bg-secondary` one, that will automatically assign the right text color to ensure the label is readable. task-3594929
This fix resolves an error that occurred when users tried to send appraisal requests by email. The issue was caused by incompatible data formatting in the recipient field. The update ensures that recipient information is properly formatted so the email sending feature works as intended.
Original PR description
Issue: ====== Clicking on send by email on appraisal request will raise an error. Steps to reproduce: =================== - Create an appraisal request - Click on send by email button Origin of the issue: ==================== In the form view of hr_appraisal , we are displaying recepient_ids in a `many2many_tags` widget which requires `display_name` field, according to the code of `onchange` here https://github.com/odoo/odoo/blob/671640cf595dcff6a827b676a04fbe12575a4909/addons/web/models/models.py#L949-L956, We need the values of recepiend_ids to be a command. Solution: ========= Use `[Command.set(ids)]` instead of the list of ids directly to make it compatible with onchange. opw-3604104
This fix corrects how Spanish financial reports display current year and prior year earnings. The Balance Sheet now properly shows current year profits in the "Current Year Earnings" account and prior year profits (after distributions) in the "Prior Years Earnings" account, ensuring accurate financial reporting for Spanish companies.
Original PR description
In the Spanish CoA there are two accounts 'Resultado del Ejercicio' and 'Resultados de ejercicios anteriores' which represent the current fiscal year's earnings and previous fiscal years' earnings.…
In the Spanish CoA there are two accounts 'Resultado del Ejercicio' and 'Resultados de ejercicios anteriores' which represent the current fiscal year's earnings and previous fiscal years' earnings. The Balance Sheet provides two lines which represent the same things. At the end of the year, what remains in 'Resultado del Ejercicio' conceptually passes into 'Resultados de ejercicios anteriores'. At the affectation of earnings (which happens at a shareholders' meeting few months after year end), the amounts in Resultado del Ejercicio and Resultados de ejercicios anteriores are put into other accounts (such as reserves, dividends etc.) - the remainder stays in Resultado de ejercicios anteriores. This commit enables those two report lines to work as expected: - the current year's Profit and Loss appears in Resultado del ejercicio; - the previous years' Profit and Loss, minus any contributions to other accounts, appear in Resultados de ejercicios anteriores. Task: 3060790 Forward-Port-Of: odoo/enterprise#50184 Forward-Port-Of: odoo/enterprise#42352
This fix resolves an issue that was causing PDF exports of financial reports with grouped data to fail with an error. The problem occurred when the system tried to retrieve group names during the export process. This fix ensures that financial reports with horizontal groupings can now be successfully exported to PDF without errors.
Original PR description
During a PDF export, the way the horizontal group name was fetched was incorrect and led to an index error. This commit fixes it.
This update fixes issues with subscription renewal orders that couldn't be canceled or converted back to quotations even when they had no invoices. The fix also corrects how invoices are counted for subscriptions and improves the handling of parent orders when renewals are canceled or confirmed. This ensures better flexibility in managing subscription orders and more accurate financial tracking.
Original PR description
[FIX] sale_subscription: allow to cancel and set to quotation uninvoiced orders
Before this commit, when an order was a renewal of an invoiced order, it was
not possible to cancel it even if this renewal had no invoice.
It was also not possible to put it back to quote because the conditions was based
on the invoice_count value.
This PR also fix the way the invoices are computed for subscriptions
taskid: 3527957
Forward-Port-Of: odoo/enterprise#51488
Forward-Port-Of: odoo/enterprise#48239Fixed how invoice totals are displayed in Peru's electronic invoicing system. The system now correctly places the full invoice amount in the payment field, while reserving a separate field exclusively for advance payments as required by Peru's regulations. This ensures invoices comply with local tax authority requirements.
Original PR description
Currently our generic UBL mechanism puts the invoice amount either in `PayableAmount` or `PrepaidAmount` depending on what has already been paid. For Peru however, the `PrepaidAmount` is reserved for advances payments (anticipos) and should not be used for anything else. That's why we change the behavior to always put the total invoice amount in the `PayableAmount` tag. Follow-up on [task-3415758](https://www.odoo.com/web#id=3415758&cids=1&model=project.task&view_type=form)
This fix corrects how follow-up emails determine their reply-to address. Previously, when no reply-to was configured in the email template, customer replies were incorrectly routed using the sender's email instead of the company's catchall email address. Now replies are properly directed to the catchall inbox, ensuring customer responses are correctly associated with their account.
Original PR description
# Context A recent bugfix PR (https://github.com/odoo/enterprise/pull/50621) added a new function `_get_email_reply_to` in aims to correctly fetch an approriate reply-to email address if it was setup…
# Context A recent bugfix PR (https://github.com/odoo/enterprise/pull/50621) added a new function `_get_email_reply_to` in aims to correctly fetch an approriate reply-to email address if it was setup in the email template used for the followup messages. But inadvertently it introduced and unexpected behavior: if the email template has no reply-to set, the function returns `False`. In that scenario, when the final email gets prepared for sending out, calling `IrMailServer.build_email` and reply-to is `False`, it falls back to the the `email_from` encoded in the email. So in pratice, instead of using the default catchall email address, it will use the same email for the `From` and `Reply-To` email headers. This is an issue, since replying to the followup email will not correctly reroute the incoming email to the correct model (res.partner in this case). # How to reproduce: 1) Make sure that the default template for the followup emails has no reply-to set up (should be the case on a fresh database). Set up a system parameter for `Key -> mail.catchall.domain` with example `Value -> mycompany.example.com` 2) Go to Accounting > Customers > Follow-up Reports 3) Select a record 4) Click the "Follow Up" button which will open up the wizard. Let's assume that contact uses "partner@email.com" as email address and that current internal user uses "user@internal.com" 5) Send out email with default values Email being sent will show: Before this fix: `Reply-To: "User" <user@internal.com>` `To: "Partner" <partner@email.com>` After this fix: `Reply-To: "Company" <catchall@mycompany.example.com>` `To: "Partner" <partner@email.com>` opw-3605881 Forward-Port-Of: odoo/enterprise#51631 Forward-Port-Of: odoo/enterprise#51577
This fix resolves an issue where DHL shipment requests were being rejected due to incorrect decimal precision in insured values. The system was sending values with too many decimal places (e.g., 4874.4980000000005), which DHL's system rejected. By using improved rounding logic, the system now sends properly formatted values that DHL accepts, ensuring shipments process smoothly without errors.
Original PR description
Before this commit `float_round` was used to round `InsuredValue` which can lead to issues described here: https://github.com/odoo/odoo/issues/20856 In case of a floating point error, DHL returns: ```111: Error in parsing request XML:Error: cvc-fractionDigits-valid: Value '4874.4980000000005' has 13 fraction digits, but the number of fraction digits has been limited to 3.``` To fix this, we need to use `float_repr` to send the correct number of fraction digits. opw-3602063 Forward-Port-Of: odoo/enterprise#51641
This update corrects how withholding tax amounts are calculated on Ecuadorian vendor bills. Previously, the system was incorrectly grouping withholding taxes by support code only, causing some retention taxes to show wrong base amounts. Now the calculation properly considers both the tax support code and the specific tax type, ensuring accurate withholding amounts on all invoice lines.
Original PR description
Steps to reproduce: - Install l10n_ec_edi - Create a vendor bill: * Customer: [Ecuadorian contact] (e.g. Instituto Ecuatoriano de Seguridad Social) * Payment Method (SRI): Otros con utilización del…
Steps to reproduce:
- Install l10n_ec_edi
- Create a vendor bill:
* Customer: [Ecuadorian contact] (e.g. Instituto Ecuatoriano de Seguridad Social)
* Payment Method (SRI): Otros con utilización del sistema financiero
* Document Number: [any]
* Invoice Lines:
1. Product: [any product] - Price: 100 - Taxes: IVA 12%
2. Product: [no product] - Price: 0 [x] - Taxes: IVA 12%
[x] A price of 0 is used to highlight the issue, but the amount doesn't matter
- Save and confirm the invoice
- Click on "ADD WITHHOLD" button
=> The base amount of the withhold lines is not computed correctly.
One line with a retention tax seems correct: (it's only correct because the tax amount of the second invoice line is 0.00)
Tax Support: 01 Tax credit for VAT declaration (services and goods other than inventories and fixed assets)
Tax: 10% Retención IVA
Base: 12.00
Amount: 1.20
The second line with a retention tax is not correct:
Tax Support: 01 Tax credit for VAT declaration (services and goods other than inventories and fixed assets)
Tax: 20% Retención IVA
Base: 12.00
Amount: 2.40
Base and Amount of the second line should be 0.
This line doesn't appear if the invoice line without product and a price of 0 is removed.
Cause:
During the computation, the subtotals and tax amounts of each invoice lines are summed and grouped by Tax Support code.
The Base field of the withhold line is then computed from these grouped subtotals or taxes, depending only on the Tax Support code, without taking into account the fact that the withhold tax can be different.
That's why the base amount of the incorrect withhold line is 12 (instead of 0).
As it has the same Tax Support code than the first line, its value is fetched from the sum made for that Tax Support code.
Solution:
The computation of the Base amount of the withhold lines should take into account
the Tax Support code, but also the applied tax.
opw-3478803
Forward-Port-Of: odoo/enterprise#48403Customers who submit helpdesk tickets with attachments through the website form can now see their uploaded files in the ticket portal. Previously, attachments were not visible to customers, which could cause confusion about whether files were successfully submitted. This fix ensures attachments are properly accessible to customers viewing their tickets.
Original PR description
Issue: ------ When we create a ticket from website form with an attachment, the portal user no longer has access to his attachment. This is problematic because he may think that it has not been sent correctly. Cause: ------ The document has no `access_token`. Solution: --------- Give an `acces_token` to the document linked to the ticket. In this way, the document will appear in the portal view's chat. opw-3601205 Forward-Port-Of: odoo/enterprise#51438
Fixed an issue where creating a WhatsApp template for Journal Entries would fail during approval submission with an error message. The system now correctly handles both generic Journal Entries and Invoices by ensuring only printable invoice records are used when generating preview documents for template approval.
Original PR description
### Summary If you create a Whatsapp template for the Journal Entry model, a error can appear if you try to submit it for approval. ### Steps to reproduce * install `whatsapp_account` * create a…
### Summary If you create a Whatsapp template for the Journal Entry model, a error can appear if you try to submit it for approval. ### Steps to reproduce * install `whatsapp_account` * create a whatsapp template for the Journal Entry model * try to submit it for approval You should be met with the following message: "Only invoices could be printed." ### Cause The Journal Entry model (aka `account.move`) can be divided in two types: generic Journal Entries and Invoices (bill, receipt, ...). One difference between generic Journal Entries and Invoices is that Journal Entries are not intended to be printed. When a user submits a whatsapp template with the Header Type set to document, a sample record is selected to generate a demo PDF. In our case, that record will be an `account.move`. The issue occurs because that sample record can be a generic Journal Entry (i.e. not printable). ### Fix This commit ensures that the selected sample `account.move` is always an invoice. opw-3543875 Forward-Port-Of: odoo/enterprise#51279
Users who are not part of the multi-website group were unable to share appointment types because they saw a blank form. This fix removes an unnecessary permission restriction that was preventing these users from accessing the appointment sharing feature. Now all users can share appointments regardless of their multi-website group membership.
Original PR description
…ite group Because the group, website.group_multi_website, was added on the appointment types field, people not in this group were getting a blank form when trying to share an appointment type. This group should not be needed as we don't need it for the domain. task-3614904
This update fixes several user-facing issues, including planning filters without colors, accounting access for branch companies, timesheet timer entries, field service product quantities, spreadsheet history, and localized reporting/tax behavior. These corrections help prevent lost work, incorrect records, missing translations, and confusing errors in daily operations.
This fix resolves a bug where manager reminder emails for timesheets were not being sent when scheduled dates were in the past. The system was incorrectly filtering for reminders scheduled only within today's date range, instead of including all reminders scheduled before today. This ensures managers receive their timesheet reminder notifications as intended.
Original PR description
Steps to reproduce the bug:
- Install `timesheet_grid` module
- Ensure you have some timesheet to submit to managers
- Go to Settings and Activate the timesheet `Manager Reminder`
- Ensure that the `Next scheduled date for manager reminder` on the
company is set to a date in the past (at least before today)
- Run the CRON `Timesheet: Managers Email Reminder`
Issue:
The mails are not sent.
Cause:
The CRON fetch the companies with the next scheduled date that is
set between today 00:00:00 and today 23:59:59.
Solution:
Fetch all companies that have a next scheduled date before
today 23:59:59.
Inspired by https://github.com/odoo/enterprise/commit/901962e93a8117752bc49c3f480c5e3ea83f7ea2
opw-3432435
Forward-Port-Of: odoo/enterprise#51707
Forward-Port-Of: odoo/enterprise#51370This fix resolves an issue in German tax reporting where custom bill references were breaking the connection between exported tax documents and their attachments. The system now correctly uses the original document name for linking, ensuring that all attachments remain properly connected during the DATEV export process.
Original PR description
Belegfeld (attachment field) is usually the same as the move name. However, right now if a user enters a custom Bill reference on a Vendor Bill, the Belegfeld will contain the reference instead. But all attachments are generated using the move name, so the connection between the datev report line and the attachment is lost during export. This commit changes this behaviour by keeping the move name as the Belegfeld when exporting the csv file. opw-3589455 Forward-Port-Of: odoo/enterprise#51715 Forward-Port-Of: odoo/enterprise#51385
This fix resolves an issue where duplicate tax lines were incorrectly created when an invoice contained both deferred and non-deferred line items. The problem occurred because the tax grouping logic was inconsistent between different calculation methods. By aligning these methods with a shared helper function, tax lines are now properly grouped and no longer duplicated when invoices are re-validated.
Original PR description
Steps to reproduce - Create an invoice with one line that must be deferred and another line that has no deferred dates - Validate - Reset to draft - Validate again --> A new tax line appears. This is because the `tax_key` was wrongly computed and did not strictly correspond with how `compute_all_tax` was computed. Therefore new tax lines were created everytime. A new helper method used by both compute methods now asserts that both `tax_key` are the same. opw-3610056 opw-3605762 opw-3619191 Forward-Port-Of: odoo/enterprise#51760
This fix resolves an issue where payments were only partially reconciled when users applied a write-off using the same account as the original payment. The system was incorrectly attempting to reconcile multiple lines from the same account together, preventing full reconciliation. Now payments and write-offs will reconcile completely as expected.
Original PR description
Steps to reproduce: - Install Accounting - Create a customer payment of $100 - Go to "Accounting / Accounting / Journals / Journal Items" - Set a Group By Account - Under "Outstanding Receipts" account, you should find the payment - Select the payment and reconcile it - Use the same account for the write-off (i.e. Outstanding Receipts) - Reconcile => The payment and the write-off are partially reconciled. They should be fully reconciled. Cause: The write-off is created with "Outstanding Receipts" account for both the write-off line and the counterpart line. Once created, a filter on the reconciliation account (i.e. Outstanding Receipts) is performed on the write-off lines to reconciled them with the payment line. As both write-off lines are using the same account, we try to reconcile the payment line ($100), the write-off line ($100) and its counterpart ($-100) together, which cannot be fully reconciled. opw-3553008
Fixed an issue where the magnifier glass search button became inaccessible when editing cells in the timesheet grid. Users can now click the magnifier glass button while a cell is being edited, improving the usability of the timesheet interface.
Original PR description
Steps: - Install `hr_timesheet` - Go to timesheet/ All timesheets - Click on a random cell to edit it - Try to click on magnifier glass As this input is located above the button at the dom level it is no longer accessible when input is focused opw-3604730 Forward-Port-Of: odoo/enterprise#51735
Fixed a display issue in the Field Service map view where the planning menu dropdown was overlapping with the zoom buttons and copyright information. The fix adds proper layering (z-index) to ensure all map controls display correctly without obstruction.
Original PR description
Steps: - Open Field Service - Go to map view - Dropdown planning menu Issue: - The planning menu dropdown overlaps with the +/- button from the map view. Cause: - Not giving the z-index property. Fix: - Add the z-index property for leaflet-top and leaflet-bottom class to properly displaying the planning dropdown menu which overlaps the +/- button and copyright information respectively. task-3502839 Forward-Port-Of: odoo/enterprise#47312