Daily updates from Odoo
Thursday, October 17, 2024
66 changes · 18.0
New functionality added to Odoo
This change adds support for subscriptions that invoice recurring products based on delivered timesheets, ensuring only timesheets from the relevant invoicing period are counted. It also fixes subscription billing scheduling issues so free subscriptions and automated invoice runs continue updating correctly.
Original PR description
Add a new bridge module for timesheeted product with recurring invoice. This module overwrite the computation of delivered quantity for recurring line invoiced on delivered timesheet to only account for those delivered during the invoice deferred period. + several fixes task-id: 4221354
Enhancements to existing features
Users can now manually unpin sub-threads in Mail instead of having them remain pinned by default. This gives users more control over their discussion sidebar and helps keep conversations organized around what matters to them.
Original PR description
Sub-thread is pinned by default and user couldn't unpin it. This commit lets user unpin the sub-thread manually. Backport of https://github.com/odoo/odoo/pull/183758
Manufacturing users can now quickly filter the manufacturing order list to see only orders assigned to them. Barcode workflows for manufacturing operation types also show a more focused list of ready, relevant orders to help teams find the right work faster.
Original PR description
In this commit: ================== - added a new 'My MOs' filter to the manufacturing order list view that returns all manufacturing orders you are assigned. - replace the domain that applied when we enter the manufacturing operation type from the barcode application to domain 'to do + respective operation type + MO ready'. task-3925741
Project information is now kept when make-to-order replenishment creates related manufacturing or purchase orders. This helps teams maintain clearer project traceability across sales, production, and purchasing workflows.
Original PR description
This PR ensures that the project field is propagated in different MTO scenarios. This commit specifically focuses on: MO -> Child MO, MO -> PO, SO -> PO scenarios. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The tax report now hides the tax period filter when standard date filters can already produce the same monthly or quarterly periods. This reduces clutter and helps users focus on only the filters needed for their reporting scenario.
Original PR description
Before, the tax period filter was always shown even if the dates could be made from the other filters Now we hide it if the periodicity is monthly or quarterly and that the start date is the first day of the year. Otherwise we can show it because it will create different dates not possible with the default filters unless we use the custom dates filter. task-4197475
Spreadsheets now open faster by skipping an unnecessary data conversion step when loading saved snapshots. This reduces wait time for users working with larger spreadsheet files, with a measured load-time improvement from 189ms to 101ms in the tested case.
Original PR description
Similarly to odoo/odoo@f02bcfadcbb66fb237a5af3a10a35e36355b8b2e we no longer use the binary field which encodes the data to base64 because we were decoding it right after, which is useless work. We now directly read the raw data from the binary field underlying attachment Time spent in `_get_spreadsheet_snapshot` when opening a spreadsheet with a 16.7Mb snapshot: before: 189ms after: 101ms
Resolved issues and error corrections
This fixes an internal issue where grouped list results could be ordered incorrectly when custom field sorting logic contained spaces or line breaks. The change makes ordering more reliable for customized Odoo models and adds tests to prevent regressions.
Original PR description
`_read_group_orderby` used `cr.mogrify`, `split(",")` and `split()[0]` for the
result coming from the `_order_to_sql` which may come from `_field_to_sql`
As a side effect, SQL code after a space/newline not adjacent to a comma will
be dropped after `split()[0]`. So the mogrified customized `_field_to_sql`
shoudn't have any space/newline not adjacent to a comma if the field is used
for `Model._order`.
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-prThe customer portal invoice preview now better matches the invoice layout selected during Print & Send. If a customer has a custom invoice template setting, the portal uses it instead of always showing the default Odoo invoice format.
Original PR description
In the Print & Send, it is possible to use a different report template than the Odoo default one ('account.account_invoices'). This is not reflected in the portal preview.
Solution:
Which template has been used for an invoice is not an information that is saved in Odoo so we can't do something 100% accurate. When an invoice is generated with a different report than Odoo's one we save that as a setting on the partner.
We will render the portal preview with that template if it is set, to try to be closer to what should be shown.
task-no (approved by CHKL)This fixes an issue where the correct PDF report option was not always shown in the accounting Print & Send flow. It helps users reliably select and send the intended document without confusion or extra manual steps.
Original PR description
The display_pdf_report_id is not correctly computed. task-no
This update fixes several user-visible issues, including point of sale rescue sessions failing to open, website Facebook snippets breaking editing, and mailing cover images not appearing correctly. It also improves spreadsheet dashboards by adding favorites and better small-screen layout, while adding invoice list information for fapiao support.
This fixes the placement of editor action buttons when using right-to-left languages such as Arabic. It makes editing content smoother for users working in those languages by respecting the direction set on the main editable area.
Original PR description
Description of the issue this PR addresses: Previously, the positioning of powerbuttons only considered the `dir` attribute on the closest block element. However for true RTL languages like Arabic, the `dir` attribute is applied to the editable container, not the individual nodes. This commit makes sure that `dir` attribute of editable is taken into account when the closest block does not have its own `dir` attribute. task-4259040 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request addresses several user-facing issues across Odoo, including duplicate email attachments, incorrect dropshipping delivery slip descriptions, misplaced table tools in email editing, currency conversion errors in shipping, missing RPC header support, and overly broad calendar email recipients. These fixes help improve accuracy, reduce customer confusion, and prevent unnecessary notifications.
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
This fixes a website issue where pages could unexpectedly jump back to the top when a popup appeared while animations were running. The change keeps visitors in the right place on the page, improving the browsing experience for animated website pages.
Original PR description
Since this commit [1], from which the scrolling element is no longer '#wrapwrap' but HTML, test 'snippet_popup_and_animations' fails. Because during animations 'overflow-x: hidden' is added on the…
Since this commit [1], from which the scrolling element is no longer '#wrapwrap' but HTML, test 'snippet_popup_and_animations' fails. Because during animations 'overflow-x: hidden' is added on the scrolling element (HTML). And a the time of a modal show, a 'overflow: hidden' style is added brievly on the 'body' element. Wich cause the page scroll to top when a modal sho while an animation is playing on the page. To fix this, unwanted behavior, we moved the 'overflow-x: hidden' rule added during animations from the HTML the the body. Since this commit [1], from which the scrolling element is no longer '#wrapwrap' but HTML, the test 'snippet_popup_and_animations' fails. This is because during animations, 'overflow-x: hidden' is added to the scrolling element (HTML). At the time a modal shows, an 'overflow: hidden' style is briefly added to the 'body' element, which causes the page to scroll to the top when a modal shows while an animation is playing on the page. To fix this unwanted behavior, we moved the 'overflow-x: hidden' rule added during animations from the HTML to the body." [1]: https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e task-4185877
Sales users will no longer see a general warning when changing a product's type on sales-related products. This reduces unnecessary interruptions while existing safeguards still block changes when they are not allowed.
Original PR description
Before the commit: Previously, when the product type of an item in a sales order was changed, a warning would be displayed, but users were still allowed to make the change. Although there are other checks in place to prevent changes to the product type under certain conditions, the general warnings were unnecessary. After the commit: Now, there will be no general warning when changing a product's type.
This fix makes the interactive sales walkthrough more reliable by ensuring guidance appears at the right time, users can continue after editing a line price without extra clicks, and the walkthrough does not fail when no document layout setup is needed. It helps users complete the sales flow with fewer interruptions during guided onboarding or training.
Original PR description
This change fixes the following issues, which occured when running the tour interactively: - The tooltip prompting the user to select or create a product wasn't shown, - After setting the SOL's price, the user had to click on the SOL again to trigger the next step (whereas they should be able to click anywhere), - If there was no document layout to configure, the tour would fail.
The Print & Send wizard now shows sending method names in the user's selected language instead of always showing English labels. This improves clarity for multilingual users and helps reduce confusion when sending accounting documents.
Original PR description
The sending methods displayed in the Print & Send wizard were populated using the selection field's `selection` field. This only gave the English terms as defined in the code. This commit fixes that by using another method that gets the values in the current user's language.
This update corrects how accrual carry-over validity is shown in Time Off settings. It prevents an unset validity value from appearing to users and fixes a related display widget name, reducing confusion when configuring leave accrual rules.
Original PR description
in this commit, fixes a issue where carry over validity isn't set value is still visible in view. task-4207945 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
This fix prevents the Calendar app from creating user settings records when they are not actually needed. It reduces unnecessary background data creation, helping keep user data cleaner without changing the visible calendar experience.
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
This fixes an issue where action buttons in list views were missing on mobile devices. Those buttons now appear in the mobile cog menu, making important list actions accessible for users on smaller screens.
Original PR description
When we create a list view with a header buttons, the buttons didn't displayed in the DOM, but it should have been shift inside the cog menus. 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
When accounting accounts are merged, their translated names are now preserved instead of being lost. This helps multilingual companies keep accurate account labels for users working in different languages.
Original PR description
At the moment, when we merge accounts, we don't merge the account name's translations. This is a bit annoying since one account might have been called 'Account Receivable' in English, and another one might have been called 'Clientes' in Spanish. At the moment, the translations of the other accounts are lost. This commit makes us merge the translations when merging the accounts. taskid: 4210775
Fixes an issue that prevented portal users from previewing quotations for Brazilian companies. This ensures sales documents can be viewed reliably without an error interrupting the customer or sales workflow.
Original PR description
Currently, you view quotations in the portal with a Brazilian company.
### Steps to reproduce
* install `l10n_br_sales`
* switch to a Brazilian company
* attempt to "Preview" a quotation
You should be met with the following traceback:
```
AttributeError: 'NoneType' object has no attribute 'decimal_places'
Template: l10n_br_sales.document_tax_totals_brazil
Path: /t/tr[2]/td[2]/strong
Node: <strong t-out="tax_totals[\'total_amount_currency\']" t-options="{"widget": "monetary", "display_currency": currency}"/>
```
opw-4247492This fix ensures project forecast users see the correct error messages when something needs their attention. Clearer messages reduce confusion and help users understand what action to take.
Original PR description
Fixed incorrect error messages that were previously displayed. task-4193991
The barcode app now shows the appropriate manufacturing orders when entering a manufacturing operation type, focusing on items that are ready or still to do. New manufacturing orders created from a scanned operation type are now assigned to that same operation type, preventing confusion and misrouting in warehouse workflows.
Original PR description
In this commit: ================== - Replace the domain that applied when we enter the manufacturing operation type from the barcode application to domain 'To Do and MO ready'; - Use the right operation type when a new MO is created from the barcode app, regardless it was created by scanning the MO's product or using the form view. task-3925741
The worksheet button on field service task portal pages now appears in the same navigation area as related options like Task and History. This keeps the page layout consistent and prevents the button from looking out of place for customers using the portal.
Original PR description
Before this commit, the worksheet button is wrongly placed in the navbar of the portal form view of a task and so, it will lead to a wrong design for that button. This commit moves that button in the right place to be sure to have the same style than the other nav buttons (this is, `Task`, `History`,...) task-4251535
Manufacturing planning now correctly includes component consumption when calculating starting inventory. This helps planners see more accurate stock levels for components that are also tracked in the Master Production Schedule.
Original PR description
When a MO consumes components that have a MPS record, the MPS does not take the consumption moves into account for the starting quantity of the MPS record. This PR removes that condition to make sure the starting inventory is correctly computed.
Subscription quotations can now be previewed in the customer portal for Brazilian companies without triggering an error. This prevents a blocker for reviewing subscription offers and improves the portal experience for affected customers.
Original PR description
Currently, you view subscription quotations in the portal with a Brazilian company.
### Steps to reproduce
* install `l10n_br_sales`
* switch to a Brazilian company
* attempt to "Preview" the subscription quotation
You should be met with the following traceback:
```
AttributeError: 'NoneType' object has no attribute 'decimal_places'
Template: l10n_br_sales.document_tax_totals_brazil
Path: /t/tr[2]/td[2]/strong
Node: <strong t-out="tax_totals[\'total_amount_currency\']" t-options="{"widget": "monetary", "display_currency": currency}"/>
```
opw-4247492The customer portal now shows the correct upcoming invoice amount for subscriptions instead of zero. This prevents customers from seeing misleading billing information when previewing a sales order.
Original PR description
Version: - 18.0 Steps to reproduce: - Install the sale_subscription module - Create a Sales Order and preview it in the portal Issue: - The next billing amount in the portal shows as zero. Cause: - The wrong amount value is being used in the condition. Solution: - Use the correct total_amount to fix the issue. task-4247106
Features or functions removed from Odoo
This update removes a repeated check related to subscription invoice dates. It simplifies the subscription sales logic without changing expected customer-facing behavior, reducing minor maintenance risk.
Original PR description
In this commit, Remove the duplicate check for next_invoice_date
Documentation and clarification updates
This update records Codeforward B.V.'s corporate Contributor License Agreement signature. It supports legal compliance for contributions to Odoo and does not change any product functionality.
Original PR description
Adds a corporate signature for Codeforward B.V. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
- sale_project: fix domain as it is not possible to select a SOL on a task in the case where the SOL's contact belongs to the same company than the contact set as the task's customer. The `.id` was removed by https://github.com/odoo/odoo/commit/e095ef5153fb1a8364a4f53896a522fefa35ecd9 and is actually necessary if we want to have SOLs where the `order_partner_id` is the parent of the `partner_id` or shares the same parent than `parent_id`. - sale: remove SOLs of discount products from th
Original PR description
- sale_project: fix domain as it is not possible to select a SOL on a task in the case where the SOL's contact belongs to the same company than the contact set as the task's customer. The `.id` was removed by https://github.com/odoo/odoo/commit/e095ef5153fb1a8364a4f53896a522fefa35ecd9 and is actually necessary if we want to have SOLs where the `order_partner_id` is the parent of the `partner_id` or shares the same parent than `parent_id`. - sale: remove SOLs of discount products from the SOLs considered as sellable. The discount products are "fake" products used to manage discounts. opw-4212956 Forward-Port-Of: odoo/odoo#183735 Forward-Port-Of: odoo/odoo#183121
When User Clicks on Send payment status to SInvoice action, a traceback will appear. Steps to reproduce the error: - Install ``l10n_vn_edi_viettel`` module - Switch to VN Company - Go to Invoicing > Customers > Invoices > Select any invoice > Actions > Send payment status to SInvoice Traceback: ``` SyntaxError: syntax error at or near ")" LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO... ^ File "odoo/tool
Original PR description
When User Clicks on Send payment status to SInvoice action, a traceback will appear. Steps to reproduce the error: - Install ``l10n_vn_edi_viettel`` module - Switch to VN Company - Go to Invoicing >…
When User Clicks on Send payment status to SInvoice action,
a traceback will appear.
Steps to reproduce the error:
- Install ``l10n_vn_edi_viettel`` module
- Switch to VN Company
- Go to Invoicing > Customers > Invoices > Select any invoice > Actions >
Send payment status to SInvoice
Traceback:
```
SyntaxError: syntax error at or near ")"
LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO...
^
File "odoo/tools/safe_eval.py", line 391, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(2134,)", line 3, in <module>
File "addons/l10n_vn_edi_viettel/models/account_move.py", line 299, in action_l10n_vn_edi_update_payment_status
self.env['res.company']._with_locked_records(self)
File "addons/account/models/company.py", line 785, in _with_locked_records
self._cr.execute(f'SELECT * FROM {records._table} WHERE id IN %s FOR UPDATE SKIP LOCKED', [tuple(records.ids)])
File "odoo/sql_db.py", line 347, in execute
res = self._obj.execute(query, params)
ValueError: <class 'psycopg2.errors.SyntaxError'>: "syntax error at or near ")"
LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO...
^
```
https://github.com/odoo/odoo/blob/072da22e72e66e6332d073502b987682f1b6e88b/addons/account/models/company.py#L745
Here, when there are no records for sending their payment status to SInvoice,
records.ids will be empty,
It will lead to the above traceback.
This commit will fix the above issue by preventing the execution of the query
when ``records.ids`` is empty.
sentry-5954926261
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#182621Currently there is the following problem when loading a chart template on a company. In case the company has no country set the loading of the template may set it. This can i.e. happen when the template specifies a `account_fiscal_country_id`. Setting a country on a company (`write`) may trigger the installation of additional localization modules related to the country (`install_l10n_modules`). The problematic `write` happens in `_pre_load_data` but the actual template data is not loaded y
Original PR description
Currently there is the following problem when loading a chart template on a company. In case the company has no country set the loading of the template may set it. This can i.e. happen when the…
Currently there is the following problem when loading a chart template on a company.
In case the company has no country set the loading of the template may set it.
This can i.e. happen when the template specifies a `account_fiscal_country_id`.
Setting a country on a company (`write`) may trigger the installation of additional
localization modules related to the country (`install_l10n_modules`).
The problematic `write` happens in `_pre_load_data` but the actual
template data is not loaded yet (happens later in `_load_data`).
This can cause the following 2 issues.
Issue (1)
The new modules may add new data to the current template (modifies the
result of `_get_chart_template_data`).
But this new data is not considered during the current loading
since the template data is fetched before the automatic installation happens.
The module may not work as intended for companies w/o the new data though.
So we would have to reload the chart template manually.
Issue (2)
The auto-installation happens after the chart template info (field `chart_template`)
is set on the company but before the data is actually loaded.
The module installation may trigger a post init hook to set up new
data on companies with the current template (field `chart_template`).
This new setup may rely on the chart template data (from before the
module was installed) being laoded already though.
Issue (2) i.e. causes runbut build error-60149.
During the populate test a company with chart_template 'generic_coa'
is created which causes the installation of module `l10n_us_reports`
during the 'generic_coa' chart template loading.
There the deferred expense and revenue accounts are loaded in a post init hook
via `_load_data` for every company where the `chart_template` field has value 'generic_coa'.
```python
ChartTemplate._load_data({
'res.company': , {
company.id: {
'deferred_expense_account_id': 'prepaid_expenses',
'deferred_revenue_account_id': 'deferred_revenue',
}
}
})
```
Here 'prepaid_expenses' and 'deferred_revenue' are xmlids of accounts of the
'generic_coa' chart template from module 'account'.
Since the template data has not been loaded yet we cannot derefence
these 2 xmlids. In the log we get the following warning:
> Failed when trying to recover prepaid_expenses for field=res.company.deferred_expense_account_id
To avoid this problem we just skip the automatic installing in case we are in the process
of loading a chart template.
runbot build error-60149
Forward-Port-Of: odoo/odoo#183792Issue: ===== The cover template of the training theme template doesn't show in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing with training template - Send a test email - Cover snippet missing Origin of the issue: ==================== While converting the template from bootstrap to table we expect to have `container` -> `row` -> `col` classes but the template was missing the `col` class opw-3944347 Forward-Port-Of: odoo/odoo#1
Original PR description
Issue: ===== The cover template of the training theme template doesn't show in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing with training template - Send a test email - Cover snippet missing Origin of the issue: ==================== While converting the template from bootstrap to table we expect to have `container` -> `row` -> `col` classes but the template was missing the `col` class opw-3944347 Forward-Port-Of: odoo/odoo#183999 Forward-Port-Of: odoo/odoo#183105
Steps --- * In the setting enable *Multi Step Routes* * Create an internal transfer with 1 operation for some product > *Mark as Todo* * On the stock.move operation line click the list icon for detailed operations. * *Add a line* => this opens a Wizard where we can choose the quant from which to pick the product for the sml * After adding the line *Add a line* again, we cannot pick the same quant Use case --- For internal transfers, we would like to be able to pick products from the s
Original PR description
Steps --- * In the setting enable *Multi Step Routes* * Create an internal transfer with 1 operation for some product > *Mark as Todo* * On the stock.move operation line click the list icon for detailed operations. * *Add a line* => this opens a Wizard where we can choose the quant from which to pick the product for the sml * After adding the line *Add a line* again, we cannot pick the same quant Use case --- For internal transfers, we would like to be able to pick products from the same quant and dispatch them to several sub-locations of the picking's destination location. Side Fix --- Delete `onRecordDiscarted` method, which wasn't being used because of the typo and doesn't appear to be necessary. opw-4072541 Co-authored-by: @ajf-odoo Forward-Port-Of: odoo/odoo#183815 Forward-Port-Of: odoo/odoo#174984
Reproduce --- - -i event_crm_sale,website_event_questions - Create new "Lead Generation Rule" (Events/Configuration/Lead Generation) - "If the Attendees meet these Conditions": `[("lead_ids", "=", False)]` - add some tag - Add new attendee to an EVENT - Add new question to the EVENT - BUG: `KeyError: 'registration_answer_ids'` opw-4125944 Forward-Port-Of: odoo/odoo#179734
Original PR description
Reproduce
---
- -i event_crm_sale,website_event_questions
- Create new "Lead Generation Rule" (Events/Configuration/Lead Generation)
- "If the Attendees meet these Conditions": `[("lead_ids", "=", False)]`
- add some tag
- Add new attendee to an EVENT
- Add new question to the EVENT
- BUG: `KeyError: 'registration_answer_ids'`
opw-4125944
Forward-Port-Of: odoo/odoo#179734Commands that stop and start the LED service in `posbox_update.sh` were removed in commit `bf96199`, however these were necessary to prevent the filesystem getting stuck in write-mode and potentially getting corrupted (see #54339). The fix is to restore these commands in `posbox_update.sh`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183868
Original PR description
Commands that stop and start the LED service in `posbox_update.sh` were removed in commit `bf96199`, however these were necessary to prevent the filesystem getting stuck in write-mode and potentially getting corrupted (see #54339). The fix is to restore these commands in `posbox_update.sh`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183868
Follow-up of https://github.com/odoo/odoo/pull/177238 PR above improved showing of new messages in Odoo while being out of focus by showing it in tab title and blinking the text. However this felt too obstructive in practice. This commit removes the blinking part, and instead show the out-of-focus amount of unread messages as a counter as prefix of the tab title. For example, if the action is "Inbox", it shows "(4) Inbox" when there are 4 unread and important messages received while odo
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/177238 PR above improved showing of new messages in Odoo while being out of focus by showing it in tab title and blinking the text. However this felt too obstructive in practice. This commit removes the blinking part, and instead show the out-of-focus amount of unread messages as a counter as prefix of the tab title. For example, if the action is "Inbox", it shows "(4) Inbox" when there are 4 unread and important messages received while odoo is out-of-focus. Also take new inbox messages into account for the out-of-focus counter. Task-4242524 Inbox contains a single message, 21 messages are posted in a DM. Before  After  Forward-Port-Of: odoo/odoo#182347
Before this commit, archived combinations were computed using a different method, despite the existence of a specific function designed for this purpose. opw-4261061 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183886
Original PR description
Before this commit, archived combinations were computed using a different method, despite the existence of a specific function designed for this purpose. opw-4261061 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183886
When reconciliing and invoice with a misc entry line, we display the amount currency of the total amount of the entry instead of the partial. Steps: - With USD company currency and EUR foreign currency - Make an invoice for 2000 EUR - Register a payment for 1000 EUR - Make a journal entry in USD, 3 credit lines 1000 USD each on the receivable account, for the invoice's partner - Come back to the invoice and reconcile it with two misc lines via the outstanding credit widget - O
Original PR description
When reconciliing and invoice with a misc entry line, we display the amount currency of the total amount of the entry instead of the partial. Steps: - With USD company currency and EUR foreign currency - Make an invoice for 2000 EUR - Register a payment for 1000 EUR - Make a journal entry in USD, 3 credit lines 1000 USD each on the receivable account, for the invoice's partner - Come back to the invoice and reconcile it with two misc lines via the outstanding credit widget - Open the payment and print the payment receipt -> The Amount Currency column of the misc entry lines show -$3000 instead of $-1000 and $-528.89 (depending of the current rate) With this commit we take the debit or credit amount currency from the partial instead of the total amount of the entry. opw-4089534 Forward-Port-Of: odoo/odoo#183819 Forward-Port-Of: odoo/odoo#180189
The "mark as read" banner helps users keep track of where they last left off in a conversation. Currently, the banner is removed in the following situations: - When returning to the thread twice. - When posting a message. - When clicking on the "mark as read" button on the banner. However, this approach is insufficient, as the banner appears too frequently. This pull request streamlines the conditions under which the banner disappears. The banner will now be removed wheni on top of
Original PR description
The "mark as read" banner helps users keep track of where they last left off in a conversation. Currently, the banner is removed in the following situations: - When returning to the thread twice. - When posting a message. - When clicking on the "mark as read" button on the banner. However, this approach is insufficient, as the banner appears too frequently. This pull request streamlines the conditions under which the banner disappears. The banner will now be removed wheni on top of the other conditions: - The user scrolls to the bottom of the thread. - The user opens a thread that does not have a scrollbar. Both circumstances are sufficient to indicate that the user has actually read the messages. task-4102924 Forward-Port-Of: odoo/odoo#183551
Issue: ====== We can't click twice on the transform button. Steps to reproduce the issue: ============================= - Create a todo - Add an image - Select it - Click on the transform button in the toolbar - The toolbar disappears so we can't click another time Origin of the issue: ==================== The issue was introduced in [1]. Removing the selection will trigger a selectionChange which itself triggers updateToolbar but now we don't have any selection so we hide the to
Original PR description
Issue: ====== We can't click twice on the transform button. Steps to reproduce the issue: ============================= - Create a todo - Add an image - Select it - Click on the transform button in the toolbar - The toolbar disappears so we can't click another time Origin of the issue: ==================== The issue was introduced in [1]. Removing the selection will trigger a selectionChange which itself triggers updateToolbar but now we don't have any selection so we hide the toolbar. Solution: ========= Revert the old fix and instead we ignore any `keydown` event when the transform container is in the dom (which means we are currently transforming an image). task-4235140 [1]: https://github.com/odoo/odoo/commit/463c248e291a53c80365ae606c7cf39e13cd290b Forward-Port-Of: odoo/odoo#183702 Forward-Port-Of: odoo/odoo#182723
**Behaviour before PR:** - In chatgpt prompt dialog, `submitPrompt` method gets called twice when user presses `ctrl + enter` after writing something. As result chatgpt responds twice with same content. This happens because in `dialog.js` a hotkey service is active on `ctrl + enter` which is responsible to trigger a click event on submit button of dialog and `submitPrompt` gets called second time. - Moreover, if text-area is empty and user hits `enter` then an empty prompt is sent to chatGPT
Original PR description
**Behaviour before PR:** - In chatgpt prompt dialog, `submitPrompt` method gets called twice when user presses `ctrl + enter` after writing something. As result chatgpt responds twice with same content. This happens because in `dialog.js` a hotkey service is active on `ctrl + enter` which is responsible to trigger a click event on submit button of dialog and `submitPrompt` gets called second time. - Moreover, if text-area is empty and user hits `enter` then an empty prompt is sent to chatGPT resulting in a meaningless response. **Behaviour after PR:** - Now, `submitPrompt` method gets called once on `ctrl + enter.` - If text-area is empty then pressing `enter` will not submit prompt. task-4207108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181334
Steps to reproduce ================== - Go to CRM - Open a lead - Open studio - Add a new notebook page - Add a many2many field - Select the task model - Save and exit studio - Switch to the new notebook page - Add a new task => Record does not exist or has been deleted. Cause of the issue ================== The CrmFormRecord is also used for the Many2Many popup. project.task also has a stage_id field, checkRainbowmanMessage is then called, but with the id of the task ht
Original PR description
Steps to reproduce ================== - Go to CRM - Open a lead - Open studio - Add a new notebook page - Add a many2many field - Select the task model - Save and exit studio - Switch to the new notebook page - Add a new task => Record does not exist or has been deleted. Cause of the issue ================== The CrmFormRecord is also used for the Many2Many popup. project.task also has a stage_id field, checkRainbowmanMessage is then called, but with the id of the task https://github.com/odoo/odoo/blob/54d6a19444bfa4f01d03117e4542a5244f274429/addons/crm/static/src/views/crm_form/crm_form.js#L44-L51 Solution ======== It makes no sense to do this if we are not acting on a crm.lead record => We check the resModel before proceeding opw-4101752 Forward-Port-Of: odoo/odoo#183375
As this pr is [merged] (https://github.com/odoo/odoo/pull/152709) so due to this ``float_round`` behaviour is bit changed due to that here is test case is failing in upgrade that checks the qty_available with product their is difference come. [Here](https://github.com/odoo/odoo/blob/251ef3edcc7e0894683acb7c69bfa437a024110f/addons/stock/models/product.py#L207) before product record ``qty_avaliable`` (it non stored field and compute) to come like this ``'qty_available': 0.7000000000000001 `` after
Original PR description
As this pr is [merged] (https://github.com/odoo/odoo/pull/152709) so due to this ``float_round`` behaviour is bit changed due to that here is test case is failing in upgrade that checks the…
As this pr is [merged] (https://github.com/odoo/odoo/pull/152709) so due to this ``float_round`` behaviour is bit changed due to that here is test case is failing in upgrade that checks the qty_available with product their is difference come. [Here](https://github.com/odoo/odoo/blob/251ef3edcc7e0894683acb7c69bfa437a024110f/addons/stock/models/product.py#L207) before product record ``qty_avaliable`` (it non stored field and compute) to come like this ``'qty_available': 0.7000000000000001 `` after new changes in ``float_round`` after this [pr](https://github.com/odoo/odoo/pull/152709) in 17.4 value is ``'qty_available': 0.7`` coming like this and after dividing [here](https://github.com/odoo/odoo/blob/913c081a8687d0f2aa6c40faeee9013fa10865db/addons/mrp/models/product.py#L280) with 0.1(qty per kit) becomes like ```py before 0.7000000000000001/0.1 7.0 after 0.7/0.1 6.999999999999999 ``` while taking quotent [here](https://github.com/odoo/odoo/blob/b3d61b372a8cd315f9063b6add634ad194f3341b/addons/mrp/models/product.py#L264) it taking 6 instead of 7 so this difference come and test case failed ``` AssertionError: Lists differ: [[142[456 chars]63, '7'], [14264, '0.7'], [14265, '-30'], [142[12426 chars]-2']] != [[142[456 chars]63, '6'], [14264, '0.7'], [14265, '-30'], [142[12426 chars]-2']] First differing element 27: [14263, '7'] [14263, '6'] Diff is 15569 characters long. Set self.maxDiff to None to see it. : Invariant check fail ``` for correcting this as discussed here https://github.com/odoo/odoo/pull/152709#issuecomment-2383006955 this fixed is proposed. 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#182265
- Have access to multiple companies (A and B for instance); - Be connected to only one company (company A); - In the profile, have notifications handled in Odoo; - Open Discuss; - Got to History; - Click on the origin of a thread, it should be a record from the second company (company B in this case); Before this commit, we will connect to the second company (as expected), but the record will not be open. This issue happens because we open the record through a doAction. Before the f
Original PR description
- Have access to multiple companies (A and B for instance); - Be connected to only one company (company A); - In the profile, have notifications handled in Odoo; - Open Discuss; - Got to History; -…
- Have access to multiple companies (A and B for instance); - Be connected to only one company (company A); - In the profile, have notifications handled in Odoo; - Open Discuss; - Got to History; - Click on the origin of a thread, it should be a record from the second company (company B in this case); Before this commit, we will connect to the second company (as expected), but the record will not be open. This issue happens because we open the record through a doAction. Before the form view is mounted, an AccessError is raised and the correct company is added to the cookies (see [1]). As the form view is not already mounted, the action service didn't push the new state into the URL. When reloading (after adding the company into the cookies), the state loaded will not contain the action to open the record. Now, we will connect to the second company, and the record will be open. opw-4240778 [1]: https://github.com/odoo/odoo/commit/6213c40932236101b529b82f0ea9fce1829c8c24 Forward-Port-Of: odoo/odoo#182974
Since [1] the meta tag 'default_title' was double-escaped due to improper handling of dynamic content within the template, leading to HTML entities being escaping twice. For example, `"` was incorrectly transformed into `&34;` Steps to reproduce: - Open a product and modify its name by adding a special character, such as a single quote. - Open the "Optimize SEO" dialog. Issue: The default title displays `'` instead of the single quote. This commit resolves this issue and
Original PR description
Since [1] the meta tag 'default_title' was double-escaped due to improper handling of dynamic content within the template, leading to HTML entities being escaping twice. For example, `"` was incorrectly transformed into `&34;` Steps to reproduce: - Open a product and modify its name by adding a special character, such as a single quote. - Open the "Optimize SEO" dialog. Issue: The default title displays `'` instead of the single quote. This commit resolves this issue and at the same time gets rid of the trailing spaces. [1] https://github.com/odoo/odoo/commit/7c54acaebe38e47cad25d8a1bbdb430e5bad265d task-3974334 Forward-Port-Of: odoo/odoo#183806 Forward-Port-Of: odoo/odoo#179739
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a local server): - Activate the developer mode - Navigate to Website and click on "Go to Website" - Click on the menu "Pages" > "Manage Pages" - At the /contactus line, click on the "bug" button to access the view - Click on "Edit" to be able to change the architecture - Add something that
Original PR description
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a…
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a local server): - Activate the developer mode - Navigate to Website and click on "Go to Website" - Click on the menu "Pages" > "Manage Pages" - At the /contactus line, click on the "bug" button to access the view - Click on "Edit" to be able to change the architecture - Add something that breaks the view in the template (i.e : ```<p t-field="no_field.exists"></p>```) - Click on "Save" and after "Go to Page Manager" - Click on the /contactus url link - An internal server error page appears with the possibility to restore the previous version of the view (soft reset) or to reset to initial version (hard reset). Click on "Hard Reset" - With your DB manager, search in the table ir.ui.view, the record with the key website.contactus. Observe that the field arch_updated is still True while the view is reset and shouldn't be in an updated state. This commit ensures consistent updating of this field. A "Hard" reset of a broken view will remove its previous architecture used for "Soft" reset, since there is no real usage where a "Previous" reset is needed after a "Hard" one. [1]: https://github.com/odoo/odoo/commit/479585140caca9fdc758709f043da500297e8046 task-3743850 Forward-Port-Of: odoo/odoo#164929
Versions -------- - 17.0+ Steps ----- 1. Have an SO selling a timesheet-based service; 2. have at least some hours delivered via timesheets; 3. click on "Create Invoice"; 4. select a date for "Timesheets Period". Issue ----- It first shows a datepicker for only the start date, only after closing it can you select a second date. Cause ----- The `daterange` widget doesn't actually default to a range, unless the date field is marked as required. As seen in the `isRange` funct
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have an SO selling a timesheet-based service; 2. have at least some hours delivered via timesheets; 3. click on "Create Invoice"; 4. select a date for "Timesheets Period". Issue ----- It first shows a datepicker for only the start date, only after closing it can you select a second date. Cause ----- The `daterange` widget doesn't actually default to a range, unless the date field is marked as required. As seen in the `isRange` function, it opens a range picker when there are two values present, the field is required, or the `alwaysRange` property is `true`: https://github.com/odoo/odoo/blob/39029710bbce55889c6b951fc423c1254e05ff22/addons/web/static/src/views/fields/datetime/datetime_field.js#L215-L224 Solution -------- Force the range picker on the `daterange` widget by setting the `always_range` option. opw-4049959 Forward-Port-Of: odoo/odoo#181079
Steps to reproduce: 1. Assign a product to category A and category B. 2. Make category A the parent of category B. 3. Put category A as restricted category of the pos.config. 4. Open the pos.config. 5. [ISSUE] click category A. The app crashes because of duplicate key. This is because we are rendering 2 product cards with the same product coming from category A (the parent) and category B (the child). To rectify, this commit proposes to remove the duplicates in the return value of `
Original PR description
Steps to reproduce: 1. Assign a product to category A and category B. 2. Make category A the parent of category B. 3. Put category A as restricted category of the pos.config. 4. Open the pos.config. 5. [ISSUE] click category A. The app crashes because of duplicate key. This is because we are rendering 2 product cards with the same product coming from category A (the parent) and category B (the child). To rectify, this commit proposes to remove the duplicates in the return value of `getProductsByCategory`. Forward-Port-Of: odoo/odoo#183794
Steps to reproduce: - Install Timesheet - Delete all tasks - Run server actions to create tasks with the following scripts https://gist.github.com/mattismegevand/5db26ee9d1e7756e7fe4600897244c1e - Go to Project -> Tasks -> All tasks - Switch to calendar view and go to june 2024 Issues: A traceback appears, the cause is an infinite recursion caused by the computation of the intersection. Since two events are next to each other their intersection is null but fullcalendar try to compute it
Original PR description
Steps to reproduce: - Install Timesheet - Delete all tasks - Run server actions to create tasks with the following scripts https://gist.github.com/mattismegevand/5db26ee9d1e7756e7fe4600897244c1e - Go to Project -> Tasks -> All tasks - Switch to calendar view and go to june 2024 Issues: A traceback appears, the cause is an infinite recursion caused by the computation of the intersection. Since two events are next to each other their intersection is null but fullcalendar try to compute it anyway which leads to the intersection span being null which causes a traceback. I suspect that the fix is https://github.com/fullcalendar/fullcalendar/commit/362a37345a4b7cb65d16f345e8555f727f1c8450 However for good measure and to fix preemptively other bug from fullcalendar an update seems like the best decision. opw-3997810 Forward-Port-Of: odoo/odoo#183151
When we try to add any product for order in the first browser with ``Mitchell Admin`` as the user and simultaneously close the session in the second browser with ``Marc Demo`` as the user, the error will occur in the first browser when we click on order. Steps to reproduce: --- - Install the ``pos_online_payment_self_order`` module - Open the Bar, copy the URL, and Open a POS session on 2 different browsers with different user on both browser - Now go to the second browser and then close
Original PR description
When we try to add any product for order in the first browser with ``Mitchell Admin`` as the user and simultaneously close the session in the second browser with ``Marc Demo`` as the user, the error…
When we try to add any product for order in the first browser with ``Mitchell Admin`` as the user and simultaneously close the session in the second browser with ``Marc Demo`` as the user, the error will occur in the first browser when we click on order. Steps to reproduce: --- - Install the ``pos_online_payment_self_order`` module - Open the Bar, copy the URL, and Open a POS session on 2 different browsers with different user on both browser - Now go to the second browser and then close the session there - Now come to the first browser and add any product - Click on Order Traceback: --- ``ValueError: Expected singleton: pos.config()`` Previous Behaviour: --- This error occurred after this commit https://github.com/odoo/odoo/pull/179382/commits/a351107ade64a0ef67b28283a38b7add0cef689e because when a session is open in two different browsers and one browser is closed, at point [1], we delete the session, and after the deleted session, the orders are not linked to any session. After FIX Behaviour: --- After the deletion of the session from one browser if the orders are not completed then those orders are transferred to the rescue session(recuse session will be created). [1]- https://github.com/odoo/odoo/blob/462acc6853dfdc1418b790e99a0611c5ef5e17e2/addons/point_of_sale/static/src/app/store/pos_store.js#L1048-L1053 sentry-5699019259 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182033
When unlinking too many records, the memory can be reached when browsing too many records, which prevents the gc to work properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183908 Forward-Port-Of: odoo/odoo#183321
Original PR description
When unlinking too many records, the memory can be reached when browsing too many records, which prevents the gc to work properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183908 Forward-Port-Of: odoo/odoo#183321
When doing a groupby on a non-relational field (e.g. a char), if the field contains NULL values in DB, they appear as `None` in the keys of the `group_lines_by_keys` dict. If the comparison operator is not implemented between the field type and `NoneType`, `sorted` will fail with a traceback. Solution: sort on keys `(k is None, k)`. if k is None, then `k is None = True`. Because `True > False`, these values are pushed to the end by the sorting. task-none Forward-Port-Of: odoo/enterpri
Original PR description
When doing a groupby on a non-relational field (e.g. a char), if the field contains NULL values in DB, they appear as `None` in the keys of the `group_lines_by_keys` dict. If the comparison operator is not implemented between the field type and `NoneType`, `sorted` will fail with a traceback. Solution: sort on keys `(k is None, k)`. if k is None, then `k is None = True`. Because `True > False`, these values are pushed to the end by the sorting. task-none Forward-Port-Of: odoo/enterprise#72008
This commit addresses the issue of applying incorrect exchange rates for foreign currency transactions. Previously, we were using the rate from the last closing date instead of the rate applicable to the transaction day. Moving forward, the correct exchange rate will be used based on the day to which the quote applies, as outlined in the official guidelines for foreign currency operations by the Dirección General Impositiva (DGI). For reference: https://www.gub.uy/direccion-general-impositiva/
Original PR description
This commit addresses the issue of applying incorrect exchange rates for foreign currency transactions. Previously, we were using the rate from the last closing date instead of the rate applicable to the transaction day. Moving forward, the correct exchange rate will be used based on the day to which the quote applies, as outlined in the official guidelines for foreign currency operations by the Dirección General Impositiva (DGI). For reference: https://www.gub.uy/direccion-general-impositiva/comunicacion/publicaciones/operaciones-moneda-extranjera. latam-task: 1264 adhoc-side-task: 43762 Forward-Port-Of: odoo/enterprise#70335
When a MO consumes components that have a MPS record, the MPS does not take the consumption moves into account for the starting quantity of the MPS record. This PR removes that condition to make sure the starting inventory is correctly computed. Forward-Port-Of: odoo/enterprise#69412
Original PR description
When a MO consumes components that have a MPS record, the MPS does not take the consumption moves into account for the starting quantity of the MPS record. This PR removes that condition to make sure the starting inventory is correctly computed. Forward-Port-Of: odoo/enterprise#69412
This avoids a manual operation when testing DIAN's webservice for support documents. no task Forward-Port-Of: odoo/enterprise#72166
Original PR description
This avoids a manual operation when testing DIAN's webservice for support documents. no task Forward-Port-Of: odoo/enterprise#72166
It’s too easy to forget to set the right group opw-4206894 Forward-Port-Of: odoo/enterprise#72050 Forward-Port-Of: odoo/enterprise#70894
Original PR description
It’s too easy to forget to set the right group opw-4206894 Forward-Port-Of: odoo/enterprise#72050 Forward-Port-Of: odoo/enterprise#70894
In the deferred computations, we always assume that both the start and end date are inclusive E.g: 1st January -> 31st December is *exactly* 1 year = 12 months However, the user may instead put 1st January -> 1st January of next year which is then 12 months + 1/30 month = 12.03 months which may result in odd amounts when deferrals are created For this reason, we now alert the user if we detect such a case with a warning banner and yellow highlight in the abnormal dates. Other cases were the num
Original PR description
In the deferred computations, we always assume that both the start and end date are inclusive E.g: 1st January -> 31st December is *exactly* 1 year = 12 months However, the user may instead put 1st January -> 1st January of next year which is then 12 months + 1/30 month = 12.03 months which may result in odd amounts when deferrals are created For this reason, we now alert the user if we detect such a case with a warning banner and yellow highlight in the abnormal dates. Other cases were the number of months is not round should not be handled. task-id: none Forward-Port-Of: odoo/enterprise#71423
When the user presses `Ctrl` + `p` to print an article, the page appears blank because the assets for print media queries are only loaded after the user clicks the "Export" button. To ensure that the print-specific styles are loaded, we will move the `knowledge_print.scss` file to the `web.assets_web_print` asset bundle. The generated stylesheet will then be linked to the page using a `link` tag with the `media="print"` attribute. The browser will then be able to load the stylesheet when the
Original PR description
When the user presses `Ctrl` + `p` to print an article, the page appears blank because the assets for print media queries are only loaded after the user clicks the "Export" button. To ensure that the print-specific styles are loaded, we will move the `knowledge_print.scss` file to the `web.assets_web_print` asset bundle. The generated stylesheet will then be linked to the page using a `link` tag with the `media="print"` attribute. The browser will then be able to load the stylesheet when the user is printing the page or previewing it for print. Steps to reproduce the issue: 1. Go to the Knowledge app. 2. Open an article 3. Press `Ctrl` + `p` to print the article. => The print rules are not loaded and the page appears blank. TO BE: The print rules should be loaded. task-4191390 Forward-Port-Of: odoo/enterprise#70243
After [this commit], there was an issue for reports where we don't have accounts as the first column. It would offset the cell too far to the left, assuming there is an account code column. This commit fixes that, so reports like the partner ledger are exporting correctly again showing the partner names. [this commit]: https://github.com/odoo/enterprise/commit/a3d76fc2b39428b7ea7c41bf98b2ecbe741a67fb Forward-Port-Of: odoo/enterprise#72038 Forward-Port-Of: odoo/enterprise#72010
Original PR description
After [this commit], there was an issue for reports where we don't have accounts as the first column. It would offset the cell too far to the left, assuming there is an account code column. This commit fixes that, so reports like the partner ledger are exporting correctly again showing the partner names. [this commit]: https://github.com/odoo/enterprise/commit/a3d76fc2b39428b7ea7c41bf98b2ecbe741a67fb Forward-Port-Of: odoo/enterprise#72038 Forward-Port-Of: odoo/enterprise#72010
Currently, an error was generated when the user tries to filter `Customer/Saleperson` in the subscription dashboard. error: `Invalid field sale.subscription.report.message_partner_ids in leaf ('message_partner_ids', 'in', [3])` This is because we have used fields 'message_partner_ids' and 'activity_user_id' to filter out records, but this field is not available in the model. This commit will fix the above issue by using fielels 'partner_id' and 'user_id' to fielter records. sentry-56
Original PR description
Currently, an error was generated when the user tries to filter `Customer/Saleperson` in the subscription dashboard.
error: `Invalid field sale.subscription.report.message_partner_ids in leaf ('message_partner_ids', 'in', [3])`
This is because we have used fields 'message_partner_ids' and 'activity_user_id' to filter out records, but this field is not available in the model.
This commit will fix the above issue by using fielels 'partner_id' and 'user_id' to fielter records.
sentry-5657224204
Forward-Port-Of: odoo/enterprise#71360Problem: The `is_available` flag was used to check both product availability and conflicts with other rentals. However, the UI message was misleading, stating "Other rental(s) in conflict" even when the product was simply not available. Steps to reproduce: - Create a rental product with a quantity of 0. - Add a rental order for that product. - In the Schedule Gantt view, hover over the order. - A warning appears stating "Other rental(s) in conflict," even though no other rentals exist
Original PR description
Problem: The `is_available` flag was used to check both product availability and conflicts with other rentals. However, the UI message was misleading, stating "Other rental(s) in conflict" even when the product was simply not available. Steps to reproduce: - Create a rental product with a quantity of 0. - Add a rental order for that product. - In the Schedule Gantt view, hover over the order. - A warning appears stating "Other rental(s) in conflict," even though no other rentals exist on the same date; the actual issue is that the product is not available. opw-4085496 Forward-Port-Of: odoo/enterprise#69783
Before this commit, when installing the account_reports and l10n_ae modules, the l10n_ae_reports and corporate_tax_report modules were not installed, even though they depended on these modules. This caused an issue during an account report test, as the necessary field was not created, leading to an "Invalid field" error: ('l10n_ae_tax_report_liabilities_account' on model 'res.company') By removing the countries field from the manifest, the modules now auto-install as expected, and the test
Original PR description
Before this commit, when installing the account_reports and l10n_ae modules, the l10n_ae_reports and corporate_tax_report modules were not installed, even though they depended on these modules. This caused an issue during an account report test, as the necessary field was not created, leading to an "Invalid field" error: ('l10n_ae_tax_report_liabilities_account' on model 'res.company')
By removing the countries field from the manifest, the modules now auto-install as expected, and the test no longer fails. But why? If a module depends on another module that has the countries attribute, there’s no need to include it back; the auto-installation will only be triggered if there is a company that belongs to that country.
Forward-Port-Of: odoo/enterprise#72132Problem: In version 17.0, the `partner_id` doesnt exist, and instead, the correct field to use is `partner`. This mismatch causes a traceback when processing invoices in the PoS. Steps to Reproduce: - Install the Chilean localization module (`l10n_cl`). - Go to PoS > Order > Invoice > Pay. - A traceback appears in the console due to the incorrect field reference. opw-4204528 Forward-Port-Of: odoo/enterprise#71737
Original PR description
Problem: In version 17.0, the `partner_id` doesnt exist, and instead, the correct field to use is `partner`. This mismatch causes a traceback when processing invoices in the PoS. Steps to Reproduce: - Install the Chilean localization module (`l10n_cl`). - Go to PoS > Order > Invoice > Pay. - A traceback appears in the console due to the incorrect field reference. opw-4204528 Forward-Port-Of: odoo/enterprise#71737
Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916 Forward-Port-Of: odoo/enterprise#71856 Forward-Port-Of: odoo/enterprise#71365
Original PR description
Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916 Forward-Port-Of: odoo/enterprise#71856 Forward-Port-Of: odoo/enterprise#71365
Before this commit, the data given to the spreadsheet init callback in the case of inserting a pivot view was not used. This could lead to an error if the data was too big to be stored in the browser's session storage. This commit removes the useless data given to the spreadsheet init. Note that it's not necessary to write a new test for this, as the existing tests already cover this case. Task: 4255049 Forward-Port-Of: odoo/enterprise#71847
Original PR description
Before this commit, the data given to the spreadsheet init callback in the case of inserting a pivot view was not used. This could lead to an error if the data was too big to be stored in the browser's session storage. This commit removes the useless data given to the spreadsheet init. Note that it's not necessary to write a new test for this, as the existing tests already cover this case. Task: 4255049 Forward-Port-Of: odoo/enterprise#71847