Daily updates from Odoo
Monday, January 22, 2024
32 changes
4 changes
Enhancements to existing features
Embedded kanban and list views in Knowledge now respect the article's readonly state. This helps prevent unintended edits when users are viewing articles they are not meant to modify, making access behavior more consistent.
Original PR description
This commit improves the usages of embedded kanban and list views by enabling the user to set as readonly when the article containing those is also readonly. task-3536028
Odoo now stores page state in the standard URL query area instead of after the # symbol. This makes links behave more consistently with browser expectations, including anchor scrolling, and improves reliability across apps and tests.
Original PR description
Before this commit, we used url fragment (#) to store the state of the page in the form of pairs of key/values. The aim of this commit, is to be more coherent with the web practices. The fragment is traditionally used to indicate the id of the HTML element (an anchor) on the page that the browser should scroll to, this is automatically done by the browser. This commit, change the current practice and start using the query/search string of the url to store the state of the page. Part of task-id : 3557575
Users can now manage their signature and initials directly from their profile preferences. This makes it easier to keep signing details up to date without needing an administrator or waiting until a document is being signed.
Original PR description
Currently, you can only change your signature and initials from the user form view or by signing a document with a new signature, therefore overriding your current one. However, it would be convenient to have access to your signature in the user preferences/my profile. This commit adds the signature fields in the user preferences form view. task-3629143
French accounting audit files can now be exported directly from the General Ledger using a more efficient process. This should significantly reduce waiting times for companies with very large accounting datasets while keeping the export available in the French reporting workflow.
Original PR description
The French FEC file was a separate module which was using the base64 enconding in order to generate the needed file. This could take very long on DBs with a few millions AML. Moved the generation of the report to enterprise, using an empty hook in Community, and adapted it so it uses the export_file functions which are then available and much more efficient. Related to : https://github.com/odoo/odoo/pull/139847 https://github.com/odoo/upgrade/pull/5435 task-3447342
28 changes
Enhancements to existing features
The appointment scheduling calendar view has been improved to group appointments by the partners (attendees) rather than just the organizer. This change makes it easier to see when multiple staff members or partners have conflicting events at the same time. The system now displays all partner attendance in the calendar view, helping managers better manage resource availability and avoid scheduling conflicts.
Original PR description
Currently the gantt view for user appointments (dentist, interview,...) is grouped by organizer of the event. While this works for the purpose of managing appointments it also hides the fact that the partners linked to each user may be attending some other event at the same time. To make this more clear we enable grouping by partner_ids and we make the gantt view default to that grouping. task-3452277
WhatsApp message templates that include date and time information will now display in the user's local timezone instead of UTC. This ensures customers receive messages with dates and times that match their location. For event registrations, the system uses the event's timezone to provide the most relevant information.
Original PR description
Before this commit: By default, all the datetime fields are stored according to `UTC`. If the user tries to send a template whose template variable is set to a field type of `datetime` then no logic…
Before this commit: By default, all the datetime fields are stored according to `UTC`. If the user tries to send a template whose template variable is set to a field type of `datetime` then no logic is written in `_find_value_from_field_path` to update the field's value according to the user's timezone. It will be sent according to `UTC`. After this commit: In the `_find_value_from_field_path` function, if `field_value` will be received of `datetime` type then a new function `_whatsapp_get_timezone` is used, which is added to the base that will return the desired timezone. By default, `_whatsapp_get_timezone` will return the user's timezone. The `_find_value_from_field_path` will update the `field_value` according to the timezone returned and if no timezone is returned then it will take `UTC` by default. This function can be overridden by any model. e.g. `event.registration` will override `_whatsapp_get_timezone` and return the event's time zone. Task - 3636178 Forward-Port-Of: odoo/enterprise#52208
This update improves the speed of account reconciliation processing in Odoo, particularly for large batches of transactions. The system now uses a more efficient method to match reconciled accounts, eliminating unnecessary repeated calculations that were slowing down the process. Users will experience noticeably faster reconciliation operations, especially when handling significant volumes of financial data.
Original PR description
Instead of trying to find the reconciled lines recursively, we can use the `matching_number`, since it now has a distinct value for each subgraph of reconciliation even for partials graphs. The situation in 16 was computing the graph by doing one query per level of depth. In 17, before this commit, only one query was done but computing the graph from each node, leading in a worse time complexity. The result was that for small batches, it was slightly faster in 17 than 16 but considerably slower for bigger batches. This commit just makes things go zoom in all cases.
Resolved issues and error corrections
This update fixes an issue where phone numbers containing spaces would cause VoIP calls to fail. The system now automatically removes spaces from phone numbers before initiating calls, ensuring a smoother calling experience for users regardless of how their phone numbers are formatted in the system.
Original PR description
Sanitizes phone numbers before using them to build request URIs. This will prevent failure whenever a phone number contains spaces. Task-3689342.
This update fixes an issue where web push notifications were not respecting scheduled delivery dates. Previously, notifications sent through the web push channel would be delivered immediately, even when a delayed delivery date was specified. Now web push notifications properly honor scheduling, consistent with how email and inbox notifications already work. This ensures notifications are sent at the intended time, which is important for multi-step processes that require user input before notifying.
Original PR description
Forward-Port-Of: odoo/enterprise#54189
This update resolves a visual flickering issue that occurred in the status bar when users started or stopped a timer in the project module. The fix removes excessive padding from the timer field, providing a smoother and more stable user experience when managing project timers.
Original PR description
**Steps:** - Navigate to the project module. - Choose any project and click on a Kanban card. - Inside the form view, click the start button from the status bar. - Observe the status bar. **Issue:** - Status bar flickering when starting/stopping timer **Cause:** - When clicking the start button in the project module's form view, the timer_start field causes flickering in the status bar due to excess padding. **Fix:** - Removing the excessive padding from the timer_start field will resolve the flickering issue. **Task**-3610481 Forward-Port-Of: odoo/enterprise#54570 Forward-Port-Of: odoo/enterprise#51930
This update fixes a technical issue in the Mexican payroll module where special Unicode quote characters in the payroll report name were causing the system to crash with an error. The fix removes these unnecessary special characters from the translation file, ensuring the payroll reports work correctly for Spanish-speaking users.
Original PR description
Thanks to the safe_eval call https://github.com/odoo/enterprise/blob/0ae2e56fc3e14ee0afdf314fda5c028ba9d33242/hr_payroll/controllers/main.py#L43 in `get_payroll_report_print`, whenever a non-ASCII character is passed, a Python `SyntaxError: invalid character` will occur because this character will be passed to `compile` https://github.com/odoo/odoo/blob/e7a511b7b5af57696e691f6f0a71bec63053f860/odoo/tools/safe_eval.py#L216 which expects only valid python code. Therefore we remove the unneccessary non-ASCII quote from the .po file that was probably a mistake in the first place. opw-3688140
Fixed a bug where changes made to behaviors in Knowledge documents were not being detected when users clicked outside the editor. The system now properly tracks when users finish editing behaviors and ensures changes are saved or discarded correctly.
Original PR description
This commit fixes a bug where the user would click outside the editor space in Knowledge after editing a behavior and this would not be seen as changes inside the record. What is happening is that the editor, and the majority of Odoo, uses the event *blur* to check if any changes has been made to the document. But this event does not bubble, in opposition to *focusout*, which means that any blur done on an element that is lower than the editable would not trigger the *onBlur* method. What we have done to fix this is simulate a blur event on the editable when we focus out of a behavior => mimicking an event bubbling to the editable and thus triggering the onBlur method. This enables the editable to handle changes done and to save/discard more efficiently and robustly. task-3662914 Forward-Port-Of: odoo/enterprise#54656 Forward-Port-Of: odoo/enterprise#53531
This fix corrects an issue where subscription products with multiple pricing periods (monthly, 6-month, yearly) were incorrectly displaying only "per month" on the website, regardless of which option customers selected. The fix ensures that when customers choose different subscription period options, the correct pricing period label now displays properly.
Original PR description
**Issue Description**: When creating a subscription product that has time-based pricing and options. The product on the website simply displays a recurring monthly period, rather than the six-month…
**Issue Description**: When creating a subscription product that has time-based pricing and options. The product on the website simply displays a recurring monthly period, rather than the six-month and annual periods as configured. This only happens in 17.0 and higher. The problem was happening because this patch wasn't calling. https://github.com/odoo/enterprise/blob/4c577804b4f6fadb1d606896a3c124909b85ab6b/website_sale_subscription/static/src/js/variant_mixin.js#L14-L28 That's because of the fact that there's https://github.com/odoo/odoo/blob/851eb198433d4fd6f72100568be3bf57a4803064/addons/website_sale/static/src/js/sale_variant_mixin.js#L82 https://github.com/odoo/odoo/blob/851eb198433d4fd6f72100568be3bf57a4803064/addons/website_sale/static/src/js/sale_variant_mixin.js#L101 the `this` function is not patched, because of some new changes in the patch function in 17.0 **Steps to Reproduce**: 1. Create a new subscription product in the `Subscriptions` app. 2. In the `Attributes & Variants` tab, add a new attribute `periods` with values such as `Monthly`, `6 Months`, `Yearly`. 3. In the `Recurring Prices` tab, add each variant of the product (`Monthly`, `6 Months`, `Yearly`) along with their corresponding `Recurring Plan` and `Recurring Price`, then save. 4. Click the `Go to Website` smart button and try to change the product variants. 5. Observe that the product is always labeled as "per month" regardless of the selected variant. **Proposed Solution**: Instead of `this` function we will manually call `VariantMixin._onChangeCombination`. opw-3654134
This fix resolves an issue where the web editor was incorrectly detecting changes to HTML content fields. The editor's value cleaning process was causing false positives when comparing original and current content. The fix ensures proper comparison by processing both values through the same cleaning method, and corrects an internal reference issue in the content sanitization process.
Original PR description
The method `getValue` of the wysiwyg could have some cleaning on the value that will always make it different from the original value. The _isDirty method of the html field will now make the original value be processed by the wysiwyg `getValue` to be able to compare it with the current value. The sanizite call in `OdooEditor.cleanForSave` had the wrong root. As we are calling `cleanForSave` for an element that is not inside the editable, the root cannot be `this.editable`. task-3679122 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the date picker calendar was not fully visible on small screens or mobile devices. The fix adds proper spacing to ensure the entire calendar picker displays correctly regardless of screen size, improving the user experience when selecting dates on mobile devices.
Original PR description
Before this commit, the datepicker was not displayed entirely on small screens if the current view wasn't tall enough. This commit adds a margin (supposedly) big enough to render the entire picker even on small screens. Task [3585878](https://www.odoo.com/web#id=3585878&cids=1&menu_id=4720&action=333&active_id=49&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149181 Forward-Port-Of: odoo/odoo#143363
Fixed an issue that prevented users from making minor edits to payment records once they were linked to an expense report. Users can now edit certain payment fields (like check printing details) without triggering errors, improving the workflow for processing expense reports with check payments.
Original PR description
Create an Expense Report Add an expense paid by company Submit to manager > Approve > Post journal entries Choose the payment method to be Checks Open Accounting dashboard, in Bank card click on 'Checks to print' Select the check Print the check Issue: Action will be blocked by error "You cannot do this modification since the payment is linked to an expense report." This occurs because the system does not allow writing to the payment record once it has been linked to the expense This commit allow to edit fields that would not trigger a move synchronize opw-3633035 Forward-Port-Of: odoo/odoo#146893
Fixed a bug where the attendee count on the survey manager's welcome page wasn't updating when participants joined a live session. The issue was caused by incorrect code from a previous technical refactoring. This fix ensures managers can now see real-time updates of how many people have joined their survey session.
Original PR description
Start a live session, on the manager side stay on the welcome page (the one that counts how many attendees joined). Using several other private browsing tabs join the live session. On the manager side, the number of attendees never changes. During a previous refactoring of legacy rpc => orm, an error slipped, instead the records and fields as separated arguments, the two were passed together as a list in a single argument. We used the opportunity to increase the verbosity in case of errors and to enrich our test cases. Fine tunning of 7422eb6 ([IMP] *: remove legacy rpc) Task-2834638 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 corrects how website pages are filtered when viewing the pages list or kanban view. Previously, when users selected a specific website, the display would show only that website's pages, but the system would still count and select all pages across all websites behind the scenes. Now the filtering works correctly so that the page count and selection actions only apply to the pages actually visible for the selected website.
Original PR description
Forward-Port-Of: odoo/odoo#148372
This fix resolves an error that occurred when users created new invoices and selected a customer while leaving the journal field empty. The system now properly handles this scenario by using the journal's company information when available, or falling back to the default company, allowing users to complete invoice creation without encountering technical errors.
Original PR description
Currently an error occurs when the user is creating a new invoice and selects the 'Customer' while the 'Journal' field is empty. Steps to Reproduce: - Install 'Accounting' module. - Go to Accounting…
Currently an error occurs when the user is creating a new invoice and selects the 'Customer' while the 'Journal' field is empty.
Steps to Reproduce:
- Install 'Accounting' module.
- Go to Accounting > Customer > Invoices and then click on New.
- Empty the 'Journal' field and then select any 'Customer'.
- The error will be generated.
Traceback on sentry:
```
KeyError: ('res.company', <function Company.__accessible_branches at 0x7fd68effbd00>, (1,), False, 2)
File "odoo/tools/cache.py", line 99, in lookup
r = d[key]
File "<decorator-gen-5>", line 2, in __getitem__
File "odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
ValueError: not enough values to unpack (expected 1, got 0)
File "odoo/models.py", line 5830, in ensure_one
_id, = self._ids
ValueError: Expected singleton: res.company()
File "odoo/http.py", line 2150, in __call__
response = request._serve_db()
File "odoo/http.py", line 1722, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1749, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1953, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "addons/account/models/account_move.py", line 2559, in onchange
return super().onchange(values, field_names, fields_spec)
File "addons/web/models/models.py", line 1062, in onchange
record._apply_onchange_methods(field_name, result)
File "odoo/models.py", line 6877, in _apply_onchange_methods
res = method(self)
File "addons/account/models/account_move.py", line 1738, in _onchange_partner_id
self = self.with_company(self.journal_id.company_id._accessible_branches()[:1])
File "odoo/addons/base/models/res_company.py", line 396, in _accessible_branches
return self.browse(self.__accessible_branches())
File "<decorator-gen-107>", line 2, in __accessible_branches
File "odoo/tools/cache.py", line 104, in lookup
value = d[key] = self.method(*args, **kwargs)
File "odoo/addons/base/models/res_company.py", line 378, in __accessible_branches
self.ensure_one()
File "odoo/models.py", line 5833, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
This error arises at [1] when the company is selected, but the 'journal_id' field is left empty,
This commit fixes the above issue by ensuring that the company is selected based on the accessible branches of the associated journal, or falls back to the default company if no journal is specified.
Link: [1]-https://github.com/odoo/odoo/blob/ad9cd949168e3be3db6e9a4983faa6b02626b0a2/addons/account/models/account_move.py#L1771
sentry-4835188267
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#148667This fix addresses a usability issue in the Point of Sale restaurant module where the split bill screen couldn't scroll when displaying a long list of order items. Users can now scroll through all items in the split bill list, making it easier to manage large orders in restaurants.
Original PR description
Current behavior: When the list of order line is too long in the split bill screen there was no scroll bar to see the last order lines. Steps to reproduce: - Open PoS restaurant - Create a new order - Add a lot of order lines - Click on the split bill button - The list of order lines is not scrollable opw-3676165 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes how the system handles default email addresses in the mail alias domain feature. Previously, the system assumed default email addresses were incomplete and would always add the domain name. Now it intelligently detects when a complete email address is provided (especially during data migrations) and preserves it correctly. This prevents email configuration errors during system upgrades.
Original PR description
Default_from on alias domain is currently managed like bounce or catchall. We consider it is always only a left-part of an email address that should be completed with alias domain name. However and notably at migration default_from could contain a complete email address. In that case better be defensive and keep the domain part of the value. Task-3690919
This update resolves multiple issues with web push notifications in the mail system, including duplicate notifications being sent, incorrect recipient calculations, and access problems in public channels. These fixes ensure push notifications work reliably and consistently with the standard mail notification system.
Original PR description
PURPOSE Provide fixes for web push notifications implementation in mail, especially it has been moved in standard mail in 17.0 . FIXES Fix override of recipients computation: add missing keys to match standard structure Fix 'notify_by_web_push' being called two times in discuss channels Fix web push recipients being computed at wrong place: should be done in a clean override of '_notify_recipients' Fix access issue when sending push notifications in public channels Task-3695571 Related to Task-3669738 (Mail: Web Push Models Rename and Fixes)
This fix corrects an issue where activities manually scheduled by users (such as reminders to follow up with a customer) were incorrectly marked as automated. The system now properly distinguishes between user-created activities and system-generated ones, ensuring that only truly automated activities are subject to automatic cancellation rules. This prevents important user-defined tasks from being unexpectedly cancelled by system processes.
Original PR description
How to reproduce: - Install contacts - Go to any contact - Schedule an activity on the contact by clicking on "Activities" The flag automated of the created activity is set to True which shouldn't be…
How to reproduce:
- Install contacts
- Go to any contact
- Schedule an activity on the contact by clicking on "Activities"
The flag automated of the created activity is set to True which shouldn't be
the case (you can check either in the DB or by adding the field with studio)
The same happens when scheduling plan, scheduling activities on multiple
records in the view list or a plan on multiple records.
This fixes the problem by modifying the activity schedule wizard so that it
always creates activities with automated flag set to False.
Note that that flags is used to distinguish activities created manually from
those created automatically. Some flows automatically cancel automated
activities (e.g. cancel 'validate my ticket') but those should probably not
cancel user defined activities (e.g. 'ask customer to pay'). That's why we must
ensure that activity created manually have that flag set to False.
[IMP] {test_}mail: modify tests to check the automated activity field value
Following the fix that ensures that activities scheduled manually (i.e.
scheduled through the mail activity schedule wizard) have the "automated" flag
set to False, we modify some tests to check that.
Task-3691827Fixed an issue where payment reconciliation was using Odoo's standard exchange rates instead of the custom rates provided by banks. Now when reconciling payments, the system will correctly apply the actual exchange rate from your bank, ensuring accurate financial records that match your bank statements.
Original PR description
In case of a payment we want to use the custom/accounting rate instead of the Odoo rate, as the rate probably comes from the bank. Forward-Port-Of: odoo/odoo#149769 Forward-Port-Of: odoo/odoo#146274
After upgrading to Bootstrap 5, certain color classes (like bg-dark, bg-black) stopped working when printing reports through the PDF generator. This fix removes incompatible CSS features that the PDF generator doesn't support, ensuring that color formatting in reports displays correctly when printed or exported to PDF.
Original PR description
After the migration to Bootstrap5 (odoo/odoo#95450), some standard bootstrap classes did not work anymore when *printing* the report via wkhtmltopdf (bg-dark, bg-black etc.....). This is because wkhtmltopdf doesn't support CSS Custom Properties and many Bootstrap5 rules use them (many have already been adapted in the referenced PR or linked ones) wkhtmltopdf doesn"t support rgba CSS function either. This fix allows for thoses classes to work when printing as they can be used if the report was edited via Studio's Report Editor. 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#150087
This fix resolves an issue that prevented users from creating new payment transactions manually in the transaction list view. The system was failing because it couldn't properly compute transaction information when creating a new record. After this update, users will be able to create new payment transactions without encountering errors.
Original PR description
**Description of the issue/feature this PR addresses:** In order to avoid failing on this computation make sure actual ids are available to be used in query. **Current behavior before PR:** - Go to payment transaction list view (activate on the list view the possibility to create a new transaction manually) - Try to create a new transaction You will get a trace-back as `invoices_count` can not be computed due to a missing/empty result of `self.ids` **Desired behavior after PR is merged:** You will be able to create as expected a new transaction Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150095 Forward-Port-Of: odoo/odoo#149850
This fix resolves a problem where PDF exports of document layouts appeared incorrectly formatted, with tables appearing squished in the bottom right corner. The issue occurred when downloading PDF previews from the Document Layout configuration page, even though the on-screen preview looked correct. The fix restores the proper formatting by correcting the underlying report template.
Original PR description
Steps to reproduce: --- 1. Go to Settings 2. In Document Layout 3. Click on Configure Document Layout 4. Preview looks right 5. Click on Download PDF Preview 6. Open the PDF 7. Preview is not right 8. The bottom right table is squished Cause of the issue: --- Introduced by https://github.com/odoo/odoo/commit/778cc239010f3bb8618824fdaf06cb19922d6498 Fix: --- Copied report_invoice_document opw-3651311 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148102
This fix prevents the web editor from automatically converting URLs into clickable links when pasting or typing in translated text fields that don't support HTML formatting. Previously, links were being incorrectly created in translation content, which could break the page layout. Now, plain text is pasted instead, preserving the integrity of translated content.
Original PR description
When pasting text inside the editor, if the text looks like a URL, a link is implicitly created. Unfortunately, this also happens when the edited element does not support HTML. Because of this, when…
When pasting text inside the editor, if the text looks like a URL, a link is implicitly created. Unfortunately, this also happens when the edited element does not support HTML. Because of this, when translating a page, links are created inside the translated text which does not support HTML. This commit solves this by pasting the plain text if the target of the paste does not support HTML (which is the case for translations). This commit also prevent link creation when typing a space after text that looks like an URL in targets that do not support HTML. In 16.0, `_handleAutomaticLinkInsertion` is also adapted to prevent unwanted link creation. Steps to reproduce for first scenario: - Add French to your website. - Edit your master English Home page. - Drop a Text snippet in the Home page. - Save the Home page. - Switch to French. - Translate the page. - From en external text input, copy `http://odoo.com`/ in your clipboard. - Put the cursor inside the Text snippet's text. - Paste. => A link was created. Steps to reproduce for second scenario: - Add French to your website. - Edit your master English Home page. - Drop a Text snippet in the Home page. - Save the Home page. - Switch to French. - Translate the page. - Put the cursor inside the Text snippet's text. - Type `http://odoo.com`/ followed by a space. => A link was created. opw-3546308 Forward-Port-Of: odoo/odoo#150081 Forward-Port-Of: odoo/odoo#148282
This update fixes a bug where users were unable to delete table rows in the web editor when using Firefox. The fix ensures that deleting a selected table row now works properly across all browsers, improving the editing experience for content creators.
Original PR description
**Current behavior before PR:** Attempting to delete a selected table row does not result in the removal of the row in Firefox. **Desired behavior after PR is merged:** Now deleting a selected table row results in removal of the row in FIrefox. task-3610789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143747
A bug prevented users from navigating to the outstanding credits section when clicking the link in the invoice notification. This fix restores the correct HTML ID that was accidentally treated as a variable, allowing users to jump directly to the outstanding credits display at the bottom of their invoice.
Original PR description
### Steps to reproduce * go create an invoice for a customer that has outstanding credits. * in the blue message at the top, click the "outstanding credits" text in bold. You should see that you're taken to the home page. We expect to be taken to the bottom of the invoice, where the outstanding credits are displayed. ### Cause A static HTML ID was mistaken for a variable in d682871a8bd393c1d497e57675904d10355331d1. opw-3691932
This fix ensures that loyalty program discounts are properly displayed on customer invoices when using the "invoice on delivered quantities" policy. Previously, discount lines were missing from invoices because loyalty products weren't configured to invoice based on ordered quantities. This restores functionality that was lost during a previous system update.
Original PR description
Problem: Discount lines are not reflected on invoices when the invoice policy is set to delivered quantities. Loyalty products' invoice policy should be defaulted to invoice on ordered quantities.…
Problem: Discount lines are not reflected on invoices when the invoice policy is set to delivered quantities. Loyalty products' invoice policy should be defaulted to invoice on ordered quantities. Thus, if the default is set to invoice on delivered quantities for all products, loyalty products are incorrectly defaulted to invoice on delivered. This feature was removed when loyalty programs was refactored, refer to commit: https://github.com/odoo/odoo/commit/71499bbd23c0e94ffd9b7f82f9d28a5afe045197 Solution: Initialize the loyalty product to have its invoice policy to be on ordered quantities. Steps to Reproduce: Navigate to Sales > Configuration > Settings > Pricing and ensure the Discounts, Loyalty & Gift Card check box is checked Navigate to Sales > Configuration > Settings > Invoicing and set the invoicing policy to Invoice what is delivered Navigate to Sales > Products > Discount and Loyalty Create a new promotion that is available on Sales. Make sure the conditional rules is if minimum $50.00 spent and the rewards is 10.00% discount on your order (which should be set as the defaults) Navigate to Sales and create a new quotation Add a product that costs more than $50 and then click on PROMOTIONS and apply the promotion that was just created and confirm the sale order Navigate to the delivery by clicking on the delivery smart button and click on validate Navigate back to the sales order and click on CREATE INVOICE Then click on CREATE AND VIEW INVOICE You should see the issue that the promotion is not applied on the invoice opw-3582958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149869
Fixed an issue where the "Apply" and "Discard" buttons for background image positioning were invisible when editing grid columns in website builder. The problem occurred because grid styling was overlapping the control buttons. This fix ensures users can now properly save or cancel background image changes in grid mode.
Original PR description
Steps to reproduce: - Go to website (“Edit” mode) > Add a “Big Boxes” block. - Switch to “Grid” mode > Select the last column n (while n > 1) and set a background image on it. - Try to change the background position > You cannot save or cancel the changes since the option buttons (“Apply” & “Discard”) are invisible. This is simply because the grid element was cloned on the background container (`.o_overlay_background`) with its grid `z-index` style (with `z-index` === n) which automatically hides the buttons. The goal of this PR is to fix this behaviour by simply forcing the `z-index` of the background element to 0. task-3648466 Forward-Port-Of: odoo/odoo#148845