Daily updates from Odoo
Navigate
Branch
Friday, February 23, 2024
90 changes
23 changes
Enhancements to existing features
This update restores the ability for users to directly edit expense lines within expense reports. This change improves usability and allows for more accurate reporting. Key fields like quantity and taxes remain readonly to prevent data inconsistencies.
Original PR description
In #138387 we modified the expense lines tree in expense reports so that the user can click on the lines to see an attached receipt in the viewer at the side of the webpage. The tree was made to be readonly to make clicking the lines easier and to make it harder for the user to change a field by mistake. This commit reverts the lines to being editable again while leaving some fields as readonly like quantity and taxes as those can invalidate the expense. Task link: https://www.odoo.com/web#model=project.task&id=3685651 task-3685651 Forward-Port-Of: odoo/odoo#149588
This update introduces an HSN (Harmonized System) code autocomplete widget for Odoo's Indonesian localization. Users can now quickly select HSN codes from a list as they enter data, streamlining the tax input process. This enhancement improves accuracy and efficiency for Indonesian businesses using Odoo.
Original PR description
- In this PR, we make some requests in js to get a list of HSN codes to match with the input entered by the user in the field. - And for the options attribute in hsn_autocomplete widget, when a user selects an option from the list, the hsn_decription will be stored in the field specified by the user. task-3646598 Forward-Port-Of: odoo/odoo#151507
This update adds a new test to ensure dropdown menus (like submenus) in Odoo are consistently and correctly tested across all versions. This improves the reliability of our software by verifying a key functionality, and helps prevent potential issues with navigation and user experience. This is a standard improvement for maintaining software quality.
Original PR description
This commit backports the test introduced in odoo/odoo#155154, as it is relevant to have it in every versions to ensure that dropdown menu (i.e. submenus) are correctly tested. 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#155156
Resolved issues and error corrections
This update resolves a performance issue that slowed down the process of adding new messages in Odoo. By optimizing how related data is calculated, the system now inserts messages approximately twice as fast, leading to a smoother user experience. This change primarily impacts the 'mail' module.
Original PR description
Move compute of `imStatusTrackedPersonas` to its inverse field. Doing the compute on the "One" side of the relation prevents from looping and computing all values whenever there is a change in any of them. In practice, this reduces the "compute" time of the message fetch (which also fetch persona as authors of messages), reducing by approximately half the time it takes to insert these messages (depending on the number of persona it had to loop through). For example from 60ms to 30ms on my machine for message insert in "partner_1_125" (populate medium). Forward-Port-Of: odoo/odoo#154918
This update resolves an issue where the system was incorrectly summing data returned from a key function. This fix ensures accurate calculations within the stock account module, improving data reliability. No immediate user impact is expected.
Original PR description
This commit fixes summing list of dicts returned by _prepare_analytic_lines. NB: This code is not yet covered by a test use case. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152819
This update resolves a performance issue related to how Odoo reads activity deadlines. By batching the reading process, the system now handles deadlines more efficiently, leading to faster response times. This change ensures smoother operation for users managing activities and appointments.
Original PR description
`__getitem__()` of BaseModel, reset the prefetch set of the recordset. Fix _compute_activity_date_deadline, to batched the reading of activity's deadline. Forward-Port-Of: odoo/odoo#154728 Forward-Port-Of: odoo/odoo#154159
This update restores missing images after upgrading to version 17.0, preventing visual errors and crashes when using website snippets. A temporary workaround is implemented to ensure images display correctly until a permanent fix is applied in the upgrade repository.
Original PR description
Commit [1] introduced default images changes for the website library. The problem is that the ir.attachment definitions are in a non-updatable environment by mistake (apparently since forever)... so…
Commit [1] introduced default images changes for the website library. The problem is that the ir.attachment definitions are in a non-updatable environment by mistake (apparently since forever)... so they are not updated after update/upgrade. This commit moves the definitions to its own updatable file, in 17.0 and above only (ignoring potential other changes that were made in 15.0/16.0 at the time but apparently led to no issue). But this is not enough: upgraded users will still have those ir.attachment records marked as non updatable and will thus not be updated. Meaning that the ir.attachment record will still reference path to images that do not exist anymore (since [1]) and thus not display anything in related snippets, or worse: crash on some non-robust-to-404-images options (This will be made more robust in another update). Note that, at the moment, we cannot solve this issue by making the /web/image route not return a 404 but a placeholder image in that case, for technical reasons (even though it would be consistent as this is what is done if you try to reach `/web/image/something_with_a_typo`). It would also be annoying to solve this problem by adding a migration script inside the Odoo repo itself: - It would only work if upgraded users do a -u again (unlikely). - That would mean an upgrade script rotting in the main repo forever. Instead, this commit chose to restore the removed images so that upgraded users will be able to use the outdated paths. In master, an upgrade script will be made (in the upgrade repo) to properly update all those attachment records and be able to finally remove those outdated images. Note that this may also be fixed without upgrade script if non-updatable records whose XML declaration is moved out a non-updatable area become updatable (under discussion with the framework team... we will see when this lands in master). Steps to reproduce: - Install a 16.0 with the website module - Upgrade to 17.0 - Drag a "Blockquote" snippet on a page => Crash and the image is missing (in the DOM but invisible and impossible to edit). Note that the crash itself will also be fixed by the later update that will be done to make editor options more robust to 404 images. [1]: https://github.com/odoo/odoo/commit/a4377bfa85b19be29a430573e0f42fff4da52757 opw-3693055 opw-3723895 opw-3744257 opw-3747348 opw-3749764 ... Forward-Port-Of: odoo/odoo#155015
This update optimizes the way Odoo searches for channels, resulting in faster performance. The change avoids inefficient database queries and ensures accurate results. It also includes improvements to testing and security rules.
Original PR description
Part 1: _search_is_member ------------------------- Separate query to fetch candidate channels because the sub-select that `_search` would generate leads psql query plan to take bad decisions. When…
Part 1: _search_is_member ------------------------- Separate query to fetch candidate channels because the sub-select that `_search` would generate leads psql query plan to take bad decisions. When candidate ids are explicitly given it doesn't need to make (incorrect) guess, at the cost of one extra but fast query. It is expected to return hundreds of channels, a thousand at most, which is acceptable. A "join" would be ideal, but the ORM is currently not able to generate it from the domain. `sudo` is added as well because the rules for the member don't need to be checked as no information is leaked. Part 2: clean rules ------------------- The rule for reading "self" is included in the rule for reading other members. It can be disabled for "read" to avoid duplicate. It also checked is_member again, but is_self necessarily implies it. Part 3: clean tests ------------------- The opportunity is taken to fix the tests. The tests where considering as "access error" when there was an assert error inside the test (for example not finding the channel or the member), but those needed to be considered as failure regardless of expected outcome of access check. Extra mute loggers are added to clean the test output. Forward-Port-Of: odoo/odoo#153697
This update corrects a bug where validating a stock picking with available quantity would incorrectly pick an empty stock picking, preventing further reservations. The fix ensures that only pickings with actual stock are validated, maintaining accurate inventory management. This resolves an issue that could lead to incorrect stock levels.
Original PR description
Usecase to reproduce: - Create a picking with available quantity and another without - Confirm both picking - In list view, select the two picking and use the validate action Expected behavior: The first picking is validated and the second has been untouched Current behavior: The second picking is picked. That will prevent any further reservation It happens because on multiple records the error message for empty picking is bypassed and the picked is applied on it. Close #153983 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#155039
This update resolves an issue where base users were incorrectly denied access to their own expense reports. A technical oversight in the system's design prevented them from generating these reports, resulting in an access error. This fix ensures all users, including base users, can properly create and access their expense reports.
Original PR description
Have a base user with no access to Accounting, Expenses, Employee Create an expense, input an amount Save and Create Report Access Error will raise You are not allowed to access 'Journal Entry' (account.move) records. This occurs because of a remaining field in the hr.expense.sheet form view after refactoring the model opw-3690493 Forward-Port-Of: odoo/odoo#154798 Forward-Port-Of: odoo/odoo#152288
This update ensures that products with warning or blocking messages are clearly displayed in the product catalog when creating quotations. This prevents users from accidentally adding products with critical issues to their orders, improving order accuracy and reducing potential errors. The fix also extends to the purchase module.
Original PR description
Currently, when adding a product to a quotation with the catalog, no warning message will appear when adding a poduct that has a warning or blocking message. Steps to reproduce: ------------------- *…
Currently, when adding a product to a quotation with the catalog, no warning message will appear when adding a poduct that has a warning or blocking message.
Steps to reproduce:
-------------------
* Go to **Sales** app -> Configuration -> Settings
* Enable **Sale Warnings**
* Go to **Products** -> Products
* Create a new product
* Under **Sales** tab:
* For warning, select either warning or blocking message
* Write a message
* Go to **Orders** -> Quotations
* Create a new quotation
* Select the **Catalog** to add products
* Add the newly created product
Why the fix:
------------
The first version of this fix was a python exclusive change. It was a bit hacky; it was raising an error when the product had a blocking warning and sending a message on the bus when the product had a non-blocking warning.
The second version was changing the return value of `_update_order_line_info` to return the price and the warning if any. The warning was shown inside JS with `_updateQuantity`. This change was not good for a stable verion as it was changing the signature of a public method.
This fix automatically changes the data that is loaded to the catalog. It adds the warning message if any and changes the `readOnly` field accordingly.
Warning/blocking messages will be automatically displayed in the catalog, on the product informations. Products with blocking messages will me marked as readonly to avoid being able to add the product to the sale order (this is the original behavior for blocking messages).
Regarding the field `readOnly` and ẁarning`:
* We can't write `res[product.id]['readOnly'] = product.sale_line_warn == "block"' because readOnly is set to True by default if the sale order is cancelled and doing this would overide that value later. See:
https://github.com/odoo/odoo/blob/21c25a7ccd0ba2d6574ddbcfbcf50dbbc03a1e6c/addons/product/models/product_catalog_mixin.py#L97-L99
* We're also sending the warning only if there is one because of this:
```python
<span t-elif="props.readOnly" class="my-2 pt-3 border-top" t-out="props.warning">
You can't edit this product in the catalog.
</span>
```
Because in the case where readOnly is True for another reason than the product having a blocking warning, the initial message will be displyed.
Since the module purchase also uses the warning on products, this fix is extended to include it.
opw-3631511
Forward-Port-Of: odoo/odoo#149155This update resolves an issue where editing the 'Products' field in loyalty programs would clear the selections. The fix ensures that product selections made in the default loyalty rule are now saved correctly when the program is created or edited, improving the user experience for loyalty program setup.
Original PR description
**Current behavior:** Creating a promo type loyalty program and editing the 'products' field in the 'Among' section of the rule created by default at the bottom of the form view before saving the…
**Current behavior:**
Creating a promo type loyalty program and editing the
'products' field in the 'Among' section of the rule created by
default at the bottom of the form view before saving the
program will cause the products selected in this field to be
cleared upon saving the program.
**Expected behavior:**
Filling out this field of the default rule before saving the
overarching loyalty program should result in the same behavior
as doing so after saving the program. That is, the field should
save the user's input.
**Steps to reproduce:**
1. Create a new loyalty program in the Discount & Loyalty tab
2. Give it a name and, before saving the program, edit the
'Products' field of the default rule that is created at
the bottom of the form to have at least one value
3. Now save the program and observe that the 'Products' field
has been cleared of the previously selected values
**Cause of the issue:**
In the form view for the loyalty.program there are two
instances of the field trigger_product_ids which are set to be
invisible unless creating a specific program type. This field
is set to be related to rule_ids.product_ids in its definition
within the loyalty.program class definition. Thus, when the
user saves the program and rule concurrently, the empty
trigger_product_ids field overwrites the product_ids field
and whatever the user had populated it with is cleared.
The reason it only happens to the default rule and not ones
which are manually added before saving the program is because
in the traverse_related() method in fields.py, only the first
record of the related field is returned to be modified. In this
case, it means only the first rule's product_ids field is
overwritten.
**Fix:**
Overwrite the create() method in program.loyalty and check if
the program being created is of type 'gift_card' or 'ewallet'
then, if so, delete the trigger_product_ids key,val from the
dictionary so it will not later override the products specified
in the loyalty rule.
opw-3669953
Forward-Port-Of: odoo/odoo#150418This update resolves an issue that caused a 500 error when creating draft invoices with payment terms that include early discounts. The fix ensures the invoice preview function correctly calculates the total amount due, even when discounts are applied, preventing the error and improving invoice generation reliability.
Original PR description
Description of the issue this PR addresses: --- On obtains a 500: Internal Server Error when creating an invoice with a 2 lines payment term. Error while rendering the template…
Description of the issue this PR addresses: --- On obtains a 500: Internal Server Error when creating an invoice with a 2 lines payment term. Error while rendering the template "account.report_invoice_document". Steps to reproduce: --- - Accounting > Configuration > invoicing > Payment Terms - New > Create and save a payment term with 2 lines: - name 80/20 test - line_1 : 80% after 0 days - line_2 : 20% after 30 days - Sales > Orders > Quotations - Chose any > use payment terms 80/20 test - Save and create associated invoice > chose regular invoice - Create draft invoice > preview > 500: Internal Server Error Cause of the issue: --- The method "_get_amount_due_after_discount" called during the rendering of the template does not return a value in case self.early_discount is False. Fix: --- Return total_amount by default since no discount is applied. opw-3683708 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149934
This update corrects a bug that prevented users from saving accrual level configurations. The issue stemmed from a technical limitation with a field's read-only status, which was incorrectly preventing data entry. The fix ensures the field can be properly updated, allowing for accurate holiday accrual planning.
Original PR description
Steps to reproduce: ------------------- - create an accrual plan; - create an accrual level; - save; - create a second accrual level; - save the form; Issue: ------ We trigger an error with an…
Steps to reproduce: ------------------- - create an accrual plan; - create an accrual level; - save; - create a second accrual level; - save the form; Issue: ------ We trigger an error with an invalid `added_value_type` field. Cause: ------ The `added_value_type` is a compute stored field without inverse. As it is not inversible, this field will be readonly by default [^1]. When the dialog window is opened, we trigger a specific logic which will trigger an onchange [^2]. During this onchange, we work with a virtual record from the `hr.leave.accrual.level` model (the one corresponding to the first level) which has an origin. Unfortunately, we are using the cached value for the virtual record, i.e. `None`. The latter will have been set as if it is a record without origin. As the `added_value_type` field is readonly on the dialog form view, we have to save the record with this value. Since this field is required, the error occurs. Solution: --------- In order to use the value on the original record, the field must be forced with `readonly=False`. Note: ----- Commit which introduced the issue: 0a9e83dfd81300fd1204693cf6d4dca2bab40b2c The fix allows you not to use `_origin` (which normally shouldn't be used in this case). [^1]: https://github.com/odoo/odoo/blob/e89ed59269974f148c2285446dcd60e871df1a01/odoo/fields.py#L451 [^2]: https://github.com/odoo/odoo/blob/25cda065dccaae5edd861114c29157c7abb68533/addons/web/static/src/model/relational_model/static_list.js#L194-L299 opw-3745463 Forward-Port-Of: odoo/odoo#155033
This update quietly resolves a warning message that appeared after importing new modules into Odoo. Previously, the system attempted to update its internal graph, which was unnecessary and caused the warning. This change ensures a smoother import process without disrupting the user experience.
Original PR description
Before this PR, after having imported a module, a warning appears in the log, because it tries to update the graph which does not make sense for an imported module. This commit makes sure the warning is skipped if the module was imported. This commit can be backported to previous versions, if useful. Forward-Port-Of: odoo/odoo#155096
This update corrects a technical error preventing users from successfully verifying a partner's Peppol endpoint. The previous issue caused a system error, blocking the verification process. This fix ensures the Peppol verification feature functions correctly for all partners.
Original PR description
### Steps to reproduce * install `account_peppol` * open a partner's list view * select a contact * on the top middle, click Actions > Verify Peppol You should be met with a traceback: `AttributeError: 'bool' object has no attribute 'setdefault'` ### Cause `button_account_peppol_check_partner_endpoint` is expected to return an action or a falsy value (no action to perform). opw-3683612 Forward-Port-Of: odoo/odoo#152817
This update fixes an issue where the 'Secured by' label was hidden for payment methods when the payment_custom or payment_demo modules were installed. The change removes a technical workaround and now correctly displays the payment provider for all payment methods, enhancing transparency and security for users.
Original PR description
If payment_custom or payment_demo is installed 'Secured by' element is overriden and becomes hidden for all payment providers. We removed xpath as it is more convenient for the users to see which provider is behind a payment method. After this commit 'Secured by' element is shown for all providers except for custom. Proper fix is available in master - https://github.com/odoo/odoo/pull/154985 Forward-Port-Of: odoo/odoo#155014
This update corrects a technical issue where translations weren't loading properly in Odoo. The team re-exported missing comments from .pot files, ensuring that translations are correctly identified and displayed for various Odoo add-ons. This improves the user experience for international customers.
Original PR description
odoo-python and odoo-javascript comments in .pot files are used to determine which translations to load. Omitting them would cause the translations not to appear. This commit goes through all .pot files and re-exports the ones where the comments have been omitted. Task-3764933. Enterprise: https://github.com/odoo/enterprise/pull/57361
This update resolves an issue where users lacked the ability to create new records with property fields if they didn't have access to the related parent record. The fix utilizes a temporary 'sudo' call to bypass access restrictions, ensuring all users can now create records with default property values.
Original PR description
When the user creates a new record having a property field, the system fetches the property definition of the parent record to retrieve the field's default values (see: `_add_default_values`). If the user lacks read access on the parent record, the user gets an access error when retrieving the property definition of the parent record. To prevent this error, we will perform a sudo call on the parent record before reading the property definition of the parent record. This allow the user to create a new record, even if they do not have access to the parent record. task-3594814 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154651 Forward-Port-Of: odoo/odoo#146265
This update stops Odoo from automatically sending emails when a validation token is assigned to an order. Previously, this created extra notifications that weren't essential for business operations. This change improves system performance and reduces unnecessary email volume.
Original PR description
Before this commit, validation transactions would send an email when the token is assigned to the order. taskid: 3675875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154650 Forward-Port-Of: odoo/odoo#151773
This update resolves an issue preventing the generation of QR codes on Saudi invoices when submitting multiple documents simultaneously. The problem stemmed from how Odoo calculates computed fields in batch processes, leading to an error when attempting to generate QR codes for related invoices. This fix ensures QR codes are correctly generated for Saudi invoices.
Original PR description
### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * deactivate the "EDI : Perform web services operations" scheduled action. (this will help ease the reproduction process) *…
### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * deactivate the "EDI : Perform web services operations" scheduled action. (this will help ease the reproduction process) * create and post two invoices for a partner that's an individual (not a company) * manually run that scheduled action. You should be met with a traceback. ### Cause When a ZATCA document is submitted, the system performs several operations, two of which are important for this issue: 1. Generating a signature (`l10n_sa_invoice_signature`) 2. Using this signature to generate a QR code (`l10n_sa_qr_code_str`) The QR code generation relies on the assumption that the signature (`l10n_sa_invoice_signature`) already exists, which is a reasonable expectation as the signature is typically created prior to the QR code. However, complications arise when multiple documents are submitted simultaneously in a batch process. During batch processing, each document in the batch undergoes the same two operations mentioned above. The issue emerges due to the behavior of non-stored computed fields. In Odoo, computed fields are evaluated in batches, meaning that if you access a computed field for one record, Odoo may also compute the same field for other records fetched in the same operation. For example, if you have two records, `A` and `B` such that `B.id in A._prefetch_ids`, and you access a computed field on `A`, Odoo will also compute this field for `B` at the same time. This behavior leads to an issue when submitting two documents (`D1` and `D2`) together. The system will generate a signature and then compute the QR code for `D1`. However, when computing the QR code for `D1`, it inadvertently attempts to also compute the QR code for `D2` due to the batch computation behavior. Since `D2`'s signature has not yet been generated at this point, this results in an error. opw-3696146 Forward-Port-Of: odoo/odoo#153810
This update significantly speeds up the opening of the messaging menu in Odoo. By caching key calculations and reducing unnecessary data access, the menu now loads much faster, especially after the initial opening. This enhances the user experience and improves responsiveness.
Original PR description
Slight speed improvement initially, good improvement especially for subsequent openings. See individual commits. On my machine, with populate medium. Duration of the different calls to sort (the most problematic method) during opening: Before: 150ms, 165ms, 141ms After: 118ms, 50ms, 40ms Forward-Port-Of: odoo/odoo#155068
This update fixes a potential issue where changing a company in Odoo could cause problems with existing financial transactions. The change ensures that transactions remain associated with their original company, maintaining data integrity and preventing errors. This improves the stability and reliability of the payment system.
Original PR description
opw-3696841 Forward-Port-Of: odoo/odoo#155113
22 changes
Enhancements to existing features
Customer portal pages now show discounts when they exist, without depending on an internal discount setting. This keeps sales, field service, rental, and subscription customer-facing information aligned with recent sales system changes.
Original PR description
Also avoid relying on the discount group in portal templates, if there is a discount, it should be displayed to the customer (and there probably won't be any if discounts are not enabled).
Point of Sale JavaScript files across several country-specific and hardware-related modules were reformatted to follow shared code quality rules. This supports more consistent maintenance and automated checks without changing business functionality.
Original PR description
In this commit we format all the js files in the pos codebase, such that they respect the eslint config used by the test added in the correspoding community branch. Task 3750944 https://github.com/odoo/odoo/pull/153055
Worksheet templates now link to a single company instead of multiple companies, aligning them with related business records. This makes company-specific worksheet setup clearer and more consistent across field service, maintenance, and quality workflows.
Original PR description
This commit's purpose is to transform the company_ids field on worksheet template to Many2one to be coherent with the other models. task-3450204
Planning emails now include options to add shared shifts or full schedules directly to Google Calendar, iCal, or Outlook. This makes it easier for employees to save work assignments in their personal calendars and reduces missed shifts or manual entry.
Original PR description
This commit add an 'add to calendar' button to the 'planning: new schedule' and 'planning: new shift' email templates If a single shift is shared: - By clicking the 'add to Google Calendar' button…
This commit add an 'add to calendar' button to the 'planning: new schedule' and 'planning: new shift' email templates If a single shift is shared: - By clicking the 'add to Google Calendar' button the user is redirected to a Google Calendar URL that will allow him to create an event for the shift - By clicking the 'Add to iCal/Outlook' button the PlanningController will send a .ics file If a planning is shared: - By clicking the 'add to calendar' button the PlanningController will send a single .ics file with every shift in the planning --- ## Details about the implementation ### In planning module In the *mail_template_data* added the buttons which redirects to the corresponding routes: - for planning.planning: the route _/planning/<string:planning_token>/<string:employee_token>.ics_ will return the ics file - for planning.slot: either the direct google calendar URL generated in the planning.py model file or the route _/slot/<string:access_token>.ics_ which will return the ics file In the *Controller* we add the 2 routes to get the corresponding .ics files this is done by creating vobject.calendar and filing it with the corresponding slot information In the *models/planning.py* we create the method planning.slot.get_calendar_from_slot() to fill the *planning slot* vobject given by the 'planning: new shift' email we also create the method planning.planning.get_calendar_from_slot_data() method to fill the *planning planning* vobject given by the 'planning: new schedule' email Those two method are separated because information about the shifts present inside a *Schedule* are given under a different form than a sum slot_ids (a dictionary generated by the method _planning_get()) so the methods that extract the data from the slots are different for a complete schedule and an alone slot (but are named the same: *get_ics_description* and *get_ics_summary*) get_ics_description simply fetches the slot *allocated percentage* *note* and *role* from the slot to later put it in the vobject.calendar description get_ics_summary gets the *resource* and *role* from the slot to put in the vobject.calendar Title also modified the relativedelta import for style reasons ### In project_forecast module inherits the get_ics_description and adds the project name in the description inherits the get_ics_summary and adds the project name in the title (only for planning.planning) ### In sale_planning module in the *controller* added 'partner_id' fetch in the _planning_get() method Created a new planning_planning.py *model* file just to inherit the two ics_summary and description function to add the Sale Order Item and Partner data. inherits the get_ics_description in the planning_slot.py model file Task-3434542 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
WhatsApp-related Odoo apps are now assigned to the dedicated WhatsApp category instead of being placed under Hidden or Tools. This makes these apps easier to find and manage in the app list without changing their business functionality.
Original PR description
before this commit, for whatsapp modules the module category is set as Hidden/Tools and also there is a new module category introduced in whatsapp module as Whatsapp after this commit, the module category for whatsapp modules will be updated to whatsapp
Restaurant POS users can now send all items from a selected category to preparation at once using a new Send button. This makes kitchen coordination faster and helps teams organize order preparation by product category instead of handling items one by one.
Original PR description
**Before the change:** The control buttons in the POS restaurant module did not have an option to send orders in preparation by category. Users were only able to send individual orders to preparation without categorization. **After the change:** After the modification, a new button labeled "Send" with a fire icon was added to the control buttons. This button allows users to select a ategory and send all products within that category to preparation. This enhancement provides a more efficient way to organize and prepare orders in the point of sale system, improving workflow and order management. https://github.com/odoo/odoo/pull/154754
Restaurant staff can now send order items to preparation in separate batches instead of all at once. This helps teams pace kitchen or bar preparation while keeping batch details internal to orders and preparation tickets, not customer receipts.
Original PR description
Allow user to sent items for preparation in batches, one at a time. Batch are only for internal use, only displayed on the order and on prep tickets, not on receipts.
Portal and guest users in Knowledge will no longer see other guests' email addresses. This improves privacy by limiting access to guest contact details to internal users only.
Original PR description
This commit hides the email adresses of other portal users when one of them is connected. This way we keep a certain level of privacy to guest users as only internal users will now be able to see their email adress. task-3753758
This update aligns online account synchronization with the platform’s newer error handling, so missing records are reported consistently. It reduces internal complexity and helps avoid confusing technical errors reaching business workflows.
Original PR description
The CacheMiss error is removed in the #153822 the business code should only get MissingError task-3043340
GSTR1 validation now better interprets GST Portal responses, making it easier to understand and resolve reported data issues. This helps businesses using Indian GST reports and POS GST reporting reduce time spent investigating unclear validation errors.
Original PR description
… Traceability Before This Commit: Managing Inaccurate Data Responses from GSTR Portal After This Commit: Simplifying Error Resolution by Enhancing Decoding of JSON Responses task: 3428326
Resolved issues and error corrections
The barcode batch transfer screen now hides the Confirm button when the user opens the settings menu. This prevents users from seeing or using an action that does not make sense in that context, making the workflow clearer.
Original PR description
To reproduce issue: .go to barcode app .click on batch transfers .click on new .click on engine icon Expected result: confirm button hide Actual result: confirm button is not hide I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr When a user navigate from batch transfer and click on a engine icon the confirm button still showing, it's no makes sense for the current view. Now, when the user click on it, the confirm button will be hide and apear when close that menu. task-3525776
Localized invoice report customizations are now isolated so they do not interfere with each other when multiple country-specific modules are installed. This reduces the risk of invoice layout errors and improves reliability for businesses operating across localizations.
Original PR description
A lot of localisations inherit the account.report_invoice_document template to include custom changes, but without primary="True". The issue is that the template is updated for every localisation. This can lead to errors when, for instance, multiple localisation xpath replace the same div, add a t-else (resulting in multiple ones in a row),... This commit makes all the inherited templates primary="True" and calls them by inheriting the report_invoice(_with_payments) templates instead. This is still a temporary solution, needed because of an issue with the editing in Studio. see odoo/odoo#106776 task id=3100225
Code cleanup and technical improvements
List views in reporting, spreadsheets, and Studio now update their visible columns more reliably when related field values change. This reduces the chance that users see outdated or incorrectly hidden columns after data changes.
Original PR description
*account_reports,spreadsheet_edition,web_studio This commit is the counterpart of odoo/odoo#153998, where we stop computing list's columns in onWillUpdateProps. Using this hook is often a mistake, as it is only called when the component is re-rendered via a parent. With the fine-grained reactivity, it may happen that the renderer is re-rendered directly (e.g. because it is subscribed to a reactive object that changes). In this case, onWillUpdateProps isn't called, so we don't recompute the columns. Before this commit, this doesn't seem to be possible, but by removing the evalViewModifier props, which is the other change done by this commit, the problem occurs: if a column has a conditional column_invisible attribute, and a field used to evaluate the expression changes, the renderer is re-rendered, as it is the one who is subscribed, whereas before it was the parent (the one defining evalViewModifier). Preliminary ref for task 3649970
Task forms and shared task forms now use a common structure, reducing duplicate setup and making future updates easier to manage. The shared task view also gains fields and behavior that were previously only available in the regular task view, creating a more consistent experience.
Original PR description
Before this commit project task and project sharing task form views were quit slimier but so different because both views contains their different code and because of that if we want do something on both of those views then we have to write same code twice so sometimes its hard to keep trace of what we need in both place and what we need in only one place also there is lots of redundant code because we need same thing in both places. This commit Make a common view which contains common data which we need both side and use this view in both places and while doing that also found some things that should be in sharing so this change will add all things we need in project sharing task form view. task-3231686
Miscellaneous changes
The aim of this commit is making sure that we don't have inconstancies between the `GROUP BY` in the `_build_query_group` and the intrastat report line generic id. Indeed, before this commit, the `incoterm code`, the transport code and the `invoice_currency_id` were not included in the generic id. It means that we can have several lines with the same generic id but with different values (for example incoterm code). This commit adds a test that check that all elements in the `GROUP BY`
Original PR description
The aim of this commit is making sure that we don't have inconstancies between the `GROUP BY` in the `_build_query_group` and the intrastat report line generic id. Indeed, before this commit, the `incoterm code`, the transport code and the `invoice_currency_id` were not included in the generic id. It means that we can have several lines with the same generic id but with different values (for example incoterm code). This commit adds a test that check that all elements in the `GROUP BY` (except the `system`, type and` region code`) are used in the generation of the generic id. For the excepted keys, `system` and `type` are already separated. Concerning the `region_code`, its value related to the company, it means that this value is not discriminant. opw-3741658 Forward-Port-Of: odoo/enterprise#57180 Forward-Port-Of: odoo/enterprise#57097
Steps to reproduce: - Create a monthly subscription for a customer with a quantity of 1 - Make an invoice and confirm it - Upsell with 2 quantity - Click on preview in new SO - Total quantity is 5 Issue: Total quantity should be 3 opw-3698971 Forward-Port-Of: odoo/enterprise#55329
Original PR description
Steps to reproduce: - Create a monthly subscription for a customer with a quantity of 1 - Make an invoice and confirm it - Upsell with 2 quantity - Click on preview in new SO - Total quantity is 5 Issue: Total quantity should be 3 opw-3698971 Forward-Port-Of: odoo/enterprise#55329
Starting October 2, 2023, SP-API no longer requires the use of AWS Identity and Access Management (IAM) or AWS Signature Version 4, which means ce don't need to sign SP-API requests with AWS Signature Version 4. At first, this change was just a deprecation. But the SPAPI will now ensure this signature isn't present anymore. task-3534880 Forward-Port-Of: odoo/enterprise#57033 Forward-Port-Of: odoo/enterprise#53839 See also: https://github.com/odoo/upgrade/pull/5723
Original PR description
Starting October 2, 2023, SP-API no longer requires the use of AWS Identity and Access Management (IAM) or AWS Signature Version 4, which means ce don't need to sign SP-API requests with AWS Signature Version 4. At first, this change was just a deprecation. But the SPAPI will now ensure this signature isn't present anymore. task-3534880 Forward-Port-Of: odoo/enterprise#57033 Forward-Port-Of: odoo/enterprise#53839 See also: https://github.com/odoo/upgrade/pull/5723
To reproduce: ============= - On a fresh database without demo data, install the timesheet_grid module - Create new user demo with following settings: - Project: User - Timesheet: User : all timesheets - Connect as demo and go to timesheet - Timesheets > All Timesheets - On list view Delete the Admin's "Internal" timesheets - Refresh > Timesheets > All Timesheets -> Receive error Problem: ======= The timesheet_grid module makes ORM calls with sample data, that don't exist in th
Original PR description
To reproduce: ============= - On a fresh database without demo data, install the timesheet_grid module - Create new user demo with following settings: - Project: User - Timesheet: User : all timesheets - Connect as demo and go to timesheet - Timesheets > All Timesheets - On list view Delete the Admin's "Internal" timesheets - Refresh > Timesheets > All Timesheets -> Receive error Problem: ======= The timesheet_grid module makes ORM calls with sample data, that don't exist in the database. Solution: ========= The timesheet_grid module should not make ORM calls with sample data. opw-3747297 Forward-Port-Of: odoo/enterprise#57025
When we copy activities, we should also copy their mailings, otherwise when we run campaign it cancels emails. task-3465452 Forward-Port-Of: odoo/enterprise#54418
Original PR description
When we copy activities, we should also copy their mailings, otherwise when we run campaign it cancels emails. task-3465452 Forward-Port-Of: odoo/enterprise#54418
Before this commit user was getting traceback on unselecting all measures in pivot view on mobile. Steps to reproduce: - switch to mobile view. - open the pivot view of any report (tested with the 'tasks analysis' one here). - unselect all measures, the traceback will appear. Observed behavior: a traceback is generated. Expected behavior: no traceback, the action helper is displayed After this commit user will not get traceback on unselecting all measures in pivot view on mobil
Original PR description
Before this commit user was getting traceback on unselecting all measures in pivot view on mobile. Steps to reproduce: - switch to mobile view. - open the pivot view of any report (tested with the 'tasks analysis' one here). - unselect all measures, the traceback will appear. Observed behavior: a traceback is generated. Expected behavior: no traceback, the action helper is displayed After this commit user will not get traceback on unselecting all measures in pivot view on mobile. Instead of that an action helper will be displayed. Task-3630703 Forward-Port-Of: odoo/enterprise#54051
Steps to reproduce: Make a delivery operation from the United States to Canada or Puerto Rico. Attept to validate the delivery. A traceback appears: ``` File "/home/odoo/src/enterprise/delivery_ups_rest/models/delivery_ups.py", line 154, in ups_rest_send_shipping result = ups._send_shipping( File "/home/odoo/src/enterprise/delivery_ups_rest/models/ups_request.py", line 406, in _send_shipping request['Shipment']['InvoiceLineTotal'] = { KeyError: 'Shipment' ``` To fix the issue we nee
Original PR description
Steps to reproduce:
Make a delivery operation from the United States to Canada or Puerto Rico. Attept to validate the delivery. A traceback appears:
```
File "/home/odoo/src/enterprise/delivery_ups_rest/models/delivery_ups.py", line 154, in ups_rest_send_shipping
result = ups._send_shipping(
File "/home/odoo/src/enterprise/delivery_ups_rest/models/ups_request.py", line 406, in _send_shipping
request['Shipment']['InvoiceLineTotal'] = {
KeyError: 'Shipment'
```
To fix the issue we need to access `request['ShipmentRequest']['Shipment']` instead of `request['Shipment']`.
opw-3710939
Forward-Port-Of: odoo/enterprise#56891The aim of this commit is handling properly intrastat fields in product template. In this commit (https://github.com/odoo/enterprise/commit/175615a7d715d790e9ba5b0addbde1b964164d5d), we change related fields to computed ones but we forgot to add inverse function to handle the case where users want to modify their `product.template` instead of their `product.product`. opw-3755024 opw-3755048 opw-3755048 Forward-Port-Of: odoo/enterprise#57131
Original PR description
The aim of this commit is handling properly intrastat fields in product template. In this commit (https://github.com/odoo/enterprise/commit/175615a7d715d790e9ba5b0addbde1b964164d5d), we change related fields to computed ones but we forgot to add inverse function to handle the case where users want to modify their `product.template` instead of their `product.product`. opw-3755024 opw-3755048 opw-3755048 Forward-Port-Of: odoo/enterprise#57131
45 changes
Enhancements to existing features
This update migrates and completes German language translations across localization modules that were reorganized after version 15.0. German localization features were consolidated into shared DIN5008 modules to serve multiple countries more efficiently. The translation updates ensure all modules have complete and accurate German language support.
Original PR description
*datev_reports,pos_cert,pos_res_cert,reports After 15.0, part of the German localization modules have been moved to the DIN5008 modules to be shared with other countries. We migrate the translations here to the correct modules in the versions after 15.0 and complete missing ones. opw-3669388 Related to https://github.com/odoo/odoo/pull/153845 Forward-Port-Of: odoo/enterprise#57158 Forward-Port-Of: odoo/enterprise#56503
This update improves the workflow for creating Service Order Lines (SOLs) directly from helpdesk tickets. Previously, users could only use the "Create and Edit" option, which required additional steps. Now users can quickly create SOLs with a streamlined quick create option, saving time and reducing friction in the ticket-to-sales process.
Original PR description
When creating SOLs on the fly for tickets, only the "Create and Edit" option is available. This PR enables the quick create for SOLs on tickets. Community: https://github.com/odoo/odoo/pull/142720 Task-3553151 Forward-Port-Of: odoo/enterprise#53833
This update improves the user experience of the individual account feature in Belgian payroll processing. The changes streamline the interface and reporting for employees viewing their payroll information, making it easier to access and understand their account details.
Original PR description
TaskID: 3762935
This update reorganizes and completes German language translations across localization modules. After version 15.0, German localization features were consolidated into shared DIN5008 modules to serve multiple countries more efficiently. This change migrates and fills in missing translations to ensure all modules have complete language support in the correct locations.
Original PR description
*de,de_skr03,de_skr04,din5008,din5008_purchase,din5008_repair,din5008_sale,din5008_stock After 15.0, part of the German localization modules have been moved to the DIN5008 modules to be shared with other countries. We migrate the translations here to the correct modules in the versions after 15.0 and complete missing ones. opw-3669388 Related to https://github.com/odoo/enterprise/pull/56503 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154915 Forward-Port-Of: odoo/odoo#153845
This update improves the speed of opening the messaging menu in Odoo by optimizing how the system calculates and accesses message information. The changes reduce unnecessary repeated calculations and data access operations, resulting in faster menu load times—especially noticeable when opening the menu multiple times. Users will experience a smoother, more responsive messaging experience.
Original PR description
Slight speed improvement initially, good improvement especially for subsequent openings. See individual commits. On my machine, with populate medium. Duration of the different calls to sort (the most problematic method) during opening: Before: 150ms, 165ms, 141ms After: 118ms, 50ms, 40ms
This update adds comprehensive testing for dropdown menus and submenus in the web interface to ensure they function correctly across all versions. By backporting this test from a recent improvement, the team ensures consistent quality and reliability of menu interactions for all users.
Original PR description
This commit backports the test introduced in odoo/odoo#155154, as it is relevant to have it in every versions to ensure that dropdown menu (i.e. submenus) are correctly tested. 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#155156
This update prevents the system from sending emails when payment validation transactions are processed and tokens are assigned to orders. This reduces unnecessary email notifications to customers and improves the overall email communication experience by only sending relevant transactional emails.
Original PR description
Before this commit, validation transactions would send an email when the token is assigned to the order. taskid: 3675875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154650 Forward-Port-Of: odoo/odoo#151773
Resolved issues and error corrections
This update corrects the spacing and alignment of form fields in the Frontdesk Drinks section. Previously, an image field was causing misalignment of input fields relative to their labels. The fix adjusts the spacing settings to ensure all form elements line up properly, improving the visual consistency and usability of the form.
Original PR description
The o_field_image in the Drinks in the form view is cancelling the negative margin applied by the row class on the o_group. Using a gutter-x 0 on the o_group removes the padding allowing the inputs to be aligned with the title. This is a quickfix and the behavior of the o_field_image in a form view should be reviewed consistently across Odoo because different module seems to use their own fix for this (Ref: new task-3584778) task-3584529 | Before | | :--: | |  | After | |  |
This update resolves critical issues in the India payroll system that were causing calculation failures. The fix corrects how gross salary is calculated and updates the rules for salary attachments and assignments, ensuring payroll processes run smoothly without errors.
Original PR description
- A traceback was caused because the gross variable was not defined correctly. - Revise the Python condition 'Attachment of Salary' and 'Assignment of Salary' for the salary rules **Note**: The upgrade script is not needed because the data file is noupdate="0". task-3649463
This fix resolves an issue where orders synchronized from Amazon's Fulfillment by Amazon (FBA) service were creating incomplete stock movements. The system now correctly marks these stock movements as completed when products are delivered by Amazon, ensuring accurate inventory tracking and order fulfillment records.
Original PR description
Currently, synchronizing done order in FBA creates some stock move that are not in the state done anymore. This is due to some changes in the management of the quantity done in stock, that needs to see if the quantity was picked or not. As, in this case, we are confirming a move for products that were stocked in an Amazon Warehouse and then delivered by Amazon, we can manually set the move as being picked. opw-3594556 opw-3662990
This fix prevents subscription email templates from being reset to default values when the sales subscription module is upgraded. By marking these templates as protected during updates, customizations made to subscription emails will now be preserved, ensuring consistent communication with customers across system upgrades.
Original PR description
Fixes that sale_subscription mail templates is reverted on module upgrade When upgrading the sale_subscription module all subscription email templates was reverted due to missing noupdate=1
Fixed issues with Shiprocket delivery integration where long warehouse or company names caused validation errors. The system now automatically truncates names to 36 characters as required by Shiprocket, and prevents delivery orders from being validated when the Shiprocket server is unreachable, improving reliability and user experience.
Original PR description
Before this commit: ================================ - When we use a longer warehouse address name or company name, the shiprocket will return an error message with `The vendor details / pick up location cannot be longer than 36 characters.` After this commit: ================================ - It will only take 36 characters if the warehouse address name or company name is longer than 36 characters while validating the delivery order. - `Cannot reach the server. Please try again later.` - If shiprocket returns this error, the delivery order should not be validated. task-3650073 Forward-Port-Of: odoo/enterprise#53507
This update fixes several issues with the Belgian CodaBox bank connection feature. The main improvements include preventing accidental disconnection when using deprecated functions, improving user-facing terminology for clarity, and ensuring bank files are correctly matched to the right currency accounts. These fixes help users with multiple accounts in different currencies avoid importing transactions to the wrong journal.
Original PR description
task-id 3755037 Documentation PR https://github.com/odoo/documentation/pull/7840
This update fixes an issue where intrastat report lines could have duplicate identifiers despite having different details like incoterm codes, transport methods, or currencies. The fix ensures all relevant transaction details are included in the line identifier so each unique combination is properly tracked and reported separately.
Original PR description
The aim of this commit is making sure that we don't have inconstancies between the `GROUP BY` in the `_build_query_group` and the intrastat report line generic id. Indeed, before this commit, the `incoterm code`, the transport code and the `invoice_currency_id` were not included in the generic id. It means that we can have several lines with the same generic id but with different values (for example incoterm code). This commit adds a test that check that all elements in the `GROUP BY` (except the `system`, type and` region code`) are used in the generation of the generic id. For the excepted keys, `system` and `type` are already separated. Concerning the `region_code`, its value related to the company, it means that this value is not discriminant. opw-3741658 Forward-Port-Of: odoo/enterprise#57180 Forward-Port-Of: odoo/enterprise#57097
This update fixes a bug where users would encounter an error when deselecting all measures in pivot view reports on mobile devices. Instead of showing an error, the system now properly displays a helpful message, improving the mobile user experience for report analysis.
Original PR description
Before this commit user was getting traceback on unselecting all measures in pivot view on mobile. Steps to reproduce: - switch to mobile view. - open the pivot view of any report (tested with the 'tasks analysis' one here). - unselect all measures, the traceback will appear. Observed behavior: a traceback is generated. Expected behavior: no traceback, the action helper is displayed After this commit user will not get traceback on unselecting all measures in pivot view on mobile. Instead of that an action helper will be displayed. Task-3630703 Forward-Port-Of: odoo/enterprise#54051
This update removes two unnecessary guided tours from the accounting module that were providing redundant or confusing user guidance. The tours were creating sample bills and displaying unhelpful instruction bubbles that didn't add value to the user experience. This cleanup helps streamline the application and reduce maintenance burden.
Original PR description
The file `test_ui` is currently not imported. The tour is pretty useless and has been improved in 17.0. We will keep it in that version, to be sure that we don't break the equivalent tour, but we can remove in these versions (it just creates a sample bill and post it, currently). The tour `account_accountant_tour_upload_ocr_step` has been deemed useless. It pops a bubble on a button where it makes no sense, with a self-explanatory message already. Forward-Port-Of: odoo/enterprise#57120 Forward-Port-Of: odoo/enterprise#56726
This fix resolves a critical error that occurred when validating shipments to Canada or Puerto Rico through the UPS delivery integration. The system was looking for shipping information in the wrong location, causing the validation to fail. With this correction, users can now successfully validate and process international deliveries to these destinations.
Original PR description
Steps to reproduce:
Make a delivery operation from the United States to Canada or Puerto Rico. Attept to validate the delivery. A traceback appears:
```
File "/home/odoo/src/enterprise/delivery_ups_rest/models/delivery_ups.py", line 154, in ups_rest_send_shipping
result = ups._send_shipping(
File "/home/odoo/src/enterprise/delivery_ups_rest/models/ups_request.py", line 406, in _send_shipping
request['Shipment']['InvoiceLineTotal'] = {
KeyError: 'Shipment'
```
To fix the issue we need to access `request['ShipmentRequest']['Shipment']` instead of `request['Shipment']`.
opw-3710939
Forward-Port-Of: odoo/enterprise#56891Fixed a bug where employees appeared available for appointments even when they had calendar events that spanned across timezone boundaries. When events were created in certain timezones (like Brussels), they could be stored in UTC on a different day, causing the appointment system to incorrectly show the employee as available. The fix now properly checks for overlapping events across day boundaries to ensure accurate availability.
Original PR description
Current behaviour: --- When an employee places an event on a certain day starting at 00:15 to 18:00 on a brussels TZ, the event is stored on the UTC TZ, so starting the day before at 23:15 to 17:00.…
Current behaviour: --- When an employee places an event on a certain day starting at 00:15 to 18:00 on a brussels TZ, the event is stored on the UTC TZ, so starting the day before at 23:15 to 17:00. This behavior shows the employee as available. Expected behaviour: --- The employee should not be available even if the event start on another day. Steps to reproduce: --- 1. Employee and db has a Brussels TZ 2. Go to Calendar 3. Add an event when employee is available 4. Event starts at 00:15 and ends at 18:00 5. Go to website > Appointment 6. Select Mitchell Admin 7. Look at the date, should be unavailable 8. => Still available Cause of the issue: --- https://github.com/odoo/enterprise/blob/d6135811316837d6523e59163739fc9b954be2e6/appointment/models/calendar_appointment_type.py#L295 If the event starts on another day than the slot, it isn't taken into account. Fix: --- Adding events from yesterday and tomorrow to know if they overlap with the slot opw-3599209 Co-authored-by: Boulif Nasreddin <bon@odoo.com> Forward-Port-Of: odoo/enterprise#57284 Forward-Port-Of: odoo/enterprise#52935
This update fixes how appointment availability is calculated for resources by implementing a default calendar that covers all hours of every day. Previously, when a resource's custom calendar was removed, the system would incorrectly fall back to the company's working schedule, causing confusing availability windows for users. The fix also improves the leave management interface by making the resource field required and hiding irrelevant calendar options.
Original PR description
Add and use a default resource calendar encompassing every hours of every days. This allows to take into account leaves for resource easily as we need a resource calendar for the computation. Indeed when the resource calendar was removed, the one set on the company was used in place which led to weird result for the end user as he didn't expect a working schedule after removing the one set on the resource. task-3562191 Forward-Port-Of: odoo/enterprise#56617
This update prevents the snailmail account followup feature from being automatically activated when the module is installed. Since this feature incurs additional costs, it will now require explicit user activation rather than being enabled by default, helping avoid unexpected charges.
Original PR description
The module is auto-installed, and activating its feature is paying, so not desired. [opw-3180544](https://www.odoo.com/web#id=3180544&model=project.task) Forward-Port-Of: odoo/enterprise#40219
The VAT units menu in the accounting reports module was difficult for users to locate because it was hidden in the configuration menu and only accessible in debug mode. This update makes the menu more discoverable and accessible, improving the user experience for teams managing VAT reporting.
Original PR description
Our users, even our best trained colleagues, don't find the `VAT units` menu. It's too hidden in the configuration menu and in debug mode. this commit makes it discoverable. task-3746523 Forward-Port-Of: odoo/enterprise#56765
This fix corrects how SEPA payment files are generated for Swiss bank accounts. A previous attempt to exclude a specific payment service level (NURG) in Switzerland had a logic error that wasn't caught by testing. The fix simplifies the condition to properly exclude this service level only in Switzerland, ensuring Swiss payments are formatted correctly while other countries remain unaffected.
Original PR description
https://github.com/odoo/enterprise/commit/3479940bf8ba5b0efcc5ce9e10a07e30af1d6f87 intended to fix the conditions under which this node appears in the file, but it was wrong. The functional testing missed this, as the sepa_pain_version field got recomputed when updating the account code; so, checking the pain version was indeed the Swiss one, then modifying the account and putting and IBAN recomputed the pain version to 'Generic', hence compromising the test. The condition can actually be made simpler: we want the SvcLvl everywhere but in Switzerland. Forward-Port-Of: odoo/enterprise#57164 Forward-Port-Of: odoo/enterprise#57104
When customers add optional products to a rental item, the rental duration was not displaying correctly in the cart, even though the price was accurate. This fix ensures that rental duration information is properly shown for all optional products by updating the template structure to include the necessary parent element for the rental details display.
Original PR description
Steps to reproduce: - Install eCommerce Rental module - For a rentable product add an optional product - Now go to the shop and to the rentable product - Select the rental period to a week for exemple - Click on "add to cart" Issues: The price is right but the duration displayed is wrong. Solution: The info are updated by this code: https://github.com/odoo/enterprise/blob/7172d0cd24dbfd9efcb01a793b8e30b797159903/website_sale_renting/static/src/js/variant_mixin.js#L44-L46. Since we didn't have the o_renting_details parent the code couldn't put the right info. opw-3730055 Forward-Port-Of: odoo/enterprise#56715
This update ensures that all sublines in intrastat reports have unique identifiers, just like the main report lines. The fix applies additional identifying values to sublines so they can be properly distinguished from one another in the system, preventing potential data confusion or reporting errors.
Original PR description
In this commit (https://github.com/odoo/enterprise/commit/0f31f77665b10ac85396ed890786f630401f0503), we ensure that generic report line ids are unique by using all discriminant values. This commit ads these discriminant values in the where to make sure that sublines have unique ID as well. no task id Forward-Port-Of: odoo/enterprise#57343 Forward-Port-Of: odoo/enterprise#57256
This update corrects an XML identifier in the Belgian CodaBox Bridge configuration settings module. The fix ensures that the system properly recognizes and references the correct configuration element, preventing potential issues with the bank connection setup process for Belgian users.
This fix resolves a crash that occurred when users tried to verify a partner's Peppol endpoint through the Actions menu. The system was incorrectly returning a boolean value instead of a proper action, causing an error. Now the verification process works correctly and either performs the action or returns nothing as expected.
Original PR description
### Steps to reproduce * install `account_peppol` * open a partner's list view * select a contact * on the top middle, click Actions > Verify Peppol You should be met with a traceback: `AttributeError: 'bool' object has no attribute 'setdefault'` ### Cause `button_account_peppol_check_partner_endpoint` is expected to return an action or a falsy value (no action to perform). opw-3683612
This update removes two payment method options that were not functioning properly: Amazon Pay with Adyen and BLIK with Stripe. These combinations are being discontinued because they either require complex setup processes that don't justify their value or are not supported by the payment provider's current technical capabilities. This cleanup simplifies the payment options available to users.
Original PR description
The following combinations of payment methods and providers are removed: - Amazon Pay - Adyen: The payment method cannot be activated because it requires saving a public key in Odoo, and no field was made available for that. Also, a custom configuration is necessary and the public key must be generated through a lengthy process that is too cumbersome for the added value of the payment method anyway. - BLIK - Stripe: The payment method is not supported by Stripe when the PaymentIntent object is created after collecting the payment details. See https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=payment#enable-payment-methods opw-3736511
Fixed an issue where payment terms were displaying only in English twice instead of showing the correct language translation. When creating invoices for Saudi Arabian companies with payment terms configured in both English and Arabic, the system now properly displays the translated payment terms based on the user's language preference.
Original PR description
Have a SA company In Accounting settings activate invoice terms Add a payment terms string in english, add the arabic translation Create an invoice Click preview Issue: Payment terms will be shown in english twice This occurs because, even if `narration` field is translatable the translation is not automatically copied when the field is copied from the company `invoice_terms`. opw-3530811 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153139 Forward-Port-Of: odoo/odoo#138949
This update corrects a technical issue in how the system calculates accounting entries related to inventory movements. The fix ensures that financial data is properly processed when recording stock transactions, improving the accuracy of accounting records.
Original PR description
This commit fixes summing list of dicts returned by _prepare_analytic_lines. NB: This code is not yet covered by a test use case. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152819
This fix improves the efficiency of how activity deadline information is retrieved in the mail system. Previously, the system was loading deadline data inefficiently one record at a time. The update now batches these reads together, reducing the number of database queries and improving overall system performance when working with activities and calendar features.
Original PR description
`__getitem__()` of BaseModel, reset the prefetch set of the recordset. Fix _compute_activity_date_deadline, to batched the reading of activity's deadline. Forward-Port-Of: odoo/odoo#154728 Forward-Port-Of: odoo/odoo#154159
This update ensures that only active internal users can be assigned to project tasks. The change improves data quality and security by preventing external or inactive users from being selected as task assignees. The restriction is now enforced at the system level rather than just in the user interface.
Original PR description
decided to add the domain condition in the project.task user_ids field definition, which means we can remove identical domains in views Added empty domains where we could want to add external/inactive user to project.task Task-3698867 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150710
This fix restores the 'Secured by' payment provider information that was being hidden when certain payment modules were installed. Users will now see which payment provider is processing their transaction, improving transparency and trust in the checkout process.
Original PR description
If payment_custom or payment_demo is installed 'Secured by' element is overriden and becomes hidden for all payment providers. We removed xpath as it is more convenient for the users to see which provider is behind a payment method. After this commit 'Secured by' element is shown for all providers except for custom. Proper fix is available in master - https://github.com/odoo/odoo/pull/154985
This release includes multiple bug fixes and improvements across accounting, inventory, HR, and e-commerce modules. Key improvements include fixing duplicate bill warnings in accounting, correcting event booth counts in sales, adding Italian tax ID support for checkout, and resolving various operational issues in inventory and expense management. These changes enhance system reliability and user experience across multiple business functions.
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
When messages are posted, the system now correctly identifies which conversation thread needs its pin state updated. Previously, the notification was missing the thread model information, causing pin states to not update properly. This fix ensures users see accurate pin status for their conversations.
Original PR description
When a message is posted, the server sends a `mail.record/insert` notification to update the related channel pin state. In order to recognize the thread, the client needs its id and its model. Currently, only the id is passed so the thread pin state is not updated. This PR adds the model to the notification.
The text editor's "clear format" button now completely removes all styling (background color, text color, and other formatting) from selected text. Previously, some color styles were not being fully removed, which could leave unwanted formatting behind.
Original PR description
**Before this PR:** When using the removeFormat button, the backgroundColor and foregroundColor were not completely removed. **After this PR:** The removeFormat button will completely remove all the styles applied to it. **task-3344762** Forward-Port-Of: odoo/odoo#130670
This fix corrects an issue where the system was not properly matching customer states to their selected countries when processing address information. The system now first looks for the correct state based on both the country and state code, and falls back to searching by state code alone if needed. This ensures customer address data is accurately captured and prevents data loss during the address processing.
Original PR description
- Before this commit, `_include_country_and_state_in_address` finding state is not respect the country. - So fix by find state by country and code first. If there is no state, we will find state by code to avoid losing data. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from changing a payment provider's company when transactions have already been processed. This protects data integrity by ensuring that payment records remain properly associated with their original company, avoiding potential accounting and reconciliation issues.
Original PR description
opw-3696841
This fix removes unnecessary warning messages that appeared in system logs after importing modules. The system was incorrectly trying to update its internal module tracking graph for imported modules, which doesn't apply to them. This change cleans up the logs and reduces confusion for system administrators.
Original PR description
Before this PR, after having imported a module, a warning appears in the log, because it tries to update the graph which does not make sense for an imported module. This commit makes sure the warning is skipped if the module was imported. This commit can be backported to previous versions, if useful.
This fix resolves an issue where product selections made in loyalty program rules were being cleared when saving the program. Users can now select products in the rule's 'Products' field before saving the loyalty program, and those selections will be preserved instead of being lost.
Original PR description
**Current behavior:** Creating a promo type loyalty program and editing the 'products' field in the 'Among' section of the rule created by default at the bottom of the form view before saving the…
**Current behavior:**
Creating a promo type loyalty program and editing the
'products' field in the 'Among' section of the rule created by
default at the bottom of the form view before saving the
program will cause the products selected in this field to be
cleared upon saving the program.
**Expected behavior:**
Filling out this field of the default rule before saving the
overarching loyalty program should result in the same behavior
as doing so after saving the program. That is, the field should
save the user's input.
**Steps to reproduce:**
1. Create a new loyalty program in the Discount & Loyalty tab
2. Give it a name and, before saving the program, edit the
'Products' field of the default rule that is created at
the bottom of the form to have at least one value
3. Now save the program and observe that the 'Products' field
has been cleared of the previously selected values
**Cause of the issue:**
In the form view for the loyalty.program there are two
instances of the field trigger_product_ids which are set to be
invisible unless creating a specific program type. This field
is set to be related to rule_ids.product_ids in its definition
within the loyalty.program class definition. Thus, when the
user saves the program and rule concurrently, the empty
trigger_product_ids field overwrites the product_ids field
and whatever the user had populated it with is cleared.
The reason it only happens to the default rule and not ones
which are manually added before saving the program is because
in the traverse_related() method in fields.py, only the first
record of the related field is returned to be modified. In this
case, it means only the first rule's product_ids field is
overwritten.
**Fix:**
Overwrite the create() method in program.loyalty and check if
the program being created is of type 'gift_card' or 'ewallet'
then, if so, delete the trigger_product_ids key,val from the
dictionary so it will not later override the products specified
in the loyalty rule.
opw-3669953
Forward-Port-Of: odoo/odoo#150418This fix resolves a critical error that occurred when previewing draft invoices with multi-line payment terms. The issue prevented users from viewing invoices when payment terms included multiple installment lines without early payment discounts. The fix ensures the system properly handles these payment term configurations.
Original PR description
Description of the issue this PR addresses: --- On obtains a 500: Internal Server Error when creating an invoice with a 2 lines payment term. Error while rendering the template…
Description of the issue this PR addresses: --- On obtains a 500: Internal Server Error when creating an invoice with a 2 lines payment term. Error while rendering the template "account.report_invoice_document". Steps to reproduce: --- - Accounting > Configuration > invoicing > Payment Terms - New > Create and save a payment term with 2 lines: - name 80/20 test - line_1 : 80% after 0 days - line_2 : 20% after 30 days - Sales > Orders > Quotations - Chose any > use payment terms 80/20 test - Save and create associated invoice > chose regular invoice - Create draft invoice > preview > 500: Internal Server Error Cause of the issue: --- The method "_get_amount_due_after_discount" called during the rendering of the template does not return a value in case self.early_discount is False. Fix: --- Return total_amount by default since no discount is applied. opw-3683708 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149934
This fix resolves a critical issue that prevented Odoo from starting up during system updates. When removing accounting report expressions, the system now properly cleans up related external values, preventing database constraint violations that would crash the upgrade process.
Original PR description
Cascade removal of account.report.expression records to corresponding account.report.external.value, avoiding the following issue when upgrading: ``` Traceback (most recent call last): File…
Cascade removal of account.report.expression records to corresponding account.report.external.value, avoiding the following issue when upgrading:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1302, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 536, in load_modules
env['ir.model.data']._process_end(processed_modules)
File "/tmp/tmpwrjjshgf/migrations/base/0.0.0/pre-models-no-model-data-delete.py", line 103, in _process_end
return super(IrModelData, self)._process_end(modules)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2562, in _process_end
self._process_end_unlink_record(record)
File "/home/odoo/src/odoo/17.0/addons/website/models/ir_model_data.py", line 36, in _process_end_unlink_record
return super()._process_end_unlink_record(record)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2491, in _process_end_unlink_record
record.unlink()
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4218, in unlink
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.ForeignKeyViolation: update or delete on table "account_report_expression" violates foreign key constraint "account_report_external_value_target_report_expression_id_fkey" on table "account_report_external_value"
DETAIL: Key (id)=(94) is still referenced from table "account_report_external_value".
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#154191This update improves the user experience when creating sales order lines by eliminating unnecessary form popups. When users quickly create a sales order line with a name matching an existing product, the system now completes the action immediately instead of opening an edit form. This makes the workflow faster and more intuitive for sales teams managing projects.
Original PR description
When creating a SOL on the fly, if the name entered matches an existing service product, selecting 'Create' should create the SOL without opening a form view modal. We do that by fetching the `default_name` from the context. However, from the Many2one field, since the name will already be present in the create vals, in will not be in the default values in the context. To fix this, this PR adds a new context key when calling `name_create` that allows us to retrieve the name from the `default_get` Enterprise: https://github.com/odoo/enterprise/pull/53833 Task-3553151 Forward-Port-Of: odoo/odoo#142720
This fix resolves an issue where users couldn't create new records with property fields if they lacked read access to the parent record. The system now uses elevated permissions to fetch the parent record's property definitions, allowing users to create records with default values even when they can't directly access the parent record.
Original PR description
When the user creates a new record having a property field, the system fetches the property definition of the parent record to retrieve the field's default values (see: `_add_default_values`). If the user lacks read access on the parent record, the user gets an access error when retrieving the property definition of the parent record. To prevent this error, we will perform a sudo call on the parent record before reading the property definition of the parent record. This allow the user to create a new record, even if they do not have access to the parent record. task-3594814 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154651 Forward-Port-Of: odoo/odoo#146265
This fix resolves an issue where batch processing of multiple Saudi invoices would fail when generating QR codes. The problem occurred because the system attempted to generate QR codes for invoices that hadn't yet been signed, causing errors during automated EDI submission. The fix ensures QR codes are only generated for invoices that have already been signed.
Original PR description
### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * deactivate the "EDI : Perform web services operations" scheduled action. (this will help ease the reproduction process) *…
### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * deactivate the "EDI : Perform web services operations" scheduled action. (this will help ease the reproduction process) * create and post two invoices for a partner that's an individual (not a company) * manually run that scheduled action. You should be met with a traceback. ### Cause When a ZATCA document is submitted, the system performs several operations, two of which are important for this issue: 1. Generating a signature (`l10n_sa_invoice_signature`) 2. Using this signature to generate a QR code (`l10n_sa_qr_code_str`) The QR code generation relies on the assumption that the signature (`l10n_sa_invoice_signature`) already exists, which is a reasonable expectation as the signature is typically created prior to the QR code. However, complications arise when multiple documents are submitted simultaneously in a batch process. During batch processing, each document in the batch undergoes the same two operations mentioned above. The issue emerges due to the behavior of non-stored computed fields. In Odoo, computed fields are evaluated in batches, meaning that if you access a computed field for one record, Odoo may also compute the same field for other records fetched in the same operation. For example, if you have two records, `A` and `B` such that `B.id in A._prefetch_ids`, and you access a computed field on `A`, Odoo will also compute this field for `B` at the same time. This behavior leads to an issue when submitting two documents (`D1` and `D2`) together. The system will generate a signature and then compute the QR code for `D1`. However, when computing the QR code for `D1`, it inadvertently attempts to also compute the QR code for `D2` due to the batch computation behavior. Since `D2`'s signature has not yet been generated at this point, this results in an error. opw-3696146 Forward-Port-Of: odoo/odoo#153810
Code cleanup and technical improvements
The manufacturing unbuild process has been restructured to make it easier for developers to customize and extend. Previously, adding new parameters to unbuild operations required completely rewriting the entire function. Now developers can make targeted modifications to specific parts of the process, reducing complexity and maintenance burden.
Original PR description
With the current design, when we want to pass more parameters from the original move lines of MO to the unbuild move lines, we can't easily extend action_unbuild() and it seems we need to completely override it. After this refactoring commit, developers can easily extend and add more parameters. @qrtl --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151983