Thursday, November 30, 2023
42 changes · 17.0
Resolved issues and error corrections
This fix stops the mail thread from accidentally loading more messages than the user requested when returning to a previous scroll position. It improves responsiveness and avoids unnecessary data loading in message conversations.
Original PR description
The IntersectionObserver was sometimes started and called its callback before the scroll was restored, in which case the load more button was always visible, leading to loading more messages than intended. To fix, delay the starting of the visible until the scroll is restored. runbot-35533
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-4680583793The project profitability section is now shown only when the required accounting conditions are enabled. This prevents users from seeing financial information areas that are not relevant to their current configuration.
Original PR description
Steps: - Install project & accounting - Open project - Open project.update - There is profitability section - Go to accounting module configuration,settings - Analytic accounting field true or false Issue: - Analytic accounting feature true or false the profitability section always visible in project.update Cause: - There is no condition for profitability section visibility Fix: - Added required conditions for profitability section visibility Task-3484413
Demo documents in Accounting and Recruitment will no longer be sent for OCR processing just because they are opened. This prevents unintended digitization of sample records and keeps OCR use manual for demo data.
Original PR description
Previously, the demo documents were automatically sent to the OCR when opened in form view. It's not what we want, those demo documents should only be sent manually. This happened because, in the demo data, the main attachment isn't set. When reading the document, the attachment previewer would select an attachment as main attachment and, as the OCR relies on the `register_as_main_attachment` hook, it would be sent for digitization. Now, the main attachment is explicitly set in the demo data definition.
This 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
Text resized through the website editor now adjusts properly on different devices and screen widths. This helps keep edited website content readable and visually consistent for visitors on phones, tablets, and desktops.
Original PR description
Since [this other commit], we use classes to change the font size of text. Unfortunately, we forgot to make them responsive. This commit fixes that. [this other commit]: https://github.com/odoo/odoo/commit/194f73a9bbad8c3c3fb5c378e7bdfa704aaacdc0 task-3615976
This update adds automated checks for several ways users create links in the web editor, including keyboard shortcuts, typed URLs, toolbar actions, and the command menu. These tests help reduce the risk of future changes breaking link creation workflows.
Original PR description
Current behavior before PR: No test cases were there for dialog box based link creation. Desired behavior after PR is merged: Added Qunit test cases for various scenarios Cases Covered: * Making links with hotkeys. * Typing valid url + space should make link. * Making link with powerbox. * Selecting text and link button on the toolbar. task-3087957
The IoT connection URL is now built using safer JSON formatting instead of manual text assembly. This helps prevent malformed connection data and improves reliability for IoT device communication.
Original PR description
Before, the url was built with string comprehension. Now json.dumps is use to ensure that the JSON sent is valid
This update improves automated checks around creating links in the website editor, including links made from typed URLs, the command menu, and the toolbar dialog. It helps ensure common link creation flows keep working reliably for users while removing reliance on obsolete test coverage.
Original PR description
Specification: -The tests are not testing the actual OdooEditor behavior, but the `editorCommands.createLink()` function (which is not used anywhere). -CreateLink method was a dead code. -No test cases were there for dialog box based link creation. Cases Covered: -typing url + space -powerbox -selecting text and link button on the toolbar task-3087957
Updates Mexican localization tax group records to fix incorrect names and add missing translations. This helps users see clearer, properly localized tax labels in accounting screens and reports.
Original PR description
These changes intend to update current tax group records to fix naming issues and add missing translations.
The course sharing feature now correctly copies the share link to the clipboard. This fixes a small but user-visible issue where learners or visitors could not copy links from the website slides sharing tools.
Original PR description
With this commit 963842381e2449ee59e5cffd1bae8656f5477e7a ClipboardJS was removed to use the native clipboard api. But here the innerText was checked instead of the value so there was nothing to copy in the clipboard. This commit fix this. Task-3607299 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes a translation-related test produce consistent results instead of failing randomly. It helps maintain development reliability without changing customer-facing functionality.
Original PR description
The test added in 09a4762b will fail randomly, because of the nondeterministic os.walk access. This commit allows this nondeterminism in the test. 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
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
A bug prevented accounting dashboard totals for journal entries marked for review from appearing. The fix makes those review counts and amounts display correctly, helping finance teams spot entries that need attention.
Original PR description
This commit fixes the consistency issue missed in https://github.com/odoo/odoo/commit/a9dd388a1128ac406b6a5cec58b3833aadb04c62. Currently, to_check_vals dictionary has journal records as keys. Later, the total amount and count of account moves marked with `to_check` are retrieved by journal.id, which don't exist in the `to_check_vals` dictionary, so `to_check` value is never displayed on the dashboard. That dictionary should contain the actual ids instead. task-3611262 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
Fixes an issue where loading demo data after installing CRM without demo data could fail because the demo user lacked the right sales access. This makes demo data setup behave consistently whether it is loaded during installation or afterward.
Original PR description
How to reproduce: - install a new DB without demo data and crm: -i crm --without-demo=1 - go to settings and click on "Load demo data" at the end of the page - the demo data will not be installed and…
How to reproduce: - install a new DB without demo data and crm: -i crm --without-demo=1 - go to settings and click on "Load demo data" at the end of the page - the demo data will not be installed and the following error will appear in the logs "Assigned user Marc Demo has no access to the document and is not able to handle this activity." - and "Marc Demo" has no access to the CRM app If the "crm" module is installed with the demo data at the module installation, it works and "Marc Demo" has access to the CRM app. The cause of the problem is that in the first case "Marc Demo" doesn't belong to group_sale_salesman while in the second case well. By reverting partially the change that remove the group_sale_salesman by removing group_sale_salesman_all_leads (see odoo/odoo#139731), the problem is solved. Technical note: the load of the demo data as a second step fails when creating an activity on a record for which "Marc Demo" has no access to because in the create method of mail_activity, we check that the user has access to the underlying record (_check_access_assignation). It works when installing the demo data while installing the module because in that case "Marc Demo" belongs to "group_sale_salesman" which give him the read access to the record. The solution here is to just re-add that group where it is removed indirectly by removing the group group_sale_salesman_all_leads from "Marc Demo". Another solution would have been to remove this check (_check_access_assignation) as we don't need it anymore (see odoo/odoo#139917 where we display activities for which the user has no access to the underlying record from the menu in the systray). But it won't solve the consistency between installing the demo data while installing the module vs installing the demo data afterward. That's why this solution has been chosen, but we plan also to remove the check (_check_access_assignation) as it is no longer needed. Note that planning activities from the interface even if the assigned user has no access to the underlying record works because the flag "automated" is set to true in that case (that flag will probably also be removed). Task-3600535
The recruitment kanban card footer now displays its items with consistent vertical alignment. This minor visual fix makes applicant and job cards look cleaner and easier to scan.
Original PR description
The kanban's footer elements were misaligned vertically, specifically the status icon. task-3473010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Posted demo invoices will no longer be automatically sent for OCR digitization. This keeps the digitization process focused on draft invoices only, avoiding unnecessary processing of invoices that are already finalized.
Original PR description
When checking if an invoice needs to be automatically sent to the OCR, we weren't checking the state of the invoice. Only draft invoices should be sent. In practice, it wasn't much of an issue as new invoices are created in the `draft` state, but for demo invoices, some of them are already in the `posted` state. Those shouldn't be sent for digitization.
This update fixes critical issues in the marketing automation system that were causing duplicate email traces to be created for the same contact and activity. These duplicates were leading to incorrect campaign statistics and emails being sent multiple times to the same person. The fix addresses timing comparison problems, participant synchronization issues, and campaign duplication scenarios, while also significantly improving test coverage to prevent future regressions.
Original PR description
Several corner cases in marketing automation may lead to duplicate traces
for a given activity / participant pair. This leads notably to statistics
being wrong, as well as traces that are canceled e.g. a mailing sent several
times on the same record uses the same email and is thus ignored once a
first email is sent.
With this task we fix several issues leading to trace duplication, notably
* a datetime comparison failing when comparing datetime.now and sql.now;
* synchornization not taking into account participants already having
traces;
* campaign duplication with synchronization date leading to duplicate
traces;
Tests are added for those use cases, to try to avoid future regressions
as much as possible.
Task-3506681 (MA: Test cleanup)
Task-2981581 (MA: Fix trace duplication and various issues)
Forward-Port-Of: odoo/enterprise#51210
Forward-Port-Of: odoo/enterprise#47413This 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
This update optimizes the mail enterprise tests by loading data and messages more efficiently. The change reduces redundant loading operations in the attachment preview tests, making the test suite run faster and more reliably.
Original PR description
Test of fix in community commit. https://github.com/odoo/odoo/pull/143867
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 a critical error that occurs when creating credit notes with text-only corrections in Chilean electronic invoicing. The issue happened because the system attempted mathematical calculations on empty fields, causing the process to fail. Users can now successfully create and confirm credit notes for Chilean invoices without encountering system errors.
Original PR description
Steps to reproduce: - Install Accounting and l10n_cl_edi - Switch to a Chilean company (e.g. CL Company) (1) - Activate a foreign currency (e.g. USD) - Create an invoice: * Customer: [a Chilean…
Steps to reproduce: - Install Accounting and l10n_cl_edi - Switch to a Chilean company (e.g. CL Company) (1) - Activate a foreign currency (e.g. USD) - Create an invoice: * Customer: [a Chilean customer] (e.g. Blanco Martin & Asociados EIRL) * Currency: USD * Document Type: (33) Factura Electrónica * Invoice Lines: [a line with a product and a tax] - Confirm the invoice - Add credit note: * Credit Method: Partial Refund * Reason: [any] * Only Text Correction: [checked] - Click on "REVERSE" - Confirm the credit note => A ZeroDivision Error is raised. (2) - Create an invoice: * Customer: [any foreign customer] (e.g. Azure Interior) * Currency: CPL * Document Type: (110) Factura Exportación Electrónica * Invoice Lines: [a line with a product without tax] - Confirm the invoice - Add credit note: * Credit Method: Partial Refund * Reason: [any] * Only Text Correction: [checked] - Click on "REVERSE" - On the credit note, set "(112) Nota de Crédito de Exportación Electrónica" as Document Type - Confirm the credit note => A ZeroDivision Error is raised. Cause: The "Only Text Correction" option is creating a credit note with a line in which only the label matters. All the other values are empty causing the error in some division. opw-3591417 Forward-Port-Of: odoo/enterprise#51689
This 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