Wednesday, January 10, 2024
55 changes · 17.0
Enhancements to existing features
This update fixes how the Barcode App handles destination locations and package assignments when scanning multiple products. Previously, when users scanned a group of products followed by a destination or package, only the last product was affected. Now the destination or package correctly applies to all scanned products in the group, making the app behavior match its configuration label "After group of Products".
Original PR description
Before this commit, in the Operations Types Barcode Apps configuration, if the setting for Destination Location or Put in Pack was set on "After group of Products", once in the app, if the user scans…
Before this commit, in the Operations Types Barcode Apps configuration, if the setting for Destination Location or Put in Pack was set on "After group of Products", once in the app, if the user scans multiple products then scan a destination, the destination is actually applied only to the last scanned product. For the put in pack, all the scanned product were placed in the package, except when an existing package is scanned (in this case, like for the destination, only the last scanned product was concerned.) This worked like that because in fact, this setting's option reflected the old optional setting and should work like before the creation of those settings. But the label, "After group of Product", was misleading and it could be verify interesting to make those settings work like the label said and applied the destination and the package after a group of scanned product. This commit do that. But this change implies an issue: what should happen if you scan partially a reserved line then scan a destination or a package ? Should all the quantity be moved there ? To avoid this issue, we split the reservation before to assign the package or destination on an uncompleted reserved line. task-3599397
The edit dialog for financial report cells now displays the current value before editing, making it easier for users to see what they're changing. Additionally, when editing text fields, the dialog now uses a larger text area instead of a single-line input, giving users more space to write and edit longer text entries.
Original PR description
* Show the current value of the cell in the edit popover * Replace the input by a textarea when the cell figure_type is 'string'. It gives more space for the user to write.
This update improves the Indian GST Report feature with two user-friendly enhancements: a direct "Buy Credits" button that allows users to easily purchase EDI service credits without leaving the system, and a confirmation notification that appears when users successfully connect to the Indian GST Report service. These changes streamline the user experience and make it easier for businesses to manage their GST compliance reporting.
Original PR description
[IMP] l10n_in_reports_gstr: add buy credits button -Added buy credits button in the view which gives ease to user to directly buy l10n_in_edi IAP credits [IMP] l10n_in_reports_gstr: added connection successful notification -Whenever a user is successfully connected with l10n_in_reports_gstr it will display the user a notification of successfully being connected with Indian GST Report Related PR - https://github.com/odoo/odoo/pull/120785 Forward-Port-Of: odoo/enterprise#40806
This update improves Thailand's tax reporting functionality by adding a reference field to tax reports, including total amounts excluding VAT, and refining how reversed bills are handled in purchase tax reports. These enhancements make tax reporting more accurate and comprehensive for businesses operating in Thailand.
Original PR description
Impacted Version: - 16.0 and above This commit improve below features: - Add reference field to tax report - Add total excluding VAT amount to tax report - Filter completely reconciled reversed bill on purchase tax report task-3623502 Forward-Port-Of: odoo/enterprise#53798 Forward-Port-Of: odoo/enterprise#52496
This update improves how the Point of Sale system handles currency conversion caching by using Odoo's new built-in caching method instead of a custom approach. The change makes currency calculations faster and more reliable, especially when processing multiple orders on the same day, by better organizing how currency rates are stored and retrieved.
Original PR description
Since https://github.com/odoo/odoo/pull/137609/commits/b6242264ea9f9f9f42cca4427e30071219ae6a70 a new way of caching the currency conversions and computation was implemented. Therefor the PR https://github.com/odoo/odoo/pull/145810 can be adapted to use this new caching method, removing the usage of a local `lru_cache` which can be error prone. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix prevents portal users from seeing an access error when opening shared project task timesheet details, especially for sub-tasks. It ensures the system can safely check the related customer information needed for timesheet sales links without blocking the portal view.
Original PR description
Steps ===== - Install sale_timesheet - Create a project shared (in edition) with a portal user - Creata a task with a subtask and log timesheets for the subtask - As a portal user open the parent…
Steps ===== - Install sale_timesheet - Create a project shared (in edition) with a portal user - Creata a task with a subtask and log timesheets for the subtask - As a portal user open the parent task form - Go in the timesheet tab - Click on the button "Sub-tasks Hours/Days Spent" at the bottom of the page Issue ===== An access error appears for a res.partner record. Cause ===== https://github.com/odoo/odoo/pull/135528 introduced the field allowed_so_line_ids on model account.analytic.line. This field is computed based on the values of the field commercial_partner_id (res.partner relation). However, portal users have no access to res.partner records and the presence of this field in account.analytic.line view (for timesheet) therefore raises an access error for portal user. Fix === A sudo is used in method _default_sale_line_domain to be able to fetch the ids of the partners linked to the timesheet, even as a portal user. task-3572112 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Filtering project tasks by customer in the Gantt view now works correctly. This prevents an error that could interrupt users when reviewing grouped task schedules by customer.
Original PR description
Step:
-----
- install to project_enterpise module
- Go to project > all tasks in the Gantt view
- Group by customers
- Filter any customer
Issue:
-----
The wrong domain is passed in the search method so traceback occurred.
Cause:
------
Currently, we don't replace `child_of ` operator with `ilike` in _search_on_comodel method so
child_of is passed in the search method and orm is not handled.
Before the domain:
[('name', 'child_of', 'admin')]
Now:
[('name', 'ilike', 'admin')]`
Fixed:
-----
We correct the domain.
**Issue in this commit**-
https://github.com/odoo/enterprise/commit/57eb5b72796e0aeff6d8368219281760acb7c307
task-3625825Installed industry modules now use their real database ID instead of a placeholder. This prevents “record not found” errors when users try to uninstall an industry module, making module management more reliable.
Original PR description
Currently, when you attempt to uninstall an industry module, you are met with a 'record not found' error. ### Cause The list of industry modules is fetched from `odoo.com`. Since they do not exist in the database, they are all assigned an ID of `-1`. This ends up causing an issue in case of uninstall because no record with and ID of `-1` can be found. ### Fix When a module is installed, it gets a record in the database (and ID). The fix simply uses that ID if it exists, instead of `-1`. opw-3662239
Video calls that use Odoo's relay server can now better adapt to available bandwidth. Instead of dropping packets when connections are weaker, the call can lower video resolution to keep conversations smoother and more reliable.
Original PR description
This commit adds the simulcast feature to calls when relayed by an odoo SFU server, this allows for better bandwidth management by scaling down resolution instead of losing packets. see: https://github.com/odoo/sfu/releases/tag/v1.1.0
This fix ensures archived records are still included when Odoo updates related field values during onchange operations. It prevents missing data in these internal updates and also avoids unnecessary extra data loading, improving performance in affected workflows.
Original PR description
In e0297bd, we fixed the inverse field values of the new record during the onchange. But we actually filter out inactive records by doing record[self.name] in _update(). And since the XtoMany field cache values should always contain inactive records, we need to add with_context(active_test=False) on records. Also remove the useless 'if value', value is always truly because it is always a record. Note that this solves a performance issue in our production, because in order to filter out inactive records, we need to fetch the active field next to every prefechable field.
Restricted website editors can now open the SEO optimization dialog on website pages without seeing an access error. If they do not have permission to edit the page, the dialog opens in read-only mode with an explanation, avoiding disruption while preserving access controls.
Original PR description
Commit [1] allowed restricted editor to use the optimize seo dialog: - When they have write access on the record, they can fill the form and save changes - when they don't have the write access, the form is in readonly and a warning is shown to explain it. But a mistake was made: the restricted editor, when opening the SEO dialog on a website.page, would receive an access error directly, instead of the expected readonly SEO dialog without a save button. Step to reproduce: - Login with a restricted editor with no extra rights - Go to / homepage - Open the optimize seo dialog - An access right error is shown [1]: https://github.com/odoo/odoo/commit/891162574eead15cf64a4f934e5f12346cbcfbbf
Portal users assigned as resellers could receive a 403 error when opening an opportunity because the page tried to display partner avatar information they were not allowed to access. This fix prevents that access issue, allowing reseller portal users to view their assigned opportunities normally.
Original PR description
**Steps to Reproduce** 1). Create an opportunity, and give it a new contact 2). Set Joel Willis as the reseller (needs a partner grade for that) 3). Log in as Joel, and try to open this opportunity through the portal -> Access Error 403 **Technical** We are trying to show the avatar of the partner because a portal user doesn't have access to see the avatar so 403 forbidden errors occur. This problem occurred after this commit: https://github.com/odoo/odoo/commit/df8535fbd40e1e5c09dbe616a3332c76c23525c8 **After this PR** Now portal user can see the opportunity. Task-3580254
This fixes incorrect default sales tax references in the Swiss and Estonian localization templates. Businesses using these localizations will get the intended tax configuration when setting up products or accounting defaults, reducing the risk of wrong tax setup.
Original PR description
Instead of replacing the default taxes, the key has been duplicated in the dict. (https://github.com/odoo/odoo/commit/0870357cc48ba0a7f7ce18ac32ecb677ee579498) So, instead of assigning the new tax, it is overriden by the old keys. So, the old tax is still the one referenced in the template. l10n_ee: the old tax has been deactivated, and the default_tax hasn't been changed. Added the tag to the test so it will be seen on merge next time. Linked to runbot error 52792 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
Users opening recently upgraded databases could see a browser error caused by an outdated cached translation file. The change stops loading that obsolete file now that translations are handled by the browser, preventing the crash and improving reliability after upgrades.
Original PR description
When a user connects to its database that has been freshly upgraded to 17.0 database, he gets the following JS crash:
```
TypeError: can't access property "defineLocale", moment is undefined
@http://www.odoo.test/web/webclient/locale/fr_FR:13:10
@http://www.odoo.test/web/webclient/locale/fr_FR:9:4
@http://www.odoo.test/web/webclient/locale/fr_FR:10:2
```
Before 17.0, the `/web/webclient/locale/<string:lang>` route was used to get the appropriate `momentjs` locale and was cached for a duration of 1 week.
So when connecting to the upgraded database we will get the cached file, but as `momentjs` has been removed (see odoo/odoo@4327c062d820) it will crash.
Now as `luxon` is using browser's `Intl` to get the translations, we can safely remove the call to that endpoint (it will always return an empty file anyway)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix corrects how credit time is classified in Belgium's payroll system. Previously, credit time was incorrectly treated as paid work, but it is now properly configured as unpaid work for the CP200 employment structure. This ensures accurate payroll calculations and compliance with Belgian labor regulations.
Original PR description
Before this commit, at belgium payroll's installation, credit time was a paid work entries Now, it's an unpaid work entries for CP200 structure. task : 3598821
This fix ensures that spreadsheet sheet names cannot be left empty. Previously, users could dismiss a warning dialog and leave the sheet name blank. Now, after confirming the warning, the sheet name field automatically regains focus, requiring users to enter a valid name before proceeding.
Original PR description
Previously, the sheetName was allowed to be left empty or unchanged after displaying a warning dialog, contrary to the desired behavior. This commit addresses the issue, ensuring that after user confirmation, the sheetName regains focus. Task-3588208
Fixed an issue where the total cell in the My Timesheets view was displaying in black instead of the correct color (red, green, or orange) to indicate overtime, on-time, or undertime status. A recent code change had inadvertently broken the color styling logic, which has now been restored and tested to prevent future regressions.
Original PR description
Steps to reproduce:
- Go to my timesheets
- Total cell is colored in black instead of (red, green, orange) according to its {down, no, over}time.
Source:
- Commit 9a27926 changed the cell bg color from t-att-class to class. So the override of t-att-class added in commit 858ee74 to override the bg color is not working as expected. bg-400 is applied instead as its still in class.
Fix:
- bg-400 is moved again to t-att-class and a js test was added to make sure we be alerted about regressions next time in timesheet_grid.
task-3632025This fix resolves a translation problem where certain text strings with line breaks were not being properly translated. The issue occurred because the translation extraction tool (python-babel) and the JavaScript parser handled line breaks differently, making affected content untranslatable. The fix removes these problematic line breaks from the code and updates translation files to ensure all content can be properly translated.
Original PR description
The parser of the library we use to extract strings to be translated (python-babel) doesn't handle escaped newlines in the same way as the JavaScript parser. The resulting mismatch makes the content that uses them untranslatable.
for example:
```js
const hey = _t("slt \
çv ?"
);
```
is exported as "slt \nçv ?", while the content of the variable is "slt çv ?".
This commit removes faulty occurrences from the code base and re-exports the corresponding POT files.
*: helpdesk, stock_barcode
Community: https://github.com/odoo/odoo/pull/145971This fix ensures that appointment resource avatars are now properly displayed for all users, including those without special access rights. Previously, public users would only see a generic grey camera placeholder instead of the actual resource avatar. This improves the user experience by showing consistent and professional resource information during the appointment booking process.
Original PR description
Display the appointment resource avatar for public user. Before this changes, the grey camera placeholder was displayed for appointment resource. Like the staff user we now bypass the access rights for appointment resource to get its avatar (if it belongs to the appointment type) task-3611307 Forward-Port-Of: odoo/enterprise#51832
This update corrects how the German DateV export groups accounting data. Previously, the system was incorrectly combining multiple transaction lines into a single entry. The fix ensures each line is properly identified by its description (Buchungstext) rather than being merged based on account and partner information, resulting in more accurate export files that comply with German accounting requirements.
Original PR description
'Buchungstext' is supposed to hold the line label and not the move name (or ref). It implies that the idea of grouping the data by accounts + partner does not hold anymore (as we need to split by line label). We get rid of this grouping as it's a byproduct of trying to group the line of product with the line of tax and the receivable/payable. opw-3633926 Forward-Port-Of: odoo/enterprise#53664 Forward-Port-Of: odoo/enterprise#53539
This fix corrects a character encoding problem in SEPA payment batch files that was causing payment reference text to exceed the required 35-character limit. When payment references contained special characters like ampersands, they were being incorrectly converted during XML generation, resulting in oversized fields that could cause payment processing failures. The fix ensures special characters are properly handled before trimming the text to the correct length.
Original PR description
Steps to reproduce: (tested with l10n_be : sepa country) - set up SEPA Credit/debit Transfer - Create a bill with payment ref "Wynand & Olivier sont de joyeux drilles!" - Make a payment (for a…
Steps to reproduce: (tested with l10n_be : sepa country) - set up SEPA Credit/debit Transfer - Create a bill with payment ref "Wynand & Olivier sont de joyeux drilles!" - Make a payment (for a belgian customer with an iban account set) - Go to Payment: slect the payment - Create a Batch Issue: The generated xml has the tag InstrId with a text of 39 characters instead of 35 Cause: We trim and sanitize the text https://github.com/odoo/enterprise/blob/6fae2c1a728e167120967743b5413bda5a12d92e/account_sepa/models/account_journal.py#L350 But we don't convert the "&". And in https://github.com/odoo/enterprise/blob/ca40a44463f18181b687cf431dc18a5c2593775e/account_sepa/models/account_journal.py#L175 the `&` seems to be converted to `&` -> 39 characters instead of 35 Solution: if a trim is necessary (length is important) 1) replace &<> 2) trim 3) unescape So when etree does its "popote" the length is respected opw-3628530 Forward-Port-Of: odoo/enterprise#52770
This update allows users to delete automatic account transfers with intelligent handling based on the transfer's status. If a transfer is linked to finalized account records, deletion is prevented. If linked to draft records, those drafts are automatically removed first. Otherwise, the transfer deletes immediately. This resolves a previous limitation where all deletion attempts would fail.
Original PR description
Problem --------- Currently, when trying to delete an automatic transfer, an error is raised. Objective --------- Implement the following behavior: 1. If the transfer is linked to some POSTED account moves -> cannot delete 2. If the transfer is linked to some DRAFT account moves -> delete the DRAFT moves, then delete the transfer 3. Else, the delete action should work right away. Solution --------- 1. Override the unlink to implement the implement the desired behavior. 2. Set up a cascade deletion of the transfer lines when we delete the transfer all together. 3. Addition of tests task-3621529 Forward-Port-Of: odoo/enterprise#53292 Forward-Port-Of: odoo/enterprise#52577
This fix prevents customers from using payment providers that require manual transaction capture when setting up subscriptions. Previously, using such providers could cause unwanted duplicate payment transactions to be created automatically. The fix filters out these incompatible payment methods from the subscription payment options, ensuring subscriptions only use payment providers that support automatic recurring billing.
Original PR description
### Steps to reproduce: - In payment provider setup a test Stripe and publish it. Important: make sure that in the Configuration tabs, **Manual Capturing** is checked. - Go to Subscriptions and set…
### Steps to reproduce: - In payment provider setup a test Stripe and publish it. Important: make sure that in the Configuration tabs, **Manual Capturing** is checked. - Go to Subscriptions and set up recurrence (for example Monthly), Immediate payment (Payment Terms) and uses a test contact with a valid country and dummy email address. - Add a recurring product type. In “Other Info” tab make sure that signature and payment are set up. - Click on send by email. Grab the customer email from **mailcatcher** and open the “Sign & Pay Quotation” link in incognito mode. - In the customer portal view, go through the steps to sign and pay using Stripe test credentials and test credit card. - Once confirmed, go to the backend and grab the relevant Subscription. You should see that the subscription was set to “in progress” and that there is one authorized payment transaction. - Click on the “Capture Transaction” button → log message that transaction is confirmed. - Now trigger the “Sale Subscription: generate recurring invoices and payments” CRON manually. - Go back to the subscription form view (refresh) and you will see that a draft invoice was created but also a new stripe transaction was authorized. - That shouldn't happen, a new authorized stripe transaction was authorized shouldn't be created as the next invoicing date hasn't come yet! ### Investigation: - Manually captured payment providers should **NOT** be used with Subscriptions in the first place. ### Discussion: - The proposed solution filters out the manually captured payment providers from the payment modal so we don't go into the above flow. opw-3507478 Forward-Port-Of: odoo/enterprise#52778
This fix resolves an issue where the search bar filter in the General Ledger report would become broken after navigating back from viewing journal items. Users can now reliably modify their search filters without encountering functionality problems, improving the usability of the report filtering feature.
Original PR description
### Summary Currently, when a search bar filter is defined at the time of loading a report, the search bar become broken ### Steps to reproduce * open the General Ledger * use the search bar to filter the lines * on one line, click on the button to load the journal items * using the breadcrumb, go back to the ledger * try to modify your search bar filter You should see that it doesn't work. opw-3581742 Forward-Port-Of: odoo/enterprise#50743
This fix resolves an issue where the Bank Running Balance report in Accounting was not properly resetting its default filter settings. When users navigated away from the report and returned, the previously selected filter would incorrectly override the default settings, causing unpredictable report behavior. The fix ensures that default filters are properly maintained when users interact with the report.
Original PR description
Steps to reproduce: - Go on Accounting > Dashboard > Bank: running balance - Set "6000" > unfold lines - Go back on the accounting dashboard and comes back on running balance Issue: The default filter is overriden and the report has erratic behaviour Cause: previous option is selected after https://github.com/odoo/enterprise/pull/47669 solution: Make sure no default filter is existing opw-3628605 Forward-Port-Of: odoo/enterprise#53083
This fix corrects how discounts are handled when calculating tax amounts for Brazilian invoices. Previously, the system was not properly accounting for line-item discounts, which resulted in incorrect total and subtotal amounts on invoice lines. The fix ensures that discounts are properly subtracted before calculating final invoice amounts.
Original PR description
lineNetFigure doesn't include the discount. If we don't subtract we end up setting the wrong `price_total` and `price_subtotal` on the invoice lines. The test has been adapted to include one line with a discount to test this case. opw-3627449 Forward-Port-Of: odoo/enterprise#52672
This update fixes a technical error that occurred when stopping a timer on timesheet records in the kanban view. The issue prevented users from properly stopping timers on existing records when using the group-by filter option. The fix ensures the timer functionality works correctly for all record types.
Original PR description
Issue: Encountering a traceback error when attempting to stop the timer on an existing record in the timesheet kanban view. Steps to Reproduce: Navigate to the timesheet kanban view. Use the group-by search option. Click on the start timer button for an existing record and stop the timer. Cause: The traceback is triggered due to an undefined timesheet value. The cause lies in a conditional check that restricts setting the timesheet value only for dynamic records. Solution: Remove the conditional check that limits timesheet value assignment to dynamic records. and add a new condition to ensure the timesheet value is set for both dynamic and existing records. task-3555184 Forward-Port-Of: odoo/enterprise#49709
This update fixes a bug in the Knowledge app where article titles would not display properly when switching between different articles. The title input field now automatically resizes to fit each article's name, ensuring all titles remain readable. This improves the user experience by preventing text from being cut off or hidden.
Original PR description
This commit fixes a bug where the name input would not resize when switching articles, leading to some titles being unreadable. Now each time that the article changes we resize the input to accomodate the new title. Remove the erroneous `t-esc` usage. Rectification of https://github.com/odoo/enterprise/commit/7ea555fc76ad85c536a7d22495da8603dba064ce Now that the topbar is a component, the span that is guaranteeing the width of the container of the article name input can be set with a `t-out` instruction (the topbar is re-rendered each time the record changes). The previously used `t-esc` instruction was erroneous as it does not do anything in an owl template. task-3640726 Forward-Port-Of: odoo/enterprise#53665 Forward-Port-Of: odoo/enterprise#53649
Fixed a bug that caused an error when clicking the validate button on timesheets in Kanban view. The issue was caused by incorrect data formatting when passing timesheet records to the validation function. This fix ensures timesheets can be properly validated from the Kanban interface.
Original PR description
**Steps:** - Open Timesheet > To Validate > All Timesheets - Switch to Kanban View - Click on the validate button > Traceback occurs **Issue:** - The extra layer of the list prevents proper unpacking, leading to an 'unhashable type list' error. **Cause:** - The error occurs because the method 'action_validate_timesheet' expects unpacked values, but it receives a nested list instead of individual elements **Fix:** - Remove the additional list layer by passing 'resIds' directly to allow proper unpacking and resolve the error. **Task**-3646472 Forward-Port-Of: odoo/enterprise#53855 Forward-Port-Of: odoo/enterprise#53134
When users close the calendar dialog in knowledge articles, the page was scrolling back to the top instead of staying at the user's current position. This fix restores the cursor position when the dialog closes, so users can continue working without unexpected scrolling interruptions.
Original PR description
Similarly to this [commit], but for the `/calendar` command, when closing the dialog, the article scrolls to the top. This is because the focus is forcibly given back to the `editable` and the selection was not put back inside at the position where the command was executed: it is reset to the top instead. This commit restores the selection when closing the dialog so that when the focus is given back to the `editable`, no scrolling is done. [commit]: https://github.com/odoo/enterprise/commit/09af240b59c16264060765accbad6fde0102fc16 task-3620947 Forward-Port-Of: odoo/enterprise#53916
This fix resolves an error that occurred when users tried to change the expected payment date for items in the Aged Payable or Aged Receivable reports. Users can now successfully update payment dates without encountering system errors, improving the usability of these important financial reports.
Original PR description
Currently, an error appears if you try to change the expected date of an Aged Payable/Receivable line. ### Steps to reproduce * install `account_accountant` * open the Aged Payable report * unfold a partner * click on a move and select 'Change expected payment date' You should be met with an error. opw-3647341 Forward-Port-Of: odoo/enterprise#53709
Internal users were unable to open task details due to permission restrictions on worksheet data. This fix allows the system to safely retrieve worksheet information without requiring full access to the Field Service module, enabling all internal users to view task information regardless of their app permissions.
Original PR description
Before this PR when we log in as internal user it is giving access error when trying to open url of the task. So in this PR we have fixed the issue by adding sudo task-3430762 Forward-Port-Of: odoo/enterprise#53745 Forward-Port-Of: odoo/enterprise#44530
This fix prevents the appointment booking system from crashing when a user's browser has an invalid or unknown timezone setting. The system now handles unexpected timezone values gracefully instead of failing, ensuring users can always access and book appointments without technical errors.
Original PR description
If a user has a timezone in his cookies that is unknows by the server To reproduce: - modify the browser cookies to a random string (or `Etc/Unknown`) - access an appointment at `/appointment/<id>` where id is an appointment without a location configured (e.g. "Technical Demo") --> crash Task-id: 3623583 Forward-Port-Of: odoo/enterprise#52007
This fix prevents users from accidentally losing articles when using the move function. Previously, article items could be selected as destination locations, which could result in data loss. The system now only allows valid parent locations when moving articles, protecting your content organization.
Original PR description
This commit fixes a bug where the article items were considered as valid parents when using the **move to** button. These articles should not be considered as such because you could easily lose them when moving them in another hierarchy. We changed the search domain inside the `get_valid_parent_options` function to not include items. task-3627789 Forward-Port-Of: odoo/enterprise#52307
This update ensures Belgian payroll calculations remain compliant with the latest government regulations through January 2024. The payroll parameters have been updated to reflect current tax rates, deductions, and other statutory requirements from Belgium's Ministry of Finance, ensuring employees receive accurate salary calculations and deductions.
Original PR description
https://eservices.minfin.fgov.be/myminfin-web/pages/public/fisconet/document/9e9a6b60-c329-4132-9d57-a4fd33aafe0e Forward-Port-Of: odoo/enterprise#53548
This fix improves the Web Studio field editor to properly validate decimal precision settings for float fields. Previously, users could enter any value when editing decimal precision, which would cause errors when saving. Now the system only accepts valid numbers (0-20) and shows a clear visual indicator when invalid input is entered, preventing configuration errors.
Original PR description
Before this commit, the digits options (eg: in FloatField) was of type string. This means that when editing the value with studio, the user could type anything. The FloatField would then fail when being instanciated after leaving studio when editing a record. When passing the digits option, it should only contain an array of two ints. The first number is supposed to represent the total number of digits and the second one represent the decimal precision. The total number isn't actually used in the JS codebase. Solution ======== - Introduce a new option type: digits - Only allow integers between 0 and 20 as that value is passed to `toFixed` - If the entered value is invalid, set a red border on the input and do nothing opw-3614919 Forward-Port-Of: odoo/enterprise#53734 Forward-Port-Of: odoo/enterprise#52889
Fixed a display issue in the Sign module where a popover menu was appearing on top of a modal dialog when editing sign templates. Users can now properly interact with the role selection modal without the popover blocking it. Additionally, improved the behavior so that clicking a role in the modal correctly selects it without closing the interface.
Original PR description
In sign when you're editing a template, you can change the role of a sign item by opening a popover. However, if you click on "search more", it will open a modal that doesn't overlap the popover due to a bigger zindex of the popover. This commit fixes this by adjusting the popover's zindex. TODO: clicking on a role in modal doesn't select it. task-3575711 Forward-Port-Of: odoo/enterprise#49900
This fix allows locked subscription orders to be invoiced properly. Previously, a safeguard was put in place to prevent invoicing renewed contracts, but it was too restrictive and blocked invoicing of regular locked orders. The update ensures that subscription orders can be invoiced while still protecting against duplicate invoicing of renewed contracts in the subscription hierarchy.
Original PR description
Since https://github.com/odoo/enterprise/pull/38427 locked orders remain in a sale state. Nothing prevent to invoice them when they are regular order. Subscription should be invoiceable too. Before this commit, the 'done' state and after https://github.com/odoo/enterprise/pull/38427 the locked orders are not invoiceable. It was done to prevent invoicing renewed contracts. This measure would make sure that only one subscription of the hierarchy could be invoiced. taskid: 3595378 Forward-Port-Of: odoo/enterprise#50654
Fixed an issue where the cursor would jump to the beginning of the document when users closed the article selection dialog after using the "/link" command. Now the cursor correctly returns to where the user was editing, providing a smoother and less disruptive editing experience.
Original PR description
When the user inputs the "/link" command and subsequently closes the dialog for article selection, the cursor currently relocates to the start of the document, disrupting the editing flow. To address this issue, this commit will restore the cursor to its original position upon dialog closure. Steps to reproduce the issue: 1. Open an article you can edit 2. Put your cursor in a text block 3. Enter the "/link" command 4. Press `enter` to validate the command 5. Close the dialog for article selection (-> "CANCEL" button) => The cursor will be relocate to the start of the document. TO BE: The cursor should be restored to its original position upon dialog closure. task-3620947 Forward-Port-Of: odoo/enterprise#53732 Forward-Port-Of: odoo/enterprise#53048
This update fixes a display issue in the Intrastat Report where "Supplementary Units" were showing excessive decimal places (e.g., 498.96000000000004 instead of 498.96). The fix rounds these values to match the precision of the product's unit of measure, ensuring cleaner and more accurate reporting for compliance purposes.
Original PR description
Steps to reproduce:
- Install Accounting and Inventory
- Activate "Units of Measure" in Inventory settings
- Activate "Intrastat" in Accounting settings
- Create a product: (e.g. Product X)
* Unit of Measure: Dozens
* Purchase UoM: Dozens
* Cost: [any]
* Commodity Code: [any] (e.g. 01012100 Pure-bred breeding horses)
* Supplementary Units: 0.33
- Create a vendor bill:
* Intrastat Country: [any]
* Invoice Lines:
- Product: Product X
- Quantity: 126
- Confirm vendor bill
- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Filter on the vendor bill period
=> The value of "Supplementary Units" is displayed with a lot of decimal digits (i.e. 498.96000000000004).
Cause:
Floating point issue during the computation of the field.
Solution:
Round "Supplementary Units" field to the decimal accuracy configured for "Product Unit of Measure".
opw-3464654
Forward-Port-Of: odoo/enterprise#52264This update fixes a display issue with invoice reports in Saudi Arabia that was causing the report layout to appear messy and incorrectly formatted. The problem was caused by CSS styling that was breaking the table header layout. The fix adjusts the styling to ensure invoice reports display properly for Saudi Arabian companies.
Original PR description
### Steps to reproduce - install the following modules: - Accounting - Studio - Saudi Arabia - Accounting (l10n_sa) - Go to Settings > Users & Companies > Companies and create a New Company (named…
### Steps to reproduce
- install the following modules:
- Accounting
- Studio
- Saudi Arabia - Accounting (l10n_sa)
- Go to Settings > Users & Companies > Companies and create a New Company (named S**A Company** for example) with Saudi Arabia as the country in the address
- Switch to the new **SA Company**
- Go to Settings > Accounting
- Choose Saudi Arabia package as the Fiscal Localization package
- Go to Accounting and click on the studio icon (the one left of the user profile avatar)
- Click on reports
- Clear the filters
- Click on Invoices
- Click on the **Company tagline** box
- In the select box shown, choose `elif: o._get_name_invoice_report() == '|10n_gccarabic_english_invoice'`
- U can notice how the template is not rendered correctly
### Investigation:
- the major issue was the `flex-direction: column;` that caused the table header to be viewed as blocks
https://github.com/odoo/enterprise/blob/e892bc8f022ed3962de06a61c1be181c89cdc831/web_studio/static/src/client_action/report_editor/report_iframe.scss#L170C1-L187C2
- Some xml tags / classes needed to be refined to enhance the layout
opw-3544938
Forward-Port-Of: odoo/enterprise#51711Timesheets in the grid view were not displaying in the expected order after a recent technical update. This fix restores the proper sorting based on how users organize their timesheet data by section and row, making the timesheet view more intuitive and convenient to use.
Original PR description
Steps: - Install Timesheet app. - Open timesheet. Issue: - Timesheet are not order the way it was before grid owl conversion. Cause: - After grid view owl converion grid is fetching data from server side and it was not taking any orderby into account so it was getting data according to default order on timesheets which is `date desc, id desc`. Fix: - Added a method to get order according to section and row fields so it will display data according to user pref and it'll be more convenient for users. task-3610476 Forward-Port-Of: odoo/enterprise#51547
This fix ensures that detraction messages appear on PDF invoices for Peruvian transactions, matching the functionality already available in XML files. Previously, the detraction message would only display in XML format but not on printed PDFs, even when the transaction amount qualified for detractions under Peruvian tax law.
Original PR description
In PR https://github.com/odoo/enterprise/pull/34220 we removed the restriction to be able to show the detraction message if the amount is lower than 700 Soles. This was only done in the XML but also needs to be done in the PDF. Legal Reference: https://orientacion.sunat.gob.pe/como-funcionan-las-detracciones Task Latam: https://latam-localizations.odoo.com/web#id=1147&menu_id=88&cids=1&action=188&model=project.task&view_type=form Before:  After:  Forward-Port-Of: odoo/enterprise#53878
This fix resolves an issue where payment reconciliation was incomplete when users applied a write-off using the same account as the original payment. Previously, the system would only partially reconcile the payment and write-off amounts. Now the reconciliation completes fully by properly organizing the write-off line structure, ensuring all related transactions are correctly matched.
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"…
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. Solution: The first line of the write-off should contain the counterpart line. So we can just select that line for reconciliation. opw-3553008 Forward-Port-Of: odoo/enterprise#51892
The salary configurator now properly handles empty contracts by displaying an error message instead of showing a blank page with no information. This prevents user confusion and makes it clear when a contract is missing required details like wages or benefits.
Original PR description
Purpose ======= With an empty contract, the end user is in front of a page with no information (wage, advantages, etc), which gives the feeling that the configurator is broken. Return an error instead of trying to display the page at all costs. task-3663181 Forward-Port-Of: odoo/enterprise#53540
When merging two helpdesk tickets, the description text was appearing with HTML tags visible instead of being properly formatted. This fix ensures that formatted text displays correctly in the merge confirmation log, improving the readability of merged ticket information.
Original PR description
### Steps to reproduce: - Install **helpdesk** _app_ and the **Helpdesk Merge action** _module_. - Open **helpdesk** app. - Open **Customer Care** tickets in **list** view - Select the two tickets: -…
### Steps to reproduce:
- Install **helpdesk** _app_ and the **Helpdesk Merge action** _module_.
- Open **helpdesk** app.
- Open **Customer Care** tickets in **list** view
- Select the two tickets:
- Where can I download a catalog ?
- Wood Treatment
- Click on **Action** button and choose **Merge**
- Click **MERGE**
- Open the ticket **Where can I download a catalog ?**
- In the chatter log, notice how the **description** is not formatted properly
### Investigation:
- The `changes` are rendered using `t-esc` https://github.com/odoo/enterprise/blob/385c20dc2328cf146698195cac65c93a1b2fd480/data_merge/data/mail_templates.xml#L14
- Which comes from the `merge_records()` method https://github.com/odoo/enterprise/blob/fd309b8ce3649bdd3f86fb3a6723d398a58570ad/data_merge/models/data_merge_group.py#L161
- using `_record_snapshot()` method that uses `_render_values()` method that converts the formatted value into a string https://github.com/odoo/enterprise/blob/fd309b8ce3649bdd3f86fb3a6723d398a58570ad/data_merge/models/data_merge_record.py#L193 hence when the marked safe description coming from https://github.com/odoo/odoo/blob/49df26564203d2d836308828965d8bffff27b364/odoo/fields.py#L2026-L2030 is converted to a string making it not safe any more and escaped when rendered.
opw-3627171
Forward-Port-Of: odoo/enterprise#53095This update corrects an issue with IP signature value handling in the HR Contract Salary module. The fix ensures that signature validation works properly when processing salary contracts, improving the reliability of contract management workflows.
Original PR description
Forward-Port-Of: odoo/enterprise#54057
This fix resolves a crash in the domain selector that occurred when handling false values in selection filters. Users working with subscription lists in spreadsheets can now properly view and edit list properties without encountering errors. The fix ensures the domain selector correctly processes all data types including boolean false values.
Original PR description
Steps to reproduce: - Open the Subscription app - click on the list cog wheel - Spreadsheet > Insert list in spreadsheet - Select the blank spreadsheet and insert the list - right click any cell with a list function - click on "See list properties" => boom `undefined is not iterable (cannot read property Symbol(Symbol.iterator))` The list domain has the shape `["subscription_state", "not in", ["2_renewal", "5_renewed", false]]` `false` makes the domain selector crash. see https://github.com/odoo/enterprise/blob/ffb5aa25eb76c2229fa3034b67ff5cfdf8221316/sale_subscription/views/sale_subscription_views.xml#L89 opw 3670344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148495
This fix resolves an issue where calendar events synchronized from Outlook to Odoo would lose their organizer information if the email address capitalization differed between the two systems. For example, an event with organizer email "Firstname.Lastname@example.com" in Outlook would fail to match the user with email "firstname.lastname@example.com" in Odoo. After this fix, Odoo now correctly matches organizers regardless of email capitalization, ensuring events are properly assigned to the right person.
Original PR description
Description of the issue/feature this PR addresses: When a calendar event gets synchronized from Outlook calendar to Odoo in which the organizer's email address' capitalization doesn't match between Outlook and Odoo, the event is created in Odoo without an organizer. (i.e. `user_id` is `False`) Current behavior before PR: If the organizer's email address is `Firstname.Lastname@example.com` in Outlook and `firstname.lastname@example.com` in Odoo, the event is created in Odoo without an organizer. Desired behavior after PR is merged: Odoo is able to find the correct organizer user ID even though the capitalization of the email address wouldn't match. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147069
This fix resolves an issue where form fields would not display updated values from automatic field updates (onchange events) when users were actively editing other fields. Now when one field triggers an automatic update to another field, the new value will correctly appear in the input field even if the user is currently editing it, ensuring data consistency and preventing confusion.
Original PR description
Before this commit, a Field using the useInputField hook can ignore values from an onchange in some cases. Problem: ======= In order to know if it should apply the value of an onchange on the field's…
Before this commit, a Field using the useInputField hook can ignore values from an onchange in some cases.
Problem:
=======
In order to know if it should apply the value of an onchange on the field's input, the useInputField hook uses a useEffect which will check if the field is not dirty (being edited) and if it is not invalid. If it true, it will apply the value returned by getValue which often corresponds to record.data[fieldName]. By executing getValue, it will therefore start to observe changes in record.data[fieldName] until the next render. If getValue is not executed then changes applied by onchange on record.data[fieldName] are ignored because we don't observe record.data[fieldName].
Solution:
=======
Always execute getValue in the useEffect to always observe changes on record.data[fieldName] and apply them correctly on the input if needed. (It s a hack but we don't have a better solution for now)
How to reproduce:
================
- Go to a Form view with a field B with onchange and a field A (char field)
- Edit field B (an onchange is in progress)
- Insert a value in the input of field A
- The onchange is resolved with a value for field A
- The value in the input for field A does not change (because the field is in edition)
- Click outside the input for field A (trigger change event)
- Edit field B (an onchange is executed directly)
Before this commit:
The value returned by the second onchange is not visually applied to
field A. The old value is still present in the input.
After this commit:
The value returned by the second onchange is correctly applied to field A.
Its input contains the value of the onchange.
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 update fixes a crash that occurs in the website image editor when certain image metadata is missing. Previously, editing an image without specific format information would cause an error. Now the system gracefully handles this situation by hiding the format option, similar to how it worked in earlier versions.
Original PR description
[FIX] web_editor: make the system robust when old mimetype is missing Steps to reproduce: - Add an image on the website. - Save. - With the HTML editor, change the src of the image (to…
[FIX] web_editor: make the system robust when old mimetype is missing Steps to reproduce: - Add an image on the website. - Save. - With the HTML editor, change the src of the image (to "https://odoo.com/logo.png" for example) and remove the `mimetypeBeforeConversion` data attribute of the image. Note that it is important to change the src of the image to ensure that the system does not add the `mimetypeBeforeConversion` data attribute back on the image. - Enter in edit mode and click on the image. -> Traceback of type "Cannot read properties of undefined (reading 'split')". This traceback appears because the `_renderCustomXML()` method of `ImageHandlerOption` relies on the presence of formats on the list returned by the `_computeAvailableFormats()` method. Since [1], if there is no `mimetypeBeforeConversion` data attribute on the image, one of the format in the list is `undefined`. As `_renderCustomXML()` tries to perform a `split()` on this format, a traceback appears. Although the steps to reproduce the result seem tricky, it has been decided to create a fix for this situation. Indeed, in version prior to 16.4, the equivalent steps to reproduce (in which the `mimetype` data attribute is removed instead of the `mimetypeBeforeConversion`) do not lead to a traceback. In those versions, if there is no mimetype on the image, the options such as "Filter", "Width" and "Quality" are not shown in the editor panel. The goal of this commit is to apply the same logic for the version 16.4; hide the "Format" option if the image does not have the `mimetypeBeforeConversion` data attribute. To do so, the `_computeWidgetVisibility()` method has been adapted consequently. To avoid the traceback, the `_computeAvailableFormats()` method has been adapted. It now returns an empty list if the image does not have the `mimetypeBeforeConversion` data attribute. As there is no `undefined` format in the returned list of valid formats, the traceback is avoided. [1]: https://github.com/odoo/odoo/commit/730588b802506844e6ca54df312333bfd8df1d52 task-3631487 Forward-Port-Of: odoo/odoo#145524
This update fixes how payment method options are displayed and managed in the payment system. Payment method buttons now only appear when payment providers are actively enabled or in test mode, custom payment providers no longer allow changing their assigned payment method, and users can now create new payment methods directly from the provider interface. These changes improve the user experience by reducing confusion and enabling necessary functionality.
Original PR description
**[FIX] payment: show the payment methods buttons only on active providers** When the payment provider was disabled, the "Enabled Payment Buttons" was shown, although it was not possible to enable them yet. The button is now hidden until the provider's state is set to either 'enabled' or 'test'. ---- **[FIX] payment_custom: hide payment methods buttons on custom providers** Custom-flow payment providers should not allow assigning a different payment method than the one that was set. --- **[FIX] payment: allow creating new payment methods from the provider** When browsing a payment provider's payment methods, the "New" button was disabled because the action did not allow Kanban views.
This update fixes a display issue with invoice reports for Saudi Arabia companies where the layout was appearing messy and disorganized. The problem was caused by incorrect styling that made table headers display as blocks instead of in a proper row format. The fix adjusts the CSS and XML structure to ensure invoices render correctly for Saudi Arabian accounting localization.
Original PR description
### Steps to reproduce - install the following modules: - Accounting - Studio - Saudi Arabia - Accounting (l10n_sa) - Go to Settings > Users & Companies > Companies and create a New Company (named…
### Steps to reproduce
- install the following modules:
- Accounting
- Studio
- Saudi Arabia - Accounting (l10n_sa)
- Go to Settings > Users & Companies > Companies and create a New Company (named S**A Company** for example) with Saudi Arabia as the country in the address
- Switch to the new **SA Company**
- Go to Settings > Accounting
- Choose Saudi Arabia package as the Fiscal Localization package
- Go to Accounting and click on the studio icon (the one left of the user profile avatar)
- Click on reports
- Clear the filters
- Click on Invoices
- Click on the **Company tagline** box
- In the select box shown, choose `elif: o._get_name_invoice_report() == '|10n_gccarabic_english_invoice'`
- U can notice how the template is not rendered correctly
### Investigation:
- the major issue was the `flex-direction: column;` that caused the table header to be viewed as blocks
https://github.com/odoo/enterprise/blob/e892bc8f022ed3962de06a61c1be181c89cdc831/web_studio/static/src/client_action/report_editor/report_iframe.scss#L170C1-L187C2
- Some xml tags / classes needed to be refined to enhance the layout
opw-3544938
Forward-Port-Of: odoo/odoo#144083This fix corrects the display of material quantities in the Consumption Warning dialog when adding extra components to a Manufacturing Order. Previously, the amounts shown were reversed, making two different action buttons produce identical results. Now the correct quantities are displayed, allowing users to properly validate their material consumption decisions.
Original PR description
Currently in 17.0, when adding an additional component on a Manufacturing Order, the Consumption Warning wizard shows: - to consume: amount of additional component - consumed: 0.0 It should be the reverse. Moreover, this makes the 'Set Quantities & Validate' button have the same result as the 'Confirm' button, which is useless. task 3670356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects an issue where the system was incorrectly generating Phase 2 QR codes for all Saudi Arabian invoices, regardless of whether they were Phase 1 or Phase 2. The system now properly detects Phase 1 invoices (those not yet submitted to ZATCA) and generates the correct QR code format for each phase, ensuring invoices print with the appropriate compliance codes.
Original PR description
Currently, when we try to print a ZATCA invoice after installing the l10n_sa_edi module, the system will always default to printing the Phase 2 QR code on the invoice reports, irrespective of whether…
Currently, when we try to print a ZATCA invoice after installing the l10n_sa_edi module, the system will always default to printing the Phase 2 QR code on the invoice reports, irrespective of whether or not the invoice itself is for Phase 1 or 2. To fix this, we check if the Invoice has edi_documents, in which case it is marked as Phase 2 and runs as usual. Otherwise, we mark it as Phase 1 and call the initial function. Description of the issue/feature this PR addresses: When we try to print the QR code for ZATCA phase 1 invoices, the system tries to print phase 2 invoices. to circumvent this, we check if the invoice has edi_documents, in which cases it has to be/was submitted to ZATCA and thus is phase 2. Otherwise, it is phase 1 and we call the initial phase 1 QR code calculation. Current behavior before PR: System tries to print phase 2 QR code even if invoice is phase 1. Desired behavior after PR is merged: If an invoice is not linked to any edi documents, it means it is phase 1 and should render the QR code using the phase 1 calculation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148777 Forward-Port-Of: odoo/odoo#147901