Daily updates from Odoo
Wednesday, September 4, 2024
23 changes
4 changes
Resolved issues and error corrections
This fixes an issue where sales order confirmation emails were not sent to a CC address when that address matched the company or sender email. Businesses can now rely on copied recipients receiving customer-facing email notifications as configured.
Original PR description
[Reproduce] - Apply diff (ref.1) (optional) - Install payment_demo,website_sale - Configure email server (or Mailhog) - Skip if applied (ref.1): - Change email of current company to…
[Reproduce]
- Apply diff (ref.1) (optional)
- Install payment_demo,website_sale
- Configure email server (or Mailhog)
- Skip if applied (ref.1):
- Change email of current company to contact@yourcompany.com
- Update template: "Sales: Order Confirmation", so the cc field is set to the same email
- Buy something in the website shop
- BUG: email not sent to CC
(ref.1)
```diff
diff --git a/addons/sale/data/mail_template_data.xml b/addons/sale/data/mail_template_data.xml index ed191440817f..2a02d13bd312 100644
--- a/addons/sale/data/mail_template_data.xml
+++ b/addons/sale/data/mail_template_data.xml
@@ -69,6 +69,7 @@
<field name="model_id" ref="sale.model_sale_order"/>
<field name="subject">{{ object.company_id.name }} {{ (object.get_portal_last_transaction().state == 'pending') and 'Pending Order' or 'Order' }} (Ref {{ object.name or 'n/a' }})</field>
<field name="email_from">{{ (object.user_id.email_formatted or object.company_id.email_formatted or user.email_formatted) }}</field>
+ <field name="email_cc">{{object.company_id.email_formatted }}</field>
```
opw-4012438This fix prevents a Firefox-specific crash that could interrupt users when navigating Email Marketing screens during guided tours or related iframe activity. The page now waits for the embedded content to fully load in a safer way, improving reliability without changing user-facing features.
Original PR description
__Current behavior before commit:__ On Firefox `iframeEl.contentDocument` might be `null` inside the `readystatechange` event handler. This makes the page crash with the error `TypeError: iframeEl.contentDocument is null`. __Description of the fix:__ Utilizing `event.target` instead of `iframeEl.contentDocument` to make sure the document is not `null`. Since nothing is done in the event handler unless `document.readyState === "complete"` we can just use the `load` event instead. __Steps to reproduce the issue on runbot:__ On Firefox (127): 1. Install `mass_mailing` 2. Open the debug menu > Start Tour 3. Start the `mass_mailing_tour` 4. Go to Email Marketing > open a mailing with the `Sent` state 5. Click on any link/tab (e.g. a/B Tests) -> Crash opw-4005833
The website editor color picker now opens with the expected color combination tab first, restoring the previous website-building experience. This fixes a regression introduced by a mailing editor change that made an important website design workflow harder to use.
Original PR description
*: web_editor, mass_mailing This purely reverts [1] which, while implementing a minor feature for the mass_mailing editor, broke a major feature of the website builder. This went unnoticed because the test tours were also adapted to account for the change. Once the time is right, the minor feature will be re-implemented although it probably will be done another way. Also, the functional need should be rediscussed as I don't see the point in showing the "solid" tab at all if it is to show it only when such a color was previously selected. Just removing that tab seems to improve the UI and would be a one-line-code feature instead of this. To re-discuss. [1]: https://github.com/odoo/odoo/commit/8594fa708c06232cde5743be2b66f551ff5a4589
Italian electronic invoices can now be generated when an invoice includes a negative line with a different tax. This prevents an incorrect blocking error during Send & Print and aligns the export with what the Italian SDI system accepts.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_it_edi - Switch to an Italian company (e.g. IT Company) - Create an invoice for an Italian customer with: * 1 positive line having a tax * 1 negative line having another tax - Confirm the invoice - Generate E-invoice XML via "Send & Print" button **Issue:** A UserError is raised because orphan negative lines are not allowed after dispatching the negative lines. **Solution:** Remove the UserError as SDI accepts negative lines. opw-4132287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
13 changes
New functionality added to Odoo
A new UAE payroll reporting option lets teams generate an Excel master report covering one or more months. The report lists employees and their earned amounts, making payroll review and record keeping easier.
Original PR description
This will add a new Reporting menu for the UAE to create a master report. This master report is an Excel file representing one or more month(s) with each employee and the amount earned by them. Task: 3744558
Enhancements to existing features
The email composer action flow has been improved to make common messaging tasks easier and more consistent for users. This should reduce friction when creating or sending messages from Odoo and improve day-to-day productivity in the mail experience.
Original PR description
https://github.com/odoo/odoo/pull/177806
Helpdesk refunds now better match the quantity actually returned, instead of creating a credit note for the full original quantity. This helps avoid over-refunding customers and reduces manual correction work for support and accounting teams.
Original PR description
Currently, if we do a refund after returning a partial quantity, it creates a credit note for all the quantity. This PR will override the "reverse_moves" action to allow partial refunding in helpdesk. task-3905637
Australian payroll is updated so salary rules are managed under one structure, making payroll configuration easier to maintain. Employee and contract records now support clearer tax schedule selection, helping payroll teams apply the right tax treatment more consistently.
Original PR description
This commit includes the following changes: - Merging all salary rules under one salary structure. - Setting fields for selecting tax Schedule. - Code and test case cleanup. 3846971
Time-off requests now use a more flexible hour format for custom start and end times, replacing fixed dropdown choices. This makes payroll, timesheet, and Belgian payroll validation flows better aligned with precise leave-hour entry.
Original PR description
* = hr_payroll_holidays, timesheet_grid_holidays test_l10n_be_hr_payroll_account In this commit, the request_hour_from and request_hour_to fields are no more Selection field Now it's converted to the Float field which is in HH: MM form Task-3888748
Portal users will now only see timesheets on helpdesk tickets when the related service billing policy makes them relevant. The timesheet list is also clearer by labeling entries as task/ticket and showing the ticket name when appropriate.
Original PR description
In this PR:
- On the ticket portal form view, timesheets should only be visible if the
invoicing policy of the service selected on the ticket is either 'prepaid'
or 'based on timesheets'.
- In the timesheets list view in the portal:
- Changed the 'task' label to 'task/ticket'.
- Display the name of the ticket instead of the name of the task if applicable.
task-3908761This update adds a validation flow for employee extra hours recorded through attendance. It helps businesses control overtime more reliably and ensures related payroll, work entries, contracts, and planning calculations reflect approved extra time.
Original PR description
task-3999208
Avalara tax names are now shorter and easier to scan, showing only the tax type and percentage. More detailed jurisdiction information is still preserved in the tax description, and related taxes are grouped automatically for easier organization.
Original PR description
The avalara taxes names were simplified to only keep the tax type and percentage. The full name of the type, juris code, and percentage was moved to the tax description. Finally, tax groups were created and associated to taxes based on their names. task-4032827
Purchase approval requests can now include the intended vendor directly on the product line before creating an RFQ. This helps teams avoid automatically selecting the default vendor and reduces rework when the preferred supplier or price differs.
Original PR description
When we make an approval, of 'purchase' type, and 'create rfq', the products are directly purchased from the top vendor of the list. If you want to change that, it will be time consuming to remove it from an open RFQ, or change the vendor, find the right price. instead, in this commit, we allow to indicate vendor straight away from the product tab of the approvals. task-3871938
Appointment users now see ready-made setup templates when creating their first appointment types, helping them get started faster with common configurations. The update also adds onboarding prompts to connect Google or Microsoft calendars when synchronization is available but not yet set up.
Original PR description
1. [IMP] appointment{_account_payment}: add onboarding templates Add some onboarding to appointment in the shape of clickable cards of templates on the appointment.type list and kanban views. They…
1. [IMP] appointment{_account_payment}: add onboarding templates
Add some onboarding to appointment in the shape of clickable
cards of templates on the appointment.type list and kanban views.
They will appear instead of the helper when no appointment
exists or is returned by the current search. e.g. on the first
module usage (with no demo data).
This will help the user discover and set up various possible
appointment type options.
6 templates are available to choose from. Clicking one of these
templates will create an appointment type and open its form view,
with matching preset data and configuration.
2. Add calendar synchronization onboarding
[IMP] appointment_{google_calendar}
[ADD] appointment_microsoft_calendar
For both connectors (google calendar and microsoft calendar),
add a button in an information banner on appointment type form
view to connect their account when all the following conditions
are fulfilled:
- The general sync credentials are set in the global settings
- The sync is not paused in the global settings
- The user had no sync token (meaning they have not sync'd their
calendar yet, or have reset their sync account) (meaning it will not
be shown if user paused their sync manually!)
The default use case would be to be redirected in google calendar
/ microsoft calendar account selection pages. In the unlikely case
the configuration has changed, a notification will be shown instead.
A small bridge module is added to handle this feature for microsoft
calendar between appointment and microsoft_calendar.
Task-3644621
Co-authored-by: Clément Cardot (cacl) <cacl@odoo.com>
Co-authored-by: Noé Antoine (nan) <nan@odoo.com>Self-order kiosks can now use connected IoT box devices to print receipts and process payments. This brings kiosk checkout capabilities closer to regular Point of Sale setups, helping businesses serve customers more smoothly with less manual intervention.
Original PR description
The self order kiosk previously didn't support receipt printing or payment via IoT box devices. This PR adds that functionality, using the same configuration fields as regular PoS. task-4128846
The appointment type kanban view now shows the number of upcoming appointments, making it easier for users to see what needs attention. Labels and wording were also adjusted so teams can better understand which appointment types are generating the most meetings.
Original PR description
Purpose ======= Display the upcoming appointments count on the kanban view and some view rewording. Specification ============= What interests most the users is: - what I have to do - which types get the most meetings Changing the kanban view to reflect that. Task-4143350
Resolved issues and error corrections
Payroll users can once again register payments for payslips that generate miscellaneous journal entries. This prevents payroll payment workflows from being blocked by a recent accounting validation change.
Original PR description
A recent update restricted the registration of payslip payments since the journal entries generated were misc entries. https://github.com/odoo/odoo/pull/174314 This commit fixes the issue by bypassing that check for payslip payments.
6 changes
Resolved issues and error corrections
A previously removed method that handles page reloading in the IoT module was causing errors for users with older interface versions. This fix restores the method to ensure compatibility and prevent system errors when users interact with IoT device setup.
Original PR description
We removed the `reload_page` method [here](https://github.com/odoo/enterprise/pull/68394/files#diff-ccc5eed84ca6b725960d95f2ab8b48188d5a078ab60a0a7c6c8ff7aeb29eddd9). Since, clients non-updated views still call it, but get a traceback as it doesn't exist anymore. We then add it again to fix the issue. Support task: 4152608
This fix resolves an issue where subscriptions with the same invoice address were being billed separately instead of consolidated into a single invoice. The system now correctly groups subscriptions by their invoice address before generating invoices, ensuring that customers with multiple subscriptions to the same billing location receive one combined invoice instead of multiple separate ones.
Original PR description
Steps to reproduce: - Settings > Enable 'Consolidate subscriptions billing' - Contact > Create a company - Contacts & Addresses tab > Add - Add an invoice address on the company - Add an individual…
Steps to reproduce: - Settings > Enable 'Consolidate subscriptions billing' - Contact > Create a company - Contacts & Addresses tab > Add - Add an invoice address on the company - Add an individual then duplicate it - Create a subscription with the indiviual as customer - Duplicate the subscription then set the duplicate contact as customer - Debug mode > Scheduled actions - Sale subscription: Generate recurring invoices and payments > Run manually The subsciptions are invoiced separately instead of having one invoice for both. The consolidated billing should produce only one invoice since the invoicing address is the same. This behavior works as intended if using the create invoices action on both subscriptions at once. Here, the recurring invoice creation for subscriptions uses its own grouping function using partner_id as a key instead of partner_invoice_id which is 'parent invoice address id if any, else partner_id'. Because this grouping is performed before creating the invoices, we end up processing sale orders that should have belonged to the same group separarately and thus create the invoices one by one. This means we don't let _create_invoices do the grouping since we only pass it one SO at a time, this fix will make it so _create_invoices is called on the grouped SOs instead. opw-4114035
A dialog in the Account Reports module was failing to close properly due to a missing close function. This fix implements a custom close function that properly handles the dialog closure, allowing users to successfully open and close dialogs without encountering errors.
Original PR description
When we tried to open the dialog, we would get an error telling us that the function close from the props is missing. The fix is to use a custom close function that will trigger the action of type `act_window_close` task-4154392
This fix prevents the invoice status of a sales order from incorrectly reverting from "Fully Invoiced" to "Nothing to Invoice" when a field service product's price is changed to zero after invoicing. The system now checks whether an order has already been invoiced before recalculating invoice status, ensuring the invoice history remains accurate and unchanged.
Original PR description
### Steps to reproduce: - Install Sale and Field Service modules - Create a Quotation with a normal product and another Field service product - Confirm the quotation and invoice it - Change the…
### Steps to reproduce: - Install Sale and Field Service modules - Create a Quotation with a normal product and another Field service product - Confirm the quotation and invoice it - Change the delivered quantity of the field service product to meet the order quantity - Check the invoice status (will be 'Fully Invoiced') - Set the field service product in the SO to a unit price 0 ### Current behavior before PR: After creating an invoice for a SO that has field service product and then set the product's unit price to 0 the SO invoice_status will change from 'Fully invoiced' to 'Nothing to invoice'. This is happening because in FSM we don't invoice SOL that has price_unit equals 0 which will lead that the SO inovice status will change too to 'Nothing to invoice'. https://github.com/odoo/enterprise/blob/17.0/industry_fsm_sale/models/sale_order.py#L84:L91 ### Desired behavior after PR is merged: We are now checking before computing the invoice status of any FSM product if the SO is not yet invoiced because if it is we won't modify the invoice status of the SOL. opw-4017282
This fix corrects an issue where the sales order item list in field service tasks was incorrectly displaying down payments and loyalty rewards. The solution refines the filtering logic to show only relevant sales order items, improving accuracy when creating tasks for customer service requests.
Original PR description
Steps to reproduce the bug: 1. Install the Sales and Loyalty apps. 2. Create a sales order for 'client x' and assign a loyalty reward to it. 3. Invoice the sales order with a down payment. 4. Navigate to the Helpdesk app and create a ticket for 'client x'. 5. Create a task for the ticket and check the Sales order item list. Issue: The sales order item list incorrectly includes down payments and loyalty rewards due to an imprecise domain. Solution: Adding a domain function that we can override computed field where it's necessary, to filter the sale_order_line records accurately. opw-4001226 odoo pr : https://github.com/odoo/odoo/pull/173667 Forward-Port-Of: odoo/enterprise#66388
This fix resolves an issue where customers couldn't add certain product variants to their cart when the product had multiple subscription plans. The system now correctly recognizes when a variant matches any of the subscription plans already in the cart, allowing the purchase to proceed instead of showing a compatibility error.
Original PR description
Steps ----- [website_sale_subscription] 1. Create a recurring product with 2 recurring plans. 2. Create 2 variants for this product. 3. In the "Recurring Prices" tab, add a variant to the first plan and the other variant to the other plan. 4. Go to eCommerce and add to the cart the second variant (not the default selected one, this is important). 5. Refresh the page > ** This product pricing is not compatible with the product(s) in your cart. ** Cause ----- `_get_first_suitable_recurring_pricing` doesn't specify a plan, so it can return a pricing which doesn't match the cart's plan. Change ----- Allow adding to the cart if any of the product's variants are matching the cart's plan. opw-4081043