Thursday, May 22, 2025
33 changes · 18.0
Enhancements to existing features
The calendar view no longer performs unnecessary permission checks before loading. This slightly improves loading speed while keeping the same access restrictions enforced by the system.
Original PR description
Before this commit, before loading the calendar view's data, we first checked whether the user had create and edit access rights (and we did that sequentially...). However, this is completely useless. If the user doesn't have those rights, the view's postprocessing, in python, adds `edit` and/or `create` attributes on the arch root node, to indicate operations that aren't allowed. This commit removes those 2 calls, thus speeding up a bit the loading of the calendar view. task-4603194 Part-of: odoo/odoo#199276 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
Test data was updated so vendor bill quantities are set before prices, preventing automatic vendor price recalculations from changing expected results. This keeps accounting, localization, and subscription test coverage stable after vendor price behavior improvements.
Original PR description
The corresponding community PR enables the use of a product's vendor prices on vendor bills. This means that unit prices are recomputed when the qty changes. Some tests set the qty after the price, causing a price computation. To avoid this, we set the qty first, then theprice. No Task (18.0 Bug pad)
Resolved issues and error corrections
This update adjusts an automated live chat test so it waits for browser history updates before moving back and forward. It helps reduce false test failures and improves confidence in live chat quality checks without changing end-user functionality.
Original PR description
The tour fixed implicitly checks the browser's history. In Odoo, and history entry is pushed after a setTimeout(0) to allow multiple calls to be aggregated. The fix aknowledges this by introducing delays before executing the action. runbot-error-108129 runbot-error-223364 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
Miscellaneous changes
JoFotara portal expects credit notes lines ids (in the XML) to match those of the original invoice. This expectation was not satisfied before, causing partial credit notes submission to fail. This commit solves this issue. task-4752035 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209882
Original PR description
JoFotara portal expects credit notes lines ids (in the XML) to match those of the original invoice. This expectation was not satisfied before, causing partial credit notes submission to fail. This commit solves this issue. task-4752035 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209882
This fixes an accounting screen issue where the 'Accounting Entries' section was always shown, even when it was not relevant. Users should now see a cleaner, more accurate interface with that section appearing only when appropriate.
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
The blog page heading can now be customized instead of being locked to a fixed title. This lets website managers translate or adjust the wording for different audiences, improving localization and content control.
Original PR description
Following [1], the blog page reverted to using the first blog post as the cover. However, the title of the page ("Our Latest Posts") was made non-editable and, consequently, non-translatable, which is not ideal.
This commit addresses the issue by making the title editable, ensuring it can also be translated.
[1]: https://github.com/odoo/odoo/commit/05ef95d3f13ac42713bb8d8a3002f149345cc08b
opw-4289735This update removes obsolete hidden setup fields from Chilean and Latin American invoicing screens. It prevents unnecessary Odoo.sh build warnings without changing how users create or manage invoices, refunds, journals, or bank records.
Original PR description
## Description of the issue/feature this PR addresses: Starting in 18.0, it is no longer mandatory to define invisible fields in views so that other expressions (domains, modifiers) can work…
## Description of the issue/feature this PR addresses:
Starting in 18.0, it is no longer mandatory to define invisible fields
in views so that other expressions (domains, modifiers) can work correctly,
as they are now added automatically to views.
However, their presence in the codebase causes issues when building
development branches in Odoo SH, which is why this commit removes
the reported fields that are throwing warnings.
```
Please indicate why the always invisible fields are present in the view, or remove the field tag.
Addon: 'l10n_cl'
View: view_move_form_inherit_l10n_cl
Fields:
<field name="l10n_latam_internal_type" invisible="1"/>
View: view_complete_invoice_refund_tree
Fields:
<field name="currency_id" column_invisible="True" readonly="state in ['cancel', 'posted']"/>
View: view_res_bank_form
Fields:
<field name="fiscal_country_codes" invisible="1"/>
Addon: 'l10n_latam_invoice_document'
View: view_account_journal_form
Fields:
<field name="country_code" invisible="1"/>
View: view_move_form
Fields:
<field name="l10n_latam_available_document_type_ids" invisible="1"/>
<field name="l10n_latam_manual_document_number" invisible="1"/>
View: view_account_move_reversal
Fields:
<field name="l10n_latam_use_documents" invisible="1"/>
<field name="l10n_latam_available_document_type_ids" invisible="1"/>
```
In the case of the view "l10n_cl.view_move_form_inherit_l10n_cl,"
since it only contains one field, the entire view will be removed.
No other views inherit from it.
Related enterprise PR: https://github.com/odoo/enterprise/pull/85904
## Current behavior before PR:
SH branches throw a warning because invisible fields are present in views, which is no longer needed after linked commit.
## Desired behavior after PR is merged:
SH branches won't become red or warn about invisible fields present in views because they have been added automatically to the view.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prList views now highlight selected rows consistently, whether they are even or odd striped rows. This removes a small visual inconsistency so users can more clearly see which record they have selected.
Original PR description
Current behavior before PR: When selecting an even row by clicking on it (if it's not opening a record) or by selecting the checkbox and then unchecking it, it will highlight this row. This is only working on even rows but not on odd rows. Desired behavior after PR is merged: This fix aims to make even and odd rows work correctly by being highlighted. task-4809597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that occurred when users downloaded a PDF for a draft invoice that had not yet been confirmed. This prevents a crash and allows the download flow to handle draft invoices more reliably.
Original PR description
When the user downloads the pdf of a draft invoice, a traceback will appear. Steps to reproduce the error: - Create a new invoice > Don't confirm it - Go to list view of invoices - Select that…
When the user downloads the pdf of a draft invoice,
a traceback will appear.
Steps to reproduce the error:
- Create a new invoice > Don't confirm it
- Go to list view of invoices
- Select that invoice > Download > PDF
Traceback:
```
File "addons/account/controllers/download_docs.py", line 52, in download_invoice_documents_filetype
doc_data = invoice._get_invoice_legal_documents(filetype, allow_fallback=allow_fallback)
File "addons/account_edi_ubl_cii/models/account_move.py", line 45, in _get_invoice_legal_documents
return super()._get_invoice_legal_documents(filetype, allow_fallback=allow_fallback)
File "addons/account/models/account_move.py", line 5712, in _get_invoice_legal_documents
return self._get_invoice_pdf_proforma()
File "addons/account/models/account_move.py", line 5686, in _get_invoice_pdf_proforma
filename = self._get_invoice_proforma_pdf_report_filename()
File "addons/account/models/account_move.py", line 5744, in _get_invoice_proforma_pdf_report_filename
return f"{self.name.replace('/', '_')}_proforma.pdf"
AttributeError: 'bool' object has no attribute 'replace'
```
https://github.com/odoo/odoo/blob/36e4b6f93bf2123557947e910e1be651c5357319/addons/account/models/account_move.py#L5744
When the customer downloads the pdf a draft invoice, ``self.name`` will be False,
So it will lead to the above traceback.
sentry-6191644587
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPayslips now stay in sync when an employee's legal name is corrected after the payslip was created. This prevents outdated or misspelled employee names from remaining on payroll documents, improving record accuracy.
Original PR description
Currently if you make a mistake in the name of your employee and create a payslip, it's name will never be corrected since there is no direct dependency on the field.
The customer statement page now keeps its navigation breadcrumb visible on smaller screens. Action buttons adjust their placement instead, making it easier for users to understand where they are and move around on mobile devices.
Original PR description
Because the customer statement buttons took too much space, the breadcrumb becomes invisible. This commit fixes always show the breadcrumb, and the buttons move instead. task-4583817
This update removes outdated hidden fields from Chilean electronic invoicing and stock document screens. It prevents unnecessary warnings in Odoo SH development builds without changing normal user workflows or visible functionality.
Original PR description
## Description of the issue/feature this PR addresses: Starting in 18.0, it is no longer mandatory to define invisible fields in views so that other expressions (domains, modifiers) can work…
## Description of the issue/feature this PR addresses:
Starting in 18.0, it is no longer mandatory to define invisible fields
in views so that other expressions (domains, modifiers) can work correctly,
as they are now added automatically to views.
However, their presence in the codebase causes issues when building
development branches in Odoo SH, which is why this commit removes
the reported fields that are throwing warnings.
```
Please indicate why the always invisible fields are present in the view, or remove the field tag.
Addon: 'l10n_cl_edi'
View: view_account_move_debit_note
Fields:
<field name="country_code" invisible="1"/>
View: view_invoice_form
Fields:
<field name="l10n_cl_dte_acceptation_status" invisible="1"/>
<field name="l10n_cl_reference_doc_internal_type" invisible="True"/>
View: view_account_move_reversal
Fields:
<field name="country_code" invisible="1"/>
<field name="l10n_cl_edi_reference_doc_code" readonly="1" force_save="1" invisible="1"/>
View: l10n_cl_latam_document_type_view
Fields:
<field name="l10n_cl_show_caf_button" invisible="1"/>
Addon: 'l10n_cl_edi_stock'
View: view_picking_edi_form
Fields:
<field name="l10n_cl_sii_send_file" invisible="1"/>
<field name="l10n_cl_dte_file" invisible="1"/>
<field name="l10n_cl_draft_status" invisible="1"/>
View: view_picking_edi_tree
Fields:
<field name="country_code" column_invisible="True"/>
```
Related community PR: https://github.com/odoo/odoo/pull/210616
## Current behavior before PR:
SH branches throw a warning because invisible fields are present in views, which is no longer needed after linked commit.
## Desired behavior after PR is merged:
SH branches won't become red or warn about invisible fields present in views because they have been added automatically to the view.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe point of sale IoT scale test has been updated to match a related correction made in the main Odoo codebase. This helps ensure scale integration checks remain accurate and avoids false test failures after the upstream fix.
Original PR description
This commit simply amends the expected scale checksum after the fix that was carried out in the community PR (odoo/odoo#209815) opw-4643243
Abandoned cart emails would send twice because the email values for the abandoned cart template would include the partner on the record already, but we were also including the partner email in the email values. Adjusted the email values to be empty when there is already a recipient found on the template. opw-4684534 Forward-Port-Of: odoo/odoo#210586 Forward-Port-Of: odoo/odoo#206158
Original PR description
Abandoned cart emails would send twice because the email values for the abandoned cart template would include the partner on the record already, but we were also including the partner email in the email values. Adjusted the email values to be empty when there is already a recipient found on the template. opw-4684534 Forward-Port-Of: odoo/odoo#210586 Forward-Port-Of: odoo/odoo#206158
Currently, the default ffmpeg configuration used for screencast conversion fails when browser dimensions result in odd-numbered width or height, as H.264 requires even dimensions. This commit adds a padding filter to ensure dimensions are even numbers. runbot-160976 Forward-Port-Of: odoo/odoo#209100
Original PR description
Currently, the default ffmpeg configuration used for screencast conversion fails when browser dimensions result in odd-numbered width or height, as H.264 requires even dimensions. This commit adds a padding filter to ensure dimensions are even numbers. runbot-160976 Forward-Port-Of: odoo/odoo#209100
Suppose an invoice line of 11.0 with 21% tax. The total of the invoice is 13.31. With a cash rounding of 0.05 UP, the total of the invoice becomes 13.35. If we apply an early payment discount of 2% on payments, we expect a discount of 0.25 because 13.35 * 0.98 = 13.08 but 13.10 with the cash rounding. 13.35 - 13.10 = 0.25 However, the cash rounding of the payment register wizard is computed from the total invoice instead of taking the amount stored on the accounting item. Then, he was computi
Original PR description
Suppose an invoice line of 11.0 with 21% tax. The total of the invoice is 13.31. With a cash rounding of 0.05 UP, the total of the invoice becomes 13.35. If we apply an early payment discount of 2% on payments, we expect a discount of 0.25 because 13.35 * 0.98 = 13.08 but 13.10 with the cash rounding. 13.35 - 13.10 = 0.25 However, the cash rounding of the payment register wizard is computed from the total invoice instead of taking the amount stored on the accounting item. Then, he was computing an early payment of 13.35 * 0.02 = 0.27 instead. At the end, the invoice was still open with a residual amount of 0.02. opw-4730764 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207049
Steps to reproduce: - Have a single currency active (no base.group_multi_currency) - Create a journal entry with lines: 1. Debit 10 | Credit 0 2. Debit 0 | Credit 10 - Save (note: line 2 `amount_currency` will be -10) - Modify the journal entry lines 2. (edit) Debit 10 | Credit 0 3. (new) Debit 0 | Credit 20 - Save Issue: Validation error will block the action psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_mov
Original PR description
Steps to reproduce: - Have a single currency active (no base.group_multi_currency) - Create a journal entry with lines: 1. Debit 10 | Credit 0 2. Debit 0 | Credit 10 - Save (note: line 2 `amount_currency` will be -10) - Modify the journal entry lines 2. (edit) Debit 10 | Credit 0 3. (new) Debit 0 | Credit 20 - Save Issue: Validation error will block the action psycopg2.errors.CheckViolation: new row for relation "account_move_line" violates check constraint "account_move_line_check_amount_currency_balance_sign" It occurs because, as we don't have `amount_currency` in the view, for line 2 the write operation will only store the updated values of `debit`,`credit`,`balance`, leaving the old amount of `amount_currency`. This creates an inconsistency as: - old `amount_currency` sign is negative - new `balance` sign is positive opw-4430334 Forward-Port-Of: odoo/odoo#204206 Forward-Port-Of: odoo/odoo#200566
If a tag is set on a product, it has to be propagated on the base and the tax lines. It was only set on the base line before this fix. task_id: 4789153 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209676
Original PR description
If a tag is set on a product, it has to be propagated on the base and the tax lines. It was only set on the base line before this fix. task_id: 4789153 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209676
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms
Original PR description
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe. task:3358438 Forward-Port-Of: odoo/odoo#210805 Forward-Port-Of: odoo/odoo#127190
**Issue:** when defining the form for kanban view, required attribute is not added making it true by default **steps to reproduce:** 1. install timesheets app 2. from projects app, open a task with timesheet in mobile view 3. click on `Add` button present in timesheet page 4. try to save the timesheet without 'Description' observation: Form not saved with notification "invalid field: Description" **solution:** Add relevant `required` and `readonly` property to the field this ma
Original PR description
**Issue:** when defining the form for kanban view, required attribute is not added making it true by default **steps to reproduce:** 1. install timesheets app 2. from projects app, open a task with timesheet in mobile view 3. click on `Add` button present in timesheet page 4. try to save the timesheet without 'Description' observation: Form not saved with notification "invalid field: Description" **solution:** Add relevant `required` and `readonly` property to the field this makes the behavior same across each view [see list view](https://github.com/odoo/odoo/blob/17.0/addons/hr_timesheet/views/project_task_views.xml#L41-L54) note: 1. techincal name of Description field is 'name' 2. `readonly` attribute is added to make the behavior same across each view opw-4725348 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr ; Forward-Port-Of: odoo/odoo#209630
Adding CLA Forward-Port-Of: odoo/odoo#210640 Forward-Port-Of: odoo/odoo#161944
Original PR description
Adding CLA Forward-Port-Of: odoo/odoo#210640 Forward-Port-Of: odoo/odoo#161944
Steps to Reproduce : - Drag and drop text snippet / or select some text. - Apply the back-ground color to the text. - Click on the Animate button. - You will notice that the background got removed/misplaced. The issue was caused because the animated text is wrapped in an element with "display: inline-block". To fix the bug, we moved the element with the background color inside the wrapper of the animated text, instead of keeping it outside. This fix works as long as the animated text
Original PR description
Steps to Reproduce : - Drag and drop text snippet / or select some text. - Apply the back-ground color to the text. - Click on the Animate button. - You will notice that the background got removed/misplaced. The issue was caused because the animated text is wrapped in an element with "display: inline-block". To fix the bug, we moved the element with the background color inside the wrapper of the animated text, instead of keeping it outside. This fix works as long as the animated text is exactly the same as the one with the background color. If only a portion of the text with a background color is animated, the fix doesn’t work. That case was too complex to handle, and in any case, the most common user scenarios are now fixed. task-4690318 Forward-Port-Of: odoo/odoo#210953 Forward-Port-Of: odoo/odoo#206240
When generating the self-invoice XML, the system incorrectly uses the invoice_date field, which reflects the supplier’s invoice date. However, for self-invoices in Italy, the date field (i.e., the accounting date) should be used instead. According to Italian regulations, self-invoices must be issued within 15 days of the transaction, and the invoice date must fall within the month the invoice is received. Using the supplier’s invoice date (e.g., April 2025) when the invoice is actually receiv
Original PR description
When generating the self-invoice XML, the system incorrectly uses the invoice_date field, which reflects the supplier’s invoice date. However, for self-invoices in Italy, the date field (i.e., the accounting date) should be used instead. According to Italian regulations, self-invoices must be issued within 15 days of the transaction, and the invoice date must fall within the month the invoice is received. Using the supplier’s invoice date (e.g., April 2025) when the invoice is actually received in May 2025 results in non-compliance. References Official: https://www.agenziaentrate.gov.it/portale/documents/20143/451259/Guida_compilazione-FE-Esterometro-V_1.9_2024-03-05.pdf/67fe4c2d-1174-e8de-f1ee-cea77b7f5203 , page 14 Extra: https://www.fiscoetasse.com/approfondimenti/16247-reverse-charge-interno-e-reverse-charge-esterno.html , entry 5  Forward-Port-Of: odoo/odoo#210342
- Fixes the error coming from using discounts in invoices: the node `AllowanceChargeReasonCode` was added while not accepted by the Turkish implementation, and the amounts might not respect the asked format in some cases. - Fixes the error coming from invoices using a different currency than the company one (TRY). Although the documentation says the node `PricingExchangeRate` is only needed "If the prices of goods or services on the invoice are shown in a currency other than the 'Docum
Original PR description
- Fixes the error coming from using discounts in invoices: the node `AllowanceChargeReasonCode` was added while not accepted by the Turkish implementation, and the amounts might not respect the asked format in some cases. - Fixes the error coming from invoices using a different currency than the company one (TRY). Although the documentation says the node `PricingExchangeRate` is only needed "If the prices of goods or services on the invoice are shown in a currency other than the 'Document Currency", and our file did indeed use only one currency at a time (either all TRY or all USD amounts, e.g.), the server was still refusing our file. - Limits the decimal precision to 2 for most amoutns, as requested by the nilvera format. - Use uppercase on invoice names when putting them in the xml. task-4356940 Forward-Port-Of: odoo/odoo#210622 Forward-Port-Of: odoo/odoo#205749
<b>Steps to reproduce:</b> 1. Go to Sales > Create a Quotation 2. Add Customer > Set Customer's lang to French or German 3. Add a product, confirm the quotation 4. Click "Create Invoice" > Select "Down Payment (percentage)" 5. Set amount (e.g., 20.5%) and create the invoice <b>Issue:</b> - When creating a down payment invoice using the "percentage" option, description text is translated correctly to partner's language (e.g., French or German), but amount in description remains f
Original PR description
<b>Steps to reproduce:</b> 1. Go to Sales > Create a Quotation 2. Add Customer > Set Customer's lang to French or German 3. Add a product, confirm the quotation 4. Click "Create Invoice" > Select "Down Payment (percentage)" 5. Set amount (e.g., 20.5%) and create the invoice <b>Issue:</b> - When creating a down payment invoice using the "percentage" option, description text is translated correctly to partner's language (e.g., French or German), but amount in description remains formatted using English conventions (e.g. "20.5%" instead of "20,5 %" in French or German). <b>Cause:</b> - This happens because the amount is inserted as a raw float without localization. <b>Solution:</b> - This fix uses `formatLang()` with the correct context to format the percentage amount according to the partner's language (i.e., proper decimal separator). <b>opw-4743326</b> Forward-Port-Of: odoo/odoo#210927 Forward-Port-Of: odoo/odoo#210570
Currently because of the changes in ca35adf7412b132e37c22d09 both the test `test_increase_available_quantity_3` and `test_decrease_available_quantity_3` are always skipped, even with demo data. That's because `self.stock_location` points to a new location created in `setUpClass`. So no demo data quant can have this location_id as it cannot be referenced from a demo data file. However, "stock.stock_location_stock" is actually created in a data file, `stock_data.xml`. So we can revert back to u
Original PR description
Currently because of the changes in ca35adf7412b132e37c22d09 both the test `test_increase_available_quantity_3` and `test_decrease_available_quantity_3` are always skipped, even with demo data. That's because `self.stock_location` points to a new location created in `setUpClass`. So no demo data quant can have this location_id as it cannot be referenced from a demo data file. However, "stock.stock_location_stock" is actually created in a data file, `stock_data.xml`. So we can revert back to using `env.ref` instead of creating a new location. With that both tests are properly executed when demo data are installed while they are skipped without demo data. We're also creating the quants in case they are not found in the database so we ensure the test is always run. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204682
This **PR** introduces manual input for lines 01, 04, 10, and 25 in the mod.111 report. The previous automatic calculation based on tax tags was unreliable and could produce inaccurate values, so manual entry ensures the data correctly reflects actual figures. **task**-4797773 Forward-Port-Of: odoo/odoo#210279
Original PR description
This **PR** introduces manual input for lines 01, 04, 10, and 25 in the mod.111 report. The previous automatic calculation based on tax tags was unreliable and could produce inaccurate values, so manual entry ensures the data correctly reflects actual figures. **task**-4797773 Forward-Port-Of: odoo/odoo#210279
…atch Batch generation currently takes contract templates, which it should not Forward-Port-Of: odoo/enterprise#86120
Original PR description
…atch Batch generation currently takes contract templates, which it should not Forward-Port-Of: odoo/enterprise#86120
Fix qty_delivered when a rental order is processed through the PoS. This commit ensure that the PoS qty_delivered computation is done after the other calculation Steps to reproduce: ------------------- * Make a rental for 1 product * Open the sale order in PoS * Pay for the rental > Observation: The qty_delivered is set to 2 instead of 1 on the rental Why the fix: ------------ When the order is a rental processed through the PoS, we recompute the rental qty and add the PoS quantity
Original PR description
Fix qty_delivered when a rental order is processed through the PoS. This commit ensure that the PoS qty_delivered computation is done after the other calculation Steps to reproduce: ------------------- * Make a rental for 1 product * Open the sale order in PoS * Pay for the rental > Observation: The qty_delivered is set to 2 instead of 1 on the rental Why the fix: ------------ When the order is a rental processed through the PoS, we recompute the rental qty and add the PoS quantity to make sure that the value is correct. The computation is actually just the fusion of the PoS and rental _compute_qty_delivered methods. opw-4582505 Forward-Port-Of: odoo/enterprise#85130 Forward-Port-Of: odoo/enterprise#84768
In https://github.com/odoo/odoo/commit/6d2bfc85bc0e387fbf4d3a64eb15b18ec59e9b47 we removed an explicit flush performed right after move creation. Because of this change, when fetching data for the sie import we might not see all the relevant lines. We need to ensure to flush any data left in cache before making a SQL query no opw Forward-Port-Of: odoo/enterprise#82591 Forward-Port-Of: odoo/enterprise#82292
Original PR description
In https://github.com/odoo/odoo/commit/6d2bfc85bc0e387fbf4d3a64eb15b18ec59e9b47 we removed an explicit flush performed right after move creation. Because of this change, when fetching data for the sie import we might not see all the relevant lines. We need to ensure to flush any data left in cache before making a SQL query no opw Forward-Port-Of: odoo/enterprise#82591 Forward-Port-Of: odoo/enterprise#82292
…tems When using OSS, the user has to put the OSS tag on the product. This test ensures the OSS tag is well propagated from the product to the accounting items representing the invoice line plus the generated tax lines. task_id: 4789153 Forward-Port-Of: odoo/enterprise#85381
Original PR description
…tems When using OSS, the user has to put the OSS tag on the product. This test ensures the OSS tag is well propagated from the product to the accounting items representing the invoice line plus the generated tax lines. task_id: 4789153 Forward-Port-Of: odoo/enterprise#85381
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms
Original PR description
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe. task:3358438 Forward-Port-Of: odoo/enterprise#85968 Forward-Port-Of: odoo/enterprise#43574
This commit fixes an issue with the Facebook app and the management of pages. For Facebook to identify the user as able to manage a page, we need to provide another permission to the scope. The permission `business_management` is needed for the API to understand that the user is able to manage its pages. Thus we are adding it to the scope but as an optional permission. Some users may not have this permission set up for their own applications, thus we are adding the system parameter `social.
Original PR description
This commit fixes an issue with the Facebook app and the management of pages. For Facebook to identify the user as able to manage a page, we need to provide another permission to the scope. The permission `business_management` is needed for the API to understand that the user is able to manage its pages. Thus we are adding it to the scope but as an optional permission. Some users may not have this permission set up for their own applications, thus we are adding the system parameter `social.facebook_no_business_management`. This parameter blocks the addition of the permission to the scope if set to any value, if not set it adds the permission to the scope. task-4719790 Forward-Port-Of: odoo/enterprise#84032