Tuesday, October 15, 2024
17 changes · 17.0
Resolved issues and error corrections
Automated actions with a negative delay now schedule their background checks using the delay size rather than falling back to every minute. This reduces unnecessary system activity and helps avoid minor performance overhead without changing the intended automation behavior.
Original PR description
Issue --> If the Delay (`trg_date_range`) field is set to a negative number, the automation cron defaults to an interval of 1 minute. This causes an unnecessary number of cron executions, leading to minor performance issues. Solution --> Use the absolute value of the Delay to calculate the cron interval. opw-3992050
Attendance screens now display times using the time format configured for the user's language. This fixes inconsistencies in the Gantt and form views, especially for organizations using 12-hour or localized time formats.
Original PR description
Before this PR, if you changed the time format in the language, the Gantt and the form view of the attendance did not follow those formats. With this PR, the dates displayed in the Gantt and form view are based on the time format set in the language. Task-4098672 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Public channel invitation links are now ignored by link previews. This prevents automatic preview checks from creating misleading guest joined notifications in public channels.
Original PR description
**Current behavior before PR:** When link-preview is done on public channel invitation links it posts a guest joined the channel message in the public channel. **Desired behavior after PR is merged:** now we are ignoring public channel invitations links for link-preview, so it does not post guest joined the channel backported PR: https://github.com/odoo/odoo/pull/178932 which handle's ignore link-preview. task-4083161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents errors when a Point of Sale user moves between backend sessions where their employee record may not exist. Employee information is now stored per PoS configuration, so each session keeps the correct employee context and users can switch sessions more reliably.
Original PR description
Before this commit, logging into the PoS with a user not present in another session and then navigating back to the backend to open a different session resulted in an error due to the missing employee. This commit resolves the issue by incorporating the confid ID when saving employee ID in sessionStorage, ensuring employee information is accurately maintained. opw-4255768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The stock detailed operations screen now hides package-related fields that could appear editable but would not be saved correctly. This prevents warehouse users from making changes that are later overwritten, reducing confusion during delivery processing.
Original PR description
Steps --- * install `stock` * from *Settings* > *Stock* activate packages * create a product P and put 2 packages (pk1, pk2) of 10 units each in stock (inventory adjustment) * create a delivery order…
Steps
---
* install `stock`
* from *Settings* > *Stock* activate packages
* create a product P and put 2 packages (pk1, pk2) of 10 units each
in stock (inventory adjustment)
* create a delivery order for 10 P > *Mark as Todo*
* go to the detailed ops for the move
* => it auto suggest the sml: pk1, qty = 10
* set the qty on the generated sml to 3
* *add a line* > pick from *WHStock - pk2*:
* => this creates the sml: pk2, qty = 7
* set the new sml's package to pk1
* => the *Pick From* field doesn't change
* *save*, the second sml's package has been reset to pk2
Cause
---
In the detailed ops we use a dummy `quant_id` field on sml to allow
selecting a quant and carrying some fields values from it to the sml.
But, when the quant was selected, setting the values of the carried
field, will not affect back the quant. And later, because the quant is
set, we use its values instead of the ones the user specified.
Fix
---
Hide the affected fields in the view, so the user cannot attempt to set
them, which would not work. i.e if they want to set the package id they should
do it via the quant dropdown.
opw-4089523Slovak invoices and report templates now show company identification numbers in the order commonly used by local Slovak business software. This is a cosmetic reporting fix that improves consistency with local standards without changing any accounting data or workflow.
Original PR description
Order of company values on reports is different in most of local software in Slovakia. Fix is only cosmetic to follow standards. This commit changes order of specific company values on report_template & report_invoice. Order before commit: vat (IČ DPH) company_registry (IČO) income_tax_id (DIČ) Order after commit: company_registry (IČO) income_tax_id (DIČ) vat (IČ DPH) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where upsell activity reminders for timesheet-based sales could fail to appear more than once. Sales teams will now receive repeated reminders when needed, helping them identify additional billing opportunities reliably.
Original PR description
opw-4147106
The point-of-sale daily Z ticket can now be printed even when a value is missing. This prevents a checkout reporting issue and helps stores reliably close and reconcile their day.
Original PR description
Can't print ticket Z of the day in POS if value was undefined. Now it's working --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The invoice creation flow for timesheet-based services now opens the Timesheets Period selector as a date range immediately. This avoids an awkward two-step date selection and makes invoice preparation smoother for sales and service teams.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have an SO selling a timesheet-based service; 2. have at least some hours delivered via timesheets; 3. click on "Create Invoice"; 4. select a date for "Timesheets Period". Issue ----- It first shows a datepicker for only the start date, only after closing it can you select a second date. Cause ----- The `daterange` widget doesn't actually default to a range, unless the date field is marked as required. As seen in the `isRange` function, it opens a range picker when there are two values present, the field is required, or the `alwaysRange` property is `true`: https://github.com/odoo/odoo/blob/39029710bbce55889c6b951fc423c1254e05ff22/addons/web/static/src/views/fields/datetime/datetime_field.js#L215-L224 Solution -------- Force the range picker on the `daterange` widget by setting the `always_range` option. opw-4049959
Fixed an issue in the web editor where the image transform toolbar disappeared after one click, preventing users from applying the transform action again. This keeps image editing controls accessible and avoids interruptions when editing content such as todos or rich text fields.
Original PR description
Issue: ====== We can't click twice on the transform button. Steps to reproduce the issue: ============================= - Create a todo - Add an image - Select it - Click on the transform button in the toolbar - The toolbar disappears so we can't click another time Origin of the issue: ==================== The issue was introduced in [1]. Removing the selection will trigger a selectionChange which itself triggers updateToolbar but now we don't have any selection so we hide the toolbar. Solution: ========= Revert the old fix and instead we ignore any `keydown` event when the transform container is in the dom (which means we are currently transforming an image). task-4235140 [1]: https://github.com/odoo/odoo/commit/463c248e291a53c80365ae606c7cf39e13cd290b
Miscellaneous changes
Steps ----- - Install Employees app. - Have a user with "Settings" Administration rights and no "Employees" rights. - Open an employee profile, open "Work Information" tab and click on an employee in the organizational tree. ** Access error for `message_main_attachment_id` field ** Cause ----- We are checking if the user has access rights on the employee https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L294 and redirecting to th
Original PR description
Steps ----- - Install Employees app. - Have a user with "Settings" Administration rights and no "Employees" rights. - Open an employee profile, open "Work Information" tab and click on an employee in the organizational tree. ** Access error for `message_main_attachment_id` field ** Cause ----- We are checking if the user has access rights on the employee https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L294 and redirecting to the private employee if that's the case. However, this does't guarantee that the user has the `hr.group_hr_user` group necessary to access some fields that were added with `groups="hr.group_hr_user"` https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L122 opw-4096073 Forward-Port-Of: odoo/odoo#182726
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page - With the `admin browser`, update the demo user language from the Settings to English - Reload the page on the `demo browser`, the menus will have stayed in French while the rest of the page is translated in English Details: - Only the first query after the following step will have an issue, t
Original PR description
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page -…
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page - With the `admin browser`, update the demo user language from the Settings to English - Reload the page on the `demo browser`, the menus will have stayed in French while the rest of the page is translated in English Details: - Only the first query after the following step will have an issue, the problem corrects itself on the second refresh. - Could not reproduce on the runbot but could do it locally and on Odoo.SH (in 16.0) and on `odoo.com` free database (18.0). This issue was already discussed more than a year ago (https://github.com/odoo/odoo/pull/110207) but was finally closed without being merged. The problem can now be fully reproduced while previously, it was a bit blurry. 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#182640
This issue arises when multiple clicks are made on the calendar view button. Steps to reproduce: - Install either the `google_calendar` or `microsoft_calendar` module. - Go to calendar > Click multiple times on the calendar view button. - Error will be generated This issue specifically occurs if either the `google_calendar` or `microsoft_calendar` module has been installed. this issue occurs because here https://github.com/odoo/odoo/blob/79666cbab0ab0947b3d853ab58a929635c309bab/addons
Original PR description
This issue arises when multiple clicks are made on the calendar view button. Steps to reproduce: - Install either the `google_calendar` or `microsoft_calendar` module. - Go to calendar > Click multiple times on the calendar view button. - Error will be generated This issue specifically occurs if either the `google_calendar` or `microsoft_calendar` module has been installed. this issue occurs because here https://github.com/odoo/odoo/blob/79666cbab0ab0947b3d853ab58a929635c309bab/addons/google_calendar/static/src/views/google_calendar/google_calendar_model.js#L28 google or microsoft sync will taking longer then 1s, this promise will resolve after 1s and the component is destroyed. so to address this issue, we need to eliminate the race condition and await the completion of the google/microsoft sync. Task-3768492 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161831
When unlinking too many records, the memory can be reached when browsing too many records, which prevents the gc to work properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183321
Original PR description
When unlinking too many records, the memory can be reached when browsing too many records, which prevents the gc to work properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183321
The LATERAL was destroying perfs to compute the account roots. It took more than 7 sec on a db that only had 660k move lines. Replaced it by a simple JOIN which reduced it to 1.2 sec. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170689
Original PR description
The LATERAL was destroying perfs to compute the account roots. It took more than 7 sec on a db that only had 660k move lines. Replaced it by a simple JOIN which reduced it to 1.2 sec. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170689
opw-4224602 Forward-Port-Of: odoo/odoo#183559
Original PR description
opw-4224602 Forward-Port-Of: odoo/odoo#183559
The check is comparing an empty recordset to False, which is not equal. Credits to @JZorko https://github.com/odoo/odoo/pull/171478 task-no Forward-Port-Of: odoo/odoo#183545
Original PR description
The check is comparing an empty recordset to False, which is not equal. Credits to @JZorko https://github.com/odoo/odoo/pull/171478 task-no Forward-Port-Of: odoo/odoo#183545