Tuesday, January 14, 2025
53 changes
13 changes
Resolved issues and error corrections
Activity Plans are now filtered so users only see plans for the company they have selected, along with global plans when no specific company is chosen. This prevents confusion from unrelated company plans appearing in the list and helps teams work with the right HR activity templates.
Original PR description
Steps: - Go to the 'Activity Plans' section. - Select a company in the company widget. - Activity plans were not filtered based on the selected company. Issues: - Activity plans were not filtered correctly by the selected company, showing plans from unrelated companies. Fix: - Added domain to display activity plans assigned to the selected company. - Added domain to display global activity plans when no company is selected. Task - 4441838 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Miscellaneous changes
**Affects** 16.0+ **Steps to reproduce:** - Render the Contact qweb widget with fields ["phone", "website"] ```py Contact = self.env["ir.qweb.field.contact"] partner = self.env["res.partner"].create( { "name": "Test Partner", "phone": "1234567890", "website": "https://www.example.com", } ) result = Contact.value_to_html(partner, {"fields": ["phone", "website"]}) ``` **Result:** - The website is not shown --- This is a regression int
Original PR description
**Affects**
16.0+
**Steps to reproduce:**
- Render the Contact qweb widget with fields ["phone", "website"]
```py
Contact = self.env["ir.qweb.field.contact"]
partner = self.env["res.partner"].create(
{
"name": "Test Partner",
"phone": "1234567890",
"website": "https://www.example.com",
}
)
result = Contact.value_to_html(partner, {"fields": ["phone", "website"]})
```
**Result:**
- The website is not shown
---
This is a regression introduced in 9e53aea9, in combination with some buggy behavior in the qweb compilation.
Somehow the `t-elif` condition is applying on the next element instead on itself, hiding the website item. I did not investigate this further.
ping @lvsz @ryv-odoo
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#192460
Forward-Port-Of: odoo/odoo#19120117 changes
Enhancements to existing features
The contract template list now shows columns that are relevant to templates and hides columns that do not apply. This makes the HR contract salary setup screen easier to read and helps users find template information faster.
Original PR description
Some columns don't make sense for a contract template, so they shouldn't be shown. On the other hand, some columns would make sense to be shown for templates. Task: 4433307
23 changes
Resolved issues and error corrections
Guest visitors in live chat can now click mentions without triggering an error. This prevents disruptive traceback messages during customer conversations and keeps the chat experience smooth.
Original PR description
Purpose of this commit: When an operator mentions someone in an ongoing live chat conversation and the guest clicks on it, a traceback error is raised. This occurs because clicking on the mention attempts to execute an action to open the mentioned partner's record. Since the guest user lacks access to the action services in the services registry, the error is triggered. This commit resolves the issue. task-4459050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Partly backporting 3731550474dc90819fa1667385f35f4a22ee4f11 Currently, to ensure the filled forms are set as readonly, we erase all the existing flags. Instead, we now only force the readonly flag. Forward-Port-Of: odoo/odoo#191207
Original PR description
Partly backporting 3731550474dc90819fa1667385f35f4a22ee4f11 Currently, to ensure the filled forms are set as readonly, we erase all the existing flags. Instead, we now only force the readonly flag. Forward-Port-Of: odoo/odoo#191207
The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session. But the PoS move does not use the transition account of any used caba taxes but the "real" account directly (see commit a011dcc0bdbe892b0a505a6a4169c5168bd018f6). So there is no need for a caba move. Further an exchange difference move for the tax amount may be created. The issue is that the tax amounts from the cash basis are not bei
Original PR description
The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session. But the PoS move does not use the…
The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session.
But the PoS move does not use the transition account of any used caba taxes but the "real" account directly (see commit a011dcc0bdbe892b0a505a6a4169c5168bd018f6). So there is no need for a caba move.
Further an exchange difference move for the tax amount may be created. The issue is that the tax amounts from the cash basis are not being matched correctly with the tax amounts from the PoS move (since we only look for the transition account on the PoS move).
Reproduce on runbot for l10n_mx
1. Install l10n_mx
2. Set the 'IVA 16% VENTAS' tax as Customer Taxes on a product. Set the Sales Price to 100.
3. Create a payment method and journal for the PoS
* Payment method: Cash on journal CSH1
* Journal: POS
5. Create a PoS using the payment method and journal from the previous step.
6. Start a PoS session
7. Sell the product from step 2 via the Cash payment method.
8. Close the Session
9. The following journal entries will be created: (All the tax lines use the same tax account; the "final" and not the caba transition account)
```
* 1 entry in the POS journal (order)
base: | - 100.0 $
tax: | - 16.0 $
receivable: | + 116.0 $
* 1 entry in the CSH1 journal (cash / payment)
cash: | + 116.0 $
receivable: | - 116.0 $
* 1 entry in the CBMX journal (caba)
base: | - 100.0 $
base: | + 100.0 $
tax: | - 16.0 $
tax: | + 16.0 $
* 1 entry in the EXCH journal (exchange difference)
for the cash basis rounding difference
tax: | - 16.0 $
tax: | + 16.0 $
```
This commit fixes the issue by just skipping the creation of caba moves during the reconciliation of the PoS move lines. Further we make sure no exchange difference entry is created for the (not even created) cash basis entries.
opw-4355124
Forward-Port-Of: odoo/odoo#193375
Forward-Port-Of: odoo/odoo#193195Minimal Configuration: - Create an account (49999 Great Account) that has a default tax (15%) - Settings > Accounting: define "Separate discount accounts on invoices" > Customer invoices with an account (e.g. 443000 Cash Discount Loss) Steps to reproduce: - Create an invoice with an invoice line that has "Great Account", a discount (10%) and a price (100) and a tax (15%) - Confirm -> amount = 108.9 - Duplicate the invoice (in the ticket: Create a Credit Note) Issue: => The credit not
Original PR description
Minimal Configuration: - Create an account (49999 Great Account) that has a default tax (15%) - Settings > Accounting: define "Separate discount accounts on invoices" > Customer invoices with an…
Minimal Configuration: - Create an account (49999 Great Account) that has a default tax (15%) - Settings > Accounting: define "Separate discount accounts on invoices" > Customer invoices with an account (e.g. 443000 Cash Discount Loss) Steps to reproduce: - Create an invoice with an invoice line that has "Great Account", a discount (10%) and a price (100) and a tax (15%) - Confirm -> amount = 108.9 - Duplicate the invoice (in the ticket: Create a Credit Note) Issue: => The credit note is not of the same amount = 106.80. That is, MINUS discount * tax_amount <-> 108.90 MINUS 10% * 21= 106.80 Cause: When there is a "Separate discount accounts on invoices" that is set, discount line appear on the journal items of the document; moves between the default account for such transaction to the chosen move in the settings. When iterating through those discount lines, the condition was not strict enough to filter them out and would put a tax on them (as my dear colleague Andrea said: the bomb has been planted) Therefore, when creating a credit/duplicating, we copy the data wrongly (but in a correct a way for a standard flow) which gives incoherent results opw-4166601 Forward-Port-Of: odoo/odoo#187565
Description of the issue this commit addresses: The Italian tax report lacks clarity and can be improved both in readabilty and usability by splitting the monthly and the annual reports. --- Desired behavior after this commit is merged: The Italian tax report is now split in a monthly and an annual report. The report uses the sections mechanism to be split in the different parts it is made from and clean the UI by not having everything on the same sreen. --- Enterprise PR: h
Original PR description
Description of the issue this commit addresses: The Italian tax report lacks clarity and can be improved both in readabilty and usability by splitting the monthly and the annual reports. --- Desired behavior after this commit is merged: The Italian tax report is now split in a monthly and an annual report. The report uses the sections mechanism to be split in the different parts it is made from and clean the UI by not having everything on the same sreen. --- Enterprise PR: https://github.com/odoo/enterprise/pull/62405 Task-3479785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164064
Steps to reproduce: - Start a Viva wallet payment - Immediately cancel and remove the payment line - After a few seconds, a traceback occurs This commit fixes the issue by ensuring that the Viva Wallet status polling only runs if it is still the current payment line. task-4472269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193358
Original PR description
Steps to reproduce: - Start a Viva wallet payment - Immediately cancel and remove the payment line - After a few seconds, a traceback occurs This commit fixes the issue by ensuring that the Viva Wallet status polling only runs if it is still the current payment line. task-4472269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193358
Steps to reproduce: - Enter website edit mode. - Drag and drop a "Products" dynamic snippet onto the page. - Drag and drop a "Search" snippet onto the page. - Save the page. - Perform a search for "dynamic" using the search input. - Bug: The dynamic snippet alert message appears in the results. The same issue occurs with the "Embed code" snippet, where text inside "<script>" elements appears in search results. With this commit, elements like "css_non_editable_mode_hidden" and "<scr
Original PR description
Steps to reproduce: - Enter website edit mode. - Drag and drop a "Products" dynamic snippet onto the page. - Drag and drop a "Search" snippet onto the page. - Save the page. - Perform a search for "dynamic" using the search input. - Bug: The dynamic snippet alert message appears in the results. The same issue occurs with the "Embed code" snippet, where text inside "<script>" elements appears in search results. With this commit, elements like "css_non_editable_mode_hidden" and "<script>" are excluded from search results. opw-4420622 Forward-Port-Of: odoo/odoo#192029
Before this commit, if a payment method requiring customer identification was used for an order in Point of Sale but the order was not immediately invoiced, closing the session and later invoicing the order in a new session would result in the invoice being marked as unpaid. opw-4292231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187759
Original PR description
Before this commit, if a payment method requiring customer identification was used for an order in Point of Sale but the order was not immediately invoiced, closing the session and later invoicing the order in a new session would result in the invoice being marked as unpaid. opw-4292231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187759
After modifying the price of an order line, going to floorplans, selecting the previous table and setting a customer now keep the price previously manually set. As the attribute `order_line.price_manually_set` is not saved in backend, when loading an order from the backend its value is always False. Now we recompute this attribute by comparing the default price of the product and the unit price of the orderline. opw: 4393328 Description of the issue/feature this PR addresses: Current
Original PR description
After modifying the price of an order line, going to floorplans, selecting the previous table and setting a customer now keep the price previously manually set. As the attribute `order_line.price_manually_set` is not saved in backend, when loading an order from the backend its value is always False. Now we recompute this attribute by comparing the default price of the product and the unit price of the orderline. opw: 4393328 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#193015 Forward-Port-Of: odoo/odoo#191053
Expiration dates on loyalty cards are available to be used, but do notdo anything. Added a validation error when expiration dates are added to loyalty cards to warn about this. opw-3997339 Forward-Port-Of: odoo/odoo#171453
Original PR description
Expiration dates on loyalty cards are available to be used, but do notdo anything. Added a validation error when expiration dates are added to loyalty cards to warn about this. opw-3997339 Forward-Port-Of: odoo/odoo#171453
Steps to Reproduce the Bug: - Enable multi-storage location - Create a storable product “P1” with the following BoM: - Component: C1 - Create two orderpoints: - First orderpoint: - Route: Manufacture - Product: P1 - Min: 1, Max: 1 - Location: Shelf 1 - Second orderpoint: - Route: Manufacture - Product: P1 - Min: 1, Max: 1 - Location: Shelf 2 - Click on “Order Once” of the first orderpoint. - A manufacturing order (MO) is created with the destination loca
Original PR description
Steps to Reproduce the Bug:
- Enable multi-storage location
- Create a storable product “P1” with the following BoM:
- Component: C1
- Create two orderpoints:
- First orderpoint: - Route: Manufacture - Product: P1 - Min: 1, Max: 1 - Location: Shelf 1
- Second orderpoint:
- Route: Manufacture
- Product: P1 - Min: 1, Max: 1 - Location: Shelf 2
- Click on “Order Once” of the first orderpoint.
- A manufacturing order (MO) is created with the destination location: Shelf 1.
- The “To Order” field will be computed as 0.
- Click on “Order Once” of the second orderpoint.
Problem:
The same manufacturing order is updated, even though its destination location is Shelf 1 which is wrong and The “To Order” quantity for the second orderpoint remains at 1. So each time the scheduler is triggered, the MO is updated by one unit if the trigger is set to “auto”.
opw-4418632
Forward-Port-Of: odoo/odoo#192035## Description Following ef90c22efda8a1d56d41eb0739d94733fb574f41, the delegated `_name_search` on `product.product` executed when performing a `name_search` on `product.template` is always unbounded (no limit). For non-selective domains on large databases, this can lead to manipulating extremely large lists of IDs, which are re-injected into other queries, resulting in performance regressions and excessive Postgres memory consumption. We introduce an upper bound on the delegated `_name_sear
Original PR description
## Description Following ef90c22efda8a1d56d41eb0739d94733fb574f41, the delegated `_name_search` on `product.product` executed when performing a `name_search` on `product.template` is always unbounded…
## Description
Following ef90c22efda8a1d56d41eb0739d94733fb574f41, the delegated `_name_search` on `product.product` executed when performing a `name_search` on `product.template` is always unbounded (no limit). For non-selective domains on large databases, this can lead to manipulating extremely large lists of IDs, which are re-injected into other queries, resulting in performance regressions and excessive Postgres memory consumption.
We introduce an upper bound on the delegated `_name_search`. To avoid excessive iterations when there is no limit, the bound is set large enough but not so large that it causes blocking regressions. Each iteration becomes more selective than the previous one, as already found templates are excluded from the search scope.
## Benchmark
On a database with over half-million active products, a non-selective `name_search` that matches 1/3 of the products (For ex: `name='d', args=[('sale_ok', '=', True)]`, which happens during via dropdown of products on a `sale.order`):
| | Before | After |
|---------------|------------------|-------|
| Timings (hot) | 15min+ (timeout) | 50ms |
## Reference
opw-4448182
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#193448
Forward-Port-Of: odoo/odoo#193293The WhatsApp message composer now shows which WhatsApp Business Account a user is replying from. This helps teams managing multiple brands, companies, or departments avoid confusion and respond from the correct account.
Original PR description
Users managing multiple WhatsApp accounts, such as for different brands, companies, or departments need to easily identify on whose behalf they are chatting within the mail composer. **After this PR:** The placeholder in the mail composer's textarea for WhatsApp channels displays `Answer as (WhatsApp Business Account name)` to clarify which account the user is responding from. **Task**-4188700 https://github.com/odoo/odoo/pull/191365
The appraisal demo data has been refreshed with clearer goal titles and a complete feedback report for Ronnie Hart. This makes sample appraisal workflows more realistic and easier to understand for users evaluating or demonstrating the module.
Original PR description
- edit goals titles - add full feedback report for `Ronnie Hart` Task: 4388551
WhatsApp channel messages no longer apply markdown formatting, so text is sent in a way that better matches WhatsApp's expected behavior. This reduces confusion from unintended bold, italic, or other formatting when teams communicate with customers through WhatsApp.
Original PR description
PR community: https://github.com/odoo/odoo/pull/174941
Point of Sale documents now show a customer's contact address without repeating the company name. This makes printed or fiscal documents clearer and avoids redundant address information for customers.
Original PR description
- Creation of a new field `pos_contact_address` in `res_partner.py` to display the address of the partner without the company name. task-id: 4414057 community PR: https://github.com/odoo/odoo/pull/192018
Miscellaneous changes
Just some cleaning / update before going further in email changes. This is done in 18.1 so that we can compare tests in 18.1 and 18.2+ in order to highlight changes. Improve some push tests as they may be impacted by recipients management change. Related to Task-4464566: [mail] Cover project/helpdesk gateway features Prepares Task-4273479: [mail] Stop autofollow madness ! Prepares Task-4273479: [mail] Email-like recipients Forward-Port-Of: odoo/enterprise#77125
Original PR description
Just some cleaning / update before going further in email changes. This is done in 18.1 so that we can compare tests in 18.1 and 18.2+ in order to highlight changes. Improve some push tests as they may be impacted by recipients management change. Related to Task-4464566: [mail] Cover project/helpdesk gateway features Prepares Task-4273479: [mail] Stop autofollow madness ! Prepares Task-4273479: [mail] Email-like recipients Forward-Port-Of: odoo/enterprise#77125
Steps to reproduce: - activate analytic accounting in the Accounting settings - open the profit and loss - create a financial budget with the "budget" filter - select an analytic account -> The report is completely messed up because the budget feature is not able to handle other columns in the report. This commit solves the issue by "lowering" the budget headers on the same level of header than analytic headers. opw-4298672 Forward-Port-Of: odoo/enterprise#76692
Original PR description
Steps to reproduce: - activate analytic accounting in the Accounting settings - open the profit and loss - create a financial budget with the "budget" filter - select an analytic account -> The report is completely messed up because the budget feature is not able to handle other columns in the report. This commit solves the issue by "lowering" the budget headers on the same level of header than analytic headers. opw-4298672 Forward-Port-Of: odoo/enterprise#76692
Forward-Port-Of: odoo/enterprise#77096
Original PR description
Forward-Port-Of: odoo/enterprise#77096
…endar editor Steps to reproduce ================== - Install industry_fsm,web_studio - Go to Field Service - Switch to the calendar view - Open studio => The color value is empty, it should be "Color" Cause of the issue ================== We only keep many2one and selection fields, but in this case, it's an integer field. Solution ======== Here's a few example where integer field are used: [planning_view_calendar] and [project_task_view_calendar_fsm_worksheet]. => Kee
Original PR description
…endar editor Steps to reproduce ================== - Install industry_fsm,web_studio - Go to Field Service - Switch to the calendar view - Open studio => The color value is empty, it should be "Color" Cause of the issue ================== We only keep many2one and selection fields, but in this case, it's an integer field. Solution ======== Here's a few example where integer field are used: [planning_view_calendar] and [project_task_view_calendar_fsm_worksheet]. => Keep integer fields --- [planning_view_calendar]: https://github.com/odoo/enterprise/blob/c37ed1a684fd9b91e394b7b14f282b9ebabcb751/planning/views/planning_views.xml#L332 [project_task_view_calendar_fsm_worksheet]: https://github.com/odoo/enterprise/blob/3205a82c4616b969b87aa2f6d05a2da636688037/industry_fsm_report/views/project_views.xml#L29 opw-4443497 Forward-Port-Of: odoo/enterprise#76789 Forward-Port-Of: odoo/enterprise#76454
Currently * "Fecha Expedición" = accounting date * "Fecha Operación" = invoice date (only set if different from accounting date) After this commit * "Fecha Expedición" = invoice date * "Fecha Operación" = delivery date (only set if different from invoice date) This is the same way the fields are handled in the spanish EDIs too (see related community PR). opw-4367470 Community PR: https://github.com/odoo/odoo/pull/192467 Forward-Port-Of: odoo/enterprise#77051 Forward-Port
Original PR description
Currently * "Fecha Expedición" = accounting date * "Fecha Operación" = invoice date (only set if different from accounting date) After this commit * "Fecha Expedición" = invoice date * "Fecha Operación" = delivery date (only set if different from invoice date) This is the same way the fields are handled in the spanish EDIs too (see related community PR). opw-4367470 Community PR: https://github.com/odoo/odoo/pull/192467 Forward-Port-Of: odoo/enterprise#77051 Forward-Port-Of: odoo/enterprise#76523
Before this commit: When the user clicks on the studio icon just after opening any app before its view gets loaded, the traceback will occur because the `get_view` method has not yet loaded. After this commit: Traceback will not occur. Task-4348166 Forward-Port-Of: odoo/enterprise#77043 Forward-Port-Of: odoo/enterprise#75881
Original PR description
Before this commit: When the user clicks on the studio icon just after opening any app before its view gets loaded, the traceback will occur because the `get_view` method has not yet loaded. After this commit: Traceback will not occur. Task-4348166 Forward-Port-Of: odoo/enterprise#77043 Forward-Port-Of: odoo/enterprise#75881
Display commission of current company only Allow sale user to edit the forecast value Various UI improvements taskid: 4452731 Forward-Port-Of: odoo/enterprise#76905 Forward-Port-Of: odoo/enterprise#76546
Original PR description
Display commission of current company only Allow sale user to edit the forecast value Various UI improvements taskid: 4452731 Forward-Port-Of: odoo/enterprise#76905 Forward-Port-Of: odoo/enterprise#76546
The related community commit fixed the issue where we forgot to extract terms from spreadsheet files ending in "_dashboard.osheet.json" and were file references were added multiple times in the .pot files. This commit re-exports all spreadsheet pot files again using the fixed code. Related to https://github.com/odoo/odoo/pull/190598 Forward-Port-Of: odoo/enterprise#77038 Forward-Port-Of: odoo/enterprise#75605
Original PR description
The related community commit fixed the issue where we forgot to extract terms from spreadsheet files ending in "_dashboard.osheet.json" and were file references were added multiple times in the .pot files. This commit re-exports all spreadsheet pot files again using the fixed code. Related to https://github.com/odoo/odoo/pull/190598 Forward-Port-Of: odoo/enterprise#77038 Forward-Port-Of: odoo/enterprise#75605
*: account_3way_match, account_asset, account_budget, account_inter_company_rules, account_intrastat, approvals, approvals_purchase, delivery_easypost, delivery_fedex_rest, documents_project_sale, helpdesk_sale_timesheet, helpdesk_timesheet, industry_fsm_sale, l10n_br_edi, l10n_cl_edi_stock, l10n_co_edi, l10n_in_reports_gstr, l10n_ke_edi_oscu, l10n_ke_edi_oscu_stock, l10n_lu_reports, l10n_mx_edi, l10n_mx_edi_extended, l10n_mx_edi_sale, l10n_pe_edi, l10n_pe_reports_stock, l10n_ro_saft, mrp_plm, m
Original PR description
*: account_3way_match, account_asset, account_budget, account_inter_company_rules, account_intrastat, approvals, approvals_purchase, delivery_easypost, delivery_fedex_rest, documents_project_sale,…
*: account_3way_match, account_asset, account_budget, account_inter_company_rules, account_intrastat, approvals, approvals_purchase, delivery_easypost, delivery_fedex_rest, documents_project_sale, helpdesk_sale_timesheet, helpdesk_timesheet, industry_fsm_sale, l10n_br_edi, l10n_cl_edi_stock, l10n_co_edi, l10n_in_reports_gstr, l10n_ke_edi_oscu, l10n_ke_edi_oscu_stock, l10n_lu_reports, l10n_mx_edi, l10n_mx_edi_extended, l10n_mx_edi_sale, l10n_pe_edi, l10n_pe_reports_stock, l10n_ro_saft, mrp_plm, mrp_workorder, pos_blackbox_be, pos_sale_stock_renting, product_unspsc, project_sale_subscription, quality_control, quality_mrp, sale_planning, sale_purchase_inter_company_rules, sale_purchase_stock_inter_company_rules, sale_renting, sale_stock_renting, sale_subscription, sale_subscription_stock, sale_subscription_timesheet, stock_barcode, stock_barcode_mrp, stock_enterprise, test_sale_subscription, web_studio To adapt to the changes made in odoo/odoo#184131, all the references to product packagings or UoM categories are removed. Also, the packaging unit is shown in barcode app interface in case it's different from the main unit. Upgrade PR: odoo/upgrade#6629 Task-4252043 Forward-Port-Of: odoo/enterprise#72206
1) Action button on Appointment Type kanban view only appear on hover, it should be always visible. 2) When a user books a meeting, Odoo creates an activity, which is unnecessary for calendar event linked with appointment type. This PR exclude appointment model in valid_activity_model_ids using helper function, so we won't get any activity on appointment type. (See community commit.) 3) The 'Connect Google' button with info and warning it's too vague for users. Add new warning when ther
Original PR description
1) Action button on Appointment Type kanban view only appear on hover, it should be always visible. 2) When a user books a meeting, Odoo creates an activity, which is unnecessary for calendar event…
1) Action button on Appointment Type kanban view only appear on hover, it should be always visible. 2) When a user books a meeting, Odoo creates an activity, which is unnecessary for calendar event linked with appointment type. This PR exclude appointment model in valid_activity_model_ids using helper function, so we won't get any activity on appointment type. (See community commit.) 3) The 'Connect Google' button with info and warning it's too vague for users. Add new warning when there are no creds but Google Calendar is Installed. Show old warning + info if creds are found but not synced. 4) The translation icon is badly positioned, it should be inside the field. 5) On Appointment Resource Create, Make Timezone field invisible if there is no resource_id. 6) When creating a booking in POS, the admin is always set as an attendee, becuase default for `default_partner_ids` was set to current user on create, which is not correct. 7) Change booked_mail_template_id field's name to 'Booking Email', as it may contain mail for appointment event which yet to be confirmed. Task-4243603 Forward-Port-Of: odoo/enterprise#76991 Forward-Port-Of: odoo/enterprise#72274
Server Actions =========== - Rename Action menu to "Actions on select" - Add an Actions creation in Actions menu (cog wheel) - Redirect to Server Actions Automations ========== - Add an Automations menu in Documents Cog Menu, below Actions on select - If base_automations is not installed -> propose to upgrade to Studio - If base_automations is installed -> redirect to Automations rules lighten as in CRM In the context of providing a partially pre-filled automation rule form
Original PR description
Server Actions =========== - Rename Action menu to "Actions on select" - Add an Actions creation in Actions menu (cog wheel) - Redirect to Server Actions Automations ========== - Add an Automations menu in Documents Cog Menu, below Actions on select - If base_automations is not installed -> propose to upgrade to Studio - If base_automations is installed -> redirect to Automations rules lighten as in CRM In the context of providing a partially pre-filled automation rule form for the target folder, we change the `folder_id` label from "Parent folder" to "Folder". task-4334749 Forward-Port-Of: odoo/enterprise#75719
When a subscription has the require_payment payment flag and no payment token, we will send a reminder to pay by mail. No automatic invoice will be created. Before this commit, when the SO is in this situation, no visual aid will help. taskid: 4367794 Forward-Port-Of: odoo/enterprise#74911
Original PR description
When a subscription has the require_payment payment flag and no payment token, we will send a reminder to pay by mail. No automatic invoice will be created. Before this commit, when the SO is in this situation, no visual aid will help. taskid: 4367794 Forward-Port-Of: odoo/enterprise#74911
The payment screen no longer shows a validate button when it cannot be useful for the payment workflow. This avoids confusion for accounting users and helps prevent unnecessary manual actions.
Original PR description
This button is only useful for marking payments as paid when the matching doesn't do it automatically, which can only happen if there is no reconciliation being done, which only happens when there is no outstanding account used. opw-4445889
The live badge on minimized call participant cards now displays with proper spacing and a clean background. This improves the visual clarity of calls in Odoo Discuss without changing how calls work.
Original PR description
Before this commit the `LIVE` badge on the minimized call participant card had some styling issues. This was caused by missing padding on the related div tag and non-transparent background on the parent tag. This commit fixes the issue by introducing some padding and removing the css class that adds background opacity. Before:   After:  
Automated website and app tours now skip unnecessary waiting when a step only performs an action and does not need to find an on-screen element. This makes internal tests run faster and required small updates to several tours so they remain reliable.
Original PR description
In the macro class, for each step, we wait 50ms to see if a mutation occurs and then look for the trigger of the step in the DOM. So, if a step of the macro does not have a trigger, we do not look for a trigger and we only do an action, there is no reason to wait for a mutation to occur in the DOM. So, we can continue the macro directly. 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 update corrects the reporting code used for partial incapacity in Belgian payroll declarations. It helps ensure payroll absence data is submitted accurately for compliance reporting.
This update makes an automated restaurant preparation display check wait for the right screen elements before moving forward. It helps prevent false test failures after recent speed improvements, improving reliability without changing user-facing behavior.
Original PR description
Due to [317c781bd917](https://github.com/odoo/odoo/pull/192015) commit, the tour PreparationDisplayPaymentNotCancelDisplayTour is faster. This causes behavior changes in the turns. We need to add steps to ensure that the triggers for these are present in the DOM before continuing the turn.
Miscellaneous changes
Steps: - Install project_todo - Create a second company - Create a project - Link the project to a company - Setup a default value for task.project_id with your new project (1) - Try to open project_todo Actual result: - Error due to company id - can't adapt type 'res.company' Expected result: - No error - Welcome task is created and project is opened opw-4465277 Caused by https://github.com/odoo/odoo/pull/173625 Forward-Port-Of: odoo/odoo#193359
Original PR description
Steps: - Install project_todo - Create a second company - Create a project - Link the project to a company - Setup a default value for task.project_id with your new project (1) - Try to open project_todo Actual result: - Error due to company id - can't adapt type 'res.company' Expected result: - No error - Welcome task is created and project is opened opw-4465277 Caused by https://github.com/odoo/odoo/pull/173625 Forward-Port-Of: odoo/odoo#193359
Steps to reproduce (db with Accounting installed): - create a child company - give a user (e.g. Marc Demo) access to the child company, set their "Accounting" rights to "Accountant" and "Administration" to None. - log as this user and select only the child company in the company selector. - try to access "Accounting/Configuration/Accounting/Currencies" -> Access Error It is happening as in the `res.currency` model, several methods try to access the root company, but there's only the c
Original PR description
Steps to reproduce (db with Accounting installed): - create a child company - give a user (e.g. Marc Demo) access to the child company, set their "Accounting" rights to "Accountant" and "Administration" to None. - log as this user and select only the child company in the company selector. - try to access "Accounting/Configuration/Accounting/Currencies" -> Access Error It is happening as in the `res.currency` model, several methods try to access the root company, but there's only the child company in `allowed_company_ids` from the context. The fix here is to: 1) When accessing the root company in order the get its currency, just access the currency of the child company, as it is the same. 2) Use sudo when accessing other fields from the root company. opw-4352595 Forward-Port-Of: odoo/odoo#192632
Steps to reproduce ================== - Use a mobile viewport - Go to Inventory > Delivery Orders - Open any record - Click on a product - Click on add => TypeError: ml.data.quant_id is undefined Cause of the issue ================== On mobile, the quant_id field is not present in the view opw-4288556 Forward-Port-Of: odoo/odoo#192732
Original PR description
Steps to reproduce ================== - Use a mobile viewport - Go to Inventory > Delivery Orders - Open any record - Click on a product - Click on add => TypeError: ml.data.quant_id is undefined Cause of the issue ================== On mobile, the quant_id field is not present in the view opw-4288556 Forward-Port-Of: odoo/odoo#192732
Expiration dates on loyalty cards are available to be used, but do notdo anything. Added a validation error when expiration dates are added to loyalty cards to warn about this. opw-3997339 Forward-Port-Of: odoo/odoo#171453
Original PR description
Expiration dates on loyalty cards are available to be used, but do notdo anything. Added a validation error when expiration dates are added to loyalty cards to warn about this. opw-3997339 Forward-Port-Of: odoo/odoo#171453
Before this commit, if a payment method requiring customer identification was used for an order in Point of Sale but the order was not immediately invoiced, closing the session and later invoicing the order in a new session would result in the invoice being marked as unpaid. opw-4292231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187759
Original PR description
Before this commit, if a payment method requiring customer identification was used for an order in Point of Sale but the order was not immediately invoiced, closing the session and later invoicing the order in a new session would result in the invoice being marked as unpaid. opw-4292231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187759
Before this commit, if there were multiple pricelist rules applicable to a product but they had minimum quantity conditions, PoS did not compute the price with the correct applicable pricelist rules if the top pricelist rule's minimum quantity was not satisfied. opw-4407515 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193202
Original PR description
Before this commit, if there were multiple pricelist rules applicable to a product but they had minimum quantity conditions, PoS did not compute the price with the correct applicable pricelist rules if the top pricelist rule's minimum quantity was not satisfied. opw-4407515 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193202
Steps to reproduce: - Enter website edit mode. - Drag and drop a "Products" dynamic snippet onto the page. - Drag and drop a "Search" snippet onto the page. - Save the page. - Perform a search for "dynamic" using the search input. - Bug: The dynamic snippet alert message appears in the results. The same issue occurs with the "Embed code" snippet, where text inside "<script>" elements appears in search results. With this commit, elements like "css_non_editable_mode_hidden" and "<scr
Original PR description
Steps to reproduce: - Enter website edit mode. - Drag and drop a "Products" dynamic snippet onto the page. - Drag and drop a "Search" snippet onto the page. - Save the page. - Perform a search for "dynamic" using the search input. - Bug: The dynamic snippet alert message appears in the results. The same issue occurs with the "Embed code" snippet, where text inside "<script>" elements appears in search results. With this commit, elements like "css_non_editable_mode_hidden" and "<script>" are excluded from search results. opw-4420622 Forward-Port-Of: odoo/odoo#192029
The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session. But the PoS move does not use the transition account of any used caba taxes but the "real" account directly (see commit a011dcc0bdbe892b0a505a6a4169c5168bd018f6). So there is no need for a caba move. Further an exchange difference move for the tax amount may be created. The issue is that the tax amounts from the cash basis are not bei
Original PR description
The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session. But the PoS move does not use the…
The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session.
But the PoS move does not use the transition account of any used caba taxes but the "real" account directly (see commit a011dcc0bdbe892b0a505a6a4169c5168bd018f6). So there is no need for a caba move.
Further an exchange difference move for the tax amount may be created. The issue is that the tax amounts from the cash basis are not being matched correctly with the tax amounts from the PoS move (since we only look for the transition account on the PoS move).
Reproduce on runbot for l10n_mx
1. Install l10n_mx
2. Set the 'IVA 16% VENTAS' tax as Customer Taxes on a product. Set the Sales Price to 100.
3. Create a payment method and journal for the PoS
* Payment method: Cash on journal CSH1
* Journal: POS
5. Create a PoS using the payment method and journal from the previous step.
6. Start a PoS session
7. Sell the product from step 2 via the Cash payment method.
8. Close the Session
9. The following journal entries will be created: (All the tax lines use the same tax account; the "final" and not the caba transition account)
```
* 1 entry in the POS journal (order)
base: | - 100.0 $
tax: | - 16.0 $
receivable: | + 116.0 $
* 1 entry in the CSH1 journal (cash / payment)
cash: | + 116.0 $
receivable: | - 116.0 $
* 1 entry in the CBMX journal (caba)
base: | - 100.0 $
base: | + 100.0 $
tax: | - 16.0 $
tax: | + 16.0 $
* 1 entry in the EXCH journal (exchange difference)
for the cash basis rounding difference
tax: | - 16.0 $
tax: | + 16.0 $
```
This commit fixes the issue by just skipping the creation of caba moves during the reconciliation of the PoS move lines. Further we make sure no exchange difference entry is created for the (not even created) cash basis entries.
opw-4355124
Forward-Port-Of: odoo/odoo#193375
Forward-Port-Of: odoo/odoo#193195Before this commit, the condition to check the loyalty card to be saved in IndexedDB only kept the loyalty cards related to the finalized orders that were synced. It should keep the items that are not synced or finalized. opw-4257389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188968
Original PR description
Before this commit, the condition to check the loyalty card to be saved in IndexedDB only kept the loyalty cards related to the finalized orders that were synced. It should keep the items that are not synced or finalized. opw-4257389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188968
Before this commit: the bg color of a table cell is set to a fixed value when selected After this commit: the selection will have a blue overlay color effect on the selected cells with bg color task-4398980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192039 Forward-Port-Of: odoo/odoo#191366
Original PR description
Before this commit: the bg color of a table cell is set to a fixed value when selected After this commit: the selection will have a blue overlay color effect on the selected cells with bg color task-4398980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192039 Forward-Port-Of: odoo/odoo#191366
**Affects** 16.0+ **Steps to reproduce:** - Render the Contact qweb widget with fields ["phone", "website"] ```py Contact = self.env["ir.qweb.field.contact"] partner = self.env["res.partner"].create( { "name": "Test Partner", "phone": "1234567890", "website": "https://www.example.com", } ) result = Contact.value_to_html(partner, {"fields": ["phone", "website"]}) ``` **Result:** - The website is not shown --- This is a regression int
Original PR description
**Affects**
16.0+
**Steps to reproduce:**
- Render the Contact qweb widget with fields ["phone", "website"]
```py
Contact = self.env["ir.qweb.field.contact"]
partner = self.env["res.partner"].create(
{
"name": "Test Partner",
"phone": "1234567890",
"website": "https://www.example.com",
}
)
result = Contact.value_to_html(partner, {"fields": ["phone", "website"]})
```
**Result:**
- The website is not shown
---
This is a regression introduced in 9e53aea9, in combination with some buggy behavior in the qweb compilation.
Somehow the `t-elif` condition is applying on the next element instead on itself, hiding the website item. I did not investigate this further.
ping @lvsz @ryv-odoo
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#192460
Forward-Port-Of: odoo/odoo#191201Before this commit, when the number popup was opened, pressing any key would select the "1" button by default. This caused the number "1" to be added to the buffer when pressing "Enter" while typing numbers with the keyboard. This behavior was particularly problematic when entering the PIN code for employee login, leading to incorrect entries. Additionally, a small modification was made to prevent the incorrect password alert from appearing when the popup is closed. opw-4428481 ---
Original PR description
Before this commit, when the number popup was opened, pressing any key would select the "1" button by default. This caused the number "1" to be added to the buffer when pressing "Enter" while typing numbers with the keyboard. This behavior was particularly problematic when entering the PIN code for employee login, leading to incorrect entries. Additionally, a small modification was made to prevent the incorrect password alert from appearing when the popup is closed. opw-4428481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192231
Before this commit, we used the size of the first page to determine the size of the canvas for reportlab. This would cause issues if we uploaded a PDF with any subsequent page larger than the first as we would attempt to draw the signature outside the canvas. Example PDF included in the support ticket. This seems to only be an issue with PyPDF2 2.12.1. This commit fixes this issue by setting the height and width of the canvas to the respective maximum for all pages. opw-4293390 Forward-P
Original PR description
Before this commit, we used the size of the first page to determine the size of the canvas for reportlab. This would cause issues if we uploaded a PDF with any subsequent page larger than the first as we would attempt to draw the signature outside the canvas. Example PDF included in the support ticket. This seems to only be an issue with PyPDF2 2.12.1. This commit fixes this issue by setting the height and width of the canvas to the respective maximum for all pages. opw-4293390 Forward-Port-Of: odoo/enterprise#76072
Refactors the button bar component and makes the xlsx button always show on accounting reports. task-4402561 Forward-Port-Of: odoo/enterprise#75580 Forward-Port-Of: odoo/enterprise#73580
Original PR description
Refactors the button bar component and makes the xlsx button always show on accounting reports. task-4402561 Forward-Port-Of: odoo/enterprise#75580 Forward-Port-Of: odoo/enterprise#73580
Before this commit: When the user clicks on the studio icon just after opening any app before its view gets loaded, the traceback will occur because the `get_view` method has not yet loaded. After this commit: Traceback will not occur. Task-4348166 Forward-Port-Of: odoo/enterprise#77043 Forward-Port-Of: odoo/enterprise#75881
Original PR description
Before this commit: When the user clicks on the studio icon just after opening any app before its view gets loaded, the traceback will occur because the `get_view` method has not yet loaded. After this commit: Traceback will not occur. Task-4348166 Forward-Port-Of: odoo/enterprise#77043 Forward-Port-Of: odoo/enterprise#75881
This commit https://github.com/odoo/enterprise/commit/49d19b63d8e6ea44fdeeb1023d962191c6897e24 is missing optional chaining for `name` as `order.account_move?.l10n_latam_document_type_id` can be undefined. Steps to reproduce: - Install l10n_cl - Select the CL Company - Go to POS - Select products - Change the client to Blanco Martin & Asociados EIRL (has all the information for l10n_cl) - Click on "payment" - Select any payment method - Select the option "Invoice" - Validate - Con
Original PR description
This commit https://github.com/odoo/enterprise/commit/49d19b63d8e6ea44fdeeb1023d962191c6897e24 is missing optional chaining for `name` as `order.account_move?.l10n_latam_document_type_id` can be undefined. Steps to reproduce: - Install l10n_cl - Select the CL Company - Go to POS - Select products - Change the client to Blanco Martin & Asociados EIRL (has all the information for l10n_cl) - Click on "payment" - Select any payment method - Select the option "Invoice" - Validate - Console error opw-4455627 Forward-Port-Of: odoo/enterprise#76798
An error occurs when the system tries to access single values from multiple records at [1]. Link [1]: https://github.com/odoo/enterprise/blob/2e1af04e36fcbdcd11e3a7e2994673b2c4a5cf85/social_youtube/models/res_config_settings.py#L19 Traceback On Sentry: ``` ValueError: Expected singleton: res.config.settings(105, 106) File "odoo/http.py", line 2366, in __call__ response = request._serve_db() File "odoo/http.py", line 1894, in _serve_db return self._transactioning( Fil
Original PR description
An error occurs when the system tries to access single values from multiple records at [1]. Link [1]:…
An error occurs when the system tries to access single values from multiple records at [1].
Link [1]: https://github.com/odoo/enterprise/blob/2e1af04e36fcbdcd11e3a7e2994673b2c4a5cf85/social_youtube/models/res_config_settings.py#L19
Traceback On Sentry:
```
ValueError: Expected singleton: res.config.settings(105, 106)
File "odoo/http.py", line 2366, in __call__
response = request._serve_db()
File "odoo/http.py", line 1894, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1957, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1924, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2171, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "odoo/models.py", line 6090, in search_read
return records._read_format(fnames=fields, **read_kwargs)
File "odoo/models.py", line 4032, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "odoo/models.py", line 6999, in __getitem__
return self._fields[key].__get__(self)
File "odoo/fields.py", line 1291, in __get__
self.compute_value(recs)
File "odoo/fields.py", line 1473, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 5238, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 110, in determine
return needle(*args)
File "home/odoo/src/enterprise/18.0/social_youtube/models/res_config_settings.py", line 19, in _compute_youtube_oauth_client_id
if self.env.user.has_group('social.group_social_manager') and self.youtube_use_own_account:
File "odoo/fields.py", line 1232, in __get__
record.ensure_one()
File "odoo/models.py", line 6212, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
To resolve this issue, Use an iteration(for loop) to iterate records one by one.
Sentry-6200420369
Forward-Port-Of: odoo/enterprise#76588