Monday, August 5, 2024
19 changes · 17.0
Enhancements to existing features
The web company selector has been adjusted so it can be extended instead of fully rebuilt when custom behavior is needed. This makes future customizations simpler and reduces development effort and maintenance risk for organizations using multiple companies.
Original PR description
Currently, it is not possible to inherit the company selector widget. To modify the behavior of the widget, developers need to create a new one instead of inheriting it, which is not ideal. This commit introduces changes that allow inheriting the company selector widget and also makes it easier to replace or extend the CompanySelector class within the SwitchCompanyMenu. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the accounting move form experience in Odoo's Accounting app. It is intended to make daily accounting work smoother for users, with limited business impact based on the available change details.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes lunch alert notifications so they include the needed source information when shown inside Odoo. Users who handle notifications in Odoo can now run lunch alerts without hitting an error when opening the notification thread.
Original PR description
Steps to reproduce: - My user > Preferences - Set notifications to 'Handle in Odoo' - Lunch > Configuration > Alerts - Add all locations to any alert - Debug mode > Scheduled Action - Manually run your alert An error occurs when trying to access the message thread because none was given. It is expected for messages of type user_notification not to have a thread, but this is never checked on the js side of things. This is because we assume information on the origin should be passed when sending the notification, which in this case we did not provide. opw-4057887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
### [FIX] hr_holidays: search for leaves in user's tz For the sake of simplicity we'd assume 3 days: Mon, Tue, Wed. Let's also assume that the everything happens in GMT+10 Now if we have a valid leave allocation for Mon and Tue, we should NOT be able to able to take it on Wed. However, because of the way Timestamps are casted to dates it is possible. It happens as follow: user "asking" server for leave on Wed, defines requested day by passing by the datetimes in the context ranging fr
Original PR description
### [FIX] hr_holidays: search for leaves in user's tz For the sake of simplicity we'd assume 3 days: Mon, Tue, Wed. Let's also assume that the everything happens in GMT+10 Now if we have a valid…
### [FIX] hr_holidays: search for leaves in user's tz
For the sake of simplicity we'd assume 3 days: Mon, Tue, Wed.
Let's also assume that the everything happens in GMT+10
Now if we have a valid leave allocation for Mon and Tue, we should
NOT be able to able to take it on Wed. However, because of the way
Timestamps are casted to dates it is possible. It happens as follow:
user "asking" server for leave on Wed, defines requested day by passing by
the datetimes in the context ranging from Tue 21:00 to Wed 09:00
Why such datetime range? Firstly because we have hardcoded devault values
for events that range from 07:00 to 19:00 in local time (ref.1).
Secondly because we're in GMT+10 so this range gets shifted:
07:00 on Wed becomes 21:00 on Tue
19:00 on Wed becomes 09:00 also on Wed
Then because allocations ranges are defined by dates not datetimes,
implicit casting is performed that causes cut-off of the time from the datetime
and in the end instead of checking if leave is allowed on Wed we check if
it is allowed on Tue and Wed.
### [FIX]
Shifting back into the user's timezone before casting.
### [Reproduction of the original issue]
- install hr_holidays
- create employee E
- create & validate new Allocation A (in TimeOff/Allocations):
- of type T (creating new type will help identify the issue)
- for employee E
- valid from Mon to Tue
- Open E's time off (Employee E -> Time Off)
- Switch your browser TZ that is +10
- Attempt to book time off for E on Wed
- BUG: you are allowed to do so
opw-3850159
(ref.1)
calendarEventToRecord from calendar_model
https://github.com/odoo/odoo/blob/15.0/addons/web/static/src/legacy/js/views/calendar/calendar_model.js#L74-L75
Forward-Port-Of: odoo/odoo#174952
Forward-Port-Of: odoo/odoo#172748This fix restores click-to-zoom for product images when shoppers view the website shop on mobile devices. It keeps hover-based zoom disabled on mobile while allowing tap/click zoom to work as configured, improving the product browsing experience.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to Website / Shop; 2. click on a product; 3. click on the phone icon to get mobile view; 4. open the editor; 5. click on the product image; 6. set Layout /…
Versions -------- - 17.0+ Steps ----- 1. Go to Website / Shop; 2. click on a product; 3. click on the phone icon to get mobile view; 4. open the editor; 5. click on the product image; 6. set Layout / Image Zoom to Both; 7. save. Issue ----- Clicking on the product image doesn't zoom it. Cause ----- Commit 75cb82490200 improved zoom features. In the `_startZoom` function it added a comment to an early return, explaining zoom-on-hover should be ignored on mobile: https://github.com/odoo/odoo/blob/75cb824902000b2c05716c8992ec486cf7102cea/addons/website_sale/static/src/js/website_sale.js#L490-L495 The issue is that this function also handles zoom-on-click, which gets skipped as well with the early return. This early return didn't fire in the editor before commit 55f182291164, because it checked the value of `config.device.mobile`, which was `undefined`. After this commit, it checks `uiUtils.isSmall()` instead, which does return true in the editor, fully disabling the ability to zoom-on-click: https://github.com/odoo/odoo/blob/55f1822911641a63309078dbc6dadf0c9fdc0796/addons/website_sale/static/src/js/website_sale.js#L341-L343 Solution -------- Move the check on `uiUtils.isSmall()` from the early return to the `salePage.dataset.ecomZoomAuto` check, so that only zoom-on-hover gets skipped on mobile. opw-3880081
Failed Viva Wallet payment notifications no longer trigger an internal error when transaction details are missing. This helps point-of-sale teams handle failed card payments more reliably without disrupting payment processing.
Original PR description
Currently, If 'MerchantTrns' is not available due to failed transactions, The System only sends a notification but does not return it. therefore errors occur from here [1] due to the unavailable of 'MerchantTrns'. link [1]: https://github.com/odoo/odoo/blob/ede5da1f72088ac1f78c9bc5206ccd666dce8c3d/addons/pos_viva_wallet/models/pos_payment_method.py#L118 To resolve this issue, return a send notification if 'MerchantTrns' is not available in 'data_webhook'. Related PR: https://github.com/odoo/odoo/pull/171764 Sentry - 5466498742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales users without inventory permissions can now open the product forecast from a sales order without hitting an access error. The report avoids loading unnecessary inventory valuation data, so users only access the information needed for the forecast.
Original PR description
Steps to reproduce: - Have a user have no inventory rights and User rights for sales - As that user, create a sale order that sells a storable product, which has at least one picking related to it in progress - Click on the forecast icon then on 'View Forecast' Issue: An access error will be triggered, as the user doesn't have the rights to consult `stock.valuation.layer` records. These records being useless for the forecast report itself, we can restrict instead what fields are read for the moves, to only fetch actually required fields. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could occur when preparing email recipients for multiple invoice sending wizards at the same time. Users should be able to use the send mail option more reliably when working with invoices in batches.
Original PR description
Fixed error on compute method when more of one wizard is created and tried to get the `mail_partner_ids`. This section is for `invoice_single` records, so, if you send multiple move_ids a singleton error is returned because you send the moves of all the wizards. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Printed GCC invoices now show the custom label entered on an invoice line instead of replacing it with the product name. This helps businesses present clearer, intended descriptions to customers and avoids confusion on printed invoices.
Original PR description
### Steps to reproduce * install `l10n_sa` * create a new invoice and add a line with a product and a custom label. * print the invoice You will see in the 'Description' column that the product's display name is shown instead of the label you set opw-4071925
The spreadsheet domain editor’s “active records” toggle is now visible when dark mode is used. This prevents confusion for users who rely on the toggle while filtering or selecting records in spreadsheets.
Original PR description
The "active records" toggle from the domain editor was invisible in darkmode because it has a whit/transparent image over a forces white background. This revision forces a dak background limited to the toggle button so that it becomes visible again. Task-4081249 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 improves the layout of survey cards so action buttons and statistics no longer overlap at smaller or grouped screen sizes. Users can more easily read survey progress and access results without visual clutter.
Original PR description
Prevent the activity button from overlapping the "See results" button in the ungrouped kanban mode on small screen sizes. Prevent the stats text (registered, completed, passed) from overlapping the separator and the other stats text on medium and larger screen sizes. Task-4061131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Point of Sale issue where balancing lines were validated against the session currency instead of the company currency. It helps prevent incorrect accounting checks when POS sessions use currencies that differ from the company currency.
Original PR description
Prior to this commit, when adding a balancing line, it was incorrectly checked with the session currency instead of the company currency. opw-3985175 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The global filter entries in the spreadsheet's side panel were not displaying correctly when dark mode was enabled. This fix ensures the filter panel maintains its intended light appearance regardless of the user's theme preference, improving the visual consistency and usability of the spreadsheet editing interface.
Original PR description
The global filter entries of the side panel were not keeping their "light" theme because we relied on the BS class `bg-white` which is adapted when using the dark mode. Task-4081249
Description of the issue/feature this PR addresses: This commit fixes a read access error on the field employee_ids of hr_leave when a user, who is not in group_hr_holidays_user, tries to cancel/refuse a timeoff. The bug only appears when the timeoff crosses a public holiday. Current behavior before PR: An access error pops up when an user , who is not a timeoff officer/admin, tries to cancel a timeoff. The timeoff should cross a public holiday in order for the bug to appear. Desired
Original PR description
Description of the issue/feature this PR addresses: This commit fixes a read access error on the field employee_ids of hr_leave when a user, who is not in group_hr_holidays_user, tries to cancel/refuse a timeoff. The bug only appears when the timeoff crosses a public holiday. Current behavior before PR: An access error pops up when an user , who is not a timeoff officer/admin, tries to cancel a timeoff. The timeoff should cross a public holiday in order for the bug to appear. Desired behavior after PR is merged: The user is able to cancel its timeoff even if he/she is not a timeoff officer/admin. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174682
Issue ---- The german translation for some tax lines for Luxembourg have the wrong format. This makes the line get ignored when generating a XML report. Steps ---- - Install `l10n_lu`. - Change the fiscal country to Luxembourg. - Go to Accounting -> Tax Report. - Choose Tax Report (LU) from the Report button above. - Generate a XML report. - The XML report doesn't have the `767` & `768` codes. Cause ---- Corresponding tax lines are mis-formated. opw-4053595 Forwa
Original PR description
Issue ---- The german translation for some tax lines for Luxembourg have the wrong format. This makes the line get ignored when generating a XML report. Steps ---- - Install `l10n_lu`. - Change the fiscal country to Luxembourg. - Go to Accounting -> Tax Report. - Choose Tax Report (LU) from the Report button above. - Generate a XML report. - The XML report doesn't have the `767` & `768` codes. Cause ---- Corresponding tax lines are mis-formated. opw-4053595 Forward-Port-Of: odoo/odoo#174223
Previously, there was no clean way to redirect old URLs like /xx.asp?id=xx with the correct HTTP status code. This update adds support for such redirects, allowing people to migrate to Odoo more easily. fiximp-realife --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175188
Original PR description
Previously, there was no clean way to redirect old URLs like /xx.asp?id=xx with the correct HTTP status code. This update adds support for such redirects, allowing people to migrate to Odoo more easily. fiximp-realife --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175188
**Description** - From 16.0, while opening invoices of accounting and clicking on the web studio button, it is showing traceback for French localization of the "l10n_fr" module. As per [this](https://github.com/odoo/odoo/pull/171275) file in V16, module [l10n_fr_invoice_addr] has been optimized to adapt the documents as per new French law. Although, the traceback is showing due to the fact that while performing the "l10n_fr_invoice_addr" module's view, the "shipping_field" has set the groups
Original PR description
**Description** - From 16.0, while opening invoices of accounting and clicking on the web studio button, it is showing traceback for French localization of the "l10n_fr" module. As per…
**Description** - From 16.0, while opening invoices of accounting and clicking on the web studio button, it is showing traceback for French localization of the "l10n_fr" module. As per [this](https://github.com/odoo/odoo/pull/171275) file in V16, module [l10n_fr_invoice_addr] has been optimized to adapt the documents as per new French law. Although, the traceback is showing due to the fact that while performing the "l10n_fr_invoice_addr" module's view, the "shipping_field" has set the groups to null in this [account_move.py](https://github.com/odoo/odoo/pull/171275/files#diff-5125aad1cd2220c7e0c4cfe80ec0541acf5e9f4dbce46fb370e94cd281012b36R17) file which should not be the case. Due to this, as per this [condition](https://github.com/odoo/odoo/blob/16.0/odoo/models.py#L1464), it is trying to find groups in V16.0, which will lead to traceback as the groups are set null here. Whereas in stable version 15.0, it was working due to the fact that previously the groups were set to null through the [account_move.xml](https://github.com/odoo/odoo/blob/15.0/addons/l10n_fr_invoice_addr/views/account_move_views.xml#L9) file. - As a result, to resolve this issue this commit will pop the groups of "shipping_field" instead of setting it to null to bypass the traceback for the invoices of "l10n_fr" localization. **Steps to Reproduce (V16.0)** - Change the language to French. - Install "l10n_fr" module - Get an FR company. - Create an invoice, it's partner(customer) should be of FR , then confirm the invoice. - Open the invoice and then click on the web studio button. **Solution** - To resolve this issue this commit will pop the groups of "shipping_field" instead of setting it to null to bypass the traceback for the invoices of "l10n_fr" localization. **Current behavior before PR:**  --- opw-[4044861](https://www.odoo.com/odoo/project.task/4044861?cids=2) I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173162
Current behaviour: --- When sending an email through Email Marketing, the icon is right in the preview, but wrong in the received email. Steps to reproduce: --- 1. Install mass_mailing 2. Create a new mailing 3. Select a template with a twitter icon 4. The icon is the new one 5. Click on Test 6. Open the email 7. Wrong icon Cause of the issue: --- Twitter icons have been overriden in fontawesome_overridden.scss However this css is not loaded when writing the src in fontToImg
Original PR description
Current behaviour: --- When sending an email through Email Marketing, the icon is right in the preview, but wrong in the received email. Steps to reproduce: --- 1. Install mass_mailing 2. Create a new mailing 3. Select a template with a twitter icon 4. The icon is the new one 5. Click on Test 6. Open the email 7. Wrong icon Cause of the issue: --- Twitter icons have been overriden in fontawesome_overridden.scss However this css is not loaded when writing the src in fontToImg in convert_inline.js Fix: --- Same fix as for tiktok, forcing a custom font and changing the icon code to match the font (ie: one icon is F099 in FA but E800 in the custom font) opw-3963437 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170942
Versions -------- - 15.0+ Steps ----- 1. Have an employee on a 40 hour/week work schedule; 2. for a past week, create a sick leave for monday & tuesday; 3. create 8 hour timesheets for the remaining weekdays; 4. switch the employee's work schedule to 35 hour/weeks; 4. navigate to the week with the leaves in Timesheets. Issue ----- The hours displayed next to the employee name shows -11:00, ignoring the the timesheets created by the leaves. Cause ----- `resource.calendar.leav
Original PR description
Versions -------- - 15.0+ Steps ----- 1. Have an employee on a 40 hour/week work schedule; 2. for a past week, create a sick leave for monday & tuesday; 3. create 8 hour timesheets for the remaining…
Versions -------- - 15.0+ Steps ----- 1. Have an employee on a 40 hour/week work schedule; 2. for a past week, create a sick leave for monday & tuesday; 3. create 8 hour timesheets for the remaining weekdays; 4. switch the employee's work schedule to 35 hour/weeks; 4. navigate to the week with the leaves in Timesheets. Issue ----- The hours displayed next to the employee name shows -11:00, ignoring the the timesheets created by the leaves. Cause ----- `resource.calendar.leave` records have a `calendar_id` field which is inialized to the resource's calendar, and updates if the resource changes, but not when the resource's calendar changes. As a consequence, the `_work_intervals_batch` method used for this calculation gets called on the employee's new calendar, which is no longer related to the calendar associated with their leaves. Solution -------- Replace the `onchange_resource` method with a compute method which updates the leave's field if the employee's calendar changes. opw-3693131 Forward-Port-Of: odoo/odoo#172292 Forward-Port-Of: odoo/odoo#169291