Daily updates from Odoo
Navigate
Branch
Friday, June 20, 2025
63 changes
35 changes
Enhancements to existing features
Document sharing emails and permission messages are now clearer and more consistent, with tailored guidance for spreadsheets. Users also get warnings when external recipients may be unable to access shared documents, and document request uploads now end with a clearer success flow.
Original PR description
This PR is divided in four commits : - [IMP] documents: changes share mail template In this commit, we change the share email to look like the request document mail template and we now always send…
This PR is divided in four commits :
- [IMP] documents: changes share mail template
In this commit, we change the share email to look like the request document mail template and we now always send emails. We don't use the `message_notify` anymore.
- [IMP] documents{_spreadsheet}: changes share text depending on source
This commit changes the helper messages in the document permission panel to be more concise and precise. We also add specific messages to spreadsheets documents.
- [IMP] documents: show warning when sharing to external user.
This commit adds a warning when one tries to share a document to some external users but the `access_via_link` parameter is set to `none` which will prevent the users to actually access the document. It also adds some visuals to quickly target the problematic users.
- [IMP] documents: change request portal view
This commit changes the request document template to look more like the view when sharing a single document. It also redirect to a success page when the upload is successful.
Task-4480388Users can now open a PDF shared in Chatter and sign it directly from the preview toolbar. This makes signing contracts, agreements, purchase orders, and similar documents faster without switching to a separate signing flow.
Original PR description
In this PR, - Users can now receive documents to sign directly in the Chatter (in CRM, Sales or any other app). - The document could be anything a contract, agreement, purchase order, etc. - When the user opens the document in the PDF preview, there's a Sign button in the toolbar. - Clicking it lets the user sign the document quickly. Task: 4779825
The Sign app now shows more useful details in request lists, including the responsible person and signed document. Shared signing templates are easier to identify, public-user requests are hidden from user document menus, and shared request names are cleaner for recipients.
Original PR description
In this commit, - Add fields of 'Responsible' and 'signed document' in list view. - Hide sign request of public user from document menu of user when sharing a template for sign. - Add a icon to display 'shared' templates in kanban view when template is shared by link. - Remove '-shared' from shared request display name. task-4279714
This update aligns group management behavior across list and Kanban views, including Helpdesk, POS appointments, and Studio. It helps keep the user experience consistent after related platform changes, reducing confusion when working with grouped records.
Original PR description
This commit adapts some patches, extensions and tests to changes made in https://github.com/odoo/odoo/pull/210593 task-4613135
Field service projects can now hide unit prices, taxes, and discounts from customer-facing reports and portal views. Users without sales access can still open the product overview, but sensitive product pricing stays hidden.
Original PR description
Following changes:
- Added a "Hide Prices" field in the project.If enabled, the Unit Price, Taxes, and Disc.% fields will be hidden
in both the report and portal view.
- When a user does not have 'salesman' access rights, the product stat button will be visible to the user, but they will not be
able to see the product's price.
Technical Details:
- The reason for using a patch is that we were extending the product line component in industry_fsm_stock. To achieve this,
we needed to extend both industry_fsm_stock and industry_fsm_sale. This approach became too complex, so we have to use a patch instead of extending.
task-4523325The Documents permission panel now lets users add people to invite directly from a field instead of first clicking an invite button. This streamlines the sharing flow and reduces friction when granting access to documents.
Original PR description
To improve the user experience of the permission panel, we replace the button "Invite people" by a field allowing to add directly the partners to invite. Task-4781262
The Indian reporting Balance Sheet now opens with the horizontal split option turned off by default. This makes the standard report view simpler and avoids users having to manually untick the option when they prefer the regular layout.
Original PR description
before this PR: split horizontally is ticked by default on Balance Sheet. after this PR: split horizontally is unticked by default. Related PR (Upgrade): https://github.com/odoo/upgrade/pull/7827 Previous version PR: https://github.com/odoo/enterprise/pull/86032 Task Id: 4836667
This change appears to improve the setup phase to make initialization faster. Faster setup can reduce waiting time for teams and improve overall operational efficiency, though no specific affected business area was provided.
This update adjusts how Odoo sorts records so it behaves more like database sorting. For businesses, this should improve consistency in areas that rely on ordered records, including Colombian electronic invoicing, with limited visible change.
Original PR description
The implementation is much closer to what is done by the SQL. We have a few semantic changes that needs to be adapted. odoo/odoo#155850
Businesses can now offer the same product as either a recurring subscription or a one-time purchase, without creating duplicate product records. This simplifies catalog management, reduces stock tracking complexity, and gives online customers a clearer purchase choice at checkout.
Original PR description
**Before this commit:** - Selling a product both as a subscription and as a one-time purchase required creating two separate products. This approach introduced unnecessary complexity, including data duplication, stock management issues, and additional noise in the product catalog. **After this commit:** - A new checkbox is added in the Sales tab of the product form, allowing products configured as subscriptions to also be sold as a one-time purchase. - This eliminates the need to create duplicate products. **Key changes include:** - Allowing the creation of sales orders without requiring a recurring plan for products marked as eligible for both subscription and one-time purchase. - Enabling customers in the eCommerce portal to choose between a recurring subscription (e.g., regular delivery) or a one-time purchase at checkout. task-4458601
The accounting reports app now sends reminder emails to submit an account return shortly after the reporting period closes and again just before the deadline. This helps businesses reduce missed submissions and follow up on required returns more reliably.
Original PR description
Send reminder mail to submit an account return, the day after its period is closed and the day before the deadline. task-4752152
Tax return checks now have a dedicated form view with activity tracking, chatter, and quick access to run check actions. Businesses can assign approvers and see clearer audit trails for status changes and resets, making review and compliance workflows easier to manage.
Original PR description
New features for `account.return.check`: - Form view, with stat button that executes the check action, with chatter and activity. - Field for approvers. - Tracking for `bypassed`, `approver_ids` and `return_state`, with `return_state` appearing first. - "Tax Return Reset" title for the tracking values when the return is reset. - List view, that is accessed via activity. - Return name displayed in the kanban view when accessed via activity task-4823849
This update adjusts automated tests in Documents Spreadsheet, Spreadsheet Edition, and Web Studio so they stay aligned with recent platform changes. It helps maintain quality and reduces the risk of regressions without introducing direct user-facing changes.
Original PR description
We adapt the tests in documents_spreadsheet, spreadsheet_edition and web_studio to the changes brought by https://github.com/odoo/odoo/pull/208592. Task ID: 4610804
Spreadsheet users now get suggested global filters based on relevant search fields already defined in their data sources. This makes it easier to create useful filters that work consistently across related records and models.
The ESG app’s summary text was improved to be clearer, more grammatically correct, and more polished. This helps users better understand the app’s purpose when viewing it in Odoo.
Original PR description
This is grammatically correct and more polished. No task ID
Adds the initial backend support needed for audio transcription in the AI module. The update also records end-to-end transcription timing, helping teams monitor provider performance and overall request speed.
Original PR description
[IMP] ai: setting up basic backend for audio transcription This commit introduces basic backend for audio transcription across the project. Introduced benchmark --- Additionally, the transcription endpoint now logs an observed real-time factor (oRTF) metric for each request. Unlike the typical RTF, which measures pure model inference time, our oRTF captures the full round-trip latency, including file upload, processing by the provider, and receiving the transcription. Note --- This commits stems from two transcription tasks: task-[4532108](https://www.odoo.com/web#id=4532108&view_type=form&model=project.task) task-[4791084](https://www.odoo.com/web#id=4791084&view_type=form&model=project.task)
Resolved issues and error corrections
This update adjusts internal tests in Documents and Spreadsheet Edition so they match recent changes to how model selection data is represented. It helps keep quality checks reliable and prevents false test failures after the related platform change.
Original PR description
…or class
This commit is the counterpart of https://github.com/odoo/odoo/pull/215137.
Note that the mocks of `display_name_for` in `documents` were not correct, as they were returning a list of strings instead of a list of objects `{ model: string, display_name: string }`.The test setup now gives the test user the required permission group before checking unit of measure fields. This prevents automated test failures and helps keep the inter-company sales and purchasing workflow stable after recent platform changes.
Original PR description
This commit fixes tests failure caused by odoo/odoo#212098. The mentioned PR removed all occurrences of uom fields without the uom group. That led to failing any test that tried to access uom field without having the uom group. This commit ensures that the uom group is applied on the test user before accessing uom field.
The disallowed expenses report is adjusted so Belgian fiscal categories represent additional deductions, such as eInvoicing software, separately from truly non-deductible expenses. This makes the report labels and calculations more accurate for preparing fiscal declarations and avoids treating extra deductions as impossible 120% disallowed expenses.
Original PR description
Problem --------- In odoo/enterprise#76066, we allowed to account for >100% deductibility, but it wasn't done quite right. The whole purpose of the report and Fiscal categories is to help the…
Problem --------- In odoo/enterprise#76066, we allowed to account for >100% deductibility, but it wasn't done quite right. The whole purpose of the report and Fiscal categories is to help the accountant to prepare his Fiscal Declaration. In Belgium, those Fiscal Categories are used in that declaration to declare: - additional deductions (like the one for eInvoicing software) - disallowed expenses (expenses that cannot be deduced from the calculation of your income) - ... detail your income to what's taxable and and at what rate (not yet fully supported) We considered that the added deductibility of 20% for invoicing software expenses was a 120% Disallowed Expense, but this is wrong and that does not exist. It is just a 20% rate on particular software expense that can be additionally reported in a specific section of the Fiscal Declaration, and that will further reduce the income before the computation of the income tax (the other 100% part being reported normally). Objective --------- Rename report columns to make the UI more generic and correct and remove the disallowed computation that are not necessary anymore. task-4848518
The AI field refresh action now returns linked record values in the format expected by the updated system. This prevents refreshed many-to-one AI fields from incorrectly displaying “No Access,” improving reliability for users working with AI-generated field values.
Original PR description
Purpose: -------- Following the changes in [1], the relational model uses an object instead of an array for m2o values. However, the "Refresh value" button next to an ai m2o property still returns an array, which results in showing "No Access" as m2o value. This commit changes the returned value to an object. Task-4775956 [1]: https://github.com/odoo/odoo/pull/202534
Miscellaneous changes
…rrect data from MO operation **Problem:** lines of mrp.workcenter.productivity added from the workorder widget do not update the linked analytic account with the right amount **Steps to reproduce:** - enable "analytic accounting" setting - Unarchive MTO route - Create a new product - In the inventory page check MTO and Manufacture routes - click on the Bill of materials smart button and create a new BOM - add a component and an operation - Create another product, set "produc
Original PR description
…rrect data from MO operation **Problem:** lines of mrp.workcenter.productivity added from the workorder widget do not update the linked analytic account with the right amount **Steps to reproduce:**…
…rrect data from MO operation **Problem:** lines of mrp.workcenter.productivity added from the workorder widget do not update the linked analytic account with the right amount **Steps to reproduce:** - enable "analytic accounting" setting - Unarchive MTO route - Create a new product - In the inventory page check MTO and Manufacture routes - click on the Bill of materials smart button and create a new BOM - add a component and an operation - Create another product, set "product type" as service - in the "create on order" field select "project & task" - create a new quotation with these two products and confirm - click on the "manufacturing" smart button - in the work orders page click on the "open work order" button at the right of the line - click on add a line - set a duration of 30:10 and clik elsewhere on the screen - save - click on the "analytic account" smart button - select the only line and click on the "gross margin" smart button **Current behavior:** There is a single line with an amount of 0.01 **Expected behavior:** The price should reflect the hourly rate of the employee for the task (that's 50.28 with a 100$/hours rate for instance) **Cause of the issue:** There is two issue here. First Issue : When clicking on save on the widget, this will modify the time_ids field of the mrp.workorder this will create a new mrp.workcenter.productivity with the values we wrote. Consequently, on the vals_list when the create method is triggered duration is set to the duration we wrote (so here 30.17) Because of this, when the _compute_duration is the triggered previous_durations will be [30.17] and _create_analytic_entry will be called with a parameter of 30.17 https://github.com/odoo/enterprise/blob/8a21b4f8ee8d24ebbc9ac2eb08696a0de056357f/project_mrp_workorder_account/models/mrp_workcenter_productivity.py#L10-L14 Therefore, inside _create_analytic_entry duration will be 0 and amount will also be 0 This issue does not happen if the duration is set by changing the "real duration" in the "work orders" page of the manufacturing order. This is because when doing it this way, we modify the duration of the mrp.workorder which triggers the set_duration_method which also creates a new mrp.workcenter.productivity but here the _prepare_timeline_vals returns a dictonary without a duration field https://github.com/odoo/odoo/blob/4fe90167266a92c3a5941eac9a6a2084a80056ac/addons/mrp/models/mrp_workorder.py#L352-L353 Second Issue: The line we see with a 0.01 amount is actually created before we save. It's created from the onchange method when we change the duration on the form. The onchange of duration triggers an onchange of start date which gets the value of duration and triggers of recomputation of duration https://github.com/odoo/odoo/blob/4fe90167266a92c3a5941eac9a6a2084a80056ac/addons/mrp/models/mrp_workcenter.py#L522-L531 As a consequence, _compute_duration is called. self.duration is initially not rounded so in our exemple previous duration will be equal to 30.1666666666668 https://github.com/odoo/enterprise/blob/8a21b4f8ee8d24ebbc9ac2eb08696a0de056357f/project_mrp_workorder_account/models/mrp_workcenter_productivity.py#L10-L11 However after the call to super()._compute_duration(), self.duration will be rounded thanks to the use of convert to duration inside the super method https://github.com/odoo/odoo/blob/4fe90167266a92c3a5941eac9a6a2084a80056ac/addons/mrp/models/mrp_workcenter.py#L472 So when doing the difference here inside _create_analytic_entry https://github.com/odoo/enterprise/blob/8a21b4f8ee8d24ebbc9ac2eb08696a0de056357f/project_mrp_workorder_account/models/mrp_workcenter_productivity.py#L38 duration will be 5.555555555556424e-05 and amount will be -0.005555555555556424 which results in the creation of this line with an amount of 0.01 **fix:** Calling the creation of account.analytic.line from the compute method leads to other problems : For instance, if a line is added in the "open work order" widget and we change the end date but change our mind and don't save the line, the duration will have been computed and a new account analytic line will have been created Whereas calling the method _create_analytic_entries from create() and write() ensures it's only called when the model is saved opw-4715690 Forward-Port-Of: odoo/enterprise#85517
At the moment, the tax aggregators always give a base line with no tax the `None` grouping key. Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one. This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line. Community PR: https://github.com/odoo/odoo/pull/213405 task-4242065 Forward
Original PR description
At the moment, the tax aggregators always give a base line with no tax the `None` grouping key. Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one. This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line. Community PR: https://github.com/odoo/odoo/pull/213405 task-4242065 Forward-Port-Of: odoo/enterprise#87918 Forward-Port-Of: odoo/enterprise#87223
The [_get_common_substring](https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L708-L782) method ought to return None if the substring is shorter than 10. The check is only done while looping through the normalised labels, but the loop is [skipped](https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L777) if we have exactly 2 labels, t
Original PR description
The [_get_common_substring](https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L708-L782) method ought to return None if the substring is shorter than 10. The check is only done while looping through the normalised labels, but the loop is [skipped](https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L777) if we have exactly 2 labels, thus returning the substring irrespective of its length. Instead, we should do the actual length check (and substitute with None as needed) right before returning. The phrasing of the method's docstring is also updated to clarify that in the case of identical normalised labels, the _normalised_ label is returned rather than its original form. Forward-Port-Of: odoo/enterprise#87826
### Steps to reproduce: - Install PoS mexican localization - Navigate to PoS and create an order with a discount line - Go to back end and try to refund this order - Notice an error pops-up ### Cause: This is happening because when refunding an order we are checking if every line has positive price but since discount lines will have negative value it trigger the validation error. https://github.com/odoo/enterprise/blob/78bcd2e0b9296ad124ea1c3157a884fa6e62999a/l10n_mx_edi_pos/model
Original PR description
### Steps to reproduce: - Install PoS mexican localization - Navigate to PoS and create an order with a discount line - Go to back end and try to refund this order - Notice an error pops-up ### Cause: This is happening because when refunding an order we are checking if every line has positive price but since discount lines will have negative value it trigger the validation error. https://github.com/odoo/enterprise/blob/78bcd2e0b9296ad124ea1c3157a884fa6e62999a/l10n_mx_edi_pos/models/pos_order.py#L286 ### Fix: We check if the order lines are positive but after filtering the discount lines out opw-4528737 Forward-Port-Of: odoo/enterprise#87916 Forward-Port-Of: odoo/enterprise#84331
Mail now override unlink of all models to remove hanging activities. Indeed notably with server actions activities may be added on models not inheriting from mail.thread or mail.activity.mixin e.g. users. They should be removed when removing records otherwise they lead to void records, and do not mean anything business wise anyway. See community PR for more details. Forward-Port-Of: odoo/enterprise#88015
Original PR description
Mail now override unlink of all models to remove hanging activities. Indeed notably with server actions activities may be added on models not inheriting from mail.thread or mail.activity.mixin e.g. users. They should be removed when removing records otherwise they lead to void records, and do not mean anything business wise anyway. See community PR for more details. Forward-Port-Of: odoo/enterprise#88015
Since the access rights to see the hk rental is given to the payroll officer and the rights to modify the status is given to the employee administrator, you have payroll adminsitrator that cannot change the status and employee administrator that cannot access the model. As the model seems to be dedicated to Payroll and you need to be payroll officer to techniaclly change the status, we modify the view to allow this operation to payroll Adminsitrator. Forward-Port-Of: odoo/enterprise#87837
Original PR description
Since the access rights to see the hk rental is given to the payroll officer and the rights to modify the status is given to the employee administrator, you have payroll adminsitrator that cannot change the status and employee administrator that cannot access the model. As the model seems to be dedicated to Payroll and you need to be payroll officer to techniaclly change the status, we modify the view to allow this operation to payroll Adminsitrator. Forward-Port-Of: odoo/enterprise#87837
In this commit: https://github.com/odoo/enterprise/commit/13d527b2f940d2215a3bba578e47f180a0b7126e We wrongly removed the move_attachment_ids from the model params. Meaning that when putting an attachment on the reconciled line, the paper clip for the attachments was not visible on the statement line no task id Forward-Port-Of: odoo/enterprise#88044
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/13d527b2f940d2215a3bba578e47f180a0b7126e We wrongly removed the move_attachment_ids from the model params. Meaning that when putting an attachment on the reconciled line, the paper clip for the attachments was not visible on the statement line no task id Forward-Port-Of: odoo/enterprise#88044
- Create a product with tracking by serial numbers then set a lot and serial number on the product - Activate the option Display Lots & Serial Numbers on Invoices in the Inventory settings - Create a sale order with the test product and confirm it - Create the invoice and send the cfdi report - Request a cancel and select the reason 01 Document issued with errors (with related document) . On the CFDI PDF report of the new invoice, there are no lines for lots and serial numbers—they are not
Original PR description
- Create a product with tracking by serial numbers then set a lot and serial number on the product - Activate the option Display Lots & Serial Numbers on Invoices in the Inventory settings - Create a…
- Create a product with tracking by serial numbers then set a lot and serial number on the product - Activate the option Display Lots & Serial Numbers on Invoices in the Inventory settings - Create a sale order with the test product and confirm it - Create the invoice and send the cfdi report - Request a cancel and select the reason 01 Document issued with errors (with related document) . On the CFDI PDF report of the new invoice, there are no lines for lots and serial numbers—they are not printed. The report uses the _get_invoiced_lot_values method from sale_stock to retrieve serial numbers. This method is first called when sending the CFDI for the parent invoice. However, when it is called for the child invoice, the method checks the quantity of the serial product, which is now depleted. This commit introduces a hook that allows to filter the amls taken into account in get_invoiced_lot_values. In l10n_mx_edi, we do not take the amls from the parent invoice after a cfdi cancellation. community PR: https://github.com/odoo/odoo/pull/202262 opw-4644031 Forward-Port-Of: odoo/enterprise#87687 Forward-Port-Of: odoo/enterprise#81656
During this commit:https://github.com/odoo/enterprise/commit/8419a92ae4697656da5b18325a5cc653a87e3ab5 we moved the reload of the statement line from the _setAccountOnReconcileLine function but by doing so the receivable and payable button are not reloaded anymore no task id Forward-Port-Of: odoo/enterprise#87865
Original PR description
During this commit:https://github.com/odoo/enterprise/commit/8419a92ae4697656da5b18325a5cc653a87e3ab5 we moved the reload of the statement line from the _setAccountOnReconcileLine function but by doing so the receivable and payable button are not reloaded anymore no task id Forward-Port-Of: odoo/enterprise#87865
In this commit: https://github.com/odoo/enterprise/commit/c0f8c5d17b9d78b640d744d8bfb6a2bb4002776a, we changed the way payment are matched with statement lines. Before, we were splitting the aml.ref based on ' ', then check for each word if there is an equivalent in the st_line label. But this is not restrictive enough. So now, there is the rules we apply, in the right order : 1 - Check if there is a payment ref like SO|INV|BILL|...xxxx/xxx-yy in the aml.ref 2 - Check for full match with
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/c0f8c5d17b9d78b640d744d8bfb6a2bb4002776a, we changed the way payment are matched with statement lines. Before, we were splitting the aml.ref based on ' ', then check for each word if there is an equivalent in the st_line label. But this is not restrictive enough. So now, there is the rules we apply, in the right order : 1 - Check if there is a payment ref like SO|INV|BILL|...xxxx/xxx-yy in the aml.ref 2 - Check for full match with aml.ref 3 - Check if there is a word more than 16 characters long who match with aml.ref 4 - Check for full match with aml.move_name 5 - Check for full match with move.payment_reference If we have any multiple match, we don't reconcile. no-task Forward-Port-Of: odoo/enterprise#87811
Some fixes in regarding quality and mrp - Hide the failure location depending on the test_type - redirect the stock move to the failure location instead of the picking or mo (for the backorder) Forward-Port-Of: odoo/enterprise#81211
Original PR description
Some fixes in regarding quality and mrp - Hide the failure location depending on the test_type - redirect the stock move to the failure location instead of the picking or mo (for the backorder) Forward-Port-Of: odoo/enterprise#81211
Changes include: - Better background color alternation for each journal entry. - Journal Entry number is now shown only once, and in bold. - Moved the date into the same column as the Journal Entry number to save space. task-4844519 Forward-Port-Of: odoo/enterprise#86991
Original PR description
Changes include: - Better background color alternation for each journal entry. - Journal Entry number is now shown only once, and in bold. - Moved the date into the same column as the Journal Entry number to save space. task-4844519 Forward-Port-Of: odoo/enterprise#86991
The system will crash when we try to set the account for statement lines. And at [1], we can see that this fetches the `previous_statement_lines`. [1] https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L654-L656 After that, it calls the `_prepare_reconciliation_rule_data` method. and try to find a `common substring`. https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_a
Original PR description
The system will crash when we try to set the account for statement lines. And at [1], we can see that this fetches the `previous_statement_lines`. [1]…
The system will crash when we try to set the account for statement lines. And at [1], we can see that this fetches the `previous_statement_lines`. [1] https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L654-L656 After that, it calls the `_prepare_reconciliation_rule_data` method. and try to find a `common substring`. https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L676 In the `_get_common_substring` method, when [2] is executed, and if we have the below `payment_ref` ``` [ 'PRLV SEPA VROOMLY STR16NASUC4VSCWSRGTVURANBFJQM4LJU9 VROOMLY', 'PRLV SEPA AMAZON PAYMENTS EUROP 450X4WSOR73LFYYL 171-6087599-8440309 AMZN MKTP FR 45 0X4WSOR73LFYYL', 'PRLV SEPA VROOMLY STR16NASTLNFBLLPVADQPRANTXVPUDYDFY VROOMLY', 'VIR STRIPE VROOMLY-6NXKKON62EKBHVFLXZ3T9PTDOP5 VROOMLY', 'PRLV SEPA VROOMLY STR16NAST8PLKGEKOLWOLRANIEPSODZENR VROOMLY' ] ``` (means our len(substring) is less than 10), Then it returns `None` from line [3]. [2] https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L777-L781 [3] https://github.com/odoo/enterprise/blob/e8f7975659f3bfea42acdc7495efeccbffe183bc/account_accountant/models/account_bank_statement.py#L780 **Steps to produce:-** 1. Install the `Accounting` module. 2. Set up the `Odoo demo bank`. 3. Click on `Transactions` under Bank. 4. Set account as `Cash Discount Loss` for `Monthly Office Rent ` and `Annual Public liability insurance`. 5. For `Deposit on the invoice 784`, set the account as other than `Cash Discount Loss` and then delete that, and again set the account as `Cash Discount Loss`. **Error:-** `AttributeError: 'NoneType' object has no attribute 'strip'` **Solution:-** - In this commit, we handle the case where `_get_common_substring` returns `None` by checking it before calling .strip(). - This prevents the system from crashing without changing the function’s return value. **Sentry - 6682820343** Forward-Port-Of: odoo/enterprise#87828
The call was done with `bank` parameter instead of `branch`. This made the tests (and the feature) fail. ref: odoo/enterprise#74967 runbot-114997 Forward-Port-Of: odoo/enterprise#87617
Original PR description
The call was done with `bank` parameter instead of `branch`. This made the tests (and the feature) fail. ref: odoo/enterprise#74967 runbot-114997 Forward-Port-Of: odoo/enterprise#87617
This commit changes the style of the transfer button in the transfer view to be solid instead of outlined. ## Before  ## After  Forward-Port-Of: odoo/enterprise#87825
Original PR description
This commit changes the style of the transfer button in the transfer view to be solid instead of outlined. ## Before  ## After  Forward-Port-Of: odoo/enterprise#87825
28 changes
Enhancements to existing features
This update improves Hoot, Odoo’s internal unit testing system, with clearer diagnostics, safer error handling, and more consistent test runner behavior. The changes help developers maintain and troubleshoot Odoo tests more reliably while keeping the impact limited to the testing ecosystem.
Original PR description
## Pull Request HOOT (PRHOOT) 33 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/87476 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Taiwan localization now defaults to calculating VAT rounding at the whole-invoice level instead of line by line. This better matches local invoicing practice, where tax is based on the total sales amount, improving accuracy and compliance for Taiwanese invoices.
Original PR description
For general invoicing purposes, VAT of Taiwan is rounded per invoice level, not per invoice. Also, they do not separately compute the tax amount per each line to generate the final totals. They use total sales amount * tax. task - 4875546
When users use the automatic fix to prepare a POS scale for certification, the system now also enables Units of Measure. This makes it easier for businesses to assign the right product units, such as kilograms, immediately after the setup is corrected.
Original PR description
This commit automatically enables the 'Units of Measure' setting when the user auto-fixes their settings to make their POS scale certified. While this is not a strict requirement, it helps the users to then quickly set the correct units for their products (e.g. kg) task-4885681
Resolved issues and error corrections
This update adjusts Turkish Nilvera e-invoice exports so they no longer include unsupported buyer reference data or ID fields missing the required type information. This helps prevent invoice rejections by Nilvera and improves reliability for Turkish electronic invoicing.
Original PR description
[FIX] l10n_tr_nilvera_einvoice: exclude ID without schemeID Nilvera expects a `<schemeID>` with every `<ID>`. In Odoo currently, we only support VKN or TCKN as a schemeID that get impacted from the VAT Number. Also, Nilvera reject any `<BuyerReference>` tag. Before: - The generated XML contains some `<ID>` tags without 'schemeID' attribute. - The generated XML contains some `<BuyerReference>` tag. After: - The `<ID>` tags with no 'schemeID' are removed from the XML. - The `<BuyerReference>` tag is removed from the XML. Task-4822777 runbot: https://runbot.odoo.com/runbot/bundle/18-0-tr-nilvera-partner-ref-override-tax-id-roto-376352
This fix prevents Discuss call tests from keeping old browser window data in memory after each test ends. It lowers test memory usage and helps keep automated testing more stable without changing end-user functionality.
Original PR description
Before this commit, discuss call HOOT tests retained the window object after test ended. Retained memory was about 2.5Mb-4Mb per test. An earlier PR [1] fixed a similar issue from a `const` object…
Before this commit, discuss call HOOT tests retained the window object after test ended. Retained memory was about 2.5Mb-4Mb per test. An earlier PR [1] fixed a similar issue from a `const` object being used in field default value. This was a problem because JS models internal code is keeping a reference to this object, and since HOOT suite test reuses the same window object, the window of each test were retained. The PR [1] fixed the issue by not setting object as default value of the field. Note that the default value and its presence in internal code of JS models happened for all tests that use `@mail` static files. That means this PR `[1]` fixed a retained memory for all `@mail` and related tests. While this fixed many tests, we still observed this retained memory on all discuss call tests. This happens because while the default value no longer uses this shared object, the computed value still does. Therefore call tests were sharing the const and thus retaining the window object. Note that the computed method is implicitly lazy, so this is only invoked in code that actually uses this `iceServers` field, hence why only discuss call tests were still affected by the issue. This commit fixes the issue by replacing the DEFAULT_ICE_SERVERS object by GET_DEFAULT_ICE_SERVERS function. This ensures each test use a different object, thus preventing retaining the window object after test has ended. [1]: https://github.com/odoo/odoo/pull/204521
Point of Sale receipts for GCC companies now show the cashier line only once instead of repeating “Served by.” This makes receipts cleaner and avoids confusing duplicate wording for customers.
Original PR description
Steps to reproduce: 1. Install l10n_gcc_pos. 2. Set the company’s country to a GCC country. 3. Print a POS receipt. Issue: - The receipt displays the phrase 'Served by' multiple times first two hardcoded and third one from prefix due to the cashier prop already including the prefix 'Served by '. - https://github.com/odoo/odoo/blob/f2dc7b5aaaf60d23e42e92f1ca0c6eed4ea13bf2/addons/l10n_gcc_pos/static/src/overrides/app/screens/receipt_screen/receipt/order_receipt.xml#L22 - Standard header data https://github.com/odoo/odoo/blob/0f8546528566acbcd2dd2fc1a99ae148ea2a7895/addons/point_of_sale/static/src/app/store/pos_store.js#L2099-L2105 Solution: - Replace cashier prop with gcc_cashier to return only the cashier’s name, without the 'Served by ' prefix. This avoids duplication and allows the template to handle translations consistently. opw-4724578
Portal users can now view the leads and opportunities assigned to them across all companies they are permitted to access, not just the main company. This fixes missing records in multi-company setups and helps partners reliably follow their sales opportunities.
Original PR description
Correct multi-company lead visibility in portal. [task-4482622](https://www.odoo.com/web#view_type=form&model=project.task&id=4482622) Description of the issue/feature this PR addresses: In a…
Correct multi-company lead visibility in portal. [task-4482622](https://www.odoo.com/web#view_type=form&model=project.task&id=4482622) Description of the issue/feature this PR addresses: In a multi-company environment, portal users (partners) were unable to access Opportunities and Leads belonged to them, when these records belonged to company(branch) that is not main company. Their visibility was restricted to records from the main company, even if their access rights were configured to allow access to multiple companies. Steps to reproduce: 1. Create a new company 2. Create a partner and grant them portal access 3. Grant the partner access right to the new company. 4. Switch to the new company and create an opportunity and assign it to this partner (Under assigned Partner tab). 5. Log in as the partner, go to "my/opportunities." 6. The opportunity is not there. Desired behavior after PR is merged: Partners can see lead/opportunities from multiple companies. --- Current behavior exists for other portal endpoints such as my/subscriptions, my/sales, my/invoices but I believe that the current behavior is expected and normal for these endpoints. --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Fixes an error that occurred when users edited a scheduled email and added another attachment from the chatter. This makes scheduled email editing more reliable and prevents users from being interrupted by a traceback.
Original PR description
Steps to reproduce - open a record from Contacts app - from chatter, click `send mail` , open full mail composer - add a attachment - schedule a message, by clicking '▼' on send message - Again from…
Steps to reproduce - open a record from Contacts app - from chatter, click `send mail` , open full mail composer - add a attachment - schedule a message, by clicking '▼' on send message - Again from chatter, click on edit the same message - try to add another attachment Observation: A traceback is received Issue: Currently, `onFileUploaded` function attempts to get `res_ids` from `data`, https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/static/src/core/web/mail_composer_attachment_selector.js#L25-L30 but in case message is scheduled, which is stored in `mail.scheduled.message` ,when editing it we do not have `res_ids` https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/wizard/mail_compose_message.py#L120 instead we have `res_id` field, https://github.com/odoo/odoo/blob/69828835c926485ec80ed92e14dd11fbc6c1caaa/addons/mail/models/mail_scheduled_message.py#L46 hence a traceback is received when trying to json parse a `undefined` value. Fix: Adapt the `onFileUploaded` function to consider both, `res_ids` and `res_id` opw-4839926 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A website testing tour was corrected so it more accurately detects when popup animations have finished and when scrolled elements are hidden. This helps keep automated website checks reliable and reduces false failures during quality assurance.
Original PR description
In this commit, we fix the tour snippet_popup_and_animations. For trigger: "...olumns .row > :last-child:not(:has(.o_animating))", :not(:has) is always true because no child has class o_animating. When the goal is check that the element has not a class, just use :not Also, when the scroll is well done, the element become invisible. So we need to add :hidden.
This fix restores a default invoice description for Spanish TicketBAI point-of-sale orders when no origin is provided. It prevents submission errors and helps affected POS invoices meet the required tax reporting format.
Original PR description
Before PR #187439, the field DescripcionFactura defaulted to `manual` when the origin was False.
That PR removed the fallback and moved the default assignment to `_l10n_es_tbai_get_invoice_values` in `l10n_es_edi_tbai` module, but forgot to apply the same logic in `_l10n_es_tbai_get_values`.
Steps to reproduce:
- Create a new TBAI POS order
- Try to submit it
- You’ll get an error:
```cvc-complex-type.2.4.a: Invalid content was found starting
with element 'DetallesFactura'. One of '{FechaOperacion,
DescripcionFactura}' is expected.
```
This fix restores the fallback value 'manual' for POS invoices
to ensure schema compliance.
opw-4834333The Point of Sale product card now shows the last weighed value with adjusted text sizing. This makes the weighing information easier to read for cashiers when handling products sold by weight.
Original PR description
This small PR changes the text size displaying last weighed value for a product **Before:**  **Now:** 
The date range picker now lets users click an already selected start date to continue choosing an end date. This removes an unnecessary workaround and makes date range entry smoother and more intuitive.
Original PR description
This commit fixes an issue in the datetime_picker where clicking on an already selected start date would not initiate the selection of an end date. As a result, users were forced to select a different date first before being able to reselect the same start date. With this fix, clicking the start date again now correctly triggers the end date selection phase, improving the overall usability of the daterange picker. task-4845373
Pasting plain text into code blocks now keeps indentation using regular spaces instead of hidden non-breaking spaces. This makes copied code easier to edit, read, and reuse without unexpected invisible characters.
Original PR description
### Rationale for omitting `nbsp` in code blocks: - Code blocks, usually rendered within `<pre>` tags, inherently preserve whitespace & indentation through browser’s white-space: pre CSS behavior. Thus, inserting `nbsp` to maintain space visibility is redundant & may introduce hidden characters. ### Description of the issue/feature this PR addresses: - Indentation pasted as plain text inside code blocks was replaced by `nbsp`. ### Desired behavior after PR is merged: - Pasting plain text inside code blocks preserves indentation using normal spaces, avoiding insertion of `nbsp`. task-4815939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Task assignees on private projects can now see documents linked to their tasks when they should have access. The update also removes document access when people are no longer followers, helping keep project documents visible to the right users only.
Original PR description
**Steps to reproduce:** - Install the `documents_project` module. - Create a project, set visibility to '**Invited internal users (private)**', and add Marc Demo as a follower. - In the project…
**Steps to reproduce:** - Install the `documents_project` module. - Create a project, set visibility to '**Invited internal users (private)**', and add Marc Demo as a follower. - In the project settings tab, hover over the folder name and open it. - Click the gear icon and select 'Share', ensuring Marc Demo is listed under '**People with access**'. - Set both '**Internal Users**' and '**Anyone with the link**' to None, then click 'Done'. - Create a task for the project and add Marc Demo as the assignee - Upload a document via the document smart button - Now go to the task with Marc Demo Marc Demo cannot see the document but can see the attachment. The document smart button shows 0 count. **Issue:** Marc Demo, a project follower and task assignee, cannot see the document because it’s not shared with his user’s partner. **Solution:** - Grant 'view' access to task assignees if project visibility is set to 'Invited internal users (private)', allowing assignees to access the documents. - Revoke document access for partners who are unsubscribed and no longer followers of the associated project and task. - Also, implemented a test case to cover these use-cases. opw-4702911
German POS receipts using Fiskaly now show official, readable names for TSS security information instead of internal technical field names. This makes receipts clearer for customers and staff and helps businesses present required certification details in a more understandable way.
Original PR description
Currently when using Fiskaly, the receipt gets printed with the technical names of the tss values. Steps to reproduce: ------------------- * Set up the db to use fiskaly * Open restaurant * Place and pay an order > Observation: On the receipt screen the name of the tss values are shown as: transaction_number, signature_algorithm, client_serial_number, .... Why the fix: ------------ Beore this commit https://github.com/odoo/enterprise/commit/d1a94147060083da54f9423f8c379676fbb7db66#diff-960ffa6839618d084dd5de6e29458ef68766a31250fc7d296512ec5358f04056 we were using a dictionnary `name, value` when using tss information, cf `_initTssInformation()` in `l10n_de_pos_cert/static/src/overrides/models/models.js`. We re-introduce this behavior and revert the following commit https://github.com/odoo-dev/enterprise/commit/9f75e3fe092bd838fffb11a35a8d854afff71869 to use the official names instead of the technical ones. opw-4822342
This update improves and fixes Odoo's internal unit test coverage for Hoot-based testing across several Enterprise apps. It helps keep future changes safer by making automated tests clearer and more reliable, with no intended impact on end users.
Original PR description
## Pull Request HOOT (PRHOOT) 33 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/213223
Purchase order lines now show budget warnings only when their analytic distribution actually matches the relevant budget line. This avoids misleading red warnings and ensures over-budget purchase lines are highlighted consistently when multiple lines are present.
Original PR description
**Steps to reproduce:** - Install account_budget - Activate "Budget Management" in Accounting settings - Go to "Accounting / Accounting / Analytic Budget" - Create a new budget: * Budget Type:…
**Steps to reproduce:** - Install account_budget - Activate "Budget Management" in Accounting settings - Go to "Accounting / Accounting / Analytic Budget" - Create a new budget: * Budget Type: Expense * Period: [this month] * Budget Lines: [a line with an analytic account (AA) in 2 plans] - Open the budget **Issue 1:** Create a PO at the current date with a line having only one of the AA as analytic distribution and an amount higher than the budgeted amount. The PO line and the Budget button appear in red, but it shouldn't because the analytic distribution of the line doesn't match all the accounts defined on the budget line. The line will not impact the budget, but it appears in red, which is confusing. **Cause 1:** When computing the budget lines linked to the PO line, the domain that is used is only taking into account the plans that are set on the PO line, ignoring the plans that are not set. For the Budget button, all the PO lines are used instead of just those having the correct analytic distribution. **Issue 2:** - Create a PO at the current date with 2 lines: 1) a line with the same AA than the budget line and an amount higher than the budget amount 2) a line with the same AA than the budget line and an amount lower than the budget amount - Save the PO The first line should be red, but it is not. **Cause 2:** When computing the budget lines linked to the PO lines, only the last PO line has its value set. opw-4757067
Miscellaneous changes
task-id: 4746445 IAP PR: https://github.com/odoo/iap-apps/pull/1088 Forward-Port-Of: odoo/odoo#213819
Original PR description
task-id: 4746445 IAP PR: https://github.com/odoo/iap-apps/pull/1088 Forward-Port-Of: odoo/odoo#213819
### Steps to reproduce: - On a contact, add the "Factur-X" E-Invoicing method under the "Accounting" tab - Create an invoice with this contact as the customer - Send the invoice, download the PDF - Verify the PDF. For example with https://demo.verapdf.org/ - `The aforementioned EOL marker shall be immediately followed by a % (25h) character followed by at least four bytes, each of whose encoded byte values shall have a decimal value greater than 127` - `The MIME type of an embedded file, o
Original PR description
### Steps to reproduce: - On a contact, add the "Factur-X" E-Invoicing method under the "Accounting" tab - Create an invoice with this contact as the customer - Send the invoice, download the PDF -…
### Steps to reproduce: - On a contact, add the "Factur-X" E-Invoicing method under the "Accounting" tab - Create an invoice with this contact as the customer - Send the invoice, download the PDF - Verify the PDF. For example with https://demo.verapdf.org/ - `The aforementioned EOL marker shall be immediately followed by a % (25h) character followed by at least four bytes, each of whose encoded byte values shall have a decimal value greater than 127` - `The MIME type of an embedded file, or a subset of a file, shall be specified using the Subtype key of the file specification dictionary. If the MIME type is not known, the "application/octet-stream" shall be used` ### Cause: - 1 Pypdf 2.2 is [adding the necessary binary](https://github.com/py-pdf/pypdf/commit/036789a4664e3f572292bc7dceec10f08b7dbf62) like Odoo [does](https://github.com/odoo/odoo/blob/c1679123c9c6f7184293befb399de1e79a6205a9/odoo/tools/pdf/__init__.py#L471) for Pypdf2.1 because it is mandatory for PDF/A. The issue comes from two line break following each others: Pypdf2.2 adds one at the beginning of the [file](https://github.com/py-pdf/pypdf/blob/036789a4664e3f572292bc7dceec10f08b7dbf62/PyPDF2/pdf.py#L487): `\n % E2 E3 CF D3` Then Odoo [adds the header `%PDF-1.7\n` before](https://github.com/odoo/odoo/blob/c1679123c9c6f7184293befb399de1e79a6205a9/odoo/tools/pdf/__init__.py#L469) resulting in : `b"%PDF-1.7" \n \n % E2 E3 CF D3` PDF/A expects to have `% E2 E3 CF D3` on the second line right after the header but there is nothing on this line. - 2 The Subtype is badly formatted: from `text/xml` to `/text#232Fxml` instead of `/text#2Fxml` This occurs as Odoo [replace `/` by `#2F`](https://github.com/odoo/odoo/blob/2e43bee546d5c14729d654386209b539d8aa71d7/odoo/tools/pdf/__init__.py#L369-L377). But then when [adding the subtype](https://github.com/odoo/odoo/blob/2e43bee546d5c14729d654386209b539d8aa71d7/odoo/tools/pdf/__init__.py#L595C17-L595C74) to the attachment, we call `NameObject` from PyPdf. This object will [format](https://github.com/py-pdf/pypdf/blob/1c4173a12cd21b91dff6d6596ed0bbf1999f2d10/PyPDF2/generic/_base.py#L548) the text again replacing the `#` by `#23`. ### Solution: - Don't add a `\n` after `%PDF-1.7` when using `_pypdf2_2`. - As PyPdf2.2 is doing the formatting itself, we don't format on our side if `submod == ._pypdf2_2`. We still need to add the `/`. opw-4748600 Forward-Port-Of: odoo/odoo#211006
Backport of https://github.com/odoo/enterprise/pull/86477 which improves what was done in commits - https://github.com/odoo/odoo/commit/ebd6b5f374303dcdfcc69fa64522c1b83bd7fe58 - https://github.com/odoo/enterprise/commit/37cc5e067ff8d1e45edbd9a167a2d801c658739c since it avoids reloading the demo data twice by hooking on `_install_demo`. Instead, we just call our own function to create the demo data once in the accountant module. This commit therefore only reverts ebd6b5f374303dcd
Original PR description
Backport of https://github.com/odoo/enterprise/pull/86477 which improves what was done in commits - https://github.com/odoo/odoo/commit/ebd6b5f374303dcdfcc69fa64522c1b83bd7fe58 - https://github.com/odoo/enterprise/commit/37cc5e067ff8d1e45edbd9a167a2d801c658739c since it avoids reloading the demo data twice by hooking on `_install_demo`. Instead, we just call our own function to create the demo data once in the accountant module. This commit therefore only reverts ebd6b5f374303dcdfcc69fa64522c1b83bd7fe58 Enterprise PR: https://github.com/odoo/enterprise/pull/87204 Forward-Port-Of: odoo/odoo#213379
**PROBLEM** In the user menu, the text of dropdown item sometimes overlap with the checkbox next to it when it's too long. **STEP TO REPRODUCE** (happened with the italian localization of the onboarding module, but it's no longer the case because the text was shortened) 1. In `enterprise/web_enterprise/i18n/it.po`, for the msgid "Dark Mode" set the translation to something long. 2. click on the user menu and notice the text for the dark mode dropdown item is overlapping with the checkbox
Original PR description
**PROBLEM** In the user menu, the text of dropdown item sometimes overlap with the checkbox next to it when it's too long. **STEP TO REPRODUCE** (happened with the italian localization of the onboarding module, but it's no longer the case because the text was shortened) 1. In `enterprise/web_enterprise/i18n/it.po`, for the msgid "Dark Mode" set the translation to something long. 2. click on the user menu and notice the text for the dark mode dropdown item is overlapping with the checkbox next to it. **CAUSE** The checkbox in the user_menu.xml template use d-flex and flex-row-reverse, which doesn't work well with the class form-switch. form-switch add a negative left-margin of -2.5em to the <input> inside the checkbox template. **FIX** Put the description text before the checkbox in a flex div, and remove the flex-row-reverse on the checkbox. opw-4654405 Forward-Port-Of: odoo/odoo#214127
**Description** - Correction of the entry to calculate Time as per the set duration. **Steps to Reproduce** 1. go to Payroll app -> work entries -> work entries 2. Create new work entry. 3. set the end date at least 24 hours away from the start date. 4. notice that there is a 24 hours extra added/ per everyday you add. --- **Before** the calculation of the work entries duration was incorrect if it exceeds one day. --- **After** the work entry duration is calculated correc
Original PR description
**Description** - Correction of the entry to calculate Time as per the set duration. **Steps to Reproduce** 1. go to Payroll app -> work entries -> work entries 2. Create new work entry. 3. set the end date at least 24 hours away from the start date. 4. notice that there is a 24 hours extra added/ per everyday you add. --- **Before** the calculation of the work entries duration was incorrect if it exceeds one day. --- **After** the work entry duration is calculated correctly and still well rounded. --- **Why the fix** - When the following commit was merged, it introduced duration rounding , but rouding the entire timedelta converted to seconds instead of the number of seconds within a day, while still adding the total days - - commit : https://github.com/odoo/odoo/commit/80ae5f47650077b75dfbe4e813a122c81538cab3 --- opw-4827487 Forward-Port-Of: odoo/odoo#213211
Whenever there is a fault in the ZATCA onboarding steps (like missing Certificate Signing Request (CSR) information etc.), a traceback is returned to the user instead of a clear error message. This behavior was introduced by the following PR: https://github.com/odoo/odoo/pull/205671 which changed the return format of the `_l10n_sa_call_api` function in case of failures. Steps to reproduce: - Configure a Saudi Arabia company - Switch ZATCA environment to Simulation (or Production) - At
Original PR description
Whenever there is a fault in the ZATCA onboarding steps (like missing Certificate Signing Request (CSR) information etc.), a traceback is returned to the user instead of a clear error message. This…
Whenever there is a fault in the ZATCA onboarding steps (like missing
Certificate Signing Request (CSR) information etc.), a traceback is
returned to the user instead of a clear error message.
This behavior was introduced by the following PR: https://github.com/odoo/odoo/pull/205671
which changed the return format of the `_l10n_sa_call_api` function in
case of failures.
Steps to reproduce:
- Configure a Saudi Arabia company
- Switch ZATCA environment to Simulation (or Production)
- Attempt to onboard a journal using an incorrect OTP code
- A traceback is triggered instead of a clear user-facing error
Traceback example:
```
File "/home/odoo/src/odoo/17.0/addons/l10n_sa_edi/models/account_journal.py", line 200, in _l10n_sa_compute_production_csid_validity
journal.l10n_sa_production_csid_validity = self._l10n_sa_get_pcsid_validity(
File "/home/odoo/src/odoo/17.0/addons/l10n_sa_edi/models/account_journal.py", line 516, in _l10n_sa_get_pcsid_validity
b64_decoded_pcsid = b64decode(PCSID_data['binarySecurityToken'])
File "/usr/lib/python3.10/base64.py", line 80, in b64decode
s = _bytes_from_decode_data(s)
File "/usr/lib/python3.10/base64.py", line 45, in _bytes_from_decode_data
raise TypeError("argument should be a bytes-like object or ASCII "
TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType'
```
This is due to the check in `_l10n_sa_get_compliance_CSID` for an 'error'
key, not present in the response when an OTP is invalid because in these
case, the `_l10n_sa_call_api` return the response_data directly.
This fix improves the behavior by displaying a user-friendly alert
message with the error returned by ZATCA, instead of a traceback.
This ensures a better experience and compliance with CCSID onboarding flows.
opw-4838542
Forward-Port-Of: odoo/odoo#215067
Forward-Port-Of: odoo/odoo#214391- Adding new taxes required by DIOT - Adding relevant tags and accounts Enterprise PR: https://github.com/odoo/enterprise/pull/82864 task-4568859 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213194 Forward-Port-Of: odoo/odoo#204742
Original PR description
- Adding new taxes required by DIOT - Adding relevant tags and accounts Enterprise PR: https://github.com/odoo/enterprise/pull/82864 task-4568859 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213194 Forward-Port-Of: odoo/odoo#204742
With a Spanish company and `l10n_es_edi_facturae`: - Create an invoice with a Spanish contact and confirm it. - Create a credit note for this invoice. Send and print it. In the Facturae XML, the `InvoiceClass` uses `OO` instead of `OR` (as specified on page 24 of [the specifications](https://www.facturae.gob.es/formato/Versiones/Esquema_castellano_v3_2_x_06_06_2017_unificado.pdf)). This commit also removes the hard-coded `'FC'` for `InvoiceDocumentType`, writing `'FA'` instead in the c
Original PR description
With a Spanish company and `l10n_es_edi_facturae`: - Create an invoice with a Spanish contact and confirm it. - Create a credit note for this invoice. Send and print it. In the Facturae XML, the `InvoiceClass` uses `OO` instead of `OR` (as specified on page 24 of [the specifications](https://www.facturae.gob.es/formato/Versiones/Esquema_castellano_v3_2_x_06_06_2017_unificado.pdf)). This commit also removes the hard-coded `'FC'` for `InvoiceDocumentType`, writing `'FA'` instead in the case of a simplified invoice. opw-4806099 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#211649
Previously, when multiple form snippets were added to the same page, corresponding fields (e.g., the "Name" field) in each form were assigned the same ID. This happened because we retrieved the form fields from the `FormEditorRegistry`. For the first form snippet, field IDs are generated and assigned correctly. However, assigning IDs to the fields also updated the fields stored in the `FormEditorRegistry`. So when a second form snippet is added, the fields it receives from the registr
Original PR description
Previously, when multiple form snippets were added to the same page, corresponding fields (e.g., the "Name" field) in each form were assigned the same ID. This happened because we retrieved the form…
Previously, when multiple form snippets were added to the same page, corresponding fields (e.g., the "Name" field) in each form were assigned the same ID. This happened because we retrieved the form fields from the `FormEditorRegistry`. For the first form snippet, field IDs are generated and assigned correctly. However, assigning IDs to the fields also updated the fields stored in the `FormEditorRegistry`. So when a second form snippet is added, the fields it receives from the registry already have an ID. The ID generation logic skips fields that already have an ID, so the fields in subsequent forms never got new IDs. With this fix, we now create a shallow copy of each field before using it. This prevents the original field definitions in the `FormEditorRegistry` from being modified. As a result, fields in different forms now receive unique IDs without needing to explicitly delete the field ID to force a new one to be generated. [task-4251881](https://www.odoo.com/web#id=4251881&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#210537 Forward-Port-Of: odoo/odoo#183883
Backport of https://github.com/odoo/enterprise/pull/86477 which improves what was done in commits - https://github.com/odoo/odoo/commit/ebd6b5f374303dcdfcc69fa64522c1b83bd7fe58 - https://github.com/odoo/enterprise/commit/37cc5e067ff8d1e45edbd9a167a2d801c658739c since it avoids reloading the demo data twice by hooking on `_install_demo`. Instead, we just call our own function to create the demo data once in the accountant module Community PR: https://github.com/odoo/odoo/pull/2133
Original PR description
Backport of https://github.com/odoo/enterprise/pull/86477 which improves what was done in commits - https://github.com/odoo/odoo/commit/ebd6b5f374303dcdfcc69fa64522c1b83bd7fe58 - https://github.com/odoo/enterprise/commit/37cc5e067ff8d1e45edbd9a167a2d801c658739c since it avoids reloading the demo data twice by hooking on `_install_demo`. Instead, we just call our own function to create the demo data once in the accountant module Community PR: https://github.com/odoo/odoo/pull/213379 Forward-Port-Of: odoo/enterprise#87204
- Reworking the DIOT report to comply with 2025 standard - Adjusting operation_type values on res.partner to match - Adjusting DIOT tests and other tests affected by the rework Community PR: https://github.com/odoo/odoo/pull/204742 task-4568859 Forward-Port-Of: odoo/enterprise#87102 Forward-Port-Of: odoo/enterprise#82864
Original PR description
- Reworking the DIOT report to comply with 2025 standard - Adjusting operation_type values on res.partner to match - Adjusting DIOT tests and other tests affected by the rework Community PR: https://github.com/odoo/odoo/pull/204742 task-4568859 Forward-Port-Of: odoo/enterprise#87102 Forward-Port-Of: odoo/enterprise#82864