Friday, May 16, 2025
17 changes · 17.0
Enhancements to existing features
This commit adds translations for Luxembourg VAT report in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
This commit adds translations for Luxembourg VAT report in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The Nilvera e-invoice purchase journal setting is now shown only in the restricted invoicing settings area. This prevents access errors for users without accounting manager permissions and keeps the Turkish e-invoicing setup aligned with similar invoicing settings.
Original PR description
The l10n_tr_nilvera_purchase_journal_id field was causing access errors due to its placement in the "Integrations" section without any group restriction, exposing it to users without the necessary rights. In contrast, the similar account_peppol_purchase_journal_id field is defined under the "Invoicing" section with the proper group restriction (account.group_account_manager), and behaves correctly. This fix moves the Nilvera field into the same restricted section as the Peppol field, aligning its access control and visibility with other similar fields in the same context. build_error-111279
Miscellaneous changes
Before this PR, the name_search function would perform a search on products by injecting a list of ids in the domain instead of using a subquery. In cases where this list of ids is way too big, the search query becomes extremely slow. This PR uses a subquery instead in the domain to avoid this problem. Benchmarks: |Num. product_ids| Before PR | After PR | |---------------------|---------------|--------------| |28801| 65 s| <1 s| opw-4743566 --- I confirm I have signed the CLA
Original PR description
Before this PR, the name_search function would perform a search on products by injecting a list of ids in the domain instead of using a subquery. In cases where this list of ids is way too big, the search query becomes extremely slow. This PR uses a subquery instead in the domain to avoid this problem. Benchmarks: |Num. product_ids| Before PR | After PR | |---------------------|---------------|--------------| |28801| 65 s| <1 s| opw-4743566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207953
Online orders now assign quotations to the customer's own salesperson before falling back to the parent company's salesperson. This keeps eCommerce sales ownership consistent with backend sales rules and prevents quotes from being routed to the wrong person.
Original PR description
Steps: - Create a partner and it's parent partner and set different salesperson on each. - Login with child partner and add product to cart. - Go to backend and open related quotation. Issue: - Salesperson set on quotation is customer's parent partner's salesperson even though salesperson set on customer. While in backend it first check customer's salesperson and if customer does not have salesperson then it set parent's salesperson. Cause: - In eCommerce we gave parent's salesperson first priority then customer's salesperson. Fix: - Swap priority to set first customer's salesperson opw-4757042
Fixed an issue where uploading a vendor bill could fail if users had previously grouped the Accounting dashboard by type. The upload now ignores unrelated search defaults, allowing bills and attachments to be created normally.
Original PR description
Step to reproduce: - install accounting - in the dashboard searchbar, add a `Group By` with value `type` - go to vendor bills view from the dashboard - upload any file Error: Wrong value for…
Step to reproduce: - install accounting - in the dashboard searchbar, add a `Group By` with value `type` - go to vendor bills view from the dashboard - upload any file Error: Wrong value for `ir.attachment.type`: 'purchase' Expected: The upload process should go on without any error Explanation: in the `onFileUploaded` hook for vendor bills AccountFileUploader JS component, we included all context when we are creating the `ir.attachment` object. The group-by we added earlier are thus also added as `default_type` in the context. But when creating a record, the ORM checks for all `default_*` key in the context and try to use it as additional values for the created record. Since the key-value combination `type` and `purchase` is not valid in an `ir.attachment` record, it throws this error. Solution: Before passing the context, we have to make sure to clean all the `default_*` contexts to avoid these kind of behaviors. In python, usually we use `clean_context` method before calling `create`. But since this is in JS, we manually filter all key-value item that starts with "default_" in the context object. opw-4512697
Small image attachments no longer show cramped download and delete buttons that could appear in the wrong place. Users can still access delete actions when viewing the image enlarged, making attachment handling cleaner and easier.
Original PR description
Before this commit: When the attachment size was too small, the download and delete buttons on the image overlay were incorrectly positioned, leading to a less user-friendly experience. Aftert this commit: The delete and download button is not shown shown for the small images and you get a delete option when the image is zommed in. task-3563828
When users schedule a custom activity plan from a record, the current page now refreshes in place instead of reopening a default form view. This keeps navigation breadcrumbs clean and helps users immediately see the newly enabled plan in the chatter without losing context.
Original PR description
Scheduling a custom activity plan on a single record should do a `soft_reload` of the current view in order to avoid breadcrumbs pollution. The most frequent use case for that action is scheduling a plan from the chatter of the form view of a record, and retriggering an unnamed default form act_window would only restrict possible operations for the user. After this commit, the current view will be reloaded and the user will most probably be able to see its enabled plan in the chatter. task-4525830
Jordan UBL e-invoice files now keep the required party identification field even when no ID value is available. They also use the correct fallback country code when a partner has no country set, helping avoid validation issues during electronic invoicing.
Original PR description
When generating the JO UBL file, we want to keep the PartyIdentification and its ID node, even if the latter is empty. Also, in the same file, the country code of a partner should be set to 'PN' if the partner doesn't have its country set. task-4656827
The signing flow now prevents users from completing auto-signature with only spaces in the Full Name field. This helps ensure signed documents include a valid signer name and avoids incomplete or invalid signature records.
Original PR description
Currently, entering only spaces in the Full Name field when signing in auto mode enables the sign button, allowing users to proceed without a valid name. Steps to reproduce: 1. Sign > Create a request 2. Attempt to sign in auto mode with only spaces in the Full Name field 3. Observe that the sign button becomes enabled Cause: The system does not checks for whitespace-only name Solution: Add a validation to disable the sign button if the trimmed name is empty in auto mode. opw-4628577
This reverts commit d413a9895742594d064084cd6dafbf1f2ec97221. This fix was decided after https://github.com/odoo/enterprise/pull/74127 that was trying to prevent invoicing users to see accounting features, when it seemed to be unwanted to have the two property accounts fields required while having no CoA installed. The issue is, now when having Accounting installed, we can create a user without having CoA as these two fields are not required anymore, but we end up with a error message when cre
Original PR description
This reverts commit d413a9895742594d064084cd6dafbf1f2ec97221.
This fix was decided after https://github.com/odoo/enterprise/pull/74127
that was trying to prevent invoicing users to see accounting features,
when it seemed to be unwanted to have the two property accounts fields
required while having no CoA installed.
The issue is, now when having Accounting installed, we can create a user
without having CoA as these two fields are not required anymore, but
we end up with a error message when creating an invoice ('no CoA
installed') although we could be have added accounts manually instead
of installing a CoAi (which is not possible for invoicing user).
In this situation, we should be able to create a contact, and having these
fields required will force the user to create them.
Finally, it is ok to revert the full chain, as the original issue is
fixed by this commit https://github.com/odoo/enterprise/commit/68f6c1f9fd3ff6762c98e1a405ade035129efce0
Forward-Port-Of: odoo/odoo#209832# Context Building on a recent PR (https://github.com/odoo/odoo/pull/188697), we introduce multiple small tweaks to enhance the life of support agents and system admins that work a lot with the log files in the the context of email related issues. # Changes * A given `mail.mail` record being processed by the `_send` method can end up sending multiple emails under the hood ( if `recipient_ids` points to muliple ids). This means that the ratio between one `mail.mail` record and the number
Original PR description
# Context Building on a recent PR (https://github.com/odoo/odoo/pull/188697), we introduce multiple small tweaks to enhance the life of support agents and system admins that work a lot with the log…
# Context Building on a recent PR (https://github.com/odoo/odoo/pull/188697), we introduce multiple small tweaks to enhance the life of support agents and system admins that work a lot with the log files in the the context of email related issues. # Changes * A given `mail.mail` record being processed by the `_send` method can end up sending multiple emails under the hood ( if `recipient_ids` points to muliple ids). This means that the ratio between one `mail.mail` record and the number of email sent through SMTP is not always 1:1. We added a new log line that counts the total emails processed in the loop which should give a more precise estimation of the real number of emails attempted through SMTP * Given the above, we the usual log line was not reporting all the (redacted) list of email addresses but only the `email_to` of the last `msg` value created during the inner loops. We now correctly show a comma seperated list of all recipients in a given batch. * The historical log line `Sent batch %s emails via mail server ID #%s` could be missleading as it was not counting the number of emails but the number of `mail.mail` records processed. It was reformulated to account for this. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206657
https://github.com/odoo/odoo/pull/207357 introduced a test that was flaky if an SO's sequence and id did not match. Fix ----- Directly use the SO's name in the expected filename instead. Forward-Port-Of: odoo/odoo#210114
Original PR description
https://github.com/odoo/odoo/pull/207357 introduced a test that was flaky if an SO's sequence and id did not match. Fix ----- Directly use the SO's name in the expected filename instead. Forward-Port-Of: odoo/odoo#210114
Fixes the tests of the efaktur module; which are failing in 16 & 17 at the moment. The biggest issue is that the invoices created during the setup were done before the patch, causing them to not correctly consume a tax number. In 16, there is also issues due to a missing sale journal, so I update the test to use the accounting setupclass and setup a proper ID test company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of:
Original PR description
Fixes the tests of the efaktur module; which are failing in 16 & 17 at the moment. The biggest issue is that the invoices created during the setup were done before the patch, causing them to not correctly consume a tax number. In 16, there is also issues due to a missing sale journal, so I update the test to use the accounting setupclass and setup a proper ID test company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203868
This reverts commit e4111ac8f817f97b3d6128453659a1014b6db00f. This fix was decided after https://github.com/odoo/enterprise/pull/74127 that was trying to prevent invoicing users to see accounting features, when it seemed to be unwanted to have the two property accounts fields required while having no CoA installed. The issue is, now when having Accounting installed, we can create a user without having CoA as these two fields are not required anymore, but we end up with a error message when cre
Original PR description
This reverts commit e4111ac8f817f97b3d6128453659a1014b6db00f. This fix was decided after https://github.com/odoo/enterprise/pull/74127 that was trying to prevent invoicing users to see accounting…
This reverts commit e4111ac8f817f97b3d6128453659a1014b6db00f.
This fix was decided after https://github.com/odoo/enterprise/pull/74127
that was trying to prevent invoicing users to see accounting features,
when it seemed to be unwanted to have the two property accounts fields
required while having no CoA installed.
The issue is, now when having Accounting installed, we can create a user
without having CoA as these two fields are not required anymore, but
we end up with a error message when creating an invoice ('no CoA
installed') although we could be have added accounts manually instead
of installing a CoAi (which is not possible for invoicing user).
In this situation, we should be able to create a contact, and having these
fields required will force the user to create them.
Finally, it is ok to revert the full chain, as the original issue is
fixed by this commit https://github.com/odoo/enterprise/commit/68f6c1f9fd3ff6762c98e1a405ade035129efce0
Forward-Port-Of: odoo/enterprise#85446Before this commit: Some of the names in the stock_type list were wrong, causing an invalid type error when validating delivery. After the commit: Added a lookup table to update the incorrect names to match names in FedEx documentation. Fedex docs: https://developer.fedex.com/api/en-is/catalog/ship/docs.html opw-4725488 Forward-Port-Of: odoo/enterprise#84762
Original PR description
Before this commit: Some of the names in the stock_type list were wrong, causing an invalid type error when validating delivery. After the commit: Added a lookup table to update the incorrect names to match names in FedEx documentation. Fedex docs: https://developer.fedex.com/api/en-is/catalog/ship/docs.html opw-4725488 Forward-Port-Of: odoo/enterprise#84762
The xsd changed. Now the rounding needs to be to 2 decimals everywhere. The official xsd does not mention it, but the field submit_more must appear on the xml. Also, while it's not blocking directly, the declaration will be rejected if the special deduction is filled without specifying the special %age. So we add a banner warning the user of it. opw-4789154 Forward-Port-Of: odoo/enterprise#85464
Original PR description
The xsd changed. Now the rounding needs to be to 2 decimals everywhere. The official xsd does not mention it, but the field submit_more must appear on the xml. Also, while it's not blocking directly, the declaration will be rejected if the special deduction is filled without specifying the special %age. So we add a banner warning the user of it. opw-4789154 Forward-Port-Of: odoo/enterprise#85464