Tuesday, March 5, 2024
36 changes · 17.0
New functionality added to Odoo
This update adds PDF viewing capabilities to the Odoo platform. The enhancement improves the user experience by enabling direct PDF document viewing within the web interface, reducing the need for external tools and streamlining document management workflows.
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
Enhancements to existing features
The salary configurator now intelligently manages benefit choices for Belgian employees. When selecting a Private Bike benefit, the system automatically disables the Fuel Card option and clears any previously entered amount, preventing conflicting benefit selections and improving the user experience.
Original PR description
[IMP] l10n_be_hr_contract_salary: improve salary configurator choices This commit includes improvement to the benefit selection. Implementing a logic where selecting "Private Bike" automatically disables the "Fuel Card" option and resets any entered amount to 0 Task-3749460
Resolved issues and error corrections
This fix corrects an issue where bank account verification for payroll batches was incorrectly checking all employees in the company instead of just those in the specific batch. When a batch had no employees with bank account numbers, the system would expand the search beyond the intended batch scope. This update ensures verification stays limited to the relevant batch employees only.
Original PR description
Context: ======= If none of the batch's employees have a bank number then the employee verification was no longer limited to the batch but to the entire company. With this commit this issue is solved task: 3679494
The Documents module has been improved by removing an outdated archive toggle that was no longer relevant and reorganizing the workflow rule form to combine conditions and actions into a single unified page. This simplifies the user interface and makes the workflow configuration process more intuitive.
Original PR description
**Commit 1:** Since we can no longer archive documents, the 'Include Archived' toggle checkbox of the domain selector is now irrelevant and hence this commit removes it. Technical: The archive…
**Commit 1:** Since we can no longer archive documents, the 'Include Archived' toggle checkbox of the domain selector is now irrelevant and hence this commit removes it. Technical: The archive feature for documents has been removed with #37389. However, the active field is still being utilized for the 'trash' feature and hence cannot be removed. Whether the `Include Archived` toggle should be displayed or not, is determined by checking if a particular model has 'active' in its fieldDefs (i.e. if the model has archive/unarchive feature). As a result, the condition becomes true in the case of 'documents' model despite archive records feature not being available anymore. Thus, this commit adds a condition to check resModel, and hides the toggle checkbox from the domain selector in case of 'documents' model, by deleting 'active' from fieldDefs. **Commit 2:** This commit alters the view of documents workflow rule form such that the two separate pages for 'conditions' and 'actions' are now reorganized and merged altogether. Task: [3695462](https://www.odoo.com/web#id=3695462&menu_id=4722&cids=2&action=333&active_id=965&model=project.task&view_type=form)
This update improves the order preparation display system with better note editing, product organization, and order progression logic. Notes are now edited in-place instead of recreating order lines, products are sorted by category for easier viewing, and orders advance to the next stage more intelligently based on which items are marked as complete.
Original PR description
Behavior before the changes: - When a note was modified, it cancelled the old orderline and recreated it with the new note. - Products were not sorted by category in the order preparation display. - Clicking on the header of an order sent it directly to the next stage, regardless of whether lines were crossed out or not. - There were brackets around the order number. Behavior after changes: - When a note is modified, it is modified directly on the existing orderline. - Products are now sorted by category in the order. - Clicking on an order header sends only the crossed-out lines to the next stage. If no line is crossed out, the entire order is sent. - There are no longer any brackets around the order name. taskId: 3764317 community PR: https://github.com/odoo/odoo/pull/155246
This update fine-tunes the Luxembourg payroll salary rules to reflect regulatory changes that took effect in 2024. The changes affect salary rule parameters, categories, and contract configurations to ensure accurate payroll calculations and compliance with updated Luxembourg tax and employment regulations.
Original PR description
Tuning lu salary rules, especially some rules and parameters changed in 2024. Backport of - https://github.com/odoo/enterprise/pull/44597 task-3770404
The restaurant point-of-sale system now handles order notes more efficiently by updating them directly instead of recreating orders, organizes products by category for better clarity, and improves order progression logic so only completed items advance to the next stage. These changes streamline kitchen operations and reduce confusion during order preparation.
Original PR description
Behavior before the changes: - When a note was modified, it cancelled the old orderline and recreated it with the new note. - Products were not sorted by category in the order preparation display. - Clicking on the header of an order sent it directly to the next stage, regardless of whether lines were crossed out or not. - There were brackets around the order number. Behavior after changes: - When a note is modified, it is modified directly on the existing orderline. - Products are now sorted by category in the order. - Clicking on an order header sends only the crossed-out lines to the next stage. If no line is crossed out, the entire order is sent. - There are no longer any brackets around the order name. taskId: 3764317 enterprise PR: https://github.com/odoo/enterprise/pull/57385
This update significantly speeds up the process of creating automatic reorder points in your inventory system. By optimizing how the system calculates product stock levels across multiple warehouse locations, the operation now completes 16-30 times faster, reducing processing time from several seconds to under a second for typical configurations.
Original PR description
This commit changes the computation of product having a negative forecasted quantity to create manual orderpoints. The issue was that each replenish location needed multiple `_read_group` on…
This commit changes the computation of product having a negative forecasted quantity to create manual orderpoints. The issue was that each replenish location needed multiple `_read_group` on `stock.quant` and `stock.move` on all storable product. This commit makes only 3 `_read_group`s for all products x locations and post process the group and quantity sum by location in Python. This method gives some performance gain in time as well as in memory consumption Task: 3653272 Here is the time comparison before/after the patch for different configuration | | before | after | |---|---|---| | 700 loc, 300 prod | 14.08s | 850ms | |10 loc, 3k prod | 2.174s | 349ms | |700 loc, 30k prod | TO | 74s | 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#154596 Forward-Port-Of: odoo/odoo#149966
This update improves the performance of spreadsheet reports by reducing unnecessary recalculations when filters are used. When loading reports with filter references, the system now waits for all data to be ready before recalculating, rather than recalculating after each individual data fetch. This change reduces loading time for the Timesheet report from approximately 10-15 seconds to 6-9 seconds by eliminating redundant calculations.
Original PR description
Steps to reproduce:
- create a relational filter, let's say on `res.company`
- add a default value
- reference the filter in a cell with `=ODOO.FILTER.VALUE("my filter")`
=> every `ODOO.FILTER.VALUE` triggers an evaluation
With this commit, the re-evaluation after the data is fetched uses the
data source mechanism which only re-evaluates when all the data promises
are resolved, instead of evaluating after every resolved promise.
With this commit, the number of evaluations required when loading the
Timesheet report on our prod goes from 5 evaluations to only 3 (each evaluation
is 2-3s) because `ODOO.FILTER.VALUE("Company")` is present two times.
One issue this commit doesn't fix: there one RPC per `ODOO.FILTER.VALUE`
(can be fixed in master very easily because we refactored data fetching)
Task: 3787125
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects terminology and adds Italian language translations to the Italian EDI (Electronic Data Interchange) website sales module. The changes ensure that Italian users see properly translated and accurate terms throughout the module, improving the user experience for Italian-speaking customers and businesses using this e-commerce feature.
Original PR description
Correct the terms in this module and translate them in Italian. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155993 Forward-Port-Of: odoo/odoo#155905
This fix prevents the salary configurator from repeatedly generating commission plans every time it's accessed. By adjusting how the system processes salary updates, it now avoids unnecessary duplicate operations that were slowing down the salary configuration process.
Original PR description
When the create_new_contract function is called from update_salary it should be called with no_write set to true to avoid generating the commission plan each time the salary configurator is touched and call update_salary
Ticket ratings were not showing correctly in the helpdesk ticket list view, even though they displayed properly in other views like kanban and form. This fix updates the list view to use the correct rating field so customers can see ticket ratings consistently across all views.
Original PR description
Steps: - Install heldesk app. - Go to helpdesk app. - Open ticket view. - See ticket which contain ratings in list view. Issue: - Rating are not properly visible in ticket list view where it is…
Steps: - Install heldesk app. - Go to helpdesk app. - Open ticket view. - See ticket which contain ratings in list view. Issue: - Rating are not properly visible in ticket list view where it is properly visible in other views (kanban, form). Cause: - In list view we used `rating_last_text` field and in other view we used `rating_avg` because of that list there are not data in that field. Fix: - Replace rating_last_text by rating_avg_text field to display proper ratings. Additional info: - There are actually two ratings created from a ticket one from demo data and other from thread send email and helpdesk ratings demo data created before ratings created from thread email and since that ratings does not contains any ratings in it gives `rating_last_text` value as false. We can create our rating demo data after thread's rating by moving ratings related demo data in different file in master. task-3589757 Forward-Port-Of: odoo/enterprise#57854 Forward-Port-Of: odoo/enterprise#52371
Fixed an issue in the Barcode App where scanning an expected destination location would not split a partially processed picking line. Now when warehouse staff scan a destination that matches the expected location, the system correctly splits the line, allowing them to easily allocate different quantities to different locations without manual workarounds.
Original PR description
In a picking, when a destination is scanned, if the scanned line is not complete, the line is splitted: the processed qty goes to the scanned destination and the remaining qty still goes to the…
In a picking, when a destination is scanned, if the scanned line is not complete, the line is splitted: the processed qty goes to the scanned destination and the remaining qty still goes to the previous expected destination. That said, if the scanned destination is the move line expected location, the line is not split, which can be annoying in some case. How to reproduce: - Active multi location; - Create a receipt for 4x product A and confirm it; - Open the receipt in the Barcode App; - Scan 2x product A and then scan WH-STOCK as the destination -> Nothing happens. If the picker wants to move 2 product A in WH/Stock and 2 product A in Shelf 1, they have no easy way to do it if they scan WH-Stock first. If they scan Shelf 1 first, then the product A line will be splitted and they will get: - 2/2 product A going to WH/Stock/Shelf 1; - 0/2 product A going to WH/Stock. But if they scan WH-Stock first, they will stay with only one line: - 2/4 product A going to WH/Stock. In such case, no other choice than create a new line through the "Add Line" button (form view) and so, the reservation won't be split between the two lines. OPW-3774095
This fix corrects how Odoo calculates the remaining balance on invoices when processing multiple partial payments in Mexico's electronic invoicing system (CFDI). Previously, when making a final payment to close an invoice, the system incorrectly showed a remaining balance instead of zero. This has been resolved by fixing the payment calculation logic.
Original PR description
Steps to reproduce: - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) *…
Steps to reproduce:
- Install Accounting and l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE)
- Create an invoice:
* Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
* Invoice Date: [yesterday]
* Invoice Lines:
- Product: [any product with UNSPSC Category set]
- Price: [any]
- Taxes: [any]
- Confirm the invoice
- Generate CFDI via "Send & Print" button
- Register a partial payment from the invoice:
* Payment Way: Effectivo
* Amount: [any partial amount] (e.g. 50%)
* Payment Date: [yesterday]
- Create Payment
- Click on "Update Payments" button
- On "CFDI" tab, force CFDI on the payment
- Check the generated CFDI XML of the payment
- Attribute `ImpSaldoInsoluto` of `<pago20:DoctoRelacionado>` element contains the correct residual amount
- Register another payment from the invoice:
* Payment Way: Effectivo
* Amount: [the remaining amount]
* Payment Date: [today]
- Create Payment
- Click on "Update Payments" button
- On "CFDI" tab, force CFDI on the payment
- Check the generated CFDI XML of the payment
Issue:
In the generated CFDI XML of the closing payment, the attribute `ImpSaldoInsoluto` of `<pago20:DoctoRelacionado>` element contains a residual amount as if no payment had been done before.
Its value should be 0 as it is a closing payment.
Cause:
In the method computing the residual amount from the chain of payments, a reverse sort on the payment date is performed on the list of payments before the computation.
opw-3745151
Forward-Port-Of: odoo/enterprise#57792A recent change inadvertently broke the bank reconciliation widget's ability to suggest payment matches for invoiced sales orders. When a sales order is already invoiced and paid, the system now incorrectly prioritizes the sales order rule over the payment rule, resulting in no suggestions being shown to users. This fix restores the proper matching behavior so users can see available payment options during bank reconciliation.
Original PR description
Since https://github.com/odoo/enterprise/commit/79461fce51f1f931b34aa66f8886a5faaf9c0908 The matching with SO changed. Suppose a SO already invoiced and reconciled with a payment. Before the commit above: - the SO rule was failing. - the AML rule was able to retrieve the related payment. After: - the SO rule found a match. - since there is no available aml to match on the invoice, nothing is suggested to the user on the bank reco widget. ticket_id: 3776876 Forward-Port-Of: odoo/enterprise#57958
Fixed an issue where the grid view (such as timesheet) would not remember your previous selection when you opened a record and returned to the grid. Now when you navigate back to the grid view, your previously selected week or time period is properly restored, improving the user experience by eliminating the need to re-select your view settings.
Original PR description
Steps to reproduce ================== - Go to timesheet - Switch to the next week - Open a record by clicking on the magnifying glass icon - Go back to the grid view by clicking on the previous breadcrumb => The previously selected week is not restored Cause of the issue ================== We don't export the current state when leaving the view opw-3729307 Forward-Port-Of: odoo/enterprise#57990 Forward-Port-Of: odoo/enterprise#57510
This fix corrects an issue where the system was incorrectly suggesting accounts when creating vendor bills. Previously, if a partner name and invoice line label matched an account name, the system would suggest that account even if it was the wrong type (e.g., suggesting a payable account when a different type was needed). This update ensures accounts are only suggested when they match both the name and the correct account type, improving accuracy in bill processing.
Original PR description
Having a partner and a label that match an account in a bill line leads to the account to be predicted even if it is of the wrong account type. Steps: - Create a payable account X with name containing ABC - Open vendor bill, set partner ABC - On the invoice line set the label to ABC and unfocus the line -> The account that is predicted is account X opw-3717805 Forward-Port-Of: odoo/enterprise#57790
Fixed a bug where duplicating a warehouse in Inventory would not copy its associated operation types (picking types). Now when you duplicate a warehouse, all its operation types are properly created for the new warehouse, ensuring consistent warehouse configurations.
Original PR description
[FIX] stock: duplicating warehouse dependencies Before this commit when duplicating a warehouse, its operation types (picking.type) wouldn't get copied. This commit ensures that new picking.types are created for the duplicate warehouse. ### [Reproduce] - run odoo 17 with -i stock,mrp_subcontracting - in Inventory/Configuration/Warehouses Duplicate a Warehouse - Bug: in Inventory/Configuration/OperationTypes picking types aren't duplicated opw-3674614
This fix resolves permission problems that prevented Point of Sale users with basic access rights from performing essential tasks like creating invoices and using the "Ship Later" feature. The update adjusts access controls to ensure users with only Point of Sale permissions can properly use all core functionality without requiring additional system access.
Original PR description
Current behavior: When a user has only "User" right for point of sale and no other access some functionalities are not working properly. For example, the user cannot create an invoice from the PoS interface. And the user cannot use the "Ship Later" functionality. Steps to reproduce: - Change the right of a user to "User" for point of sale and no other access. - Log in as this user and try to create an invoice from the PoS - Try to use the "Ship Later" functionality Note: This commit modify the access right of the test pos_user so that it has the minimum access to be able to use the PoS interface properly. opw-3644739 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue in the Surveys app where comment text fields were not appearing when selected as an answer option. When a survey question is configured to allow comments as an answer choice, users can now properly see and fill in the comment field after selecting it.
Original PR description
**Current behavior:** A survey question which has a comment field counted as an answer will not reveal its text box input field when it is selected as the current answer. **Expected behavior:** After clicking on the comment field answer, the text box will be revealed and enabled. **Steps to reproduce:** 1. In the surveys app, add a question to a survey of type `Multiple choice: only one answer` 2. In the question's options, enable the `Show Comments Field` and `Comment is an answer` options 3. Go to the question in the survey, click on the comment answer and observe there is no field to enter a comment **Cause of the issue:** The function which is responsible for adapting these page elements is not selecting the correct html elements, thus their attributes are not properly changed when needed. **Fix:** Change the function variables so that they are pointing to the correct location in the DOM. opw-3748291
Fixed a bug in the recruitment job application form that caused an error when the LinkedIn Profile field was removed. The form now correctly handles missing fields and allows applicants to submit their application as long as they provide either a resume or LinkedIn profile. This ensures a smoother application experience for job seekers.
Original PR description
### Steps to reproduce:
- Install **website_hr_recruitment** module.
- Go to **Recruitment** app.
- Click on **Job Page** button on one of the position cards.
- Click on **Apply Now!** button.
- Click on **Edit** in the upper right corner.
- Remove the LinkedIn Profile, then save.
- Click on **I'm feeling lucky** button to apply the form.
- An error is raised indicating that `Cannot read properties of undefined (reading 'trim')`
### Investigation:
- the linkedin field is grabbed by `const $linkedin_profile = $('#recruitment4');`
- and then is used to check the condition `$linkedin_profile.val().trim() === ''`
- but since the field no longer exists, the `$linkedin_profile.val()` is undefined and hence the error is raised
### The Fix
- The functionality is to allow to apply the form if _**at least one**_ of the **linkedin** or **resume** fields is non-empty
- we a field as empty if it:
- doesn't exists
- exists but is value-empty
opw-3754506This fix prevents the system from unnecessarily recalculating sales order totals when no actual changes are made to order lines. Previously, the system would trigger unwanted recalculations and display duplicate tracking records with identical values, which wasted processing resources. Now, the system only recalculates when there are genuine changes to order data.
Original PR description
In some conditions, a x2many field can be considered as modified by the webclient when in fact there is no change in 'meaningful' stored fields. In this case, on save, an empty list of magic commands…
In some conditions, a x2many field can be considered as modified by the webclient when in fact there is no change in 'meaningful' stored fields. In this case, on save, an empty list of magic commands will be sent to the server, potentially triggering unexpected recomputations. Steps to reproduce: * install sale_stock & sale_management * create a new storable product * create a new SO * create a new line with this product * Confirm the SO * Set or Update the SO delivery date (Other info tab) * Save -> In the chatter, you will notice an useless tracking value being printed for the SO Total, with identical values before and after update. Cause Since the server received an empty list of commands for the `order_line` field, this triggered a recomputation of the total amounts of the SO, even though there were no effective changes in the lines. Solution Do not send empty command lists for x2m fields. This will avoid unexpected recomputation and also improve performance since the fields were recomputed for 'nothing' --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where newly added message types in the mail system could cause errors when fetching related data. The fix automatically synchronizes message type selections in the database on first access, ensuring smooth operation without disrupting existing functionality. Subsequent accesses are cached for optimal performance.
Original PR description
A new message type was added in stable. This is usually safe, however in cases where there are related fields on that same selection fetching them will raise an exception as the ORM has to fetch the translations for the selection in DB. We add a hack on mail.mail to update the selections in DB when fetching the message type the first time. Subsequent gets should be inexpensive as these are cached. task-3773301 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156112 Forward-Port-Of: odoo/odoo#155766
This fix corrects an issue where bank payment method differences were not appearing in the daily sales report when closing a Point of Sale session. Previously, only cash payment differences were shown. Now both cash and bank payment differences are properly displayed in the report, ensuring accurate financial reconciliation.
Original PR description
Current behavior: When entering a difference at the closing of the session for a bank payment method, the daily sales report was not taking into account the difference for the bank payment method. Steps to reproduce: - Start PoS and make a sales with bank and a sales with cash - Close the session with a difference for both payment methods - Go to the daily sales report and check the difference for the bank payment method. The one for the cash is there but not the one for the bank. Note: This bring back the original behavior of the report that was removed here (https://github.com/odoo/odoo/pull/146341) and makes it coexist with the current one so that all cases are covered. opw-3737223 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154929
This fix prevents users from changing the unit of measure on component stock lines after quantities have been reserved during subcontracted product receipt. Previously, changing units (e.g., from grams to kilograms) after reservation would cause system errors and inventory discrepancies. The system now blocks these changes when quantities are reserved or the receipt is completed.
Original PR description
Before this commit: "Cannot unreserve more than you have in stock" Error It was possible to purchase a subcontracted product, and on the receipt of the product, change the unit of measure o on the stock move lines of the components when the quantities were already reserved. This caused unreserve issue given that, all of a sudden, instead of having 200g, we would have 200kg reserved and the change would not be reflected on the quant. After this commit: The view was modified to not allow changes of UoM if there are reserved quantities, or if the state is done. OPW-3742720 Forward-Port-Of: odoo/odoo#154450 Forward-Port-Of: odoo/odoo#154327
This update fixes navigation button behavior in embedded PDF viewers within e-learning courses. Previously, the next, previous, first, and last buttons were incorrectly enabled or disabled based on broken logic. The fix ensures buttons display correctly based on course structure, such as showing the next button even when viewing the last PDF page if suggested slides are available.
Original PR description
Bug === When we show a PDF in e-learning, we have some navigation buttons (next, previous, last, first) with some conditions for them to be enabled or not (e.g. a documentation can have suggested slides, and so the next button is visible even if we are on the last page). Those conditions are broken (sometimes a button is disabled when it shouldn't and vice versa), this commit aims to fix that issue. Task-3751253 Forward-Port-Of: odoo/odoo#156252 Forward-Port-Of: odoo/odoo#154967
This fix resolves an error that occurred when printing Bill of Materials (BOM) documents for subcontracting products created with dynamic attributes. The system now properly handles products that don't have manually created variants, allowing users to successfully generate BOM overview PDFs without encountering crashes.
Original PR description
Current Behavior: - Traceback when printing the BOM overview. Expected behavior: - Generates a PDF of the BOM overview even if the information displayed is entirely relevant. Steps to reproduce: -…
Current Behavior: - Traceback when printing the BOM overview. Expected behavior: - Generates a PDF of the BOM overview even if the information displayed is entirely relevant. Steps to reproduce: - Inventory > Configuration > Products > Attributes Create an attribute with Variants Creation Mode set to "Dynamically". Create a new product with this single attribute and multiple values. Create a BOM for this product with BOM Type set to "Subcontracting". Print the BOM overview. Cause of the issue: - Creating such a product generates a 'product.template' that is not associated to any variant and hence does not correspond to any 'product.product'. As a result the function `_get_bom_data` can not apply the method `_select_seller` properly in that case. Notes: - - There is no error if a variant was manually created for that product. - If the Variants Creation Mode set to "Dynamically" a variant is still automatically created to be associated to the product tempalte so that the erro does not rise. Fix: - As the _select_seller method is only defined for product.product and not for product.template, we can not not apply it here. Furhtermore, since the additional informations provided by the override of the method get_bom_data in the the BOM overview will not be relevant without the existence of a variant, we skip this part of the code when the argument of _select_seller is not valid. opw-3698050 - --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152275
This fix ensures that taxes are applied consistently on invoices regardless of the order they are entered. Previously, when multiple taxes had the same priority level, the calculation results would vary depending on which tax was listed first. Now taxes are sorted by a defined sequence, with a consistent fallback to tax ID when priorities are equal, guaranteeing predictable and reliable tax calculations.
Original PR description
**Issue Description**: Currently, the order in which taxes are applied can vary based on the sequence they are entered in the invoice's Taxes field. This inconsistency arises when the tax list is not…
**Issue Description**: Currently, the order in which taxes are applied can vary based on the sequence they are entered in the invoice's Taxes field. This inconsistency arises when the tax list is not manually adjusted, leading to each tax having an identical sequence value. As a result, their hierarchy within the `flatten_taxes_hierarchy` function is determined by their input order rather than a defined sequence, causing unpredictable tax calculations. https://github.com/odoo/odoo/blob/56666f8f7858fcbcce466d2240135b35509d2d96/addons/account/models/account_tax.py#L611-L632 A tax sequence should be explicitly defined, and in cases where sequences are identical, organization by tax ID should be enforced. **Steps to Reproduce**: 1. Navigate to the `Account` or `Invoice` app. 2. Go to `Configuration > Taxes`. 3. Create a new tax with the advanced option `Affect Base of Subsequent Taxes` and specify an amount. 4. Generate a new invoice and add a line item priced at 100. 5. Apply taxes in the `Taxes` column in the following order: 15% followed by the newly created tax, and note the total amount. 6. Repeat step 5, but reverse the order of the taxes. 7. Observe that the total amounts differ between the two sequences. **Proposed Solution**: To ensure that taxes are applied consistently regardless of input order, we will modify the `flatten_taxes_hierarchy` function to add sorting by id. If the sequences are identical, the sorting will depend only on the id, otherwise it will be based on the sequence. This setting ensures a predictable and logical process for applying taxes. opw-3691765 Forward-Port-Of: odoo/odoo#156031 Forward-Port-Of: odoo/odoo#154167
This fix improves how the system calculates an employee's departure date when handling contract records. Previously, the system may not have correctly identified the departure date when an employee had open contracts. The fix now ensures the system uses the last expired contract end date as the departure date when there are no open contracts for the employee, providing more accurate employee departure records.
Original PR description
Purpose ======= Take the last expired contract end date if there is not open contract for the related employee. TaskID: 3610709 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#156065
This fix resolves an issue where accessing a non-existent static file URL would cause the browser to get stuck in an infinite redirect loop. The system was incorrectly redirecting URL-based attachments through the fallback handler, creating a circular redirect. Now only stored files are served through the fallback mechanism, preventing this redirect loop.
Original PR description
Create an attachment with an URL to a static file that does not exists, e.g. '/web/static/idontexist.png'. Inside your browser try to access that file, open <localhost:8069/web/static/idontexist.png>. The browser fails with a "Too Many Redirections" error. When a path is not found, nor in the static files, nor in the controllers, `_serve_fallback` kicks in and attempt to find a resource outside of the router that matches the URL. In case it finds an attachment with a matching URL, it'll deliver it. In this specific case, it finds our attachment and return a redirection to it's URL, which is the same URL as the request hence it loops back. Don't deliver URL attachments via `_serve_fallback`, only deliver stored files. 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#154883
This update fixes the electronic address system (EAS) code used for Swedish organizations in electronic invoicing. The deprecated code has been replaced with the current valid code to ensure Swedish invoices are properly formatted and recognized by the Peppol network. This change ensures compliance with the latest international e-invoicing standards.
Original PR description
remove deprecated EAS code for Sweden. The code is no longer part of the valid list of codes. See https://docs.peppol.eu/poacc/billing/3.0/codelist/eas/ and https://docs.peppol.eu/edelivery/codelists/ Also, in the endpoint the Swedish organization number must be used, which is taken from the VAT by removing the country code and the last two digits. You can check it out here: https://organisationsnummer.dev/ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156289 Forward-Port-Of: odoo/odoo#153440
This fix resolves an issue where repair orders for products with no stock were incorrectly creating duplicate picking records, causing gaps in the repair sequence numbering. The problem occurred because draft stock movements were not being properly recognized by the assignment logic.
Original PR description
For repaired products with no stock, a new picking is wrongly created, leading to a gap in the repair sequence. This because the move is created in 'draft' and the function does not take it into account. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156083
This fix prevents users from submitting multiple reviews for the same course, even when accessing the course from multiple browser tabs. Previously, users could bypass the single-review-per-course policy by having multiple tabs open. Now the system properly enforces that each user can only submit one review per course, improving data integrity and preventing duplicate reviews.
Original PR description
Once a user posts a review, they are able to edit this single review and not create any new ones. However if the user had multiple tabs open of the same course, then they can still access the "Add a review" functionality. This fix enforces the single review per user per course policy. Task-3721958 Forward-Port-Of: odoo/odoo#156198 Forward-Port-Of: odoo/odoo#153679
This fix addresses floating-point rounding errors that were occurring in electronic invoice price calculations. The system was using an ineffective rounding method that still produced incorrect decimal values (like 83.60000000000001 instead of 83.60). By switching to Python's built-in rounding method, invoice amounts are now calculated correctly, ensuring accurate electronic invoices for customers.
Original PR description
In [1], we added a rounding of the amounts in the `<PriceAmount>` tags to avoid floating point rounding errors. However, it seems the `float_round` function does not guarantee to avoid these errors. Take the example of `price_subtotal` = 250.80 and `quantity` = 3. We will compute the PriceAmount as 250.80 / 3 which yields 83.60000000000001. Even when using `float_round(amount, 10)`, it still results in the same amount with the rounding error. For that reason we use the built-in `round` method of Python instead. [1] 58d57bbbaaab32ba0183890a9182e6de09b32ac5 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155949 Forward-Port-Of: odoo/odoo#155570
This update prevents the messaging system from sending unnecessary notifications when there are no channel members to update. Previously, this could cause errors by creating invalid channel member records. The fix improves system stability and reduces unnecessary notification traffic.
Original PR description
When there is no channel members to be updated the seen status, we should not send a notification to the channel members, otherwise, it will lead into creating a channel member with id undefined. test case added to check that the notification is not sent when there is no channel members to be updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves how the system detects duplicate accounts when loading chart templates. Previously, the system could miss duplicate accounts because it compared account codes before standardizing their format. Now it compares the properly formatted codes, preventing the creation of unwanted duplicate accounts in your chart of accounts.
Original PR description
**Description of the issue/feature this PR addresses:** Function `_pre_reload_data` checks for the existance of accounts with the same code to avoid creating a duplicate. It does so however comparing with the code before normalizing it with the length from the template, failing to find possible duplicates with a normalized code. **Current behavior before PR:** If accounts with non-normalized codes _(eg 172)_ are being loaded, there's a risk that an account with a matching normalized code _(eg 172000)_ already exists in the database. If the corresponding xmlid is not pointing at it, another account with the same code will be created triggering the ValidationError. **Desired behavior after PR is merged:** The comparison with existing accounts is made with the normalized code avoiding this conflicts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156119 Forward-Port-Of: odoo/odoo#155256