Daily updates from Odoo
Navigate
Branch
Friday, September 20, 2024
56 changes
18 changes
Enhancements to existing features
This update improves Hoot, Odoo’s internal automated testing framework, so tests better reflect real browser behavior and are easier to maintain. It also switches the main web test route to the newer test suite while keeping legacy tests available, reducing risk by limiting changes to the testing ecosystem.
Original PR description
## Pull Request HOOT (PRHOOT) - part 23 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 23 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Enterprise: https://github.com/odoo/enterprise/pull/69728 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The Point of Sale product information popup now reads the cashier role from the correct place after a page refresh. This prevents an error for employee logins with administrator PoS access, allowing staff to continue viewing product details normally.
Original PR description
Problem: The `role` attribute is being retrieved from the `raw` field, but when the page is refreshed, all attributes (including `role`) are set in the `cashier` object, not in `raw`. Steps to reproduce: - Set up a PoS session with the "Log in with Employees" setting enabled. - Use a User/Employee with Administrator PoS access (e.g., Mitchell Admin). - Start a PoS session. - Refresh the page. - Click the "i" icon to see more information about a product. - A traceback occurs. opw-4120414 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Creating a new Argentine company now keeps the AFIP responsibility type selected by the user instead of reverting it to the default Monotributo option. This ensures the correct chart of accounts is loaded from the start, reducing setup errors for Argentine accounting.
Original PR description
Create a company: - Name: Any - Country: Argentina - AFIP Responsibility Type: IVA Responsable Inscripto Save Issue: Company AFIP Type will be set back to Responsable Monotributo This occurs because when company is created the system will try to load the coa. The COA to load is currently determined only by the country of the new company, and the default for new Argentina companies is 'Responsable Monotributo' Then, the AFIP Type is changed to match the CoA In order to take into account the company settings when loading the CoA we check via context if we are operating on a company and load the template matching the AFIP Type opw-4175351
Demo employees in Sales Timesheets are now linked to newly created, dedicated contacts instead of incorrect existing ones. This keeps sample data cleaner and avoids confusion when evaluating employee, timesheet, and sales workflows.
Original PR description
The employees created in the demo data (see https://github.com/odoo/odoo/pull/108795) of sale_timesheet were linked to the wrong partners, we then create new partners dedicated to those new employees. version-17.2 task-3874828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Steps to reproduce: - Install the FSM module. - Open FSM and navigate to the calendar view. - Create a task with a customer (without a zip code). Issue: The wrong method is being called. Currently, the code uses super.onWillStart();, but this is incorrect as the method does not exist in the calendar model. Fix: We corrected the super method call. task-3617833 Forward-Port-Of: odoo/odoo#180724
Original PR description
Steps to reproduce:
- Install the FSM module.
- Open FSM and navigate to the calendar view.
- Create a task with a customer (without a zip code).
Issue:
The wrong method is being called. Currently, the code uses super.onWillStart();, but this is
incorrect as the method does not exist in the calendar model.
Fix:
We corrected the super method call.
task-3617833
Forward-Port-Of: odoo/odoo#180724Before this commit, since the design changes, the form with html expander no longer works. This commit adapts the code to expand the html field as before to take the remaining height unused by the form view when we first load the form view of `project`. task-3258533 Forward-Port-Of: odoo/odoo#168812
Original PR description
Before this commit, since the design changes, the form with html expander no longer works. This commit adapts the code to expand the html field as before to take the remaining height unused by the form view when we first load the form view of `project`. task-3258533 Forward-Port-Of: odoo/odoo#168812
Remove "Create" and "Create and Edit" of Tax Grids in the list view of Journal Items. task: 4179612 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179930
Original PR description
Remove "Create" and "Create and Edit" of Tax Grids in the list view of Journal Items. task: 4179612 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179930
* STEP TO REPRODUCE: go to configuration -> project -> switch to list view -> can't change sequence of project * REASON: in project.view_project_config we use invisible instead of column_invisible and the default_order in tree are "is_favorite desc, sequence, name, id" not like in v16 are "sequence, name, id" * SOLUTION: Change invisible -> column_invisible and change default_order of project config view to "sequence, name, id" Close https://github.com/odoo/odoo/issues/176961 Forward-Port-
Original PR description
* STEP TO REPRODUCE: go to configuration -> project -> switch to list view -> can't change sequence of project * REASON: in project.view_project_config we use invisible instead of column_invisible and the default_order in tree are "is_favorite desc, sequence, name, id" not like in v16 are "sequence, name, id" * SOLUTION: Change invisible -> column_invisible and change default_order of project config view to "sequence, name, id" Close https://github.com/odoo/odoo/issues/176961 Forward-Port-Of: odoo/odoo#180403
This commit add the missing test file in `__init__.py` 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#178377
Original PR description
This commit add the missing test file in `__init__.py` 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#178377
Steps --- * install `stock`, `sale_management` * configure reception in 2 steps (*Setting > Multi-step routes* + *Configure Warehouse Routes*) * make *Stock/Input* a return location (*Inventory* > *Configuration* > *Stock/Input* form) * create an SO for 5 units of a storable product (say P) * (put at least 5 of P available in stock) * confirm it > go to the delivery > validate * *Return* > from the wizard set *Stock/Input* as the return location * validate the `Customers -> Input`
Original PR description
Steps --- * install `stock`, `sale_management` * configure reception in 2 steps (*Setting > Multi-step routes* + *Configure Warehouse Routes*) * make *Stock/Input* a return location (*Inventory* >…
Steps --- * install `stock`, `sale_management` * configure reception in 2 steps (*Setting > Multi-step routes* + *Configure Warehouse Routes*) * make *Stock/Input* a return location (*Inventory* > *Configuration* > *Stock/Input* form) * create an SO for 5 units of a storable product (say P) * (put at least 5 of P available in stock) * confirm it > go to the delivery > validate * *Return* > from the wizard set *Stock/Input* as the return location * validate the `Customers -> Input` receipt * validate the `Input -> Stock` internal transfer * => on the orignal SO the delivered quantity is now -5 instead of 0 Cause --- When generating moves in a push rules, we copy the fields of the generating move, including `to_refund`, so both moves affect the delivered quantity. But when we check if a return move should affect the delivered/received qty on SO/POs, we only check the `usage` of the destination location; so in the case of multi-step routes, moves further down the chain will affect the qty twice or more, and we will have a negative delivered quantity Fix --- Use a stricter check to determined which moves should affect SO quantities opw-4129497 Forward-Port-Of: odoo/odoo#178392
Currently if there is any automation rule set to trigger on save on res.users, an error will be thrown any time there is a change made to the groups on a user. This is due to the changed field being a sel_groups... field which does not actually exist on the res.users model. To circumvent this, logic has been added to identify when a field is a selection group field, and pull the correct existing group from the groups_id field on the record using set logic. OPW: 4152636 --- I confirm I hav
Original PR description
Currently if there is any automation rule set to trigger on save on res.users, an error will be thrown any time there is a change made to the groups on a user. This is due to the changed field being a sel_groups... field which does not actually exist on the res.users model. To circumvent this, logic has been added to identify when a field is a selection group field, and pull the correct existing group from the groups_id field on the record using set logic. OPW: 4152636 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180367
In a Spanish company if you don't have a certificate set on the company, the PoS would generate a proforma invoice instead of a normal invoice. Steps to reproduce: ------------------- * Install l10n_es_pos * Remove the l10n_es_edi_facturae_certificate_id from the company * Open PoS * Make an order and invoice it > Observation: The invoice generated is a proforma invoice instead of a normal invoice Why the fix: ------------ When generating the invoice data in `_generate_pdf_and_sen
Original PR description
In a Spanish company if you don't have a certificate set on the company, the PoS would generate a proforma invoice instead of a normal invoice. Steps to reproduce: ------------------- * Install l10n_es_pos * Remove the l10n_es_edi_facturae_certificate_id from the company * Open PoS * Make an order and invoice it > Observation: The invoice generated is a proforma invoice instead of a normal invoice Why the fix: ------------ When generating the invoice data in `_generate_pdf_and_send_invoice` the wizard would have `l10n_es_edi_facturae_checkbox_xml` checked by default This leads to the generation of a specific invoice that will fail because there are no certificate setup on the company. This will then fallback to the proforma invoice. opw-4074779 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179107
- Have a x2many on your view; - Edit another field that through a onChange modify the x2many; - Discard the changes. Before this commit, the x2many didn't come back to its initial state. Now, the x2many will came back to its initial state. Note that this commit is a fix up of [1] which already address part of this issue. [1] https://github.com/odoo/odoo/commit/e450d03a5f4fc80198837cccf10fa349ecc205a9 Forward-Port-Of: odoo/odoo#180829
Original PR description
- Have a x2many on your view; - Edit another field that through a onChange modify the x2many; - Discard the changes. Before this commit, the x2many didn't come back to its initial state. Now, the x2many will came back to its initial state. Note that this commit is a fix up of [1] which already address part of this issue. [1] https://github.com/odoo/odoo/commit/e450d03a5f4fc80198837cccf10fa349ecc205a9 Forward-Port-Of: odoo/odoo#180829
Before this commit, the PoS would fail to load if an orderline contained a product that was not loaded into the PoS. This issue could arise, for example, when category restrictions are applied after creating draft orders, preventing the PoS from loading. opw-4119028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180230
Original PR description
Before this commit, the PoS would fail to load if an orderline contained a product that was not loaded into the PoS. This issue could arise, for example, when category restrictions are applied after creating draft orders, preventing the PoS from loading. opw-4119028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180230
* PROPBLEM: In form view we try to use m2o.field_name which is 'l10n_vn_edi_replacement_origin_id.l10n_vn_edi_invoice_number', odoo doesn't support that so it will not work at least in form view * SOLUTION: this commit make the invisible condition more simpler and create a non-store field to fix the issue 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
Original PR description
* PROPBLEM: In form view we try to use m2o.field_name which is 'l10n_vn_edi_replacement_origin_id.l10n_vn_edi_invoice_number', odoo doesn't support that so it will not work at least in form view * SOLUTION: this commit make the invisible condition more simpler and create a non-store field to fix the issue 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#180818
- Install `l10n_in` - create a branch for the Indian company - install `l10n_in_withholding` - traceback If there an Indian company has a branch, installing `l10n_in_withholding` raises an RPC error on the branch company, because the TDS group is not set on it. Since branches use the COA of the parent company, we don't need to load further. Task [link](https://www.odoo.com/odoo/project/967/tasks/4143223) task-4143223 Forward-Port-Of: odoo/odoo#178305
Original PR description
- Install `l10n_in` - create a branch for the Indian company - install `l10n_in_withholding` - traceback If there an Indian company has a branch, installing `l10n_in_withholding` raises an RPC error on the branch company, because the TDS group is not set on it. Since branches use the COA of the parent company, we don't need to load further. Task [link](https://www.odoo.com/odoo/project/967/tasks/4143223) task-4143223 Forward-Port-Of: odoo/odoo#178305
Updated imports for `zeep.wsse` components to explicitly import modules. This change is required because zeep 4.2.0 introduced an `__all__` declaration in `zeep.wsse`: ``` __all__ = [ "Compose", "BinarySignature", "MemorySignature", "Signature", "UsernameToken", ] ``` The __all__ prevents using wildcard imports for all wsse submodules as we did before. Steps to Reproduce: - Install the l10n_nl_reports_sbr module. - Navigate to Accounting > Report > Tax Rep
Original PR description
Updated imports for `zeep.wsse` components to explicitly import modules.
This change is required because zeep 4.2.0 introduced an `__all__` declaration in `zeep.wsse`:
```
__all__ = [
"Compose",
"BinarySignature",
"MemorySignature",
"Signature",
"UsernameToken",
]
```
The __all__ prevents using wildcard imports for all wsse submodules as we did before.
Steps to Reproduce:
- Install the l10n_nl_reports_sbr module.
- Navigate to Accounting > Report > Tax Report.
- Select XBRL from the dropdown menu on the PDF button in the top left corner.
- Attempt to send the document.
- An error will occur:
```
Copy code
File "/home/odoo/src/enterprise/saas-17.4/l10n_nl_reports_sbr/wizard/l10n_nl_reports_sbr_tax_report_wizard.py", line 168, in __init__
wsse.signature.MemorySignature.__init__(
^^^^^^^^^^^^^^
AttributeError: module 'odoo.tools.zeep.wsse' has no attribute 'signature'
````
opw-4181876
Forward-Port-Of: odoo/odoo#180857Versions -------- - 16.0+ Steps ----- 1. Try to import a malformed OFX file into a bank journal; 2. close traceback; 3. try to import a valid OFX or CSV file. Issue ----- Same traceback as first upload. Cause ----- There's no error handling on the RPC call. If the file is successfully imported, the `attachmentIdsToProcess` gets clear, but if there's an error, the bad file remains in the queue until leaving the view. Solution -------- Put the RPC call in a `try` block, and
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Try to import a malformed OFX file into a bank journal; 2. close traceback; 3. try to import a valid OFX or CSV file. Issue ----- Same traceback as first upload. Cause ----- There's no error handling on the RPC call. If the file is successfully imported, the `attachmentIdsToProcess` gets clear, but if there's an error, the bad file remains in the queue until leaving the view. Solution -------- Put the RPC call in a `try` block, and clear the `attachmentIdsToProcess` in `finally` to ensure this happens regardless of outcome. opw-4113740 Forward-Port-Of: odoo/odoo#180845
24 changes
New functionality added to Odoo
Marketing teams can now use WhatsApp as an activity type in automated campaigns, alongside existing channels. The change also improves tracking for WhatsApp links and campaign responses, helping teams measure engagement more accurately.
Original PR description
Whatsapp was added as an activity type in marketing automation. Whatsapp addition caused the addition of certain trigger types, as well as integrating whatsapp with link tracker. task-3595515
Enhancements to existing features
The employee referral dashboards were updated to use newer, simpler card layouts and standard styling. This makes the referral screens easier to maintain and helps keep the user experience consistent with current Odoo interface standards.
Original PR description
In this commit we have simplified the kanban arch for the hr_referral module dashboard. the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of `<field/>` tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use `<field name=... widget=image/>` instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node Task-3992107
This change updates an internal Studio test to match a recent enhancement that lets character fields handle placeholder text. It helps keep automated quality checks aligned with the product behavior, reducing the risk of false test failures during development.
Original PR description
In this commit: https://github.com/odoo/odoo/commit/fca4ad09d929ceee8820fc8b23ab7edd0898639c we added a new props to the char Field. So this test need to be adapted. task: 4191835 Community pr: https://github.com/odoo/odoo/pull/180744
The work center overview no longer sends users to the shopfloor screen. All related links now open the work order list instead, giving users a more consistent path to manage production work orders.
Original PR description
This PR removes the links to the shopfloor from the workcenter overview. Instead, all links now redirect to the WO list view. task 4081617
Appointment bookings now have clear statuses such as request, booked, checked-in, no-show, and cancelled, making it easier for teams like restaurants to track reservations in the Gantt view. Manual confirmation can also be configured more flexibly, while cancelled bookings free the slot and default appointment alarm notifications are no longer enabled automatically.
Original PR description
Purpose ======= Add a status management for gantt view for establisment such as restaurant to have clearer overview on the bookings and their status. Specification ============= Adding multiple…
Purpose ======= Add a status management for gantt view for establisment such as restaurant to have clearer overview on the bookings and their status. Specification ============= Adding multiple appointment status: - request: set when the "manual confirmation" option is checked on the appointment type. Waiting a manual action from the user to confirm the event. This blocks the slot. The "manual confirmation" can now be set for appointment based on users as well. - booked: The slot is blocked and the event is confirmed. This is the default status when the event has an appointment type. - attended (Checked-In): Set manually by the user to confirm the presence of the clients to the event. - no-show: Set manually by the user to say that the event will not happen. This will block the slot. - cancelled: Set manually by the user or automatically set when the event is not active to say that the event has been cancelled. This will free the slot. Co-authored-by: amdi-odoo amdi@odoo.com Co-authored-by: jeh-odoo jeh@odoo.com Task-4028357
The room booking app now uses the shared loading screen styling instead of maintaining its own duplicate styling. This reduces maintenance effort and helps keep the user experience consistent across Odoo, with no expected functional change for users.
Original PR description
- The room app was using his own CSS for the blocked UI. Indeed, it used the service but its CSS was not available. It now is, instead of more CSS code to support. - The web_enterprise app is using a div using the o_blockUI class... but this seems like a mistake, it never had an effect (since at least version 16.0). To investigate later. Related to task-4184418
Several kanban views were simplified so cards are easier to maintain and align with current Odoo interface standards. Users should see the same workflows with more consistent card behavior and presentation across inventory, manufacturing, Studio, and WhatsApp areas.
Original PR description
*stock_barcode_mrp,stock_barcode_picking_batch,test_web_studio In this commit we have simplified the kanban arch for the planning, project_forecast,quality_control,room,sale_subscription and sale_timesheet_enterprise modules.the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of `<field/>` tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use `<field name="..." widget="image"/>` instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color="color_field_name" on root node Task-3992107
Odoo Studio now supports “starts with” and “ends with” filter operators in the list/tree view editor. This gives users more flexible ways to define matching rules when configuring views, making it easier to tailor records and searches to business needs.
Original PR description
Task ID 4132459
The Plan Services field now has clearer tooltip text explaining how it affects automatic planning. This helps users understand when services will be automatically planned and reduces confusion during product setup.
Original PR description
This commit simply adds help text to the tooltip of the field 'plan services' (`planning_enabled`). We add the explanation about how the behavior of 'auto plan' is linked to this field. Task: 3940616
French VAT report submissions now let customers provide up to three bank accounts for reimbursement requests. The underlying VAT closing process was also adjusted so the correct closing entry can be retrieved from report options, improving reliability for the filing workflow.
Original PR description
This commit has 2 objectives: 1. Factorize a bit the vat closing entry code to add a hook function that permits to get the closing entry by using the options report. 2. Modifying the wizard to send the VAT report to the administration. Now, customers can add bank accounts (max 3) where he/she wants to be reimbursed. task-3648048
The GST return dashboard layout for India reports has been simplified to use newer interface components and clearer labels. This makes the dashboard easier to maintain and helps users see a more accurate status label for waiting reception.
Original PR description
In this commit, we have simplified the Kanban arch for the l10n_in_reports_gstr module dashboard. the goal is to simplify them, make them easier to read, and use bootstrap utility class names. -…
In this commit, we have simplified the Kanban arch for the l10n_in_reports_gstr module dashboard. the goal is to simplify them, make them easier to read, and use bootstrap utility class names. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of <field/> tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use <field name=... widget=image/> instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node also, change 'Waiting for Status' to 'Waiting Reception' as it is not available in gstr2b_status https://github.com/odoo/enterprise/blob/8819f2d2145577cac800a2e149b287ae88000336/l10n_in_reports_gstr/views/gst_return_period.xml#L275 Task-3992107
Resolved issues and error corrections
Fixed an issue where shared public Knowledge articles could appear blank on desktop devices. The page structure was adjusted so article content uses the available screen space correctly, and semantic page sections were restored to support better indexing.
Original PR description
Currently, the article content appears empty on desktop devices because the main container (`.o_knowledge_public_view`) no longer occupies the full vertical space of the page. That issue was…
Currently, the article content appears empty on desktop devices because the main container (`.o_knowledge_public_view`) no longer occupies the full vertical space of the page. That issue was introduced in [this pr](https://github.com/odoo/odoo/pull/98429). To resolve this issue, we will remove the wrapper elements: `div#wrapwrap` and the `main` element from the generated pages. This will simplify the DOM structure and allow the main container to take up all the available vertical space without needing to set the height for all containers. Since the body of the frontend_layout is completely overridden for website_knowledge, the `<header>` and `<main>` tags are reintroduced at appropriate places for a Knowledge article. Steps to reproduce the issue: 1. Open Knowledge 2. Publish an article using the share panel (click on the "Share" button) 3. Copy the share link (`/knowledge/article/<article_id>`) 4. Open an incognito tab and access the link copied at step 3 => The article content is hidden on desktop. TO BE: The article content should be visible. task-4193478
Miscellaneous changes
payment_method_id is readonly in account.batch.payment's form view when there is at least one payment on the batch. So, it cannot easily be changed in standard in order to break the constraint. It could however happen in custom views or when generating records directly from the code. Forward-Port-Of: odoo/enterprise#70230
Original PR description
payment_method_id is readonly in account.batch.payment's form view when there is at least one payment on the batch. So, it cannot easily be changed in standard in order to break the constraint. It could however happen in custom views or when generating records directly from the code. Forward-Port-Of: odoo/enterprise#70230
before this commit, when opening/resuming a POS session, the final_consumer was not always loaded, leading to loading errors. This commit ensures that the final_consumer gets loaded when opening the POS session. related PR: https://github.com/odoo/enterprise/pull/65296 opw-4171779 Forward-Port-Of: odoo/enterprise#70251
Original PR description
before this commit, when opening/resuming a POS session, the final_consumer was not always loaded, leading to loading errors. This commit ensures that the final_consumer gets loaded when opening the POS session. related PR: https://github.com/odoo/enterprise/pull/65296 opw-4171779 Forward-Port-Of: odoo/enterprise#70251
### Steps to reproduce * install `account_intrastat` * create and confirm an invoice for a Northern Irish customer * open the EC Sales Report You will see that your invoice is not included in the report opw-4123375 Forward-Port-Of: odoo/enterprise#69955 Forward-Port-Of: odoo/enterprise#69501
Original PR description
### Steps to reproduce * install `account_intrastat` * create and confirm an invoice for a Northern Irish customer * open the EC Sales Report You will see that your invoice is not included in the report opw-4123375 Forward-Port-Of: odoo/enterprise#69955 Forward-Port-Of: odoo/enterprise#69501
Before this commit, it was not possible to resequence the projects in any list views of Project and Field Service because the `handle` widget is not defined in the sequence and the default order applied in those list views does not begin with `sequence` field. This commit shows the sequence field in the list view of `Field Service > Configuration > Projects` and change the default of that list view to allow the user to resequence the projects as he wishes. Community PR: odoo/odoo#180403
Original PR description
Before this commit, it was not possible to resequence the projects in any list views of Project and Field Service because the `handle` widget is not defined in the sequence and the default order applied in those list views does not begin with `sequence` field. This commit shows the sequence field in the list view of `Field Service > Configuration > Projects` and change the default of that list view to allow the user to resequence the projects as he wishes. Community PR: odoo/odoo#180403 Close odoo/odoo#176961 Forward-Port-Of: odoo/enterprise#70137
The `Accounting` dashboard was using very naive formulas to compute deltas between years. Namely, the formulas were based on the assumpution that we'd only compare values year by year but the filters allow to work with quarters or months as well. This revision updates the dashboard file to take the months/quarters into account. task-3957037 Forward-Port-Of: odoo/enterprise#70255 Forward-Port-Of: odoo/enterprise#69286
Original PR description
The `Accounting` dashboard was using very naive formulas to compute deltas between years. Namely, the formulas were based on the assumpution that we'd only compare values year by year but the filters allow to work with quarters or months as well. This revision updates the dashboard file to take the months/quarters into account. task-3957037 Forward-Port-Of: odoo/enterprise#70255 Forward-Port-Of: odoo/enterprise#69286
Remove "Create" and "Create and Edit" of Tax Grids in the list view of Journal Items. task: 4179612 Forward-Port-Of: odoo/enterprise#69864
Original PR description
Remove "Create" and "Create and Edit" of Tax Grids in the list view of Journal Items. task: 4179612 Forward-Port-Of: odoo/enterprise#69864
Problem: The `snailmail_cost` field was not being computed because the compute method was not being called. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#70236
Original PR description
Problem: The `snailmail_cost` field was not being computed because the compute method was not being called. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#70236
Reproduce Steps: ---------- 1. Install the Planning module. 2. Navigate to My Planning. 3. Open the Repeat Shift section. 4. Click the Delete button. 5. Click on a radio button label, such as 'This and Following Shifts'. Fixed an issue where clicking the shift option labels did not select the corresponding value. The problem was addressed by setting the `id` attribute on the input element and properly associating it with the label. task-3978567 Forward-Port-Of: odoo/enterprise#
Original PR description
Reproduce Steps: ---------- 1. Install the Planning module. 2. Navigate to My Planning. 3. Open the Repeat Shift section. 4. Click the Delete button. 5. Click on a radio button label, such as 'This and Following Shifts'. Fixed an issue where clicking the shift option labels did not select the corresponding value. The problem was addressed by setting the `id` attribute on the input element and properly associating it with the label. task-3978567 Forward-Port-Of: odoo/enterprise#70143 Forward-Port-Of: odoo/enterprise#68220
### Steps to reproduce issue: 1. Go to _Accounting > Configuration > Account Reports_ 2. Select Balance Sheet and Add a line in it 3. Select the new line and give it ASSETS as parent_id 4. Go to Reporting > Balance Sheet 5. The new line is still at the end of the report ### Explanation: Lines have a `sequence` to sort them in the report. It is not computed to change along with `parent_id`, since the lines are supposed to be arranged through the `AccountReportListRenderer` widget. Be
Original PR description
### Steps to reproduce issue: 1. Go to _Accounting > Configuration > Account Reports_ 2. Select Balance Sheet and Add a line in it 3. Select the new line and give it ASSETS as parent_id 4. Go to Reporting > Balance Sheet 5. The new line is still at the end of the report ### Explanation: Lines have a `sequence` to sort them in the report. It is not computed to change along with `parent_id`, since the lines are supposed to be arranged through the `AccountReportListRenderer` widget. Because of it a line whose `parent_id` changes will not be placed correctly. ### Fix reasoning: The `parent_id` field will be removed from the view, the hierarchy is already shown in the widget. opw-4101282 Forward-Port-Of: odoo/enterprise#69568
This commit's purpose is to force the use of the widget 'taskWithHours' when the timesheet timer is launched. Previously, this was done through the xml by setting the 'type' attribute. This is no longer an option, so instead, we update the arguments given in the getPropertyFieldInfo method on the js side with the type we need. task - 4166816 affected version saas-17.2 - master Forward-Port-Of: odoo/enterprise#69663
Original PR description
This commit's purpose is to force the use of the widget 'taskWithHours' when the timesheet timer is launched. Previously, this was done through the xml by setting the 'type' attribute. This is no longer an option, so instead, we update the arguments given in the getPropertyFieldInfo method on the js side with the type we need. task - 4166816 affected version saas-17.2 - master Forward-Port-Of: odoo/enterprise#69663
- 17.0 ### Steps to reproduce: - Install sale_planning and project_forecast app. - Create a sale order with the planning product (e.g. Developer (Plan services)) and confirm it. - Create planning for that sale order and set resource (e.g. Marc demo) to it. - Click 'Publish & Send' button. - Set 'User: Own Documents Only' rights for the sales and 'User' or 'none' for the project and planning for Marc demo. - Login from that user and open the planning app. - Open assigned planning form v
Original PR description
- 17.0 ### Steps to reproduce: - Install sale_planning and project_forecast app. - Create a sale order with the planning product (e.g. Developer (Plan services)) and confirm it. - Create planning for that sale order and set resource (e.g. Marc demo) to it. - Click 'Publish & Send' button. - Set 'User: Own Documents Only' rights for the sales and 'User' or 'none' for the project and planning for Marc demo. - Login from that user and open the planning app. - Open assigned planning form view. - Print planning. ### Issue: - Traceback occurs of access right. ### Cause: - While downloading the report, it goes to access the "display_name" and "name" field of sale order line and project respectively that is computed in the _compute_display_name, but the user cannot access "sale.order.line" and "project" due to record rule. ### Solution: - Give access to the record by using sudo(). task-3978552 Forward-Port-Of: odoo/enterprise#69533
Currently, an exception is generated when the user tries to upload an image file for creating an invoice. error: `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0: invalid start byte` This is because below code line tries to load image context of uploaded image file. https://github.com/odoo/enterprise/blob/799b80d12680153a5ba42ee97501723ba38052b1/l10n_ke_edi_oscu/models/account_move.py#L567 This commit fixes the above issue by handling `UnicodeDecodeError` in `con
Original PR description
Currently, an exception is generated when the user tries to upload an image file for creating an invoice. error: `UnicodeDecodeError: 'utf-8' codec can't decode byte 0x89 in position 0: invalid start byte` This is because below code line tries to load image context of uploaded image file. https://github.com/odoo/enterprise/blob/799b80d12680153a5ba42ee97501723ba38052b1/l10n_ke_edi_oscu/models/account_move.py#L567 This commit fixes the above issue by handling `UnicodeDecodeError` in `contextlib.suppress.` sentry-5757745777 Forward-Port-Of: odoo/enterprise#69649
14 changes
Enhancements to existing features
This update improves how tax identification labels appear on financial reports by displaying country-specific terminology instead of the generic 'VAT' label. Reports will now show 'Tax ID' and other localized terms appropriate for each country, making reports clearer and more compliant with local standards.
Original PR description
This **PR** introduces support for country specific VAT labels to be displayed on their reports and replaces 'VAT' with 'Tax ID'. **task**-4163352
Resolved issues and error corrections
This fixes when the Viettel e-invoice XML section is shown on invoice forms. Users should now see the correct page when working with replacement invoice information, avoiding confusion or missing details.
Original PR description
* PROPBLEM: In form view we try to use m2o.field_name which is 'l10n_vn_edi_replacement_origin_id.l10n_vn_edi_invoice_number', odoo doesn't support that so it will not work at least in form view * SOLUTION: this commit make the invisible condition more simpler and create a non-store field to fix the issue 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 a SendCloud contract has no available rates, adding it to a sales order no longer triggers a disruptive popup. Users now see the same message in a red banner, keeping the workflow clearer and less interruptive.
Original PR description
In this PR ================== Some contracts in SendCloud do not have rates. This caused an annoying popup when adding it to the Sales Order. After this PR, the red banner is displayed with the same message instead of the annoying popup when adding it to the Sales Order. Enterprise PR: https://github.com/odoo/enterprise/pull/66976 TaskId: 4012182
This fix corrects how tax tags are calculated when invoices have early payment discounts and multiple line items with different analytic accounts. Previously, the system would incorrectly mark some tax tags as inverted, causing accounting records to be misclassified. The fix ensures tax tags are consistently and correctly assigned regardless of how invoice lines are structured.
Original PR description
### Steps to reproduce the issue: 1. Create a Customer Invoice with two product lines 2. Give a negative price to one of those lines, the total must remain positive 3. Add distinct analytic accounts…
### Steps to reproduce the issue: 1. Create a Customer Invoice with two product lines 2. Give a negative price to one of those lines, the total must remain positive 3. Add distinct analytic accounts to each line's analytic_distribution 4. Add a payment term with applicable early discount 5. Confirm and Register Payment 6. Go to the Journal Entry related to the Invoice 7. Check the Invert Tags (developer mode), one of them is set to True, which should not be the case ### Explanation: In the current situation, `_compute_is_refund` and `_compute_tax_tag_invert` will assign a value to `tax_tag_invert` depending on the `account.move.line.balance`. Because of the distinct analytic accounts, the negative line is separated from the others and because of the logic behind the computes, `tax_tag_invert` is set to the opposite value. ### Fix reasoning: While `account.payment` are restricted to `account.move` with the same direction, `account.bank.statement.line` are not. In the current case, the affected lines all have `tax_ids` values. Thanks to this, we can use `account.tax.type_tax_use` independently of the line's balance to differentiate in and out transactions and assign `tax_tag_invert` consistently. We must also consider the case where `account.bank.statement.line`. To target the Early Payment Discount lines, we will separate them from the other values using `display_type`. opw-3989174 Forward-Port-Of: odoo/enterprise#69835
The Intrastat Report was displaying very large decimal numbers when exporting to PDF or XML due to unrounded calculations. This fix ensures that supplementary unit quantities are properly rounded, making the report output clean and readable for EU trade reporting.
Original PR description
With an EU company (i.e. BE) Open a product [PROD], in Accounting Tab set: - Commodity Code: 84716070 - Supplementary units: 0.56 Create an invoice to an EU partner (i.e. IT) with 5 units of [PROD] Confirm invoice Accounting > Reporting > Intrastat Report Export pdf or xml Issue: Report will show a very large decimal number This occurs because the number is computed via SL query that is not rounded opw-4160104 Forward-Port-Of: odoo/enterprise#70181
This fix ensures that when users expand a report line to view detailed sub-lines, the system properly synchronizes pending data changes before retrieving the details. Previously, unsaved changes could cause the displayed details to be inaccurate or inconsistent with the actual data.
Original PR description
Unfolding a report line calls an expand function which is responsible to run an SQL query in order to compute the sub-lines (typically the result of a groupby, but it can be something else on custom report). Not flushing was a mistake and could lead to inconsitencies. Forward-Port-Of: odoo/enterprise#70187
This fix resolves an error that occurred when users tried to open the Profit and Loss report after deleting the Balance Sheet report. The system was looking for a Balance Sheet report that no longer existed and crashing instead of gracefully handling the missing report. Now the system will simply skip the missing Balance Sheet reference and allow users to view their Profit and Loss report without interruption.
Original PR description
Currently, An error is generated while a user is trying to open the 'Profit and Loss' report when balance sheet report is not available Steps to reproduce: - Install an ```account_reports``` module.…
Currently, An error is generated while a user is trying to open the 'Profit and Loss' report when balance sheet report is not available Steps to reproduce: - Install an ```account_reports``` module. - Turn on debugger mode (from SAAS-17.2 no need this). - Navigate to Accounting / Configuration / Management / Accounting Reports, Delete the 'Balance Sheet' report - And Open 'Profit and Loss' report(In Accounting Reports). ```ValueError: External ID not found in the system: account_reports.balance_sheet``` An error occurs when the system tries to retrieve an external id of balance sheet report 'account_reports.balance_sheet' at [1], but it is not available. Link [1]: https://github.com/odoo/enterprise/blob/9d185d78813f776249a4de0469d659723a94d026/account_reports/models/account_report.py#L5401 To handle this issue, add 'raise_if_not_found=False' in ref() so that when balance sheet report is not available it will return a None value instead of traceback. Sentry-5836075163
This fix corrects a display issue in Mexican invoices where the usage description was showing an incorrect mix of two different codes. When generating invoices for Mexican customers, the system now properly displays the correct usage description that matches the selected usage code, ensuring accurate invoice documentation for compliance purposes.
Original PR description
**Steps to reproduce:** - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Usage: General expenses * CFDI to public: [checked] - Confirm the invoice - Generate CFDI and the invoice via "Send & Print" button **Issue:** On the invoice, "Usage" has an incorrect value: "S01 - General expenses" which is a mix of "S01 - Without fiscal effects" and "G03 - General expenses". The description should be the one linked to the code. opw-4118647
This update adds a missing validation rule to the batch payment system to prevent payment method changes that could violate business constraints. While the standard interface already prevents this issue, the fix ensures the constraint is enforced even when records are created or modified through custom views or direct code, protecting data integrity.
Original PR description
payment_method_id is readonly in account.batch.payment's form view when there is at least one payment on the batch. So, it cannot easily be changed in standard in order to break the constraint. It could however happen in custom views or when generating records directly from the code. Forward-Port-Of: odoo/enterprise#70230
Fixed an issue where partner addresses were not shown when assigning a customer to a Field Service task until after saving. The fix restores the address display functionality so users can see the complete partner information right away when selecting a customer, improving the user experience and reducing confusion.
Original PR description
Steps to reproduce: ------- - install field service app - Go to the Field Service app and create a new task. - Assign a partner (customer) to the task. - Notice that the address of the assigned…
Steps to reproduce: ------- - install field service app - Go to the Field Service app and create a new task. - Assign a partner (customer) to the task. - Notice that the address of the assigned partner is not displayed immediately. - The address only appears after the record is saved. cause: -------- - context 'show_address' was not passed to _compute_display_name Technical: --------- In a previous [pull request](https://github.com/odoo/enterprise/pull/56179/commits/676e6c34a9901d4fe7f68859e1b526dfc2090413), the show_address context was removed. As a result, the _compute_display_name method was not able to correctly display the partner's address when a partner was assigned to a task.The address would only appear after the task was saved. Solution: The show_address context should be reintroduced and passed to the `_compute_display_name` method during the task creation or update process. This will allow the address to be displayed immediately when the partner is selected. task-4038335
Fixed a bug where changes to accounting accounts in the asset modification wizard were not being saved. When users modified an asset's depreciation and changed the associated accounts, those changes were lost. This fix ensures all account modifications are properly saved when the wizard is completed.
Original PR description
Issue: ===== Changes of asset are not saved. Steps to reproduce the issue: ============================= - Create a new asset - Add some accounts in the accounting section - Confirm it - Click on modify depreciation - Select re-evaluate - Change the accounts and click modify - The changes are not applied Origin of the issue: ==================== We are not including the values of accounts in the `asset_vals` dict that we use to update the asset. Solution: ========= Added the fields of the accounts to `asset_vals` dict. opw-4100185
This fix prevents users from accidentally changing the Electronic Invoice Type for already-confirmed invoices by restricting modifications to the "Nota de Débito" (Debit Note) setting in journal configuration. Previously, changing this setting would affect all invoices in that journal, including posted ones, causing invoice types to become out of sync. Now, the setting can only be modified for journals that don't have any confirmed or posted invoices.
Original PR description
### Steps to reproduce the issue: 1. Activate Colombian localization 2. Create an Invoice and Confirm 3. Go to _Accounting > Configuration > Journals_ 4. Select Customer Invoices, set Nota de Débito…
### Steps to reproduce the issue: 1. Activate Colombian localization 2. Create an Invoice and Confirm 3. Go to _Accounting > Configuration > Journals_ 4. Select Customer Invoices, set Nota de Débito to True and Save 5. Go back to your Invoice, its Electronic Invoice Type is now "Nota Débito" 6. Set Nota de Débito to False in the Customer Invoices Journal 7. Return once again to you Invoice, its Electronic Invoice Type did not change ### Explanation: When the user changes `l10n_co_edi_debit_note` in an `account.journal`, it changes this value for all entries in said `account.journal`, not only the ones in draft state. https://github.com/odoo/enterprise/blob/9137e5d9f2690bfe375436c83356ebaa4bd7e8c6/l10n_co_edi/models/account_invoice.py#L65 `_compute_l10n_co_edi_type` depending on `l10n_co_edi_debit_note`, it is called and, if the change is from False to True, `l10n_co_edi_type` is changed to a specific value. https://github.com/odoo/enterprise/blob/9137e5d9f2690bfe375436c83356ebaa4bd7e8c6/l10n_co_edi/models/account_invoice.py#L72-L81 If `l10n_co_edi_debit_note` is set back to False, `l10n_co_edi_type` is not reverted to its previous value and the user can not manually change this field for posted or cancelled entries. ### Fix reasoning: To avoid such situation from happening, the field will be restricted for journals with entries in a non draft state. opw-4174980 Forward-Port-Of: odoo/enterprise#70133
Fixed an issue where shipping labels could not be created when SendCloud contracts lacked rate information. The system now gracefully handles missing rates, allowing label generation to proceed smoothly without errors. This improves the reliability of the shipping workflow for users with certain SendCloud contract types.
Original PR description
Before this commit ================== Some contracts in SendCloud do not have rates. When trying to generate a label, an error occurs because of the missing rate, preventing the label from being created. After this commit ================= This commit ensures no error is returned when a rate can't be fetched from SendCloud. Label creation can proceed without issues. Community PR: https://github.com/odoo/odoo/pull/173791 TaskId: 4012182
Miscellaneous changes
Avoid sending more emails than necessary at events We want to make sure that in all mails sent from the calendar event, the recipients are only the ones we want and avoid sending them to 'indirect' followers. Examples use case: - Subtype Notes with Default checked. - Several Attendees set (including several users). - Each invitation email must be sent only to the corresponding attendee, no one else. - Each event reminder email must reach only the corresponding attendee, no one else.
Original PR description
Avoid sending more emails than necessary at events We want to make sure that in all mails sent from the calendar event, the recipients are only the ones we want and avoid sending them to 'indirect' followers. Examples use case: - Subtype Notes with Default checked. - Several Attendees set (including several users). - Each invitation email must be sent only to the corresponding attendee, no one else. - Each event reminder email must reach only the corresponding attendee, no one else. Example use case in runbot v16 **before** this change.  Example use case **after** this change.  @Tecnativa TT50302 Ping @pedrobaeza and @carlosdauden --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174494