Daily updates from Odoo
Saturday, August 15, 2026
30 changes
4 changes
Resolved issues and error corrections
The timesheet assistant now preserves a project that a user manually selects before saving. This prevents later suggestions from unexpectedly replacing the chosen project, reducing data entry mistakes and rework.
Original PR description
Steps to reproduce: - Select an unmatched suggestion. - Select Project A on the timesheet form (do not save it yet). - Select another suggestion matched to Project B. Observed behavior: Project A is overridden by Project B. Expected behavior: Project A remains selected on the timesheet. By initializing `project_id` with the current record's data, we prevent the suggestion loop from overwriting the user's manual selection. task-6410844 Forward-Port-Of: odoo/enterprise#127423 Forward-Port-Of: odoo/enterprise#126450
Before this commit, the two steps posting "Hello everyone!" were spliced into the meeting view tour at the index of the step clicking on the Chat action, looked up with `steps.find`. That returns the step itself, so `splice` coerced it to NaN and inserted at 0: the message was posted as the very first thing the tour did, and the marker it searched for served no purpose. Reminder that the index it aimed for does not work: the meeting view is fullscreen with the invite panel open there, and the
Original PR description
Before this commit, the two steps posting "Hello everyone!" were spliced into the meeting view tour at the index of the step clicking on the Chat action, looked up with `steps.find`. That returns the step itself, so `splice` coerced it to NaN and inserted at 0: the message was posted as the very first thing the tour did, and the marker it searched for served no purpose. Reminder that the index it aimed for does not work: the meeting view is fullscreen with the invite panel open there, and the only composer belongs to the chat panel, which opens one step later. This commit writes the two steps at the head of the list and drops the marker, so the tour runs in the order it reads. Forward-Port-Of: odoo/odoo#282181 Forward-Port-Of: odoo/odoo#282060
Steps to produce: --- - Install `website_sale` and `stock` modules - Create a product, publish it, and add it to the cart from website. - Go to `Website > eCommerce > Orders > Orders`. - Open the order, click on `Add shipping` > add `Standard Delivery`. - Confirm the order, validate the delivery via the Delivery smart button. - From the list view, click the `To fulfill` button. Issue: --- - The order that was just delivered still appears in the `To fulfill` filter results, even thoug
Original PR description
Steps to produce: --- - Install `website_sale` and `stock` modules - Create a product, publish it, and add it to the cart from website. - Go to `Website > eCommerce > Orders > Orders`. - Open the…
Steps to produce: --- - Install `website_sale` and `stock` modules - Create a product, publish it, and add it to the cart from website. - Go to `Website > eCommerce > Orders > Orders`. - Open the order, click on `Add shipping` > add `Standard Delivery`. - Confirm the order, validate the delivery via the Delivery smart button. - From the list view, click the `To fulfill` button. Issue: --- - The order that was just delivered still appears in the `To fulfill` filter results, even though all actual products have been fully delivered. Root cause: --- - The `_search_is_unfulfilled`[1] method checks whether any order line has `qty_delivered < product_uom_qty`. A delivery/shipping line (with `is_delivery = True`) is a service—it is never physically delivered, so its `qty_delivered` remains 0 while its `product_uom_qty` is typically 1. This means `0 < 1` is always true for delivery lines, causing every order with a shipping cost line to permanently appear as unfulfilled, regardless of whether all actual products have been fully delivered. Solution: --- - Added domain to exclude all service-type products from the unfulfilled orders check. - Now, an order line is considered unfulfilled only when: - `qty_delivered < product_uom_qty` (under-delivered) - `product.type != 'service'` (not a service product — excludes services, delivery lines, etc.) [1]https://github.com/odoo/odoo/blob/e5d6650c542e44441c7087c729b3b74af3c75fe0/addons/website_sale/models/sale_order.py#L171-L183 opw-6420723 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282257 Forward-Port-Of: odoo/odoo#279134
Steps: - Install portal app. - Go to my/home page. - Click on `Edit information` button. Issue: - There is no breadcrumb in `my/account` page. Cause: - After [PR](https://github.com/odoo/odoo/pull/190312) page_name of `my/account` page `my_details` was overridden by `home` from `_prepare_portal_layout_values` method. Fix: - Set page_name `my_details` after `_prepare_portal_layout_values` method call to properly set page_name. Forward-Port-Of: odoo/odoo#279072
Original PR description
Steps: - Install portal app. - Go to my/home page. - Click on `Edit information` button. Issue: - There is no breadcrumb in `my/account` page. Cause: - After [PR](https://github.com/odoo/odoo/pull/190312) page_name of `my/account` page `my_details` was overridden by `home` from `_prepare_portal_layout_values` method. Fix: - Set page_name `my_details` after `_prepare_portal_layout_values` method call to properly set page_name. Forward-Port-Of: odoo/odoo#279072
3 changes
Resolved issues and error corrections
The timesheet assistant now keeps a user's manually selected project when they switch between suggestions. This prevents accidental project changes before saving, reducing corrections and helping timesheets stay accurate.
Original PR description
Steps to reproduce: - Select an unmatched suggestion. - Select Project A on the timesheet form (do not save it yet). - Select another suggestion matched to Project B. Observed behavior: Project A is overridden by Project B. Expected behavior: Project A remains selected on the timesheet. By initializing `project_id` with the current record's data, we prevent the suggestion loop from overwriting the user's manual selection. task-6410844 Forward-Port-Of: odoo/enterprise#127423 Forward-Port-Of: odoo/enterprise#126450
Steps: - Install portal app. - Go to my/home page. - Click on `Edit information` button. Issue: - There is no breadcrumb in `my/account` page. Cause: - After [PR](https://github.com/odoo/odoo/pull/190312) page_name of `my/account` page `my_details` was overridden by `home` from `_prepare_portal_layout_values` method. Fix: - Set page_name `my_details` after `_prepare_portal_layout_values` method call to properly set page_name. Forward-Port-Of: odoo/odoo#279072
Original PR description
Steps: - Install portal app. - Go to my/home page. - Click on `Edit information` button. Issue: - There is no breadcrumb in `my/account` page. Cause: - After [PR](https://github.com/odoo/odoo/pull/190312) page_name of `my/account` page `my_details` was overridden by `home` from `_prepare_portal_layout_values` method. Fix: - Set page_name `my_details` after `_prepare_portal_layout_values` method call to properly set page_name. Forward-Port-Of: odoo/odoo#279072
Fixing the QR code size and Robustness for ZATCA. 1. The QR code is now an embedded image SVG instead of an image fetched from the server, which makes it robust against Webkit quirks. 2. We set the QR size in the preview screen to 200px (back to what it was before https://github.com/odoo/odoo/pull/277813), and we make the QR size on the physical receipt 300px so it's big enough to be scanned easily. More info in the respective commit messages. opw-6399766 Forward-Port-Of: odoo/odoo#28
Original PR description
Fixing the QR code size and Robustness for ZATCA. 1. The QR code is now an embedded image SVG instead of an image fetched from the server, which makes it robust against Webkit quirks. 2. We set the QR size in the preview screen to 200px (back to what it was before https://github.com/odoo/odoo/pull/277813), and we make the QR size on the physical receipt 300px so it's big enough to be scanned easily. More info in the respective commit messages. opw-6399766 Forward-Port-Of: odoo/odoo#282611 Forward-Port-Of: odoo/odoo#282285
13 changes
Resolved issues and error corrections
Payroll configuration now hides Mexican CFDI settings when users are working in a non-Mexican company. This prevents irrelevant country-specific options from appearing and reduces confusion for payroll administrators.
Original PR description
Steps to reproduce: 1. Switch to a non-Mexican company. 2. Go to Payroll > Configuration > Settings. 3. The CFDI settings block is visible. Reason: The CFDI block was missing a country check. Solution: Restrict the CFDI block visibility to Mexican companies. Task-6448440 Forward-Port-Of: odoo/enterprise#127022
In commit 004b56a5c31841bc0bf4a9f17902bbff8d0f509d we added warnings to tell French companies to install the PDP module. When working on commit 720294ee523c6f84d0302e6b7fd634069f72dda7 we noticed the problem that the PDP module is not available without rescanning the available modules ("Update Apps List" in debug mode in the "Apps"). This is fixed in this commit: In case the module is not installed we still show the warning but link to the "Update Apps List" wizard. task-None For
Original PR description
In commit 004b56a5c31841bc0bf4a9f17902bbff8d0f509d we added
warnings to tell French companies to install the PDP module.
When working on commit 720294ee523c6f84d0302e6b7fd634069f72dda7
we noticed the problem that the PDP module is not available
without rescanning the available modules ("Update Apps List" in
debug mode in the "Apps").
This is fixed in this commit:
In case the module is not installed we still show the warning
but link to the "Update Apps List" wizard.
task-None
Forward-Port-Of: odoo/odoo#280209In the sampel dashboard the figures are half transparent to indicate that they are just sample data, but they are still interactive. This commit disable all the pointer events on them. Task: [6467022](https://www.odoo.com/web#id=6467022&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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 rea
Original PR description
In the sampel dashboard the figures are half transparent to indicate that they are just sample data, but they are still interactive. This commit disable all the pointer events on them. Task: [6467022](https://www.odoo.com/web#id=6467022&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#282179
Before this commit, a test answering a route with a response of its own, `new Response(stream)`, reads `content-type: application/json` back from it, a header it never set. At the debug log level, the request itself fails: Unexpected token 'o', "[object Rea"... is not valid JSON This happens because the mocked fetch guesses the content type from its result, and a response is neither a string, a `Blob` nor a `FormData`, so it falls back to JSON, on the very headers the response carries.
Original PR description
Before this commit, a test answering a route with a response of its own, `new Response(stream)`, reads `content-type: application/json` back from it, a header it never set. At the debug log level, the request itself fails:
Unexpected token 'o', "[object Rea"... is not valid JSON
This happens because the mocked fetch guesses the content type from its result, and a response is neither a string, a `Blob` nor a `FormData`, so it falls back to JSON, on the very headers the response carries. The response logger then reads the body as text, "[object ReadableStream]" for a stream, and parses it as JSON.
This commit guesses the content type of a raw value only, so a response keeps the headers it was built with.
Forward-Port-Of: odoo/odoo#281968Steps to reproduce --- 1. Create and confirm a sale order. 2. Create a down payment invoice on it and post it: the down payment line reads "Down Payment (ref: INV/... on ...)". 3. Open that invoice and use Reverse and Create Invoice, then post the newly created draft down payment invoice. 4. Open the sale order: the down payment line has lost its reference and now reads only "Down Payment", and that empty label also carries over to the down payment section when generating the final invoice.
Original PR description
Steps to reproduce --- 1. Create and confirm a sale order. 2. Create a down payment invoice on it and post it: the down payment line reads "Down Payment (ref: INV/... on ...)". 3. Open that invoice…
Steps to reproduce --- 1. Create and confirm a sale order. 2. Create a down payment invoice on it and post it: the down payment line reads "Down Payment (ref: INV/... on ...)". 3. Open that invoice and use Reverse and Create Invoice, then post the newly created draft down payment invoice. 4. Open the sale order: the down payment line has lost its reference and now reads only "Down Payment", and that empty label also carries over to the down payment section when generating the final invoice. Issue --- The down payment line description is built by `_get_downpayment_description`, which only produces the "Down Payment (ref: ... on ...)" label when exactly one customer invoice is linked to the down payment `sale.order.line`, guarded by `len(invoice) == 1`. https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/sale/models/sale_order_line.py#L484-L509 Reverse and Create Invoice runs `account.move.reversal.modify_moves`, which copies the reversed invoice with `include_business_fields=True`, so the copied line keeps its `sale_line_ids` and the new draft invoice is attached to the very same down payment line as the reversed original. https://github.com/odoo/odoo/blob/3a5f7431effd4b2b2eb8ce3eed81aaba42fcd8ea/addons/account/wizard/account_move_reversal.py#L142-L149 That down payment line then references two `out_invoice` moves (the reversed one and the re-issued one), so `len(invoice) == 1` is false and the label silently falls back to the bare "Down Payment", losing the reference that the final invoice's down payment section reuses. Going back to the sale order to raise a fresh down payment instead creates a new line, which keeps a single invoice and is why the slower flow is unaffected. The `len(invoice) == 1` guard was introduced in ba954604e529. Discarding the reversed invoice (`payment_state == 'reversed'`) leaves the active re-issued invoice as the single match, so its reference is shown again; when the only linked invoice is itself reversed, the fallback keeps displaying it so existing descriptions are preserved. opw-6353384 Forward-Port-Of: odoo/odoo#277802
### Issue: When a company is not connected to the French Electronic Invoicing PDP proxy, the generated XML is missing required notes: `PMT`, `PMD` and `AAB` These notes are required by Factur-X rule `BR-FR-05/BT-22` and their absence causes validation errors on the FNFE validator ### Cause: `_l10n_fr_pdp_get_default_notes` only added the notes when the company was using a PDP proxy type Non-PDP users sending invoices via other means were excluded, which contradicts the French e-invoicing
Original PR description
### Issue: When a company is not connected to the French Electronic Invoicing PDP proxy, the generated XML is missing required notes: `PMT`, `PMD` and `AAB` These notes are required by Factur-X rule `BR-FR-05/BT-22` and their absence causes validation errors on the FNFE validator ### Cause: `_l10n_fr_pdp_get_default_notes` only added the notes when the company was using a PDP proxy type Non-PDP users sending invoices via other means were excluded, which contradicts the French e-invoicing requirements ### Steps to reproduce: - Install `l10n_fr_pdp` and switch to the FR company - In Settings, ensure French Electronic Invoicing is not activated - Create and confirm an invoice (any line with tax) - Send the invoice and open the generated XML Before the fix, the `PMT`, `PMD` and `AAB` notes are missing Activating French Electronic Invoicing would include them opw-6392262 opw-6377507 Forward-Port-Of: odoo/odoo#282031 Forward-Port-Of: odoo/odoo#279966
Before this commit, deleting a record leaves its id in the relations of a record deleted before it in the same update, and reading one of those relations hands out an entry for a record that is gone. This happens because an update takes a deleted record out of the relations that hold it, but forgets it as soon as it is deleted. However, deleting a record is what queues the deletion of the records it holds: `channelMembers` carries `onDelete: (r) => r.delete()`, so the members of a thread are
Original PR description
Before this commit, deleting a record leaves its id in the relations of a record deleted before it in the same update, and reading one of those relations hands out an entry for a record that is gone. This happens because an update takes a deleted record out of the relations that hold it, but forgets it as soon as it is deleted. However, deleting a record is what queues the deletion of the records it holds: `channelMembers` carries `onDelete: (r) => r.delete()`, so the members of a thread are deleted once the thread is already forgotten, and their ids stay in its `onlineMembers`. This commit fixes the issue by keeping the records deleted by an update known until it ends. Forward-Port-Of: odoo/odoo#282381 Forward-Port-Of: odoo/odoo#281983
Many users were receiving duplicate vendor bills. The issue was that duplicates were never detected in the receiving flow. Every incoming message returned by the proxy was processed and turned into a new `account.move`, even if it had already been imported previously. This commit filters out messages whose UUID already matches an existing `account.move` before processing them, and acknowledges those duplicates on the IAP side so they are not received again on the next run. task-5930116
Original PR description
Many users were receiving duplicate vendor bills. The issue was that duplicates were never detected in the receiving flow. Every incoming message returned by the proxy was processed and turned into a new `account.move`, even if it had already been imported previously. This commit filters out messages whose UUID already matches an existing `account.move` before processing them, and acknowledges those duplicates on the IAP side so they are not received again on the next run. task-5930116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282042 Forward-Port-Of: odoo/odoo#274963
Steps to reproduce: - Make sure you have 2 or more languages installed - Install events and website app - For the website, apply the languages you have in settings - Make sure website default language is different from backend language - Create an event - Go to the event's website page through the smart button - Switch the language of the frontend to one that is different from backend - Translate (alter) the description for this language - Click on the outlook icon to download the ics
Original PR description
Steps to reproduce: - Make sure you have 2 or more languages installed - Install events and website app - For the website, apply the languages you have in settings - Make sure website default…
Steps to reproduce: - Make sure you have 2 or more languages installed - Install events and website app - For the website, apply the languages you have in settings - Make sure website default language is different from backend language - Create an event - Go to the event's website page through the smart button - Switch the language of the frontend to one that is different from backend - Translate (alter) the description for this language - Click on the outlook icon to download the ics Current Behavior: The ics will contain a description based on the backend's chosen language Expected Behavior: The ics will contain a description based on the website's chosen language. If there's no website, it will use the browser's language Clarification: The current behavior is confusing for users as they will expect the ics to match the description of the current webpage which is dependent on the frontend's selected language. This current behavior also contradicts the google calendar behavior which grabs the description based on the frontend's selected language. The endpoints for retrieving the ics file now utilize the website=True flag to take advantage of IrHttp._match which will automatically set the context language to be the frontend's rather than the backend language. We want the ics file to be in the frontend language for visual consistency. Also, send_email_reminder function does not require with context for this reason opw-6235320 Forward-Port-Of: odoo/odoo#271968
Steps to reproduce: - Install employees and attendance app - Make sure there are 2 companies - Make user's employee record for Company B, but not A - Make company A the default company for user - Enable "attendances from backend" setting - Click on the attendance dot (systray) Current Behavior: The dot disappears and you can't check in Expected Behavior: You are able to check in Other bug scenario: If you have employee records in both Company A and Company B, you can check in.
Original PR description
Steps to reproduce: - Install employees and attendance app - Make sure there are 2 companies - Make user's employee record for Company B, but not A - Make company A the default company for user - Enable "attendances from backend" setting - Click on the attendance dot (systray) Current Behavior: The dot disappears and you can't check in Expected Behavior: You are able to check in Other bug scenario: If you have employee records in both Company A and Company B, you can check in. However, you can never check in for Company B as the default company is always selected in the server code opw-6392301 Forward-Port-Of: odoo/odoo#280566 Forward-Port-Of: odoo/odoo#278377
Steps: - Install portal app. - Go to my/home page. - Click on `Edit information` button. Issue: - There is no breadcrumb in `my/account` page. Cause: - After [PR](https://github.com/odoo/odoo/pull/190312) page_name of `my/account` page `my_details` was overridden by `home` from `_prepare_portal_layout_values` method. Fix: - Set page_name `my_details` after `_prepare_portal_layout_values` method call to properly set page_name. Forward-Port-Of: odoo/odoo#279072
Original PR description
Steps: - Install portal app. - Go to my/home page. - Click on `Edit information` button. Issue: - There is no breadcrumb in `my/account` page. Cause: - After [PR](https://github.com/odoo/odoo/pull/190312) page_name of `my/account` page `my_details` was overridden by `home` from `_prepare_portal_layout_values` method. Fix: - Set page_name `my_details` after `_prepare_portal_layout_values` method call to properly set page_name. Forward-Port-Of: odoo/odoo#279072
Fixing the QR code size and Robustness for ZATCA. 1. The QR code is now an embedded image SVG instead of an image fetched from the server, which makes it robust against Webkit quirks. 2. We set the QR size in the preview screen to 200px (back to what it was before https://github.com/odoo/odoo/pull/277813), and we make the QR size on the physical receipt 300px so it's big enough to be scanned easily. More info in the respective commit messages. opw-6399766 Forward-Port-Of: odoo/odoo#28
Original PR description
Fixing the QR code size and Robustness for ZATCA. 1. The QR code is now an embedded image SVG instead of an image fetched from the server, which makes it robust against Webkit quirks. 2. We set the QR size in the preview screen to 200px (back to what it was before https://github.com/odoo/odoo/pull/277813), and we make the QR size on the physical receipt 300px so it's big enough to be scanned easily. More info in the respective commit messages. opw-6399766 Forward-Port-Of: odoo/odoo#282285
When loading the registry, borrow the request to avoid having using the cursor linked to it. Failing use case before the fix: install base odoo, in the web interface, activate and switch to a new language then install website. The installation will hang if the stable cache is invalidated because the installation may call `_` which will fallback to the request's language - reading the table from the request's cursor - while the installation tries to update the same of that same table in anothe
Original PR description
When loading the registry, borrow the request to avoid having using the cursor linked to it. Failing use case before the fix: install base odoo, in the web interface, activate and switch to a new language then install website. The installation will hang if the stable cache is invalidated because the installation may call `_` which will fallback to the request's language - reading the table from the request's cursor - while the installation tries to update the same of that same table in another cursor. Backport of odoo/odoo#281797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282514 Forward-Port-Of: odoo/odoo#281798
3 changes
Resolved issues and error corrections
Steps: - Install portal app. - Go to my/home page. - Click on `Edit information` button. Issue: - There is no breadcrumb in `my/account` page. Cause: - After [PR](https://github.com/odoo/odoo/pull/190312) page_name of `my/account` page `my_details` was overridden by `home` from `_prepare_portal_layout_values` method. Fix: - Set page_name `my_details` after `_prepare_portal_layout_values` method call to properly set page_name. Forward-Port-Of: odoo/odoo#279072
Original PR description
Steps: - Install portal app. - Go to my/home page. - Click on `Edit information` button. Issue: - There is no breadcrumb in `my/account` page. Cause: - After [PR](https://github.com/odoo/odoo/pull/190312) page_name of `my/account` page `my_details` was overridden by `home` from `_prepare_portal_layout_values` method. Fix: - Set page_name `my_details` after `_prepare_portal_layout_values` method call to properly set page_name. Forward-Port-Of: odoo/odoo#279072
Fixing the QR code size and Robustness for ZATCA. 1. The QR code is now an embedded image SVG instead of an image fetched from the server, which makes it robust against Webkit quirks. 2. We set the QR size in the preview screen to 200px (back to what it was before https://github.com/odoo/odoo/pull/277813), and we make the QR size on the physical receipt 300px so it's big enough to be scanned easily. More info in the respective commit messages. opw-6399766 Forward-Port-Of: odoo/odoo#28
Original PR description
Fixing the QR code size and Robustness for ZATCA. 1. The QR code is now an embedded image SVG instead of an image fetched from the server, which makes it robust against Webkit quirks. 2. We set the QR size in the preview screen to 200px (back to what it was before https://github.com/odoo/odoo/pull/277813), and we make the QR size on the physical receipt 300px so it's big enough to be scanned easily. More info in the respective commit messages. opw-6399766 Forward-Port-Of: odoo/odoo#282285
When loading the registry, borrow the request to avoid having using the cursor linked to it. Failing use case before the fix: install base odoo, in the web interface, activate and switch to a new language then install website. The installation will hang if the stable cache is invalidated because the installation may call `_` which will fallback to the request's language - reading the table from the request's cursor - while the installation tries to update the same of that same table in anothe
Original PR description
When loading the registry, borrow the request to avoid having using the cursor linked to it. Failing use case before the fix: install base odoo, in the web interface, activate and switch to a new language then install website. The installation will hang if the stable cache is invalidated because the installation may call `_` which will fallback to the request's language - reading the table from the request's cursor - while the installation tries to update the same of that same table in another cursor. Backport of odoo/odoo#281797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282514 Forward-Port-Of: odoo/odoo#281798
1 change
Resolved issues and error corrections
_get_all_addr() feeds the postal address block of generated pain.001 payment files, but does not return the partner's state nor the second street line. The beneficiary state/province and street complement (suite, unit, ...) therefore never appear in the generated file, even when they are set on the partner, and there is no way to fix it from the record. Some North American banks reject wire transfers whose beneficiary address lacks the state/province, so those payments fail regardless of how com
Original PR description
_get_all_addr() feeds the postal address block of generated pain.001 payment files, but does not return the partner's state nor the second street line. The beneficiary state/province and street…
_get_all_addr() feeds the postal address block of generated pain.001 payment files, but does not return the partner's state nor the second street line. The beneficiary state/province and street complement (suite, unit, ...) therefore never appear in the generated file, even when they are set on the partner, and there is no way to fix it from the record. Some North American banks reject wire transfers whose beneficiary address lacks the state/province, so those payments fail regardless of how complete the vendor record is. Return the state code and street2 alongside the other address components, from the partner for the base implementation and from the employee private address for the hr one, so the payment engine can write them in the PstlAdr block. Steps to reproduce: - Install Accounting and enable a generic ISO 20022 payment method on a bank journal - Create a vendor located in the US or Canada with a complete address, including the state and a second street line - Register a vendor payment, add it to a batch and generate the pain.001 file - The creditor PstlAdr has no state/province, and its street line only carries the first street field: the street2 part is dropped Companion enterprise PR emitting the state in the generated file: odoo/enterprise#127958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282518
4 changes
Resolved issues and error corrections
Payroll configuration now hides Mexico-specific CFDI settings when users are working in a non-Mexican company. This prevents irrelevant options from appearing and reduces confusion for companies outside Mexico.
Original PR description
Steps to reproduce: 1. Switch to a non-Mexican company. 2. Go to Payroll > Configuration > Settings. 3. The CFDI settings block is visible. Reason: The CFDI block was missing a country check. Solution: Restrict the CFDI block visibility to Mexican companies. Task-6448440 Forward-Port-Of: odoo/enterprise#127022
The Attendance Gantt view now stays focused on today when users switch between time scales, as long as today is already within the visible range. This prevents users from losing their place when moving from a weekly view back to a daily view, making scheduling and attendance review smoother.
Original PR description
**Steps to Reproduce:** 1. Open attendnace Gantt view. 2. Set the scale to Week. 3. Set the scale back to Day. The view loses focus on today. **Reason:** * Before, when changing the scale on Gantt views and shrinking it, the view would always reset to today. * This behaviour was recently changed by the JS framework team to instead anchor the new time period around the date currently centered in the viewport. **Solution:** * If the current range includes today, scale while preserving today in the range. * Otherwise, keep the current behaviour and use the center of the viewport. Task: 6346363 Forward-Port-Of: odoo/enterprise#127387
This fix ensures draft field service planning shifts are included when Equipment is enabled or initialized. It restores the expected equipment and lot information updates after an internal planning status name changed.
Original PR description
After odoo/enterprise#113153 renamed planning.slot states `draft` to `1_draft`, enabling Equipment no longer recomputed lot_ids on draft shifts because set_values/post_init still searched for state `draft` Forward-Port-Of: odoo/enterprise#127881
This fix declares a missing internal test dependency so the Mail Enterprise test suite can run reliably. It helps prevent false failures in automated checks and supports smoother delivery of future updates.
Original PR description
The test test_check_cloc_result_in_icp uses a model from test_tools, then the dependency is required. runbot-945971
2 changes
Resolved issues and error corrections
_get_all_addr() feeds the postal address block of generated pain.001 payment files, but does not return the partner's state nor the second street line. The beneficiary state/province and street complement (suite, unit, ...) therefore never appear in the generated file, even when they are set on the partner, and there is no way to fix it from the record. Some North American banks reject wire transfers whose beneficiary address lacks the state/province, so those payments fail regardless of how com
Original PR description
_get_all_addr() feeds the postal address block of generated pain.001 payment files, but does not return the partner's state nor the second street line. The beneficiary state/province and street…
_get_all_addr() feeds the postal address block of generated pain.001 payment files, but does not return the partner's state nor the second street line. The beneficiary state/province and street complement (suite, unit, ...) therefore never appear in the generated file, even when they are set on the partner, and there is no way to fix it from the record. Some North American banks reject wire transfers whose beneficiary address lacks the state/province, so those payments fail regardless of how complete the vendor record is. Return the state code and street2 alongside the other address components, from the partner for the base implementation and from the employee private address for the hr one, so the payment engine can write them in the PstlAdr block. Steps to reproduce: - Install Accounting and enable a generic ISO 20022 payment method on a bank journal - Create a vendor located in the US or Canada with a complete address, including the state and a second street line - Register a vendor payment, add it to a batch and generate the pain.001 file - The creditor PstlAdr has no state/province, and its street line only carries the first street field: the street2 part is dropped Companion enterprise PR emitting the state in the generated file: odoo/enterprise#127958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The `modifiers` attribute was used in older Odoo versions to define field properties (invisible, readonly, required, etc.) Since the field already declares these same properties directly [state](https://github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L150-L155) , [amount_tax_signed](https://github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L229) (e.g. `invisible=...`, `readonly=...`), the `modifiers` attribute is redundant and serves no purpose. This a
Original PR description
The `modifiers` attribute was used in older Odoo versions to define field properties (invisible, readonly, required, etc.) Since the field already declares these same properties directly…
The `modifiers` attribute was used in older Odoo versions to define field properties (invisible, readonly, required, etc.) Since the field already declares these same properties directly [state](https://github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L150-L155) , [amount_tax_signed](https://github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L229)
(e.g. `invisible=...`, `readonly=...`), the `modifiers` attribute is redundant and serves no purpose.
This attribute was never added manually by us — it was auto-generated by Odoo Studio when the default view was created. Studio's default views inject `modifiers` alongside the direct attributes. [Here](https://github.com/odoo/odoo/pull/104741/changes/975e875046691c898e8c1acb87d3626cd299e5aa#diff-dfebe5a93e1b8880e88268b024be4c6f106d144b20298d7bb6c4ae09a18bafd0L67-L145)
Also the `modifiers` attribute was fully simplified [removed](https://github.com/odoo/odoo/pull/104741/changes/975e875046691c898e8c1acb87d3626cd299e5aa#diff-849f1ed2a35a8b0b9cdd67f8e34de5d2ea7bf928103a83828587ba7ec14a62e4L52) starting from version 17.0, where views rely exclusively on direct attribute expressions (`invisible`, `readonly`, `required`) instead of the `modifiers` JSON encoding [main Patch](https://github.com/odoo/odoo/pull/104741) Keeping it around in the arch is therefore dead code with no effect.
However it needs to give the error on 17.0+ like this
```
ERROR LOG:
<string>:1:0:ERROR:RELAXNGV:RELAXNG_ERR_NOELEM: Expecting an element data, got nothing
<string>:1:0:ERROR:RELAXNGV:RELAXNG_ERR_INVALIDATTR: Invalid attribute modifiers for element field
<string>:1:0:ERROR:RELAXNGV:RELAXNG_ERR_EXTRACONTENT: Element tree has extra content: field
```
As the modifer has been remove from the field [common.rng](https://github.com/odoo/odoo/pull/104741/changes/975e875046691c898e8c1acb87d3626cd299e5aa#diff-849f1ed2a35a8b0b9cdd67f8e34de5d2ea7bf928103a83828587ba7ec14a62e4L52) RelaxNG schema but modifiers set on fields here root tag is **form**, and the modifiers sit on fields inside a nested list. And Form views aren't RNG-validated from 17.0 till now —
[@validate('calendar', 'graph', 'pivot', 'search', 'list', 'activity')](https://github.com/odoo/odoo/blob/f0e58b9324af18d0cf0264aec2886d098e997f03/odoo/tools/view_validation.py#L314) has no form, and there's no [form_view.rng](https://github.com/odoo/odoo/tree/19.0/odoo/addons/base/rng).
Current senario
<img width="998" height="415" alt="image" src="https://github.com/user-attachments/assets/1a678c8f-8401-4e12-826f-9e98f6f2fe20" />
After removing the modifer: it show the same view because of field property
<img width="998" height="415" alt="image" src="https://github.com/user-attachments/assets/1a678c8f-8401-4e12-826f-9e98f6f2fe20" />
After removing the modifer still it shows the **modifiers="{'readonly':true, 'required':true}"** because the modifer is stay in the 14.0 but the 17.0 onwards it was not please see the scrrenshot its field preprty always.
<img width="1003" height="462" alt="image" src="https://github.com/user-attachments/assets/5e833924-b17c-417f-9e63-5a01c185f588" />
This Fix removes the unused `modifiers` attribute from the view arch, keeping only the direct attribute already present, with no functional change to the view's behavior.
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#280282
Forward-Port-Of: odoo/odoo#279976