Wednesday, March 26, 2025
40 changes · 18.0
Enhancements to existing features
This update improves Odoo's internal Hoot web testing tools by reducing flaky test failures and making async checks more accurate. It also adds configurable network delay simulation, helping teams better test behavior under slower or variable network conditions.
Original PR description
See commit messages for details. Fixes runbot issue [105000](https://runbot.odoo.com/odoo/runbot.build.error/105000) Enterprise: https://github.com/odoo/enterprise/pull/82189 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The subscription main view now uses a more efficient filter for subscription status. This helps the database use its index better, improving performance when opening or filtering subscription records without changing business behavior.
Original PR description
Inverse the domain on `subscription_state` from: `not in (selection_values)` -> `in (complement(selection_values))` Using the `in` operator gives Postgres the possibility to use an index on `subscription_state`, which cannot be done with a `not in` domain operator for `Selection` fields.
Product images uploaded for Urban Piper are no longer automatically converted to WebP format. This helps ensure images remain in formats supported by Urban Piper, avoiding issues when syncing or displaying products.
Original PR description
Following this commit : - Initially for image_1920 in the product form view `options` was passed as `convert_to_webp': True`. - Since whenever the image is been uploaded irrespective of any format (.jpeg, .png) it will be converted to .webp which is not supported by Urban Piper. - So for pos_urban_piper this option is been modified and made False. task-4658346
Sections and note lines are now hidden from the Journal Items tab, making accounting entries easier to review. This reduces clutter for users checking invoices and related accounting details while preserving the underlying invoice information.
Original PR description
Hide sections and notes in journal items tab. task-4517560
Resolved issues and error corrections
The survey module's automated performance tests were adjusted to account for a different database query count when Survey is installed by itself. This helps keep internal quality checks reliable without changing the user experience.
Original PR description
Query counter values are higher if only survey app is installed. Based on the SQL query, it looks like with only survey there is extra query to load the default language rb-111093 rb-111094 rb-111095
Code cleanup and technical improvements
This update removes an unnecessary waiting period before automated web tours begin. It simplifies the tour execution flow with minimal visible impact, helping keep automated interactions responsive without changing business functionality.
Original PR description
In this commit, we're removing the initial delay from macro.js. This parameter was introduced to try to optimize macro execution times. However, in practice, it doesn't change much. The debounceDelay is only used if there's a trigger in a step. 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
Miscellaneous changes
**issue:** When "Audit Trail" is activated and a user creates an incorrect payment, deleting the payment is not possible. The error message suggests archiving the payment; however, there is no option to archive it. A more flexible error message should be used instead. opw-4494820 Forward-Port-Of: odoo/odoo#200041 Forward-Port-Of: odoo/odoo#196987
Original PR description
**issue:** When "Audit Trail" is activated and a user creates an incorrect payment, deleting the payment is not possible. The error message suggests archiving the payment; however, there is no option to archive it. A more flexible error message should be used instead. opw-4494820 Forward-Port-Of: odoo/odoo#200041 Forward-Port-Of: odoo/odoo#196987
This fix prevents website editing metadata from being added to the wrong template elements. It keeps snippet-related markers limited to the intended website snippets, reducing the risk of unexpected behavior when editing website pages.
Original PR description
Since [1], the data-snippet tag was added for each t-call which was not the desired behavior. This commit fix this to restrain the addition of the data-snippet tag only for t-snippet-call. [1]: https://github.com/odoo/odoo/commit/6d5c741820cb69f7619e2cf49bce1457b2cd1efd
The website shop’s attribute filter headings now follow the theme’s text color, making them visible when a dark background is used. This improves storefront readability for businesses using customized or dark color themes.
Original PR description
When a user changes the theme colors and applies a dark background the attribute filters will not be apparent Also the color applied to text is not applied to the attributes only if the accordion is active As a fix now the accordion headers will match the updated text color from the theme opw-4559710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restaurant point-of-sale sessions now close open popups before automatically returning idle users to the floor plan. This prevents an error when a staff member closes a combo selection popup after the timeout, making table service workflows smoother.
Original PR description
- Fix traceback appearing when after 3 minutes, we're automatically redirected to the floor screen and we had a combo selector popup opened. We were redirected to the floorscreen but the popup was still opened and when closing it it was throwing a traceback. - Now just before redirecting idle user to the floorplan, we first close all opened modal. Steps to reproduce : - Open "Restaurant" - Open an empty table - Click combo product - Wait 180s :d - You'll be automatically redirected to floorplan, the combo selection popup is still opened - When closing it you have a traceback task-id: 4661502 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 shared project task page now shows the Follow button correctly for portal users with edit access. This prevents important task collaboration controls from being partially hidden, making the page easier to use for external project participants.
Original PR description
Before this commit, when accessing public project sharing page with "edit" access rights, opening a task showed the chatter and "Follow" button above but it was partially cut. This comes from the…
Before this commit, when accessing public project sharing page with "edit" access rights, opening a task showed the chatter and "Follow" button above but it was partially cut. This comes from the following causes: - portal composer has special margin/padding at the top to compensate with website header, so that scrolling on website keeps the composer at the top - portal composers should not autofocus on mount compared to backend views. The portal sharing page was mistakenly not considered a portal composer at some point and was fixed by [1]. However had regression to include the margin/padding top compensation, thus it cut the 'Follow' button. The margin/padding top is not pretty but it works fine for website. Here for project we want to ignore them. This commit fixes the issue by ignoring project sharing for the padding/margin top compensation, using variable `env.projectSharingId`. opw-4509372 [1]: https://github.com/odoo/odoo/pull/189568 Before  After 
The HTML editor now ignores Firefox events that report a text change when the text has not actually changed. This prevents unnecessary dirty-state updates, reducing false prompts or indicators that content was modified.
Original PR description
Description of the issue this PR addresses: Current behavior before PR: Firefox triggered a mutation when setting `textContent` to the same value, causing unnecessary dirty state updates in the editor. Desired behavior after PR is merged: Such mutations are now detected and ignored to prevent false positives. task-4629669 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now remove an existing value from partner lookup fields and have that change recognized by the form. This ensures the save option appears and the cleared value is properly stored, preventing frustrating data entry issues in contact-related forms.
Original PR description
In a form view with a many2one field using the res_partner_many2one widget (e.g. in the "Contacts" form view) where this field is set, remove the value. Before this commit, this didn't trigger a change in the model. As a matter of fact, the "save" button in the control panel (the small cloud) wasn't displayed. As a consequence, such a change couldn't be saved. This commit fixes the issue. OPW-4669817 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects Belgian payroll deduction amounts for the 3000 rule through April 2025. It helps ensure payroll calculations remain aligned with the latest required amounts, reducing the risk of incorrect payslips.
This update fixes unstable automated tests around appointment scheduling and Gantt calendar views. It helps prevent false failures in the testing pipeline, making releases and quality checks more dependable without changing user-facing behavior.
Original PR description
This PR fixes non-deterministic issues with a unit test in the appointment module. The issue was coming from the gantt range being separately from the mounting of the view. This could sometimes be a…
This PR fixes non-deterministic issues with a unit test in the appointment module. The issue was coming from the gantt range being separately from the mounting of the view. This could sometimes be a problem, as the second "get_gantt_data" RPC could return *after* the helper responsible for selecting the range called a `runAllTimers` that would drastically increase the current time, and thus affect the RPC payload. The fix here is to include the desired range directly in the view arch, instead of selecting the range manually from the UI. Furthermore, when trying to reproduce the non-deterministic behavior of the test mentioned above by slowing down RPCs, other gantt tests showed constitently failing results due to a poor architecture relying on animation frames instead of waiting for network calls. These tests have been fixed preventively to avoid potential timing issues. Fixes runbot issues: - [159865](https://runbot.odoo.com/odoo/runbot.build.error/159865) - [161300](https://runbot.odoo.com/odoo/runbot.build.error/161300) - [161490](https://runbot.odoo.com/odoo/runbot.build.error/161490) Community: https://github.com/odoo/odoo/pull/203472
A payroll accounting test was adjusted so it works correctly when demo data is not installed. This helps keep payroll accounting updates reliable across different deployment and testing setups.
Original PR description
With the PR [1] added test case which is failing in no demo mode (see [2]). This commit will ensure the test case will completely run witth no demo mode. [1] https://github.com/odoo/enterprise/pull/77334 [2] https://runbot.odoo.com/runbot/build/76189941
The Group S payroll export now checks whether the required company Group S code is configured before generating a file. Instead of a technical crash, users receive a clear message telling them what needs to be set up, reducing support confusion and failed report generation.
Original PR description
Currently, a traceback occurs when the user tries to create a Export to Group S report. To reproduce this issue: 1) Install `l10n_be_hr_payroll_group_s` without demo data 2) Shift to the Belgium…
Currently, a traceback occurs when the user tries to create a Export to Group S report. To reproduce this issue: 1) Install `l10n_be_hr_payroll_group_s` without demo data 2) Shift to the Belgium company 3) Create a running contract from payroll with stating date should be in past 4) Now create a Work Entry from payroll with the From date also be in the past 5) Now create a new `Export to Group S report` report from payroll/reporting 6) Make sure the date and moth are also in the past and click the `Populate` 7) Now click the `Generate Export File` Error:- ``` TypeError: can only concatenate str (not "bool") to str ``` The error is occurring because there is no `group_s_code` value by default in the company. The user has to give the value from the settings. If there is no `group_s_code` in the company, It leads to the above exception when concatenation is done between False and a string. Also, a userError was already raised from the very next life. https://github.com/odoo/enterprise/blob/eb1eff85d2119a34997067fedb602e963a5d6f02/l10n_be_hr_payroll_group_s/models/hr_payroll_export_group_s.py#L41-L43 So by making an extra check of the presence of the `group_s_code` in the company. We can resolve this issue and also make the code more robust. sentry-6289053708
The UrbanPiper POS module can now be installed even after online payments are removed. This prevents a setup error and helps businesses enable the integration without needing extra troubleshooting.
Original PR description
Steps to reproduce: === - Install point_of_sale. - pos_online_payment is auto-installed. - Uninstall pos_online_payment. - Install pos_urban_piper. - Installation fails with an XPath error. Issue: === - XPath targeting is_online_payment is not found when pos_online_payment is uninstalled. Fix: === - Replaced XPath from is_online_payment to split_transactions to ensure proper installation. task-4639074
This update renames an internal password field label used by the Monster recruitment integration to avoid confusion with another password field. It prevents system warnings while leaving the visible settings screen unchanged for users.
Original PR description
The field `res.company.hr_recruitment_monster_password` has the same label `Password` as the field `res.company.l10n_co_edi_password` from module [`l10n_co_edi`](https://github.com/odoo/enterprise/blob/b2fcd4e679fd6e4dedebdc13a5de0c89fbe3ef9a/l10n_co_edi/models/res_company.py#L15), as well as the related field on `res.config.settings` model, which generates warnings. The label on the field can be changed and the [view](https://github.com/odoo/enterprise/blob/b2fcd4e679fd6e4dedebdc13a5de0c89fbe3ef9a/hr_recruitment_integration_monster/views/res_config_settings.xml#L16-L21) where it is used will not be affected since the label is set in the view.
Before this commit, when there is a module_loader error, the error was shown on the ui for everyone, even the public users. Now, the error will be shown on the ui only if we are in debug mode TASK-ID: 4600145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202875
Original PR description
Before this commit, when there is a module_loader error, the error was shown on the ui for everyone, even the public users. Now, the error will be shown on the ui only if we are in debug mode TASK-ID: 4600145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202875
### Steps to reproduce: - Create a PoS order in restaurant and proceed with payment - Create a refund for some items in the created order - Go to the order screens and notice the refunded qty in the main order ### Cause: Since syncAllOrders method gets executed in different flows we are adding to the refunded_qty more than once. https://github.com/odoo/odoo/blob/bfbf47d7b70d9bc180968a69d0ab6c522ee877a8/addons/point_of_sale/static/src/app/store/pos_store.js#L1164 ### Fix: Set the r
Original PR description
### Steps to reproduce: - Create a PoS order in restaurant and proceed with payment - Create a refund for some items in the created order - Go to the order screens and notice the refunded qty in the main order ### Cause: Since syncAllOrders method gets executed in different flows we are adding to the refunded_qty more than once. https://github.com/odoo/odoo/blob/bfbf47d7b70d9bc180968a69d0ab6c522ee877a8/addons/point_of_sale/static/src/app/store/pos_store.js#L1164 ### Fix: Set the refunded qty as sum of quantities for the related refund order lines. opw-4536644 Forward-Port-Of: odoo/odoo#199072
FIX FOR MASTER −1 ------------------------------------------------------- After version 15 they display types stopped doing anything. Make them change the visual style again. task-4554655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203369 Forward-Port-Of: odoo/odoo#201186
Original PR description
FIX FOR MASTER −1 ------------------------------------------------------- After version 15 they display types stopped doing anything. Make them change the visual style again. task-4554655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203369 Forward-Port-Of: odoo/odoo#201186
the xmlid `hr_expense.mail_alias_expense` can be deleted by the user, don't raise error if xmlid is not found. 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 Forward-Port-Of: odoo/odoo#203002
Original PR description
the xmlid `hr_expense.mail_alias_expense` can be deleted by the user, don't raise error if xmlid is not found. 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 Forward-Port-Of: odoo/odoo#203002
**Steps to reproduce:** 1. Create a company with IQD as its currency 1. Create a product with average costing and real_time accounting 2. Create an exchange rate from USD to IQD (e.g, 0.00075758 USD per IQD) 3. Create a purchase order for the product like: a. currency: USD b. price unit: 12.6 c. qty: 6 d. discount: 33.33% 4. Confirm the order 5. Receive the product 6. Create the bill 7. Open the journal items tree view The credit/debit amounts of the journal entrie
Original PR description
**Steps to reproduce:** 1. Create a company with IQD as its currency 1. Create a product with average costing and real_time accounting 2. Create an exchange rate from USD to IQD (e.g, 0.00075758 USD…
**Steps to reproduce:**
1. Create a company with IQD as its currency
1. Create a product with average costing and real_time accounting
2. Create an exchange rate from USD to IQD (e.g, 0.00075758 USD per IQD)
3. Create a purchase order for the product like:
a. currency: USD
b. price unit: 12.6
c. qty: 6
d. discount: 33.33%
4. Confirm the order
5. Receive the product
6. Create the bill
7. Open the journal items tree view
The credit/debit amounts of the journal entries for the reception and the invoice don't match. The `amount_currency` is the same, but there are additional exchange differences items.
The reception journal item balance is taken from the `stock.valuation.layer`.
In the example, `unit_cost` is in the company currency IQD:
https://github.com/odoo/odoo/blob/191d44c91a4578445d8cb59d3172042022cb5a9a/addons/stock_account/models/product.py#L177
The invoice's balance is computed with `amount_currency`, which is converted to USD with the exchange rate and rounded:
https://github.com/odoo/odoo/blob/4e724323d811dec76c186b5cfff6e4b0135b2128/addons/account/models/account_move_line.py#L1570
The difference between the roundings (depending on the conversion rate) may generate exchange differences that shouldn't be there.
**Fix:**
Try to prepare the AML balance while creating it from a purchase
line- we have the unrounded `price_unit_discounted` that may be
used to find an accurate balance.
Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4103167)
opw-4103167
Forward-Port-Of: odoo/odoo#190043**Current behavior before PR:** When applying a text color to text that already has a gradient color, the gradient color would be removed from selected text, causing gradient color the style to be interrupted. **Desired behavior after PR is merged:** Text color can now be applied without removing or affecting the existing gradient color. task: 4196424 Forward-Port-Of: odoo/odoo#200336 Forward-Port-Of: odoo/odoo#184035
Original PR description
**Current behavior before PR:** When applying a text color to text that already has a gradient color, the gradient color would be removed from selected text, causing gradient color the style to be interrupted. **Desired behavior after PR is merged:** Text color can now be applied without removing or affecting the existing gradient color. task: 4196424 Forward-Port-Of: odoo/odoo#200336 Forward-Port-Of: odoo/odoo#184035
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 Forward-Port-Of: odoo/odoo#202596 Forward-Port-Of: odoo/odoo#201780
Original PR description
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 Forward-Port-Of: odoo/odoo#202596 Forward-Port-Of: odoo/odoo#201780
For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the `export_data` public method on the models. However: - The domain is only available in the controller. `export_data` does not receive the domain in its params. Putting the logger in `export_data` would therefore lead to the inability to log the domain. Or we would need to do one logger in the con
Original PR description
For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the…
For forensics purposes, having a log when users are doing an export is useful. In this revision, the logger is put in the controller. It would be better to put it in a lower level method, such the `export_data` public method on the models. However: - The domain is only available in the controller. `export_data` does not receive the domain in its params. Putting the logger in `export_data` would therefore lead to the inability to log the domain. Or we would need to do one logger in the controller just for the domain, and a second logger in `export_data`. - During an export using a group by (and without import compatibility) `export_data` is called recursively, in `insert_leaf`. Hence, if the logger would be put in `export_data`, there would be one log per group, therefore bloating the logs. Hence, for stable versions, the decision taken is to put the log in the controller rather than in a lower level method. It's better than nothing. A rework of the API of `export_data` is planned in master to solve the above concerns. Forward-Port-Of: odoo/odoo#202568
When a quotation has been confirmed, the invoice generated and confirmed by an accountant, the salesman of that first quotation has access to the invoice and its button "Send & Print". However, when trying to generate the document and send it, he receives an access right error. The salesman should be able to Send & Print when the invoice has been confirmed by an accountant. task-4378899 Forward-Port-Of: odoo/odoo#200180 Forward-Port-Of: odoo/odoo#191823
Original PR description
When a quotation has been confirmed, the invoice generated and confirmed by an accountant, the salesman of that first quotation has access to the invoice and its button "Send & Print". However, when trying to generate the document and send it, he receives an access right error. The salesman should be able to Send & Print when the invoice has been confirmed by an accountant. task-4378899 Forward-Port-Of: odoo/odoo#200180 Forward-Port-Of: odoo/odoo#191823
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations.
Original PR description
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations. All tokens, > including those that look like SassScript, are passed through to CSS > as-is. The only exception is interpolation, which is the only way to > inject dynamic values into a custom property. Reference: https://sass-lang.com/documentation/style-rules/declarations/#custom-properties Forward-Port-Of: odoo/odoo#203279 Forward-Port-Of: odoo/odoo#203134
### Description: When opening the replenishment view, the locations are checked to find if some products need to be refilled. If one product needs to be refilled, it will check if an orderpoint already exists, otherwise, it will create it. The issue is that the checks are currently done on all the orderpoints, even the ones not related to the product. The performances are worsened by the compute on `qty_to_order` triggered on all the orderpoints. ### Fix: To fix that, we can add a leaf
Original PR description
### Description: When opening the replenishment view, the locations are checked to find if some products need to be refilled. If one product needs to be refilled, it will check if an orderpoint already exists, otherwise, it will create it. The issue is that the checks are currently done on all the orderpoints, even the ones not related to the product. The performances are worsened by the compute on `qty_to_order` triggered on all the orderpoints. ### Fix: To fix that, we can add a leaf to the domain so that we only retrieve the orderpoints related to the products that need to be refilled. This will reduce the number of records on which we call the `qty_to_order` compute. ### Benchmark (in 18): | # of orderpoint | Before | After | | --------------- | ------ | ----- | | 44145 | 6:52 | 6s | | 22145 | 3:38 | 6s | ### Reference: opw-4618887 Forward-Port-Of: odoo/odoo#203276
When putting products in pack from the picking FormView `picking._put_in_pack` is eventually called. This method does a few things, amongst those is a write on picking.move_line_ids and another is the creation of a new package level. Both of these can be a bit slow when the picking's number of move_lines gets bigger. This can happen for SN tracked products for instance. In a database with 1800 move_lines, each _put_in_pack call takes around 1.5s, which can become cumbersome when customers are u
Original PR description
When putting products in pack from the picking FormView `picking._put_in_pack` is eventually called. This method does a few things, amongst those is a write on picking.move_line_ids and another is…
When putting products in pack from the picking FormView `picking._put_in_pack` is eventually called. This method does a few things, amongst those is a write on picking.move_line_ids and another is the creation of a new package level. Both of these can be a bit slow when the picking's number of move_lines gets bigger. This can happen for SN tracked products for instance. In a database with 1800 move_lines, each _put_in_pack call takes around 1.5s, which can become cumbersome when customers are using multiple packages. Most of this slowness is coming from two things. The first one is stock.quants synchronization when writing on move.lines. The propose solution in this commit is to skip this synchronization when the only value in the vals dict is `result_package_id`. We can do that because this value is not used in the first quants synchronization of the write method. The second one is a write of `location_dest_id` on the picking's move_ids and move_line_ids in `package_level.create`. Since the package_level.location_dest_id value is coming from the `move_line_ids` value in `_put_in_pack`, this commit adds a context key to skip this write in case we're coming from `picking._put_in_pack` #### speedup In a 17.4 customer database, putting in pack for a picking with 1800 move_lines: 1.5s -> 90ms --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200767
eLearning uses server date when processing dashboard values, which causes a mismatch from the perspective of the user. This commit changes the source of "today" to use the user's timezone on the dashboard and actions, while keeping compute functions on the server date as these values should not change based on the timezone of the observer. opw-4411615 Forward-Port-Of: odoo/enterprise#80490
Original PR description
eLearning uses server date when processing dashboard values, which causes a mismatch from the perspective of the user. This commit changes the source of "today" to use the user's timezone on the dashboard and actions, while keeping compute functions on the server date as these values should not change based on the timezone of the observer. opw-4411615 Forward-Port-Of: odoo/enterprise#80490
The Expense Account column was missing from the Asset Models list view. task-4402982 Forward-Port-Of: odoo/enterprise#80256 Forward-Port-Of: odoo/enterprise#78432
Original PR description
The Expense Account column was missing from the Asset Models list view. task-4402982 Forward-Port-Of: odoo/enterprise#80256 Forward-Port-Of: odoo/enterprise#78432
How to reproduce the issue: - Create an analytic distribution model. - In the bank reconciliation, create a new transaction. In manual operations, remove the analytic. If you reload the reconciliation, the analytic distribution is not deleted. In the `bank_rec_widget` of account_accountant, the method `_line_value_changed_analytic_distribution` is triggered when the analytic field is modified. However it does not save the new value of the analytic on the account.move.line. opw-446
Original PR description
How to reproduce the issue: - Create an analytic distribution model. - In the bank reconciliation, create a new transaction. In manual operations, remove the analytic. If you reload the reconciliation, the analytic distribution is not deleted. In the `bank_rec_widget` of account_accountant, the method `_line_value_changed_analytic_distribution` is triggered when the analytic field is modified. However it does not save the new value of the analytic on the account.move.line. opw-4460079 Forward-Port-Of: [odoo/enterprise#81340](https://github.com/odoo/enterprise/pull/81846)
[This commit] updated the XBRL version of the Dutch tax reports from the 2024 version (NT18) to the 2025 version (NT19). However, users still need to be able to submit reports for 2024 using the previous scheme. In order to allow this, we keep both the 2024 and 2025 version of the XBRL template and choose the right one depending on the year of the report. In subsequent years, we can then remove the oldest version and add the newest version. The report IDs are suffixes with the year. [op
Original PR description
[This commit] updated the XBRL version of the Dutch tax reports from the 2024 version (NT18) to the 2025 version (NT19). However, users still need to be able to submit reports for 2024 using the previous scheme. In order to allow this, we keep both the 2024 and 2025 version of the XBRL template and choose the right one depending on the year of the report. In subsequent years, we can then remove the oldest version and add the newest version. The report IDs are suffixes with the year. [opw-4600111](https://www.odoo.com/odoo/project.task/4600111) [opw-4664515](https://www.odoo.com/odoo/project.task/4664515) [This commit]: https://github.com/odoo/enterprise/commit/f1710461f37f3560486a1410f9b9ff420b052b7b Forward-Port-Of: odoo/enterprise#82026
Accessing the tax report from a branch company raised a user error due to attempting to fetch tax group XML IDs using the company’s CID. While this could be resolved by using `self.env["account.chart.template"].ref`, the report isn’t intended to be shown for branch companies. Instead, a constraint was added to prevent access in such cases. opw-4569580 Forward-Port-Of: odoo/enterprise#82101
Original PR description
Accessing the tax report from a branch company raised a user error due to attempting to fetch tax group XML IDs using the company’s CID. While this could be resolved by using `self.env["account.chart.template"].ref`, the report isn’t intended to be shown for branch companies. Instead, a constraint was added to prevent access in such cases. opw-4569580 Forward-Port-Of: odoo/enterprise#82101
Forward-Port-Of: odoo/enterprise#81788 Forward-Port-Of: odoo/enterprise#81465
Original PR description
Forward-Port-Of: odoo/enterprise#81788 Forward-Port-Of: odoo/enterprise#81465
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations.
Original PR description
This commit fixes improper interpolation of SCSS variables assigned to CSS custom properties, leading to malformed generated CSS rules (i.e. `--my-prop: $my-value` in the CSS bundle). Quote from the SASS/SCSS documentation: > CSS custom properties, also known as CSS variables, have an unusual > declaration syntax: they allow almost any text at all in their > declaration values. (...) Because of this, Sass parses custom property > declarations differently than other property declarations. All tokens, > including those that look like SassScript, are passed through to CSS > as-is. The only exception is interpolation, which is the only way to > inject dynamic values into a custom property. Reference: https://sass-lang.com/documentation/style-rules/declarations/#custom-properties Forward-Port-Of: odoo/enterprise#82084 Forward-Port-Of: odoo/enterprise#82012
As defined in https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/form/form_controller.js#L322 A record save in Form Controllers can be prevented when `onWillSaveRecord` returns `false`. But since the override in `HelpdeskTeamController` did not consider `super`, it would always break such a flow. Forward-Port-Of: odoo/enterprise#81853 Forward-Port-Of: odoo/enterprise#81769
Original PR description
As defined in https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/form/form_controller.js#L322 A record save in Form Controllers can be prevented when `onWillSaveRecord` returns `false`. But since the override in `HelpdeskTeamController` did not consider `super`, it would always break such a flow. Forward-Port-Of: odoo/enterprise#81853 Forward-Port-Of: odoo/enterprise#81769
Steps to reproduce the bug: - Install l10n_es_real_estate module - Create a customer invoice on the accounting app - Invoice's AEAT data should be real estate type for mod347 doc - Generate the BOE of tax report document of mod 347 Traceback is thrown while generating the boe of the mod347 document, the traceback is for an issue related to the param of the operation key and that was because the function _call_on_partner_sublines is run for each real estate invoice and it has a callback
Original PR description
Steps to reproduce the bug: - Install l10n_es_real_estate module - Create a customer invoice on the accounting app - Invoice's AEAT data should be real estate type for mod347 doc - Generate the BOE of tax report document of mod 347 Traceback is thrown while generating the boe of the mod347 document, the traceback is for an issue related to the param of the operation key and that was because the function _call_on_partner_sublines is run for each real estate invoice and it has a callback to be executed on each of them. The callback function is _write_type2_partner_record which should have the report option as param, but it wasn't sent that made a traceback for the params. After fixing that, another traceback was thrown because the xmlid of the real estate invoices of both sold and bought are not in the invoice types map of _write_type2_partner_record function. opw-4589314 Forward-Port-Of: odoo/enterprise#82008 Forward-Port-Of: odoo/enterprise#81033