Daily updates from Odoo
Navigate
Branch
Thursday, April 25, 2024
73 changes
2 changes
Enhancements to existing features
This update enhances how Odoo handles Peppol documents by allowing other modules to save them to alternative locations instead of just a journal. This increased flexibility improves integration capabilities and data management for Peppol-related processes.
Original PR description
Currently we are able to receive Peppol documents in a specific journal. This change allows other modules to hook into the saving process of new Peppol documents to save them somewhere else than directly in a journal. [task-3519604](https://www.odoo.com/web#id=3519604&model=project.task&view_type=form) Related to https://github.com/odoo/enterprise/pull/57018 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the validation process for HSN/SAC codes used in Odoo's Indonesian localization. Previously, validation applied to both sales and purchases, but now it's focused solely on sold products to ensure accurate compliance with Indonesian tax regulations. This change improves data integrity and reduces potential errors.
Original PR description
Before this PR: -------------------------------- - Validation check applied to both sold and purchased products. After this PR: ------ - Validation now applies to sold products only, ensuring compliance accuracy. Task Id: 3805678
24 changes
Enhancements to existing features
Accounting reports can now define custom grouping options beyond standard journal item fields. This gives businesses more flexibility when building specialized reports, such as Intrastat, using custom reporting engines.
Original PR description
Before this commit, the values allowed into the groupby field of account.report.line were restricted to only fields of account.move.line. This, however, was a bit too restrictive for some custom reports we'd like to convert to custom engines (in our case, Instrastat Report), so we decided to solve that by introducing a new hook on the custom handlers, allowing the definition new custom values for the groupby, to use them later on in some custom engines.
This update documents hidden fields that still need to remain in system views and helps identify ones that are no longer necessary. It improves maintainability and reduces unused configuration without changing day-to-day user workflows.
Original PR description
Since https://github.com/odoo/odoo/pull/137031 the invisible fields are add automatically (invisible and readonly) if they are used by python expressions in views (invisible, required, readonly, context, domain...). The mandatory invisible field must be commented just after the field tag. The comment must indicate what is the technical requirement to be present. The goal is to clean all views, improve the comprehention of the addons and remove dead code.
The Documents activity list now gives the “Request a Document” button the same hover styling as related activity actions. This creates a more consistent and polished experience for users managing document requests.
Original PR description
Give the "Request a Document" button of the activity list the same style on hover as the activity elements. Task-3862008
The Helpdesk portal search experience has been updated to better match the internal back-office view, with clearer search fields, filters, and grouping options. Ticket description search was removed to improve performance, while portal users gain better ways to search and group related ticket timesheets.
Original PR description
This PR aims to bring the portal search view closer to that of the back end. In order to do that, it adds, removes and reorganizes some search fields, filters and groupbys. Community: https://github.com/odoo/odoo/pull/132877 Task-3444823
The Australian payroll termination process has been streamlined to make ending employee contracts easier and more accurate. Updates to termination payments, payslip handling, salary rules, and employee views help payroll teams manage final payments with fewer manual steps and clearer information.
Original PR description
This will improve the flow for terminating an employee's contract. Task: 3822626
Odoo no longer includes selected company IDs in URLs for several apps, making shared links easier to read and preventing them from changing a user's active companies. When access depends on company permissions, users get a clearer path to switch to a company that can open the record.
Original PR description
*: [account_reports, documents, social, stock_barcode, web_studio]
The aim of this commit is to remove the companies IDs from the URL, and
use only the cookies to store the selected companies.
This commit will also improve the handling of access errors. If a user
encounters an access error, if one of its allowed companies has access
to the record, a button to switch to the correct company is shown.
The purpose of this is double: to have more human-readable URLs (part of
the task id : 3557575), and to avoid modifying the current selected
companies when clicking on a shared URL.
Note that this commit also modify the way the companies IDs are encoded
on the cookies. Before this commit, the IDs were separated by a comma
(",") and they were encoded as \054 by the server side but not by the
client side. Now, we use a dash ("-") to have the same encoding in both,
server side and client side.
task-id 3792021
Co-authored-by: Damien Bouvy <dbo@odoo.com>This change adds the ability to generate XLSX bank payment files from UAE payroll records. It helps payroll teams prepare bank submissions more efficiently and reduces manual spreadsheet work.
Original PR description
Change adds xlsx file for UAE bank generation. Comes from this PR (16.0): https://github.com/odoo/enterprise/pull/59194 Task: 3651407
Resolved issues and error corrections
The update prevents users from accidentally changing protected invoice or bill fields after another user has already posted the document. This helps keep posted accounting records consistent while still allowing approved technical processes to bypass the check when necessary.
Original PR description
When an invoice/bill is in a draft state and opened by 2 users, If one of them posted the invoice, the other user's form are not up-to-date, resulting in some whacky behavior like modifying fields that are supposed to be unmodifiable on a posted move. This commit adds a check on move write function to prevent this behavior, by raising error when modifying a readonly field if the field the user is going to write in a readonly mode depending on its state. If by any reason it is needed to modify the readonly field through the code, instead of resetting the move to draft, writing the change, and posting it back (which can be tedious and resource heavy), we'll allow it by adding the context `skip_readonly_check=True` to skip this check. task-id: 3536150 related Community PR: https://github.com/odoo/odoo/pull/160096
Code cleanup and technical improvements
This update modernizes how Odoo's automated product tours simulate clicks and drag-and-drop actions, making tests more consistent and easier to maintain. It also simplifies the testing helper API by removing rarely useful focus and blur actions, with no expected impact on day-to-day users.
Original PR description
In this commit, click event and drag_and_drop_native events in web_tour/static/src/tour_service/tour_utils.js have been changed to use hoot events. Also, blur and focus utils have been removed from RunningTourActionHelper because there usages are not relevant and complicate the understanding of the API. https://github.com/odoo/odoo/pull/162031
Miscellaneous changes
To reproduce: - Create a report with just one line, with code line_1_1. Give it an aggregation expression, cross_report, with formula "line_2_1.balance" - Create another report, containing a single line with code line_2_1. Give it two expressions: - One aggregation, with formula="14.0" (hardcoded fixed value), and subformula "if_other_expr_above(line_2_1.dudu, EUR(0))" - Another expression of any engine labelled 'dudu' ==> Try opening the first report; it loads forever. This i
Original PR description
To reproduce: - Create a report with just one line, with code line_1_1. Give it an aggregation expression, cross_report, with formula "line_2_1.balance" - Create another report, containing a single…
To reproduce:
- Create a report with just one line, with code line_1_1. Give it an aggregation expression, cross_report, with formula "line_2_1.balance"
- Create another report, containing a single line with code line_2_1. Give it two expressions: - One aggregation, with formula="14.0" (hardcoded fixed value), and subformula "if_other_expr_above(line_2_1.dudu, EUR(0))"
- Another expression of any engine labelled 'dudu'
==> Try opening the first report; it loads forever.
This is because the bound expression is only searched in the expressions of the active report ; not in the expressions loaded from other reports. In our case, the aggregation needing the bound is from the second report, so the bound belongs to its report as well. The looping occurs because that value, since it's not present in the first report's evaluated data, is considered as not yet computed, and the computation is continuously delayed at the end of the treatment queue, causing it to never become empty.
Forward-Port-Of: odoo/enterprise#61334
Forward-Port-Of: odoo/enterprise#58339Steps to Reproduce: - Install Timesheets app - Navigate to All timesheets from the header menu - Click on kanban view Issue: - Timer is present in the All timesheets Kanban view Causes: - Timer is present in the All timesheet kanban view because this view is inherited in my time sheets. Solution: - Using the context that is only used in MyTimeSheet Action window to hide the timer header (my_timesheet_display_timer) task-3741260 Forward-Port-Of: odoo/enterprise#61349 Fo
Original PR description
Steps to Reproduce: - Install Timesheets app - Navigate to All timesheets from the header menu - Click on kanban view Issue: - Timer is present in the All timesheets Kanban view Causes: - Timer is present in the All timesheet kanban view because this view is inherited in my time sheets. Solution: - Using the context that is only used in MyTimeSheet Action window to hide the timer header (my_timesheet_display_timer) task-3741260 Forward-Port-Of: odoo/enterprise#61349 Forward-Port-Of: odoo/enterprise#56581
## Description: Previously, the list reinsertion dialog overlooked converting user input to integers, causing JavaScript to treat numbers as strings. Consequently, unintended concatenation occurred, resulting in excessive record insertion. This PR addresses the issue by enforcing integer conversion on user input, ensuring precise record insertion. Task ID: [3833909](https://www.odoo.com/web#id=3833909&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forw
Original PR description
## Description: Previously, the list reinsertion dialog overlooked converting user input to integers, causing JavaScript to treat numbers as strings. Consequently, unintended concatenation occurred, resulting in excessive record insertion. This PR addresses the issue by enforcing integer conversion on user input, ensuring precise record insertion. Task ID: [3833909](https://www.odoo.com/web#id=3833909&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#61357 Forward-Port-Of: odoo/enterprise#60642
Steps to reproduce: 1. Configure Sendcloud shipping with pick-up location 2. Go to website, use the shipping method and select a pick-up location 3. Go to the backend, confirm the sale order and validate the delivery 4. Get Error from Sendcloud that the `house_number` is required If we check the delivery address, we see that the house number is not taken into account when creating a new partner, and the address is incomplete. This commit adds the house number to the `street` field of t
Original PR description
Steps to reproduce: 1. Configure Sendcloud shipping with pick-up location 2. Go to website, use the shipping method and select a pick-up location 3. Go to the backend, confirm the sale order and validate the delivery 4. Get Error from Sendcloud that the `house_number` is required If we check the delivery address, we see that the house number is not taken into account when creating a new partner, and the address is incomplete. This commit adds the house number to the `street` field of the address to have a complete address. opw-3864382 Forward-Port-Of: odoo/enterprise#61290
There is an additional query in no-demo mode; let us avoid useless red runbots. Runbot-62073 Forward-Port-Of: odoo/enterprise#61434
Original PR description
There is an additional query in no-demo mode; let us avoid useless red runbots. Runbot-62073 Forward-Port-Of: odoo/enterprise#61434
Forward-Port-Of: odoo/enterprise#61153 Forward-Port-Of: odoo/enterprise#60776
Original PR description
Forward-Port-Of: odoo/enterprise#61153 Forward-Port-Of: odoo/enterprise#60776
# Issue: The query for constructing the aged_payable accounting report takes too long to load. # Analysis: When a database has lots of companies, it's likely to have a huge number of rows in the account_partial_reconcile table. Currently, the entire account_partial_reconcile table is being iterated in the report generation, only to be filtered out later on in the query. This superfluous computation is extremely inefficient and it could be easily avoided by correctly using LATERAL JOIN s
Original PR description
# Issue: The query for constructing the aged_payable accounting report takes too long to load. # Analysis: When a database has lots of companies, it's likely to have a huge number of rows in the…
# Issue: The query for constructing the aged_payable accounting report takes too long to load. # Analysis: When a database has lots of companies, it's likely to have a huge number of rows in the account_partial_reconcile table. Currently, the entire account_partial_reconcile table is being iterated in the report generation, only to be filtered out later on in the query. This superfluous computation is extremely inefficient and it could be easily avoided by correctly using LATERAL JOIN syntax to make use of the filters applied later on.  # Fix: Use the correct condition inside the lateral join to filter on account_move_lines that are already filtered later on. # Benchmark: ### Report loading time | # account partial reconcile lines | # account move lines | Company size | Before | After | | --- | ------ | ------ | ------| ----- | | 588503 | 2339215 | Large | 15m+ (timeout) | ~14.02s | | 5761 | 27635 | Medium | 15m+ (timeout) | ~3s | | 11 | 1513 | Small | 7.69 | ~1.6s | #### Total number of account partial reconcile: 3279438 #### Total number of account move lines: 10688953 # Related ticket: opw-3819017 Forward-Port-Of: odoo/enterprise#61036
Since the wrong module set on the maintenance worksheets, this would lead to issues when trying to uninstall the maintenance module, as it wouldn't find every models to uninstall. This ended up leaving some entries in the database after the module was removed. runbot-57422 Forward-Port-Of: odoo/enterprise#61355
Original PR description
Since the wrong module set on the maintenance worksheets, this would lead to issues when trying to uninstall the maintenance module, as it wouldn't find every models to uninstall. This ended up leaving some entries in the database after the module was removed. runbot-57422 Forward-Port-Of: odoo/enterprise#61355
Sources: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/intermediates#bonus-a-l-emploi-plafonds-apres-l-augmentation-du-rmmmg-et-la-scission-du-calcul-29-03-2024 https://www.ucm.be/actualites/le-bonus-lemploi-renforce-au-1er-avril-2024#:~:text=Qu'est-ce%20que%20le,salaire%20net%20effectif%20est%20augment%C3%A9 Forward-Port-Of: odoo/enterprise#61358
Original PR description
Sources: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/intermediates#bonus-a-l-emploi-plafonds-apres-l-augmentation-du-rmmmg-et-la-scission-du-calcul-29-03-2024 https://www.ucm.be/actualites/le-bonus-lemploi-renforce-au-1er-avril-2024#:~:text=Qu'est-ce%20que%20le,salaire%20net%20effectif%20est%20augment%C3%A9 Forward-Port-Of: odoo/enterprise#61358
When we desactivate the 'Rental Transfers' option, it should archive the Rental route. Forward-Port-Of: odoo/enterprise#60179
Original PR description
When we desactivate the 'Rental Transfers' option, it should archive the Rental route. Forward-Port-Of: odoo/enterprise#60179
https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/instructions/special_contributions/other_specialcontributions/asbestosfunds.html Forward-Port-Of: odoo/enterprise#61135
Original PR description
https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/instructions/special_contributions/other_specialcontributions/asbestosfunds.html Forward-Port-Of: odoo/enterprise#61135
Steps to reproduce: ------------------- - create an appraisal for an employee; - be the manager of the appraisal; Issue: ------ It is not possible to edit feedback before saving it. Cause: ------ The `accessible_employee_feedback` and `accessible_manager_feedback` fields are read only if `can_see_employee_publish` and `can_see_manager_publish` are equal to `False`. These two fields depend on the `_compute_buttons_display` method, which will test whether the employees linked to the
Original PR description
Steps to reproduce: ------------------- - create an appraisal for an employee; - be the manager of the appraisal; Issue: ------ It is not possible to edit feedback before saving it. Cause: ------ The `accessible_employee_feedback` and `accessible_manager_feedback` fields are read only if `can_see_employee_publish` and `can_see_manager_publish` are equal to `False`. These two fields depend on the `_compute_buttons_display` method, which will test whether the employees linked to the user are in the appraisal managers. The following condition will never be true if the appraisal has not yet been saved: ```py user_employees in appraisal.manager_ids ``` This is because manager_ids will be a `NewId` recordset. Solution: --------- It is necessary to compare ids and not records directly because Model does not support equality between existed records in database and virtual records. opw-3869446 Forward-Port-Of: odoo/enterprise#61221
Before this commit: When exporting a report to a pdf if we were not using tax units there was no VAT After this commit: When exporting a report as pdf company VAT is shown if no tax unit is used. If we are using tax units, then tax units VAT will be shown instead task: 3864218 see: #58361 Forward-Port-Of: odoo/enterprise#61146 Forward-Port-Of: odoo/enterprise#61011
Original PR description
Before this commit: When exporting a report to a pdf if we were not using tax units there was no VAT After this commit: When exporting a report as pdf company VAT is shown if no tax unit is used. If we are using tax units, then tax units VAT will be shown instead task: 3864218 see: #58361 Forward-Port-Of: odoo/enterprise#61146 Forward-Port-Of: odoo/enterprise#61011
This traceback occurs when the user tries to duplicate a follow-up level record. To reproduce this issue: 1) Install `Accounting` 2) Open `Accounting/configuration/follow-up levels` 3) Select any one record and try to `duplicate` it. Error:- ``` TypeError: argument of type 'NoneType' is not iterable ``` https://github.com/odoo/enterprise/blob/a1921fb9a27e5da3592dbc3d9c34e41776b6c8d4/account_followup/models/account_followup.py#L47-L51 When the user tries to duplicate any rec
Original PR description
This traceback occurs when the user tries to duplicate a follow-up level record. To reproduce this issue: 1) Install `Accounting` 2) Open `Accounting/configuration/follow-up levels` 3) Select any one…
This traceback occurs when the user tries to duplicate a follow-up level record. To reproduce this issue: 1) Install `Accounting` 2) Open `Accounting/configuration/follow-up levels` 3) Select any one record and try to `duplicate` it. Error:- ``` TypeError: argument of type 'NoneType' is not iterable ``` https://github.com/odoo/enterprise/blob/a1921fb9a27e5da3592dbc3d9c34e41776b6c8d4/account_followup/models/account_followup.py#L47-L51 When the user tries to duplicate any record, the default value is None, which leads to the above traceback as there is no fallback for default. Because of refactoring in [1] After applying this commit, the issue will be resolved by giving a fallback value. Additionally, an SQL unique name constraint was encountered when attempting to duplicate it because of [2], so this commit also fixed by adding 15 days to the `highest delay in that company + the record name`. Previously duplicating `several levels` at the same time leads to `days_uniq` constraint because of the same delay. This commit will allow duplication several levels at the same time by offsetting `highest existing delay + 15 arbitrary days`. [1] https://github.com/odoo/enterprise/commit/e27a20d2e9a909260f28b18b0643b8205470236b [2] https://github.com/odoo/enterprise/blob/278290dd220e7ca8d4b9909d1bc48a93ac14c0eb/account_followup/models/account_followup.py#L44 sentry-5134878308 Forward-Port-Of: odoo/enterprise#59961
Before this commit, the test was not correctly simulating a click on the link chart button. This was due to the fact that the only event that was triggered was the pointerdown event, which is not enough to trigger the click event. For an unknown reason, only triggering the pointerdown event has a side effect during the test to trigger an event handled in the Leatlef library, would lead to an error in the library, and thus in the test suite. This commit fixes the issue by using the click he
Original PR description
Before this commit, the test was not correctly simulating a click on the link chart button. This was due to the fact that the only event that was triggered was the pointerdown event, which is not enough to trigger the click event. For an unknown reason, only triggering the pointerdown event has a side effect during the test to trigger an event handled in the Leatlef library, would lead to an error in the library, and thus in the test suite. This commit fixes the issue by using the click helper function from the web client test helpers. Runbot: 59203 Forward-Port-Of: odoo/enterprise#61410
47 changes
Enhancements to existing features
This update ensures that mandatory analytic distribution requirements are properly enforced when reconciling bank statements. Previously, users could bypass these requirements during reconciliation, which could lead to incomplete financial records. The fix also resolves an issue where the reconciliation interface would become unresponsive if an error occurred during the process.
Original PR description
Mandatory Analytic Plans should be mandatory. This was not checked when reconciling a bank statement. This commit adds a check to ensure that the analytic distribution is correct when reconciling a bank statement. Task: 3864633
The aged payable accounting report has been optimized to load significantly faster. Previously, the system was processing unnecessary data that was filtered out later, causing timeouts on large databases. The fix streamlines the data retrieval process, reducing load times from over 15 minutes to just seconds for large companies.
Original PR description
# Issue: The query for constructing the aged_payable accounting report takes too long to load. # Analysis: When a database has lots of companies, it's likely to have a huge number of rows in the…
# Issue: The query for constructing the aged_payable accounting report takes too long to load. # Analysis: When a database has lots of companies, it's likely to have a huge number of rows in the account_partial_reconcile table. Currently, the entire account_partial_reconcile table is being iterated in the report generation, only to be filtered out later on in the query. This superfluous computation is extremely inefficient and it could be easily avoided by correctly using LATERAL JOIN syntax to make use of the filters applied later on.  # Fix: Use the correct condition inside the lateral join to filter on account_move_lines that are already filtered later on. # Benchmark: ### Report loading time | # account partial reconcile lines | # account move lines | Company size | Before | After | | --- | ------ | ------ | ------| ----- | | 588503 | 2339215 | Large | 15m+ (timeout) | ~14.02s | | 5761 | 27635 | Medium | 15m+ (timeout) | ~3s | | 11 | 1513 | Small | 7.69 | ~1.6s | #### Total number of account partial reconcile: 3279438 #### Total number of account move lines: 10688953 # Related ticket: opw-3819017 Forward-Port-Of: odoo/enterprise#61036
This improvement enhances the Latin American check payment module to support handling multiple checks within a single payment transaction. Users can now edit and manage multiple checks more efficiently when processing payments, streamlining the payment workflow for businesses operating in Latin American markets.
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
This update adds automated testing for the drag-and-drop functionality when rearranging website columns on mobile devices. Following a previous improvement to support mobile ordering, this change ensures the feature works correctly by adding a test tour that validates the drag-and-drop flow for mobile-ordered columns.
Original PR description
Commit [1] improved the drag and drop to also consider elements having a mobile order. As a follow-up, this commit adds a tour testing the drag and drop flow when moving mobile ordered columns. [1]: https://github.com/odoo/odoo/commit/7b27385dba36c2e741d96e76ad5d847d09f2b084 task-3744643 related to opw-3697962
The internal note feature, previously limited to restaurant POS systems, is now available for all shop types. This improvement allows POS users to add internal notes to order lines in any shop configuration, making the feature more widely accessible and useful across different business models.
Original PR description
Allow pos users to have the "internal note" button available even in non-restaurant shops. Task-ID: 3878947 **Before:** Internal note button is only for restaurant. <img width="1800" alt="Screenshot 2024-04-22 at 15 56 44" src="https://github.com/odoo/odoo/assets/3245568/b923a1f5-e7fe-4a8a-b624-c0c31135c4fb"> **After:** <img width="1800" alt="Screenshot 2024-04-22 at 15 55 28" src="https://github.com/odoo/odoo/assets/3245568/fc82f296-7598-46b7-bbe0-0eb199872515">
Resolved issues and error corrections
The Belgian POS Blackbox module has been temporarily disabled and made uninstallable until certification requirements are completed. This is a temporary measure that will be reverted once the certification process is finished. Users will not be able to install this module until the certification is done.
Original PR description
We make this module uninstallable until the certification is done. This commit will be reverted later.
This fix resolves an issue where the edit history wasn't being properly cleared when users clicked the discard button on knowledge articles. Previously, users could undo (Ctrl+Z) after discarding changes and see the discarded content reappear in reverse order. The fix ensures history is only reset when discarding changes, not when simply navigating through the undo/redo history.
Original PR description
related community pr : https://github.com/odoo/odoo/pull/155511 Issue: ====== History steps aren't cleared when we click discard Steps to reproduce the issue: ============================= - Add anything to a knowledge article - Click discard - Click ctrl+Z - The block reappears but in reverse order Origin of the issue: ==================== This commit introduced the behavior: https://github.com/odoo/odoo/commit/0e22763a85ee2f4caf663185eb70d3d181b954b0 Solution: ========= We pass the information via the context of the record so we can set `shouldReset` as true when we click discard and as false when we just restore history. there is no easy way to pass the information directly using the props se we make use of the record which is common between `html_field` , `controller` and `topbar` task-3768456
Fixed a formatting issue in the customer statements report where text was not wrapping properly in the activity column, causing information to extend beyond the page boundaries. The fix removes unnecessary text-wrapping restrictions to ensure all content displays correctly when printing customer statements with multiple payments.
Original PR description
### Steps to reproduce 1. Activate "l10n_account_customer_statements" 3. Register payment for a large amount of invoices (6+) to the same customer 4. Tick the Group Payments box 5. Go to the customer's contact 6. Action / Print Customer Statements You should see that most of the information is outside the page ### Cause The whole table has the `text-nowrap` class. opw-3820027 Before:  After: 
This fix resolves an issue where the Brazil Avatax services module was causing test failures when installed without the EDI (Electronic Data Interchange) module. The service tax calculation function now properly handles cases where EDI is not installed, preventing errors and allowing the module to work correctly in non-EDI environments. Users who need full service tax computation features will need to install the EDI module separately.
Original PR description
_compute_l10n_br_is_service_transaction() was added as part of account.external.tax.mixin. It's supposed to be implemented for both account.move and sale.order. The sale.order override is part of l10n_br_edi_sale_services, which is only installed if EDI is installed. This causes issues with the "l10n single modules" runbot tests. When l10n_br_test_avatax_sale is tested it installs l10n_br_avatax and sale. l10n_br_avatax_services is auto-installed because of l10n_br_avatax. Because there's no sale.order override various tests will fail with NotImplementedError() [1]. Ideally there should have been a l10n_br_avatax_sale_services module that contained just this one override. In absence of that, we make the function set False to stop breaking the tests. Users who just want tax computation on services will need to install the EDI part manually. [1] https://runbot.odoo.com/runbot/build/61615058
This update corrects the visibility logic for the Share and Link buttons in the Documents module. Previously, these buttons would appear or disappear incorrectly depending on which documents were selected. Now the buttons display properly: the Link button only shows when appropriate for the selected documents, and the Share button correctly appears when at least one non-archived document is selected.
Original PR description
Bug === Create in this order - 1 normal document - 1 link document - 1 normal document Select the first and second documents, the link button is not visible. Select the second and third documents, the link button is visible and shouldn't be. Similarly, the share button should be visible if at least one document is not archived, and not if the first document is not active. Task-3874111 Forward-Port-Of: odoo/enterprise#61400 Forward-Port-Of: odoo/enterprise#61118
Fixed a bug in the Planning module where night shift employees were not being automatically assigned to open shifts due to rounding errors in workload calculations. The system now correctly rounds allocated hours to ensure shifts are properly assigned when an employee's availability matches the shift requirements.
Original PR description
To reproduce: ============= - create an employee having night shift from 21:30 to 06:00 configured as 21:30 -> 24:00 and 00:30 -> 06:00 (break of 30 minutes) - in planning create a role for this employee - create an open shift for that role from 21:30 to 06:00 - click auto plan -> shift is not assigned to the employee Problem: ======== when computing the rate of allocated hours for this shift we find out that it exceeds 100%, because the hour 24:00 is represented as 23:59:59.999999 which creates rounding issues. Solution: ========= round the allocated rate opw-3874283
This fix corrects how fleet service costs are recorded when bills are created in a currency different from the company's default. Previously, the system would incorrectly store the bill amount in the company's currency, causing cost discrepancies. Now it properly uses the correct debit value to ensure accurate fleet service cost tracking.
Original PR description
**Steps to reproduce:** 1- Install Accounting, Fleet modules 2- Create a bill in accounting with a different currency than the company's default, and add a line with a chosen vehicle_id. 3- Go to the chosen vehicle in Fleet module 4- Navigate to the service created for this bill **Current behavior before PR:** If we create a bill for a vehicle using a different currency than the company's default. The fleet service that will be created will be having the company's currency but the value will be the amount in the currency used in the bill **Desired behavior after PR is merged:** We now create the fleet service using the value in debit not the unit price or the price subtotal. opw-3734743 Forward-Port-Of: odoo/enterprise#57639
This fix resolves an issue where the survey access rule was being overridden when both the HR Appraisal and HR Recruitment modules were installed together. Previously, only the rule from the last installed module would apply. Now the rules are properly combined so both modules work correctly together.
Original PR description
The survey.survey_user_input_rule_survey_user_read rule is override in both hr_appraisal_survey and in hr_recruitment_survey. The problem arises when both modules are installed. If so, the domain is taken from the module that is installed the last. This should not be case, instead domain should be combined. task - 3597033 Forward-Port-Of: odoo/enterprise#60941
The Frontdesk module has been updated to properly declare its dependency on the SMS module. Previously, Frontdesk was using SMS features without explicitly stating this requirement, which could cause issues if someone tried to uninstall SMS. This fix ensures the system correctly recognizes that Frontdesk needs SMS to function properly.
Original PR description
This should have been done using a bridge module to allow uninstalling SMS but hey. Runbot-27909
Fixed an issue where running timers were not being counted when creating invoices for timesheet-based service products. Previously, users had to discard running timers when invoicing. Now, the system automatically stops all running timers and includes their time in the invoice calculation, streamlining the invoicing workflow.
Original PR description
Steps to reproduce: - Make a service product, with invoicing policy based on timesheet and project & task set for create on order. - Make an SO for that product - The SO will create the task and the project - Register timesheet linked with the task with 15 min - Start a timer - Create the invoice Issues: The timer is still running, with the only choice possible being to discard it. Solution: The behaviour wanted by the po is to stop all the timer and count them in the invoice. opw-3715694
Product images in the Point of Sale were appearing zoomed in and cropped incorrectly, especially for images with unusual aspect ratios. This fix restores the previous behavior where images are resized to fit properly within their container without unwanted cropping, improving the visual presentation of products.
Original PR description
The cover scss rule first stretches the image to fill the container completely, then cropped at the size of the container. This results in some poor display result if the image has a weird aspect ratio. This is a behaviour change from saas-16.3 where the image wasn't cropped and simply resized to fit inside the container. opw-3826349 saas-16.3:  saas-16.4:  fixed locally (16.4):  Forward-Port-Of: odoo/odoo#161038
This update removes a problematic field from the gamification goals sorting logic that was causing system warnings. The fix ensures that goals can be properly searched and sorted by completion status and performance metrics without triggering errors, improving the reliability of the gamification feature.
Original PR description
We are removing the ``completeness`` field from the order because it's a non-storable field. When we attempt to access this field, it triggers a logger warning check at line [1]. This commit will help you to implement a ``goals`` search by domain and order by ``ID`` and sorting by ``completeness`` and ``current`` value, with condition-based sorting for 'higher' or 'lower' requirements check at line[2]. [1] : https://github.com/odoo/odoo/pull/127353/commits/12e9749bcc1dc4f7b1a129933ae16840195bcae8#diff-7144f88ea32f36feb17ce1b8dda7dee1631f5ada34075414587df3948c6b3d1bL5317 [2] : https://github.com/odoo/odoo/blob/5c5b4d991423e0282d06a98e5677977d53dc0817/addons/gamification/models/gamification_challenge.py#L545-L548 sentry - 5162134321
This fix resolves an issue where Point of Sale orders would incorrectly revert to draft status when sync failures occurred, even after receipts were printed. Previously, validated orders that failed to sync with the server would lose their saved state and could not be recovered properly. Now, orders maintain their saved state during sync failures, ensuring that printed receipts are never lost or modified.
Original PR description
If an order was validated in PoS but encountered a sync error, the order would revert to a draft state and no receipt would be printed. However, if an order was validated in PoS without internet, the receipt could still be printed. When the internet connection was restored, the system would attempt to validate the unsynced order. If a server error occurred during this process, the system would try to revert the order to a draft state and fail. This behavior is not ideal as an order with a printed receipt should not be modified or changed. This commit ensures that in the event of a sync failure, the saved orders do not revert to a draft state. opw-3858994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a bug in manufacturing orders where unlocking and adjusting the quantity of an overproduced order resulted in removing twice the expected materials from inventory. For example, when a 2-unit order was produced as 3 units and then adjusted to 3 units, the system was removing 6 components instead of 3. The fix ensures material consumption is calculated correctly by processing quantity changes at the proper system level.
Original PR description
Usecase to reproduce: - Create a MO for 2 unit (1 component per finished product) - Produce 3 units - Mark as done - Unlock and change the quantity to 3 units Expected behavior: 3 components removed from stock Current behavior: 6 components removed from stock It happens because the set_quantity_done create a new stock.move.line with excessive quantity. Then the write of qty_producing in mrp.production will write this quantity on all the `stock.move.line`. It results by moving number of sml * the new quantity producing Solution do the write of new quantity done on the `stock.move` level and let him manage the `stock.move.line` 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#161650
Fixed an issue preventing portal users from creating new opportunities when they don't have any existing ones. This restores functionality that was previously available, allowing users to initiate new business opportunities directly from the portal interface.
Original PR description
Issue ----- Users cannot create a new opportunity on the portal if they don't have any. Fix ----- Apply the same change in 17.0 than 58356928dd9cf07158bca4e8c1ce0dcf5177d0b9 did in following versions. **opw-3809571**
Fixed a bug where the replenishment wizard was ignoring the vendor selected by the user and creating purchase orders from the default vendor instead. The system now correctly tracks and uses the vendor chosen in the replenishment dialog, ensuring purchase orders are created from the intended supplier.
Original PR description
Steps to reproduce:
- Create a product with 2 vendors
- Click replenish on the product page and select the second vendor
- The PO is created for the first vendor
Bug:
the replenishment will create a move which will create/edit a PO the selected supplier is discarded
Fix:
set the partner on the procurement group to keep track of it
note:
'supplierinfo_name' no longer used, will be removed in master related test ("test_procure_not_default_partner") is now irrelevant
opw-3776680This fix resolves an issue where users on mobile devices could not properly select analytic accounts when configuring analytic distributions. Previously, clicking on the selection modal would close the widget instead of registering the selection. Now users can successfully configure analytic distributions on mobile devices.
Original PR description
Steps to reproduce: - Activate "Analytic Accounting" in Accounting settings - Switch to a mobile view - Go to any view where there is the analytic distribution widget (e.g. expense form) - Try to configure the analytic distribution Issue: When an analytic account is selected, it is not taken into account. Cause: In mobile view, a modal is opened with a kanban view to select the analytic account. Any click on this modal is closing the analytic distribution widget. opw-3734050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Expenses were showing zero amounts on the accounting dashboard due to incorrect column references. This fix corrects the data retrieval logic and ensures that partially paid expenses are also displayed, giving users accurate visibility into amounts owed for employee expenses.
Original PR description
Steps to reproduce: - create-aprove-post an expense - Go to the accounting dashboard Issue: expenses' amount is 0 Cause: In `_count_results_and_sum_amounts`, since the expense.currency is the same as the company we don't get the correct result: https://github.com/odoo/odoo/blob/d29a622740f6c34d25c52add5367bfdf58bbaf49/addons/account/models/account_journal_dashboard.py#L641-L644 Solution: Get the right columns. We also change the domain to make sure that expenses partially paid are also displayed. Note: For the test we check that even partially paid expenses are displayed. In Master we want the residual amount to be displayed. In master: Use the amount_residual (discussed with po Laura) opw-3849036
Fixed an issue where users would see a technical error message when trying to send an empty message in the portal's quotation chatter. The system now properly handles this scenario and displays a user-friendly error message instead of a traceback.
Original PR description
Steps to reproduce: - Install e-Commerce - Go to your portal into a quotation - Go to the chatter and send an empty message Issues: A traceback is shown Solution: Catch the error and discard it as the parent method is already displaying the error message to the user. opw-3877096
The customer portal was displaying a redundant "Addresses" box that provided the same functionality as the "Edit information" option. This update removes the unnecessary box to simplify the user interface. The multiple addresses feature will be added in a future release.
Original PR description
Steps to reproduce: - Install eCommerce - Go to My account Issues: There is a box "Addresses" which is useless for the moment as it's the same page that can be accessed by clicking on "Edit information". The feature to have multiple addresses is going to be present in master at some point, however for now we're removing the box as it's useless. opw-3869920
This fix resolves a critical issue that occurred during database migrations when a company was archived. The system was unable to properly set up Point of Sale configurations for archived companies because it couldn't find the required warehouse information, causing the setup process to fail. The fix now allows the system to correctly handle archived warehouses when creating Point of Sale configurations.
Original PR description
Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table, this error is generated when it's try to create the…
Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table,
this error is generated when it's try to create the record for pos config from pos_resturant module
by data file (defined on this commit)
https://github.com/odoo/odoo/commit/3236c1cb5025d2c2d446d11f67fda1ea51ceb992
as picking_type_id field in pos_config is required and we set default value by fetching warehouse for related company but here as company is archived, related warehouse is also archived and that why we didnot get picking_type_id for archived company and that will raise Error :
```
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4787, in _create
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "picking_type_id" of relation "pos_config" violates not-null constraint
```
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#151719This fix resolves a payment processing error that occurred when customers registered for paid events through the website checkout with an extra information step enabled. The issue prevented the order from being properly tracked in the session, causing payment validation to fail. This fix ensures the order is correctly recorded so customers can complete their event registration and payment without errors.
Original PR description
This commit fixes an issue where the `sale_last_order_id` was not being set in the session when the extra info step was added to the checkout process. This caused an error during the validation of event payment in `shop_payment_validate`. Steps to reproduce the issue: 1. Install `website_event_sale` and set up a payment provider. 2. Add the extra info step to the checkout in the website. 3. Register for a paid event from the website. 4. Proceed to pay the order, which would previously result in an error. opw-3864873 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a bug in the invoice sending process where incorrect object references caused the system to crash when processing multiple invoices. The issue occurred because the code was referencing the wrong object in a loop, leading to a "too many values to unpack" error. This fix ensures invoices are sent successfully without errors.
Original PR description
In line[1], ``self`` is referenced to ``_get_default_mail_attachments_widget``, and using ``self`` instead of ``wizard`` doesn't make sense because ``self`` could potentially hold multiple values.…
In line[1], ``self`` is referenced to ``_get_default_mail_attachments_widget``, and using ``self`` instead of ``wizard`` doesn't make sense because ``self`` could potentially hold multiple values. This becomes problematic when the ``ensure_one`` method is called. Due to this below error is raised
Traceback :
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5848, in ensure_one
_id, = self._ids
ValueError: Expected singleton: account.move.send(168, 167)
File "addons/payment/models/payment_transaction.py", line 985, in _cron_finalize_post_processing
tx._finalize_post_processing()
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/payment_transaction.py", line 144, in _finalize_post_processing
super()._finalize_post_processing()
File "addons/account_payment/models/payment_transaction.py", line 217, in _finalize_post_processing
super()._finalize_post_processing()
File "addons/payment/models/payment_transaction.py", line 1001, in _finalize_post_processing
self.filtered(lambda tx: tx.operation != 'validation')._reconcile_after_done()
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/payment_transaction.py", line 87, in _reconcile_after_done
self._post_subscription_action()
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/payment_transaction.py", line 166, in _post_subscription_action
orders._send_success_mail(tx.invoice_ids, tx)
File "home/odoo/src/enterprise/saas-17.2/sale_subscription/models/sale_order.py", line 1866, in _send_success_mail
linked_invoices.with_context(email_context)._generate_pdf_and_send_invoice(template)
File "addons/account/models/account_move.py", line 4841, in _generate_pdf_and_send_invoice
return composer.action_send_and_print(force_synchronous=force_synchronous, allow_fallback_pdf=allow_fallback_pdf, bypass_download=bypass_download)
File "addons/account/wizard/account_move_send.py", line 738, in action_send_and_print
return self._process_send_and_print(
File "addons/account/wizard/account_move_send.py", line 663, in _process_send_and_print
moves_data = {
File "addons/account/wizard/account_move_send.py", line 666, in <dictcomp>
**self._get_mail_move_values(move, wizard),
File "addons/account/wizard/account_move_send.py", line 170, in _get_mail_move_values
'mail_attachments_widget': wizard and wizard.mail_attachments_widget or self._get_default_mail_attachments_widget(move, mail_template),
File "odoo/fields.py", line 1206, in __get__
self.recompute(record)
File "odoo/fields.py", line 1421, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1394, in apply_except_missing
func(records)
File "odoo/fields.py", line 1443, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4931, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 100, in determine
return needle(*args)
File "addons/account_edi_ubl_cii/wizard/account_move_send.py", line 68, in _compute_mail_attachments_widget
super()._compute_mail_attachments_widget()
File "addons/account/wizard/account_move_send.py", line 311, in _compute_mail_attachments_widget
self._get_default_mail_attachments_widget(wizard.move_ids, wizard.mail_template_id)
File "addons/account/wizard/account_move_send.py", line 138, in _get_default_mail_attachments_widget
return self._get_placeholder_mail_attachments_data(move) \
File "addons/account_edi_ubl_cii/wizard/account_move_send.py", line 112, in _get_placeholder_mail_attachments_data
if self.mode == 'invoice_single' and self._needs_ubl_cii_placeholder():
File "odoo/fields.py", line 1202, in __get__
record.ensure_one()
File "odoo/models.py", line 5851, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
[1] : https://github.com/odoo/odoo/blob/167dedab5c7423097689c6a7d0d6ee6dd904a8bf/addons/account/wizard/account_move_send.py#L311-L312
sentry - 5234450902
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix resolves an issue where customers submitting empty product reviews would see an unexpected error dialog popup. Now, users will only see a helpful message prompting them to add either text or an attachment, providing a better user experience when submitting reviews.
Original PR description
**Current behavior:** Attempting to leave a review with no body text or attachment shows an error dialog popup. **Expected behavior:** We should just see the prompt appear above the text input area informing the user to provide either text or an attachment. No dialog window should popup. **Steps to reproduce:** 1. Go to an item in the web store and in the editor enable customer ratings 2. As a portal user go to that item and attempt to submit a review with no text nor attachment **Cause of the issue:** In the input validation for this text area we reject the pending promise if there is no body text and attachment without catching the potentially undefined return. **Fix:** Add a catch block to the block where we may have an undefined return. opw-3876444
This fix resolves a conflict in how survey access permissions are managed when both the recruitment and appraisal modules are installed together. Previously, only the last installed module's permissions would apply. Now the permissions are properly combined, and they're also correctly removed when a module is uninstalled, ensuring consistent and reliable access control.
Original PR description
The survey.survey_user_input_rule_survey_user_read rule is override in both hr_appraisal_survey and in hr_recruitment_survey. The problem arises when both modules are installed. If so, the domain is taken from the module that is installed the last. This should not be case, instead domain should be combined. On top of it, the domain is not corrected when the app is unistalled. This commit fixes that too task - 3597033 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#162238
This fix ensures that theme preview images are properly displayed in the theme selection page after upgrading a database to a new version. Previously, when databases were upgraded and new themes or theme screenshots were introduced, the images would not appear because the image update process wasn't being triggered during the upgrade. The fix now ensures this process runs automatically whenever the website module is updated.
Original PR description
In order for preview images to be shown in the theme selection page, the `update_theme_images` needs to be called. This was done in a `post_init_hook`, which is called e.g. when installing `website`.…
In order for preview images to be shown in the theme selection page, the `update_theme_images` needs to be called. This was done in a `post_init_hook`, which is called e.g. when installing `website`. This was also done in a `website` override of `ir.module.module.update_list()` which is called when updating a module interactively. Unfortunately, even though this override is defiend, at the time `update_list()` is called from `loading.py` when using `-u` on the command line, the modules are not loaded yet, and therefore the override is not applied. Because of this, when a database was upgraded between versions that introduce new themes or new screenshots for themes, `update_theme_images` was not called during the upgrade, and the new images were missing in the upgraded database. This commit solves this by calling `update_theme_images` from a `function` data record, so that it is run both on install and on update of `website`. Steps to reproduce: - Install website and a theme in 14.0. - Upgrade to 15.0. - Access the theme selection page. => Images were missing for some themes. task-2719425 Forward-Port-Of: odoo/odoo#162966 Forward-Port-Of: odoo/odoo#160452
Fixed a bug where Point of Sale sales reports were not including taxes in the total price when taxes were added separately to the product price. Now when you view order reports and pivot tables in Point of Sale, the totals will correctly reflect the full amount including all applicable taxes.
Original PR description
Current behavior: If you make a sale of a product that use a taxe not included in the price. Then go in order analysis in PoS, the total price of the product will not include the taxes. Steps to reproduce: - Create a tax of 15% that is not included in price - Create a product with 10$ price and add this tax to it. (Total price including tax should be 11.5$) - Sell it in the PoS and close the session - Go in PoS > Reporting > Order. Open the pivot view and check the total price for the product - The total is 10$ instad of 11.5$ opw-3817535 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162984 Forward-Port-Of: odoo/odoo#162883
A test in the Manufacturing module was failing inconsistently depending on the database configuration. The fix adjusts how the test calculates work order duration to ensure it runs reliably regardless of working hours settings. This improves the stability of our automated testing process.
Original PR description
The `test_update_workcenter_adapt_finish_date` test was not consistent when the db was installed without demo data. The test was failing because the working hours were not the same and so the duration was different. To fix this we adjust the starting time of the work order so that it last exactly 30 minutes, and is not impacted by the working hours. runbot error : https://runbot.odoo.com/web#id=61595&cids=1&menu_id=405&action=573&model=runbot.build.error&view_type=form --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162074
This fix corrects how fleet service costs are recorded when bills are created in a currency different from the company's default currency. Previously, the system would incorrectly store the bill amount in the company's currency while using the original bill's currency value, causing cost discrepancies. Now the system properly converts and stores the correct cost value in the company's currency.
Original PR description
**Steps to reproduce:** 1- Install Accounting, Fleet modules 2- Create a bill in accounting with a different currency than the company's default, and add a line with a chosen vehicle_id. 3- Go to the chosen vehicle in Fleet module 4- Navigate to the service created for this bill **Current behavior before PR:** If we create a bill for a vehicle using a different currency than the company's default. The fleet service that will be created will be having the company's currency but the value will be the amount in the currency used in the bill **Desired behavior after PR is merged:** We now create the fleet service using the value in debit not the unit price or the price subtotal. opw-3734743 Forward-Port-Of: odoo/odoo#155632
When a database is duplicated, CDN (Content Delivery Network) settings are now automatically disabled to prevent broken website functionality. Previously, copied databases would retain CDN settings pointing to the original domain, causing images and assets to fail loading on the new domain. This fix ensures duplicated databases work properly without manual intervention.
Original PR description
When a DB is duplicated, it's going through the neutralize process which is helpful to clean stuff that will be messing around with the duplicated DB. The CDN should actually be part of that. Since a…
When a DB is duplicated, it's going through the neutralize process which is helpful to clean stuff that will be messing around with the duplicated DB. The CDN should actually be part of that. Since a CDN url is bound to a domain, when you copy the database (and most likely run it on its own different domain), it just won't properly work. Indeed, if you setup a CDN X for domain A and then copy a DB to domain B, this will happen: - You access website B - You try to load an img, which is using CDN X URL - CDN X URL is fetching the ressource on DB A instead of DB B, which might or might not exist (an image will likely share the same path so it might work, but for assets url it might not if the bundle url has changed) In the event of the assets having changed, they will never be loaded and the duplicated DB won't be loading properly. The only workaround in this case is to switch to debug mode to bypass the post processing and so the CDN url transform. Useful commits: - Introduction of neutralize https://github.com/odoo/odoo/pull/67825 - Conversion of neutralize from ORM calls to raw SQL https://github.com/odoo/odoo/commit/e5dbded9bb363351feff7ca8a56c7f8a6860f492 opw-3880102 Forward-Port-Of: odoo/odoo#163109
This fix resolves a critical error that occurs when upgrading accounting systems with duplicate journal codes. The system was attempting to process multiple journals simultaneously, causing the upgrade to fail. The fix ensures only the first matching journal is selected, allowing upgrades to complete successfully.
Original PR description
issue generated during upgrade. when it's try to find journal with journal_data['code'] and translated_code, wil get two journal, and that will raise exception as signtone error there are two journal…
issue generated during upgrade.
when it's try to find journal with journal_data['code'] and translated_code, wil get two journal,
and that will raise exception as signtone error
there are two journal with 1. INV code
2. FAC code as translated code so will get two journal and got traceback
```
select name,id, code from account_journal where id in (12,13);
name | id | code
----------------------------------------------------------------------+----+------
{"en_US": "Factures clients", "fr_BE": "Factures clients"} | 12 | FAC
{"en_US": "Factures fournisseurs", "fr_BE": "Factures fournisseurs"} | 13 | INV
(2 rows)
File "/tmp/tmpwqzy2fx8/migrations/account/saas~16.2.1.2/end-migrate.py", line 50, in migrate
ChartTemplate._pre_reload_data(company, template_data, data)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 264, in _pre_reload_data
self.env['ir.model.data']._update_xmlids([{
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2270, in _update_xmlids
rows.add((prefix, suffix, record._name, record.id, noupdate))
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 5142, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.journal(12, 13)
```
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#163022
Forward-Port-Of: odoo/odoo#162388This update adds helpful warnings when users have outdated configuration options in their settings files. Two configuration options that were renamed years ago (osv_memory_time_limit to transient_age_limit, and geoip_database to geoip_city_db) will now trigger alerts to guide users toward the correct settings, preventing silent failures.
Original PR description
Some options have been renammed a long time ago but there was no mechanism to warn the user should those option be still present in its configuration file. Odoo versions up to Odoo 14 (excluded) used `osv_memory_time_limit` and `geoip_database` in their configuration, those two options have been renamed to `transient_age_limit` and `geoip_city_db` in 14.0 ab4000f and saas-16.1 c59750d82440 but no deprecation warning / automatic failover were provided. 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 fix ensures that when a new sales order line is created and saved, the quantity delivered field is properly initialized with a default value instead of remaining empty in the database. Previously, this field would be null, which could cause issues with order tracking and fulfillment processes.
Original PR description
Steps to reproduce: - - Create an SO with an SOL and save the record. **The `qty_delivered` of that SOL will be null in the DB.** Cause of the issue: - Since the `qty_delivered` field is computed, the default value is set in the DB comes from the `_compute_qty_delivered` method at record creation. However, no default value is set here when the `qty_delivered_method` is not `'analytic'`. ### Note: In 15.0, a default value was set because of these lines: https://github.com/odoo/odoo/blob/313418804ae5cb6a786488ffc174b8eebffb796e/addons/sale/models/sale_order_line.py#L350-L353 These were removed by this commit de4911a. opw-3771589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156917
This update removes the display of subscriber numbers that were appearing next to mailing list names in website forms configured for newsletter signups. The subscriber count information was unnecessary and has been cleaned up to provide a cleaner user experience when visitors subscribe to newsletters through website forms.
Original PR description
*: website_mass_mailing Before this commit, when a "Form" snippet was added and the action was changed to "Subscribe to Newsletter", the mailing lists appeared as checkbox fields with the number of subscribers in parentheses. This commit removes the display of this unnecessary information. Steps to reproduce: - Install the "Email Marketing" module and Website. - Navigate to the Website in edit mode. - Drag & drop the "Form" block (dynamic content section). - Change the form action by setting the "Action" option to "Subscribe to Newsletter". Bug: The number of subscribers appears next to the mailing list names. task-3472820 Co-authored-by: Adrien Milis <miad@odoo.com> Forward-Port-Of: odoo/odoo#163215 Forward-Port-Of: odoo/odoo#160509
This fix resolves a testing issue where portal user tests were failing when the system runs without demo data. The solution creates a portal user during test setup to ensure tests can run reliably in all environments. This improves the stability of the testing framework.
Original PR description
The test_sudo_commands fails when testing portal user without demo data. With this commit, a portal user is created in a setupClass. build-error: 55927 Forward-Port-Of: odoo/odoo#163116
This fix removes duplicate code that was causing the inbox message counter to increment twice for each new message. The same notification logic was being executed in two different places, leading to incorrect counter values. Removing this duplication ensures users see accurate unread message counts.
Original PR description
This code is a duplicate of the mail.message/inbox notification (https://github.com/odoo/odoo/blob/17.0/addons/mail/static/src/core/web/mail_core_web_service.js#L43) resulting in the counter being incremented twice.
This fix resolves a crash that occurred when users tried to remove the start date from Resource Time Off records. The system was attempting to calculate the end date based on a missing start date, causing an error. The fix ensures the end date is only calculated when a valid start date exists, preventing the crash and allowing users to manage time off records without errors.
Original PR description
This traceback arises when the user tries to remove the `start date` Steps to produce 1. Install `resource` 2. Open `Settings/Technical/resource/Resource Time Off` 3. Create a new record and remove…
This traceback arises when the user tries to remove the `start date`
Steps to produce
1. Install `resource`
2. Open `Settings/Technical/resource/Resource Time Off`
3. Create a new record and remove the `start date`
Error:
```AttributeError: 'bool' object has no attribute 'tzinfo'
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1824, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1073, in onchange
todo = [
File "addons/web/models/models.py", line 1076, in <listcomp>
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1189, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6664, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 1138, in __get__
self.recompute(record)
File "odoo/fields.py", line 1353, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1326, in apply_except_missing
func(records)
File "odoo/fields.py", line 1375, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4982, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 102, in determine
return needle(*args)
File "addons/resource/models/resource_calendar_leaves.py", line 58, in _compute_date_to
date_to_tz = user_tz.localize(leave.date_from) + relativedelta(hour=23, minute=59, second=59)
File "pytz/tzinfo.py", line 317, in localize
if dt.tzinfo is not None:
```
when the user tries to remove the start date, an error will be produced because _compute_date_to seems to be computing the date_to based on the date_from field. when removing the `date_from` from calculations on empty or none
which leads to traceback from here
https://github.com/odoo/odoo/blob/322e7ea19b7c069fdb92d3b86e5615c55489ca21/addons/resource/models/resource_calendar_leaves.py#L54-L59
This PR solves the above issue by computing `date_to` for records that have
`date_from`. Apart from that, this PR also removes `# -*- coding: utf-8 -*-`
from the first line of the modified file.
sentry-4983497879
Forward-Port-Of: odoo/odoo#163136
Forward-Port-Of: odoo/odoo#154555This update corrects how test users are configured in the base module's testing framework. The fix ensures that tests properly use the demo user defined in the test class, which resolves a build error and improves test reliability. This is a maintenance fix that doesn't affect end users but strengthens the quality of the software.
Original PR description
build-error: 55926 Forward-Port-Of: odoo/odoo#163107
This update makes it easier for businesses to customize the default time period used in stock quantity reports. Instead of requiring code changes, administrators can now adjust the reporting period through system settings, improving flexibility and reducing implementation time.
Original PR description
Use an ir.config_parameters to set the period for the stock quantity report to ease customization. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163017
This update allows businesses to manage subcontractor inventory using standard stock practices, which may affect on-hand inventory values. The change maintains safeguards for internal locations to protect financial valuation accuracy. This gives companies more flexibility in how they track and manage subcontractor stock.
Original PR description
Some people want to manage the subcontractor stock the same way than a classic stock. It will then impact the on hand value but it's the behavior they want. I keep the constraint on internal location since it will impact valuation. 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#163177
This update fixes how the website handles page scrolling to work correctly regardless of where the scroll is positioned. It resolves bugs that occurred when customizations changed the default scrolling behavior, while keeping the standard version unchanged. The fix unifies code across different versions for better consistency.
Original PR description
*: web, web_editor Follow-up of [1] (see its own explanation for details). This is about fixing the remaining code. In the future, we will probably go even further: - No more wrapwrap element at all - No support of a main scroll which is not left up to the browser (see some more details about that in [2] which explains the many problems which occurred when the scroll was on the wrapwrap element). Those final points have yet to be confirmed though. All in all, this PR should not change any behavior in the standard stable versions. But it will fix bugs in some custo trying to change the page scrolling behavior, while unifying the versions codebases. [1]: https://github.com/odoo/odoo/commit/ffc19547c8da2ef7fee8e2ac743ab99a607dcf90 [2]: https://github.com/odoo/odoo/pull/98429 Forward-Port-Of: odoo/odoo#163247 Forward-Port-Of: odoo/odoo#159748
Documentation and clarification updates
This change adds a signed Contributor License Agreement (CLA) from Rosen Vladimirov, enabling him to contribute to the Odoo project. The CLA is a legal requirement that ensures all contributors have agreed to the terms under which their code contributions will be used.
Original PR description
Description of the issue/feature this PR addresses: Add new CLA from Rosen Vladimirov 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