Tuesday, February 25, 2025
45 changes · 18.0
Enhancements to existing features
This update reorganizes shared email testing tools so other areas can use a lighter test foundation without loading unnecessary sample data. It helps keep automated tests easier to maintain and reduces avoidable dependencies across related modules.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Odoo now includes the required authentication header when returning a 401 response for bearer-token protected routes. This improves standards compliance and helps integrations handle authentication failures more reliably.
Original PR description
There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the response which is only defined for http auth schemes (basic, digest, bearer, ...), but we don't use thoses schemes with Odoo. One place where we are correctly using the 401-Unauthorized response is with `@route(auth='bearer')`, but it lacked the `WWW-Authenticate` header to be fully compliant with the http. > The server generating a 401 response MUST send a WWW-Authenticate > header field containing at least one challenge applicable to the > target resource. https://httpwg.org/specs/rfc9110.html#status.401 https://httpwg.org/specs/rfc9110.html#field.www-authenticate https://github.com/odoo/odoo/pull/199063
Miscellaneous changes
config['demo'] is always set at runtime, there is no point in saving it as it is basically ignored from the config file. Forward-Port-Of: odoo/odoo#198387 Forward-Port-Of: odoo/odoo#189032
Original PR description
config['demo'] is always set at runtime, there is no point in saving it as it is basically ignored from the config file. Forward-Port-Of: odoo/odoo#198387 Forward-Port-Of: odoo/odoo#189032
Updating account translations can encounter tags that were added after a release. This change prevents the process from crashing in that situation and records an error instead, helping language updates continue more reliably.
Original PR description
Sometimes, a tag is added after the release (e.g. f221381fbdf8) and this lead to an error when load_account_translations is executed (e.g. when updating a language translations). Do not crash but log an error instead.
This fixes an issue where Point of Sale managers could not see margin and cost information in the product information pop-up, even when they had the expected advanced access rights. After the change, authorized managers can access the same profitability details as intended, improving visibility during sales operations.
Original PR description
Description of the issue/feature this PR addresses: - Create POS, set login with employees, assign an employee as advanced user (manager) - Disable margin & costs configuration - Open POS, click the information icon in Product Screen - Margin & costs is not visible Current behavior before PR: - In POS the margin & costs is not visible with advanced access rights (manager) Desired behavior after PR is merged: - Show the margin & costs information in product information pop up --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures Odoo returns the proper authentication instruction when bearer-token access is denied. It improves standards compliance for API integrations and helps external systems handle authentication failures more reliably.
Original PR description
There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the…
There are many places where we use 401-Unauthorized where we really should be using 403-Forbidden instead. That's because 401-Unauthorized mandates using the `WWW-Authenticate` header with the response which is only defined for http auth schemes (basic, digest, bearer, ...), but we don't use thoses schemes with Odoo. One place where we are correctly using the 401-Unauthorized response is with `@route(auth='bearer')`, but it lacked the `WWW-Authenticate` header to be fully compliant with the http. > The server generating a 401 response MUST send a WWW-Authenticate > header field containing at least one challenge applicable to the > target resource. https://httpwg.org/specs/rfc9110.html#status.401 https://httpwg.org/specs/rfc9110.html#field.www-authenticate 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
Section lines in generated PDF reports now show the expected gray background again instead of appearing only in bold. This restores the previous visual distinction for grouped sections in sales quotations and other reports, making documents easier to read and consistent with earlier versions.
Original PR description
### Steps to reproduce: - Go to Sale, create a quotation with section lines - Confirm and send - The generated PDF have section lines that are only bold (no background color) - In v17.0 sections…
### Steps to reproduce: - Go to Sale, create a quotation with section lines - Confirm and send - The generated PDF have section lines that are only bold (no background color) - In v17.0 sections lines were gray ### Cause: It was removed during a refactoring. Section lines with the "boxed" template were still supposed to be gray, but the code was `&.o_line_section td` inside of a `tbody` element, so the `&` referenced `tbody` and not `tr` on which the class `o_line_section` is added: https://github.com/odoo/odoo/blob/ddb03a55ac94b9fd48ae6ce138e70c0070bedd36/addons/account/views/report_invoice.xml#L131 ### Solution: Replace `&` by `tr` and move the change of background color to all tables, so affecting all reports. ###Before / After: "Light" template   "DIN5008" template   opw-4572732
Fixes an issue that prevented users from filtering account placeholder codes from the interface. Searches such as "starts with" and "ends with" now work correctly, avoiding invalid filter errors.
Original PR description
Current behavior before PR: - After this [fix](https://github.com/odoo/odoo/commit/56d5c9f4861b3509043660c97a702bfe0e636e3f) , any type searching is not possible for `placeholder_code` field. - For every filter applied, it just return `invalid domain error`. - this is because ` _search_placeholder_code` uses `=like` operator, but this makes it, unsearchable from frontend, as filters supports `ilike` and its related operators.  Desired behavior after PR is merged: - This PR fixes this issue, by changing the operator from `=like` -> `=ilike` - `placeholder_code` field can now be searched for filters like `starts with` and `ends with` .  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The IAP module now handles connection failures more cleanly when external Odoo services cannot be reached. This prevents low-level connection errors from surfacing and helps keep error handling consistent for users and support teams.
Original PR description
This error occurs when the `IAP` service is `unreachable` when calling the JSON-RPC in IAP. ConnectionError: HTTPSConnectionPool(host='extract.api.odoo.com', port=443) At [1] `ValueError` is now raised and handled connection errors separately because this can also be raised from `requests.post` This commit will raise a `ValueError` instead of the `ConnectionError` Link [1] : https://github.com/odoo/odoo/blob/62ca36f5a347a230eda3cec2d31797fef0c7a13d/addons/iap/tools/iap_tools.py#L140 Sentry - 6280660773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes several automated guided tests more reliable by adding waits and timing adjustments where pages or editors were not ready yet. It also modernizes barcode test coverage, helping reduce false failures and improve confidence in future changes without changing customer-facing features.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Delivery reports now show the shipping weight based only on products that are actually set to ship, even before the delivery is completed. This prevents overstated package weights when some items on an order have zero quantity to deliver.
Original PR description
Steps to reproduce the bug:
- Create two storable products:
- P1, weight: 1KG
- P2, weight: 2KG
- Create a delivery order:
- 1 unit of P1 and P2
- Mark it as "To Do"
- Set the quantity to 1 for P1 and 0 for P2
- Print the operation type
Problem:
Only product P1 appears in the report, but the total weight is 3KG instead of 1KG.
opw-4547704This fixes an unreliable automated test in the inventory batch picking area by ensuring the test updates the intended single-line picking. It helps keep validation builds stable and reduces false failures during development, with no expected impact on end users.
Original PR description
This commit avoids random error in test_group_by_country_and_product For more information: - https://runbot.odoo.com/odoo/action-573/114881 - https://runbot.odoo.com/odoo/runbot.build.error/116798 The error is caused because there are two pickings: one with a single move and the other with two moves. In the test, we should modify the move line that is alone. Since the order was not checked, the action done for the wave could return a wizard to create a backorder because we modified the quantity of a move line to 0 in a picking that has multiple move lines.
This pull request mainly streamlines internal test setup across several Odoo Enterprise apps, reducing unnecessary mail-related test data and making tests easier to maintain. It also prevents marketing automation processes from committing database changes during test mode, improving reliability and supporting future scalability work.
Manufacturing planning cells now stay on one line unless their contents would overflow, making the view cleaner while still readable. The update also improves demand cell colors for dark mode and preserves spacing around separators.
Original PR description
Due to input cell overflow, a stopgap solution was to always display demand and replenish cells on 2 lines when actual and forecasted/replenish were both activated. This is considered sub-optimal and this fix was made. When the view is loaded or reloaded due to manual changes, the DOM is updated depending on if overflow is detected in input cells. task 4420441
This update makes an automated test for Ecuador electronic delivery guides use a fixed date. That prevents date-related failures and helps ensure future checks remain reliable without changing user-facing behavior.
Original PR description
In 33509a095 we introduced a check on the data sent to the SRI. The data depends on the current date, but the test didn't execute in a `freeze_time` block. We now fix this. task-none
Spreadsheet pivot tables now match day-of-week values correctly for users in languages where weeks do not start on Sunday. This prevents users from opening the wrong underlying records when reviewing pivot results.
Original PR description
See community PR Steps to reproduce: - change your language to French (or any language which doesn't the week on Sundays) - insert a pivot into a spreadsheet - insert the dynamic version with =PIVOT(1) - change the row groups to "Day of week" - right click on any pivot value and "See records" => the day of week displayed in spreadsheet doesn't match the records. Task: 4591993
The Wi-Fi disconnection method was still unlinking an old configuration file, which is now replaced by the `odoo.conf` file. This fix replaces the file unlinking by a coniguration file update. Task: 4592796 Forward-Port-Of: odoo/odoo#198962
Original PR description
The Wi-Fi disconnection method was still unlinking an old configuration file, which is now replaced by the `odoo.conf` file. This fix replaces the file unlinking by a coniguration file update. Task: 4592796 Forward-Port-Of: odoo/odoo#198962
Debugging outgoing emails is fastidious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back who the recipients were. In this work we also log the (redacted) From and To headers. We decided to redact the headers out of excessive caution regarding the GDPR. The new `email_anonymize` function must balance disambiguation and redaction. Disambiguation so it is easy to tell two different emai
Original PR description
Debugging outgoing emails is fastidious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back…
Debugging outgoing emails is fastidious. Only the mail record id and Message-Id are logged, but most of the time the mail record is removed once the mail is sent, making it impossible to find back who the recipients were. In this work we also log the (redacted) From and To headers. We decided to redact the headers out of excessive caution regarding the GDPR. The new `email_anonymize` function must balance disambiguation and redaction. Disambiguation so it is easy to tell two different email addresses appart (for debugging). Redaction so it hard to find the original email address back (for privacy). It must also be simple. We conducted several experiments using a dataset of 600ish email address (95% of which have a local part that is at least 6 characters long) to determine a nice function. The final function keep the first character for shorter inputs (length of local part < 6) and the first plus two lasts chars for longer inputs (>=6). Using that function we achieve a 99% disambiguation of emails in the dataset (with or without redacting the domain) while retaining minimal info (3 chars at most). Redacting the domain isn't that useful as most addresses use gmail, hotmail, outlook, yahoo. Task-4361561 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#194507 Forward-Port-Of: odoo/odoo#188697
Indonesia officially added new provinces in 2022. - Papua Barat Daya was forgotten in an old PR. - Papua Pengunungan was assigned ISO code PE, not PP. In 16.0, we just change the ISO code. The XMLID will be corrected in master. Codes: https://www.geonames.org/ID/administrative-division-indonesia.html Official Document: https://peraturan.bpk.go.id/Details/232726/uu-no-29-tahun-2022 Wikipedia in English: https://en.wikipedia.org/wiki/Provinces_of_Indonesia Original PR: odoo/
Original PR description
Indonesia officially added new provinces in 2022. - Papua Barat Daya was forgotten in an old PR. - Papua Pengunungan was assigned ISO code PE, not PP. In 16.0, we just change the ISO code. The XMLID will be corrected in master. Codes: https://www.geonames.org/ID/administrative-division-indonesia.html Official Document: https://peraturan.bpk.go.id/Details/232726/uu-no-29-tahun-2022 Wikipedia in English: https://en.wikipedia.org/wiki/Provinces_of_Indonesia Original PR: odoo/odoo#193103 Forward-Port-Of: odoo/odoo#199035
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value. Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field
Original PR description
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given…
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value. Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field `team_id` is added. This field is a computed-stored field with a callable set as default. Because the default attr is defined, the ORM skips the call to the compute method and calls the default function instead when the team_id param is not given upon creation. That means that for each account.move, `_get_default_team_id` is called. Since the purpose of a compute function is already to give default values to record, removing the default callable allows to benefit from the batching of compute functions. #### speedup Test database with account_accountant and sale. Trying to create batches of account.moves | Batch size | Before PR | After PR | |:----------:|:---------:|:--------:| | 1 | 70ms | 58ms | | 50 | 150ms | 100ms | | 100 | 275ms | 188ms | | 250 | 660ms | 450ms | | 1000 | 2.43s | 1.75s | | 3000 | 7.55s | 5.33s | Average speedup: 68%. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160313 Forward-Port-Of: odoo/odoo#157887
- In calendar, when only one employee (different from the user) was selected as an attendeed in the calendar sidebar, the working location of this employee was not displayed. To work around this, switch to `multiCalendar` in that case. - When the current user was not selected as an attendee, it was possible to add a working location for the user on a day even if there was already an exisiting one. To avoid this, always fetch the user's working location to check if one already exists for a giv
Original PR description
- In calendar, when only one employee (different from the user) was selected as an attendeed in the calendar sidebar, the working location of this employee was not displayed. To work around this, switch to `multiCalendar` in that case. - When the current user was not selected as an attendee, it was possible to add a working location for the user on a day even if there was already an exisiting one. To avoid this, always fetch the user's working location to check if one already exists for a given day, but only display them if the user's filter is active. - Work locations were not displayed when "Everybody's calendar" was selected because the elements of `attendeeIds` had the wrong type. opw-4373391 Forward-Port-Of: odoo/odoo#192023
**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the corresponding stock.move.line still retains the old product (Product A). This leads to inconsistent data between stock.move and stock.move.line, which can cause inaccurate inventory reports and accounting records. **Steps to Reproduce** 1. Create a BoM (Bill of Materials) that includes Product A
Original PR description
**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the…
**Issue Description** When producing a product in Odoo and changing the by-product from Product A to Product B, the stock.move record gets updated to reflect the new product (Product B), but the corresponding stock.move.line still retains the old product (Product A). This leads to inconsistent data between stock.move and stock.move.line, which can cause inaccurate inventory reports and accounting records. **Steps to Reproduce** 1. Create a BoM (Bill of Materials) that includes Product A as a by-product with a quantity of 1. 2. Create a Manufacturing Order (MO) from this BoM. 3. Confirm the MO and set it to In Progress. 4. In the MO interface: Change the by-product from Product A to Product B. 5. Complete the MO. https://github.com/user-attachments/assets/811e181d-894d-4605-aeb9-027ff379d40d **Current Behavior** The product in the stock.move is updated to Product B. However, the product in the related stock.move.line remains as Product A. **Expected Behavior** The byproduct's product_id shouldn't even be editable in the first place when the MO has already been confirmed (as it is for components). It would be worth to add the same kind of readonly condition on the byproduct side as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198522 Forward-Port-Of: odoo/odoo#194972
The CRON has to search for documents that are not in error because they are filtered out in _process_jobs. Without that, the documents are retrieved, not processed but the cron is triggered again and again endlessly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198973
Original PR description
The CRON has to search for documents that are not in error because they are filtered out in _process_jobs. Without that, the documents are retrieved, not processed but the cron is triggered again and again endlessly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198973
This commit fills in the missing prop of the ShortcutsFooterComponent which was forgotten in https://github.com/odoo/odoo/commit/dd583fd670e0ee03b04711780bad2429b18a0788 Forward-Port-Of: odoo/odoo#199057
Original PR description
This commit fills in the missing prop of the ShortcutsFooterComponent which was forgotten in https://github.com/odoo/odoo/commit/dd583fd670e0ee03b04711780bad2429b18a0788 Forward-Port-Of: odoo/odoo#199057
Issue: ======== In `SplitBillScreenTour2`, navigating back and forth between **FloorScreen** and **ProductScreen** triggered a `SyncAllOrders` call. Immediately after, another `SyncAllOrders` call was sent from `createSplittedOrder`. Since the first request was still in progress, the second request sometimes sent only one order to the backend. This caused the original order to be filtered out from `syncingOrders`, leading to inconsistencies. Fix: ======= Step were added to check tha
Original PR description
Issue: ======== In `SplitBillScreenTour2`, navigating back and forth between **FloorScreen** and **ProductScreen** triggered a `SyncAllOrders` call. Immediately after, another `SyncAllOrders` call was sent from `createSplittedOrder`. Since the first request was still in progress, the second request sometimes sent only one order to the backend. This caused the original order to be filtered out from `syncingOrders`, leading to inconsistencies. Fix: ======= Step were added to check that the request is processed. **Runbot Error**: 114938 Forward-Port-Of: odoo/odoo#198326
The Romanian SPV servers are slow. When sending a request to them, we previously set a hard timeout limit at 10 seconds and mark the request as failed if it exceeds it. However, recently we have found a critical issue where some users found that their invoice has been sent twice (or more) to the Romanian SPV. After investigating, we found that what's likely to happen is that the SPV takes more than 10 seconds to send the response back when we're making a request, and since in our side we c
Original PR description
The Romanian SPV servers are slow. When sending a request to them, we previously set a hard timeout limit at 10 seconds and mark the request as failed if it exceeds it. However, recently we have…
The Romanian SPV servers are slow. When sending a request to them, we previously set a hard timeout limit at 10 seconds and mark the request as failed if it exceeds it. However, recently we have found a critical issue where some users found that their invoice has been sent twice (or more) to the Romanian SPV. After investigating, we found that what's likely to happen is that the SPV takes more than 10 seconds to send the response back when we're making a request, and since in our side we consider the request as failed and requires the user to send a new request again, we make the user send a second request on the same invoice, where the SPV actually acknowledges all of the received invoices. After discussing with the PO, a temporary workaround for now is to increase the timeout limit to 60 seconds (1 full minute) to reduce the likelihood of this issue happening, and log error messages on the chatter if the request (either for send/fetch/download) failed, so that the user are aware when it is timeout and be more wary not to send another request right away, in case the new timeout limit are still not enough. Other small changes in this PR: - Handle response code 401, (which is a JSON object, invalid access token) - Remove the "Error when sending the document to the SPV:" template in error documents (because not all error documents are for sending, some are from fetch/download) opw-4571713 Forward-Port-Of: odoo/odoo#198876 Forward-Port-Of: odoo/odoo#198604
**[FIX] account: fix empty string and False/None inconsistencies** When empty, the `name` field of `account.move.line` could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as `label->not set` and `label == ""` yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is an empty string, standa
Original PR description
**[FIX] account: fix empty string and False/None inconsistencies** When empty, the `name` field of `account.move.line` could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as `label->not set` and `label == ""` yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is an empty string, standardizing search behavior. opw-4167139 [Enterprise PR](https://github.com/odoo/enterprise/pull/73256) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189099 Forward-Port-Of: odoo/odoo#186079
Before this patch, if a billing user (without any administration settings level) tried to cancel a posted invoice and clicked on the "Process now" button, they got an exception. In particular, it happened because those users shouldn't have access to stuff such as the certificate, its password or the contents of the sent EDI attachment. However, they should be able to post the documents using whatever configuration the sysadmin saved. Thus, I use some `sudo()` calls and add a test to assert
Original PR description
Before this patch, if a billing user (without any administration settings level) tried to cancel a posted invoice and clicked on the "Process now" button, they got an exception. In particular, it…
Before this patch, if a billing user (without any administration settings level) tried to cancel a posted invoice and clicked on the "Process now" button, they got an exception. In particular, it happened because those users shouldn't have access to stuff such as the certificate, its password or the contents of the sent EDI attachment. However, they should be able to post the documents using whatever configuration the sysadmin saved. Thus, I use some `sudo()` calls and add a test to assert it won't break anymore. **How to test functionally:** 1. Configure a Spanish company. 2. Install `l10n_es_edi_tbai` and configure it. 3. Switch to a user that only has "Invoicing / Billing" permissions. 4. Post an invoice. 5. Send it to tbai. 6. Request EDI cancellation. 7. Send it to tbai. 8. It should work now. @moduon MT-8894 OPW-4535149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196086 Forward-Port-Of: odoo/odoo#195981
The module base_vat add a div around the vat field and so the xpath place the field in the div which is not what we want. By putting it after the address we are sure that those field are rightly placed task: 4543204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196598
Original PR description
The module base_vat add a div around the vat field and so the xpath place the field in the div which is not what we want. By putting it after the address we are sure that those field are rightly placed task: 4543204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196598
Steps to reproduce: - Set up the editor with a link at the end of a line. - Refresh to start with fresh content. - Place the cursor at the end of the line with the link. - Notice that the cursor defaults inside the link, displaying the green overlay. - Attempt to type after the link—this requires pressing right arrow key to exit. Description of the issue/feature this PR addresses: - Clicking at the end or start of a line with a link placed the cursor inside the link by default, disp
Original PR description
Steps to reproduce: - Set up the editor with a link at the end of a line. - Refresh to start with fresh content. - Place the cursor at the end of the line with the link. - Notice that the cursor defaults inside the link, displaying the green overlay. - Attempt to type after the link—this requires pressing right arrow key to exit. Description of the issue/feature this PR addresses: - Clicking at the end or start of a line with a link placed the cursor inside the link by default, displaying the green overlay. - Typing outside the link required pressing the arrow key. Current behavior before PR: - Placing the cursor at the start or end of a line with a link now defaults to positioning it outside the link. - Green overlay is no longer shown, enabling direct text entry beside link. - Accessing the link requires an intentional left or right arrow key press. task-4089085 Forward-Port-Of: odoo/odoo#186213
Currently, if an email containing a `.eml` attachment is sent, that attachment won't be able to be downloaded correctly depending on the email client used; the attachment will download, but will have a size zero. ### Steps to reproduce * On any chatter, send a message containing a `.eml` attachment (another email file). * Using Thunderbird, attempt to download that attachment. The downloaded attachment will be empty (0 kB). ### Cause The `.eml` file format, which represents an em
Original PR description
Currently, if an email containing a `.eml` attachment is sent, that attachment won't be able to be downloaded correctly depending on the email client used; the attachment will download, but will have…
Currently, if an email containing a `.eml` attachment is sent, that attachment won't be able to be downloaded correctly depending on the email client used; the attachment will download, but will have a size zero. ### Steps to reproduce * On any chatter, send a message containing a `.eml` attachment (another email file). * Using Thunderbird, attempt to download that attachment. The downloaded attachment will be empty (0 kB). ### Cause The `.eml` file format, which represents an email message, has the MIME type `message/rfc822`. According to [RFC 2046 Section 5.2.1](https://datatracker.ietf.org/doc/html/rfc2046#section-5.2.1:~:text=No%20encoding%20other%20than%20%227bit%22%2C%20%228bit%22%2C%20or%20%22binary%22%20is%20permitted%20for%0A%20%20%20the%20body%20of%20a%20%22message/rfc822%22%20entity.), attachments of this MIME type must be encoded using `7bit`, `8bit`, or `binary`. However, the system currently encodes all attachments using Base64 by default, which is not compliant with the standard for `message/rfc822`. Although some email clients tolerate Base64 encoding for `message/rfc822`, others, such as Thunderbird, Roundcube, and Zimbra, strictly follow the RFC and reject Base64-encoded `message/rfc822` attachments. As a result, these attachments appear invalid and are downloaded as empty files. opw-4126522 Forward-Port-Of: odoo/odoo#198862 Forward-Port-Of: odoo/odoo#194988
Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle customer accounts. Steps to reproduce: ------------------- * Install **l10n_es_pos** and switch to the ES Company * Open shop session * Add products to the order, select any customer, pay with customer account * Select **New order** * Select the previous customer and select **Settle due accou
Original PR description
Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle…
Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle customer accounts. Steps to reproduce: ------------------- * Install **l10n_es_pos** and switch to the ES Company * Open shop session * Add products to the order, select any customer, pay with customer account * Select **New order** * Select the previous customer and select **Settle due accounts** * Select any payment method * Validate order -> Yes > Observation: Cannot invoice empty order Why the fix: ------------ Spain requires to invoice all orders. In Pos, everything is considered as an order but settling customer accounts does not fall under the definition of an order outside of Odoo (no transfer of product, amount=0). Therefore when we settle customer account we skip the automatic invoicing and fallback on the pos bahavior without the localization. opw-4185144 Enterprise PR: https://github.com/odoo/enterprise/pull/71958 Forward-Port-Of: odoo/odoo#185375 Forward-Port-Of: odoo/odoo#183682
Currently, an error may occur when we try to export the trial balance with the SAT (XML) format. This is because the account_group ID is used to browse the account, due to a more specific account_group. Steps to reproduce: 1. Install l10n_mx_reports. 2. Create an account_group with a more specific account, such as 401.01.01 - The 4, 401, and 401.01 groups are created with demo data. 3. Go to trial balance and try exporting with "SAT (XML)". 4. An error will occur (Missing Record) beca
Original PR description
Currently, an error may occur when we try to export the trial balance with the SAT (XML) format. This is because the account_group ID is used to browse the account, due to a more specific account_group. Steps to reproduce: 1. Install l10n_mx_reports. 2. Create an account_group with a more specific account, such as 401.01.01 - The 4, 401, and 401.01 groups are created with demo data. 3. Go to trial balance and try exporting with "SAT (XML)". 4. An error will occur (Missing Record) because the account_group ID is used to browse the account. This fix does two things: 1. It ensures that only account.account lines are considered. 2. It changes the line length condition from `= 4` to `>= 4` to handle more specific grouping. opw-4537859 Forward-Port-Of: odoo/enterprise#80128
The kanban has been reworked with https://github.com/odoo/odoo/pull/167751 and odoo/enterprise@23426182d92198cf977d7eecbfb3d47117d80c59 Before this commit when a field is empty (the record has no value for a field) in the kanban editor -- new version -- that field had no size and was virtually invisible. This was because one little line of code was missing to enable the feature of applying a placeholder in the empty field to make it visible. opw-4526492 Forward-Port-Of: odoo/enterprise
Original PR description
The kanban has been reworked with https://github.com/odoo/odoo/pull/167751 and odoo/enterprise@23426182d92198cf977d7eecbfb3d47117d80c59 Before this commit when a field is empty (the record has no value for a field) in the kanban editor -- new version -- that field had no size and was virtually invisible. This was because one little line of code was missing to enable the feature of applying a placeholder in the empty field to make it visible. opw-4526492 Forward-Port-Of: odoo/enterprise#79812
In the expense app, a button enables to refund an expense directly in the payslip. This button is however not visible for payroll manager, while the action behind is. This commit solves the issue. task-4570975 Forward-Port-Of: odoo/enterprise#79879 Forward-Port-Of: odoo/enterprise#79570
Original PR description
In the expense app, a button enables to refund an expense directly in the payslip. This button is however not visible for payroll manager, while the action behind is. This commit solves the issue. task-4570975 Forward-Port-Of: odoo/enterprise#79879 Forward-Port-Of: odoo/enterprise#79570
In the follow up process, while the wizard's text is displayed correctly, the text in the chatter and in the pdf would contain too many carriage returns. The error is linked to the use of the text widget in the xml, which doesn't seem necessary in this case and is therefore removed. task-4574941 Forward-Port-Of: odoo/enterprise#79925 Forward-Port-Of: odoo/enterprise#79517
Original PR description
In the follow up process, while the wizard's text is displayed correctly, the text in the chatter and in the pdf would contain too many carriage returns. The error is linked to the use of the text widget in the xml, which doesn't seem necessary in this case and is therefore removed. task-4574941 Forward-Port-Of: odoo/enterprise#79925 Forward-Port-Of: odoo/enterprise#79517
Steps to reproduce: - With an MX Company Setup - Issue an invoice with external trade - Print pdf Issue: Partner original RFC is shown, but according to our documentation [1] and official documentation [2] as well, we should display the generic RFC for external partners XEXX010101000 [1] https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/mexico.html#external-trade [2] https://www.sat.gob.mx/articulo/99662/articulo-29-a page 59 "15. ¿Qué datos debe cont
Original PR description
Steps to reproduce: - With an MX Company Setup - Issue an invoice with external trade - Print pdf Issue: Partner original RFC is shown, but according to our documentation [1] and official documentation [2] as well, we should display the generic RFC for external partners XEXX010101000 [1] https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/mexico.html#external-trade [2] https://www.sat.gob.mx/articulo/99662/articulo-29-a page 59 "15. ¿Qué datos debe contener la versión impresa del comprobante fiscal? En la representación impresa se incluirán como mínimo los datos establecidos en la regla 2.7.1.7. de la RMF. Fundamento: Regla 2.7.1.7. de la RMF. " opw-4473180 Forward-Port-Of: odoo/enterprise#79979 Forward-Port-Of: odoo/enterprise#79527
**[FIX] account_asset: fix empty string and False/None inconsistencies** (adapting tests) When empty, the name field of account.move.line could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as label->not set and label == "" yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is
Original PR description
**[FIX] account_asset: fix empty string and False/None inconsistencies** (adapting tests)
When empty, the name field of account.move.line could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as label->not set and label == "" yielded different outcomes. The latter behavior aligns with expected ORM operations.
This fix ensures the name field is set to False whenever the computed result is an empty string, standardizing search behavior. We also adapt some tests to the new behavior in enterprise.
opw-4167139
[community PR](https://github.com/odoo/odoo/pull/186079)
Forward-Port-Of: odoo/enterprise#74855
Forward-Port-Of: odoo/enterprise#73256After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that defined that for any line having `caret_options`, we wouldn't use bold. Because of this, reports like the general ledger would display all detail lines indicating journal entries in bold (since they are in level 2). This looks very crowded and not very readable at all. In this commit, we improv
Original PR description
After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that…
After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that defined that for any line having `caret_options`, we wouldn't use bold. Because of this, reports like the general ledger would display all detail lines indicating journal entries in bold (since they are in level 2). This looks very crowded and not very readable at all. In this commit, we improve the styling rules to always disable bold on the deepest line level. That way we can never have a XLSX file with all lines in bold, and it is much easier to read the file. Meanwhile, the style management was refactored a bit to make it simpler. [opw-4501822](https://www.odoo.com/odoo/project.task/4501822) [opw-4458752](https://www.odoo.com/odoo/project.task/4458752) [indentation fix]: https://github.com/odoo/enterprise/commit/9246a864f91e7facd06fa630fa0d23a0323ce497 Forward-Port-Of: odoo/enterprise#79764 Forward-Port-Of: odoo/enterprise#77510
Problem Before this commit, if the customer deletes the rental location they would be blocked from creating a rental order as it is necessary for replenishment rules. The issue becomes critical because, once deleted, the rental location cannot be set to the company functionally given the field is not present in the view. Solution To fix this, this commit adds Rental Settings making the rental_loc_id field visible in the res_company view, allowing customers to select their desired rental
Original PR description
Problem Before this commit, if the customer deletes the rental location they would be blocked from creating a rental order as it is necessary for replenishment rules. The issue becomes critical because, once deleted, the rental location cannot be set to the company functionally given the field is not present in the view. Solution To fix this, this commit adds Rental Settings making the rental_loc_id field visible in the res_company view, allowing customers to select their desired rental location and resolve the issue independently. - opw-3973957 - opw-4488182 - opw-4545985 Forward-Port-Of: odoo/enterprise#79894 Forward-Port-Of: odoo/enterprise#79785
Because of the countries flag set in the module manifest, the module was set to be auto-installed only when there was a company with country 'CZ' existing. Although this can't really be pointed as a mistake, it was causing an error in account_reports TestAllReportsGeneration.test_generate_all_export_files, as we'd be simply installing the module l10n_cz_reports and expect everything to be set and tested. runbot error: 114355 Forward-Port-Of: odoo/enterprise#79524
Original PR description
Because of the countries flag set in the module manifest, the module was set to be auto-installed only when there was a company with country 'CZ' existing. Although this can't really be pointed as a mistake, it was causing an error in account_reports TestAllReportsGeneration.test_generate_all_export_files, as we'd be simply installing the module l10n_cz_reports and expect everything to be set and tested. runbot error: 114355 Forward-Port-Of: odoo/enterprise#79524
This commit introduces an easy way to recognize "orders" which are intended to settle customer accounts. opw-4185144 Community PR: https://github.com/odoo/odoo/pull/183682 Forward-Port-Of: odoo/enterprise#72843 Forward-Port-Of: odoo/enterprise#71958
Original PR description
This commit introduces an easy way to recognize "orders" which are intended to settle customer accounts. opw-4185144 Community PR: https://github.com/odoo/odoo/pull/183682 Forward-Port-Of: odoo/enterprise#72843 Forward-Port-Of: odoo/enterprise#71958
Steps to reproduce the bug: - Create a “quality.point”: - Operations: Manufacturing - Add a Work Order Operation - save - Update the operations to Receipt. Problem: The Work Order Operation field becomes invisible, but it is still filled so the quality point will still be applied. opw-4536136 Forward-Port-Of: odoo/enterprise#79929 Forward-Port-Of: odoo/enterprise#79868
Original PR description
Steps to reproduce the bug:
- Create a “quality.point”:
- Operations: Manufacturing
- Add a Work Order Operation
- save
- Update the operations to Receipt.
Problem:
The Work Order Operation field becomes invisible, but it is still filled so the quality point will still be applied.
opw-4536136
Forward-Port-Of: odoo/enterprise#79929
Forward-Port-Of: odoo/enterprise#79868The appointment addon adds the `@mail/utils/common/format` module to the frontent assets. However, this module depends on another one: `@mail/utils/common/html`, which isn't there. As a consequence there's a red banner displayed in the bottom left corner, indicating that there's an odoo module issue, in all websites when the appointment addon is installed. This is causing a lot of trouble with free trials. This commit adds the missing dependency. Forward-Port-Of: odoo/enterprise#80079
Original PR description
The appointment addon adds the `@mail/utils/common/format` module to the frontent assets. However, this module depends on another one: `@mail/utils/common/html`, which isn't there. As a consequence there's a red banner displayed in the bottom left corner, indicating that there's an odoo module issue, in all websites when the appointment addon is installed. This is causing a lot of trouble with free trials. This commit adds the missing dependency. Forward-Port-Of: odoo/enterprise#80079
Problem --------- Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...) One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default. But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration
Original PR description
Problem --------- Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...) One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default. But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration of the level. This always generates an additional PDF that is often not needed. Objective --------- Do not tick "Print" by default when manually executing a follow-up level, unless "Letter" is ticket in the configuration of the level. Solution --------- Set "Print" default value in the wizard to the "Letter" value of the follow up line instead of leaving it as True (which is the default). task-4574971 Forward-Port-Of: odoo/enterprise#79829