Daily updates from Odoo
Friday, January 12, 2024
29 changes
1 change
Resolved issues and error corrections
This corrects a demo holiday date in Belgian payroll to prevent two public holiday records from overlapping. It helps keep holiday data consistent and avoids confusion in payroll or time-off calculations that rely on these dates.
Original PR description
resource_public_time_off_be was coliding with resource_public_holiday_republic_day_in To avoid this, fix the date_from on public holiday
28 changes
Resolved issues and error corrections
Customers were seeing three redundant payment pending alerts when their subscription payment was processing. This fix removes the duplicate messages and keeps only one clear notification: "Your payment has been successfully processed but is waiting for approval." This provides a cleaner, less confusing experience for customers.
Original PR description
Before this commit, when the customer payed a subscription and the payment was still pending, three alerts were being showed in the screen alerting that its payment was pending, which was too much. After this commit, only the payment module pending message was kept: "Your payment has ben successfully processed but is waiting for approval". This way, the information is presented in a cleaner and direct way. Task-id: 3649938
Users can now properly view and edit the source code of duplicated reports in Web Studio. Previously, when duplicating a report, the source editor would break for the copied version. This fix ensures that both original and duplicate reports can have their sources accessed and edited without issues.
Original PR description
Steps: - Install `web_studio` - Open studio and go to reports - Duplicate a random X report - You can `Edit source` on X - When you try on X copy(1), sources are broken
This update refreshes US payroll tax parameters and deduction rules to reflect the latest regulations effective January 2024. The changes ensure accurate tax calculations and compliance with current federal payroll requirements for US-based companies using Odoo's payroll system.
Original PR description
TaskID: 3672229
This update corrects multiple data accuracy issues in the Subscriptions and MRR Evolution dashboards. The "Top Quotations" and "Top Subscriptions" tables were showing duplicate records and displaying amounts in inconsistent currencies, making comparisons meaningless. The fix switches to a normalized data model and corrects domain filters to exclude cancelled subscriptions. Additionally, chart alignment has been improved for better visual comparison across the MRR Evolution dashboard.
Original PR description
The "Subscriptions" dashboard is wrong. - check the "Top Quotations" and "Top Subscriptions" tables: the both show the same records (wrong domain). - the amounts in the two tables mentionned above…
The "Subscriptions" dashboard is wrong. - check the "Top Quotations" and "Top Subscriptions" tables: the both show the same records (wrong domain). - the amounts in the two tables mentionned above are displayed and ordered (!) in the sale order currency. Ordering amounts which are not all in the same currency makes no sense. To fix the issue, those two list now use the model `sale.subscription.report` (instead of `sale.order`) where the amounts are properly normalized to the same currency. This comes with a drawback however: 1 `sale.subscription.report` is roughly equivalent to a `sale.order.line`, which means we don't get the total amount of the SO and we could have twice the same SO in the table if it has 2 recurring lines which are among the top 10. The "See records" action is also les friendly because you end up on the auto-generated form view of `sale.subscription.report` (I'll add a form view, but in another PR, because it requires an upgrade exception) - most domains were wrong. They were including cancelled subscriptions. With all those changes, the dashboards show sensible numbers on next.odoo.com Task: 3680601
This fix resolves a test issue in the HR Payroll module where a language was being deactivated even though it was still being used by inactive employees. The fix ensures that language deactivation doesn't interfere with existing user data, preventing potential test failures and data integrity issues.
Original PR description
Companion of https://github.com/odoo/odoo/pull/148947. Forward-Port-Of: odoo/enterprise#54148
This fix corrects how appointment availability is calculated on the last available booking day. Previously, the system would show time slots that weren't actually available due to resource work hours or existing bookings. Now the system properly checks all constraints (work hours, leaves, and existing appointments) for the entire final day, ensuring customers only see slots they can actually book.
Original PR description
TO REPRODUCE 1. Create appt_type A with one resource R 2. Set work hours to 40h/week on resource R 3. Set max scheduled days on A to 14 days 4. Have a slot on A from 10.00 to 23.00 on the same weekday as now. (Let us say it's monday) 5. Go to front-end: the last available day (monday) will have slots until 23.00, despite the working hours restricting them to max 17.00. FIX As the last day's slots are computed for the whole day, the unavailabilities should also be computed. At the moment, they are only We add one day to the checked range to ensure the unavailabilities of those slots. Task-3612857 Forward-Port-Of: odoo/enterprise#51589
This update fixes leftover code references in the Belgian POS blackbox module that were missed during a previous translation system update. The module now correctly uses the updated translation function calls, ensuring all text displays properly in the point-of-sale system.
Original PR description
Commit [1] replaced all uses of env._t by calling the _t function directly, and removed _t from the env. This commit adapts forgotten occurrences. c07181b20bf4f06b783136ffdb3b7a304be6b136 opw 3664779
This update resolves a scheduling conflict in the Belgian payroll system where two public holidays were overlapping on the same date. The fix adjusts the start date of one public holiday to prevent the collision, ensuring employees' time-off records are processed correctly without duplication.
Original PR description
resource_public_time_off_be was coliding with resource_public_holiday_republic_day_in To avoid this, fix the date_from on public holiday
A bug prevented access group settings from being automatically copied when creating new child workspaces from the Documents app search panel. This fix ensures that when users create a new workspace as a child of an existing one, the parent's access settings are properly inherited, making workspace setup faster and more consistent.
Original PR description
https://github.com/odoo/enterprise/commit/ac2b8ea131688964bf04789ed8db068817b774a0 added a way to create workspaces directly from the side panel, copying some settings from its parent. Unfortunatly a typo prevent this feature to work properly. steps to reproduce: - go to the search panel of the document app - create a workspace and set some access groups on it - create a new workspace, children from that workspace before this commit: - values from parent are not copied to children after this commit: - values from parent are copied to children opw-3579989 Forward-Port-Of: odoo/enterprise#54142 Forward-Port-Of: odoo/enterprise#50875
This fix prevents administrators from editing the employee profile view using the Studio customization tool. When custom fields were added to the profile view, other users would encounter access errors because the new fields weren't included in the system's security whitelist. The solution disables editing of this view to maintain data security and prevent permission conflicts.
Original PR description
Steps to reproduce ================== - Install hr,web_studio - Login with admin - Go to "My Profile" (top right) - Open studio - Add a field - Close studio - Login with demo - Go to "My profile" => There is an access error Cause of the issue ================== On the profile view, there are some fields that are present and the user has read access to using a whitelist SELF_READABLE_FIELDS. If we add another field with studio, it will not be in the whitelist and this will fail the permission check. We cannot simply add a check to whitelist any manual fields, because this could cause some security issues. The res_users.get_view is also read called with sudo when the record is matching the current user. This means groups applied to custom fields from within studio won't restrict the field. Solution ======== Disable the edition of that view. opw-3598600 Forward-Port-Of: odoo/enterprise#53996 Forward-Port-Of: odoo/enterprise#53635
This fix resolves a problem where the partner directory page would break when a visitor's location (detected via GeoIP) didn't match any available resellers. Previously, if no partners existed in the detected country, the page would show nothing. Now, the system automatically displays all available partners as a fallback, ensuring customers can always see reseller options.
Original PR description
### [FIX] website_crm_partner_assign: reseller localization ### Issue Description: The partner() function previously inferred the country using GeoIP when no specific country (nor "all_countries")…
### [FIX] website_crm_partner_assign: reseller localization
### Issue Description:
The partner() function previously inferred the country using GeoIP
when no specific country (nor "all_countries") was specified.
However, if there were no partners from the inferred country,
the render function would lead to a broken screen.
### Resolution:
Implemented a fallback mechanism to treat the situation
as if no country was specified. This ensures that all partners are displayed
in such cases, preventing the occurrence of a broken screen.
### [Reproducing bug]
- odoo 16.4 with: website, contacts, crm_enterprise_partner_assign
- Simulate GeoIP on the backend, so it points to some COUNTRY_A:
- this can be achived by adding `country= country_obj.search([('name', 'ilike', 'mex')])` [below this line](https://github.com/odoo/odoo/blob/57d43aca2b07d3469a937890b7d5e5c4f29fe250/addons/website_crm_partner_assign/controllers/main.py#L237)
- note: it doesn't matter which country you set it to, AS LONG AS COUNTRY_A != COUNTRY_B
- in CRM/Contacts:
- create partner (set Partner Level and country to COUNTRY_B of the record )
- Publish partner by "Go to website" -> Published
- go to url: ODOO_WEBSITE/partners
- BUG: No Partners are displayed
opw-3598110
Forward-Port-Of: odoo/odoo#147896This fix corrects how cumulative charts in spreadsheets calculate totals when filters are applied. Previously, when filtering data (for example, to show only the current month), cumulative charts would incorrectly start from zero instead of including historical data from before the filter period. Now cumulative charts properly include past data in their calculations, ensuring accurate totals like subscription revenue breakdowns.
Original PR description
- Inserting a cumulated graph view inside spreadsheet (e.g. cumulated subscription MRR breakdown), - apply a global filter to filter, let's say on the current month => the first data point does not include data from before the current month (the accumulation starts at 0) 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 resolves an issue where updating a by-product in a manufacturing order after confirmation would be ignored. Now when a by-product is changed, the system correctly updates the product movements to reflect the new by-product instead of keeping the original one. This ensures accurate inventory tracking and manufacturing records.
Original PR description
Before this commit: =================== If by-product is updated in mo after confirm then the initial by-product is considered and the new one is ignored in stock_move_line(Product moves). After this commit: ================== If by-product is updated in mo then the initial by-product will updated with new one in stock_move_line(Product moves). task: 3534703 Forward-Port-Of: odoo/odoo#143779
This fix resolves an issue where the PEPPOL invoicing module was preventing users from registering Italian electronic invoices on test servers. The update adds a proper check to ensure demo mode only applies to PEPPOL-related requests, allowing test environments to function correctly while maintaining security restrictions on unverified databases.
Original PR description
Currently, if account_peppol module is installed on a non-verified database, it is not possible to register on `l10n_it_edi`, even on the test server. That happens because we do not limit the demo mode to peppol. This commit adds an additional check for the proxy_type when handling demo. We wrap `make_request` in the decorator because it's used in many places in account_peppol, so the condition has to be added inside the decorator. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The course filtering feature in the eLearning app was showing incorrect results when users selected tags to filter courses. This fix adjusts how the page caches content so that filtering works correctly for all users. Now when you select tags to filter courses, you'll see the accurate results that match your selections.
Original PR description
Issue: - The course filtering feature was consistently providing incorrect results, showing courses that were not related to the selected tags. This issue did not appear when logged in as an admin user. Steps to reproduce: - Install the eLearning app. - Navigate to the 'Courses' section on the website. - Click on a tag to filter the displayed courses. - Select additional tags to further filter the courses. - Observe that the results may not correspond to the selected tags. Solution: - This inconsistency was caused by the t-cache directive in the template, which cached parts of the page and didn't always reflect the latest user interactions, like changing the selected tags. - Modify the t-cache directive so that it caches the content only when there are no search tags. opw-3636565 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147106
Fixed an issue where down payment line descriptions weren't updating to show the related invoice name when a sales order was locked. Now, when you confirm an invoice with a down payment, the sales order line will properly display the invoice reference even if the order is locked, ensuring better traceability and clarity for your sales team.
Original PR description
Problem: The description of a down payment SOL does not recompute for a locked SO when an invoice is confirmed. Solution: Trigger the compute before it gets skipped due to the SO being locked. Purpose: The down payment line should include its reference to the invoice name despite the SO being locked or not. Steps to Reproduce on Runbot: 1. Install Sales 2. Enable "Lock Confirmed Sales" in Settings > Sale 3. Create a sales order and confirm 4. Create an invoice with down payment and confirm 5. Refer back to the sales order and the down payment line's description does not contain the invoice name opw-3612298 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148983
Corrected a grammatical error on the public discussion welcome page where the guest name label incorrectly read "Logged as" instead of "Logged in as". This fix also ensures the label is properly translated across different languages, improving the user experience for guests accessing the public discussion feature.
Original PR description
Label of guest name on public discuss welcome page was gramatically incorrect. It should be "Logged in as" rather than "Logged as". Forward-Port-Of: odoo/odoo#148943 Forward-Port-Of: odoo/odoo#147984
This update upgrades ngrok from version 3.1 to 3.5.0 to ensure continued support for remote Point of Sale connections. Ngrok ended official support for older versions on January 15th, 2024, making this upgrade necessary to maintain IoT device connectivity and remote access functionality for POS systems.
Original PR description
Ngrok will be officially ending support for all ngrok agent versions 3.1 and older starting on January 15th, 2024. So with this commit we install the latest version of ngrok 3.5.0 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#148829
This update fixes a leftover reference to an old translation method in the Live Chat module. A previous change replaced all translation calls with a new approach, but one instance was missed. This fix ensures the Live Chat feature uses the correct translation method consistently.
Original PR description
Commit [1] replaced all uses of env._t by calling the _t function directly, and removed _t from the env. This commit adapts a forgotten occurrence. c07181b20bf4f06b783136ffdb3b7a304be6b136 opw 3664779 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 resolves an access error that occurred when viewing employee records in multi-company environments where the associated user belongs to a different company. The issue was particularly triggered when archived users had their partner marked as shared. The fix ensures avatar computation works correctly by using elevated permissions, preventing security restriction errors when accessing employee forms.
Original PR description
The user associated to an employee doesn't need to be in the same company of the employee. When this happens, we could get a multi company issue when trying to _only_ display the employee form. One…
The user associated to an employee doesn't need to be in the same company of the employee. When this happens, we could get a multi company issue when trying to _only_ display the employee form. One way this issue is triggered is when the partner of the associated user is marked as partner_share=True. We may get an access error due to the rule `base.res_partner_rule`. Steps to reproduce: 1. Install HR module 2. Create an extra company with a user (U) on it. Ensure the partner of U is also set as belonging to this second company. 3. Create an employee in the first company with associated user U. 4. Archive U (this makes the partner of U get partner_share=True) 5. Try to access the employee form from the first company. We get an error: ``` Due to security restrictions, you are not allowed to access 'User' (res.users) records. Records: U (id=11, company=COMP2) User: Mitchell Admin (id=2) This restriction is due to the following rules: - user rule Note: this might be a multi-company issue. Contact your administrator to request access if necessary. Implicitly accessed through 'User' (res.users). ``` Since we allow hr.employee records to keep the associated archived user, to avoid this issue (potentially triggered differently) we opt to compute the avatar placeholder as sudo. The issue has been observed in multiple upgrade requests. Forward-Port-Of: odoo/odoo#148726 Forward-Port-Of: odoo/odoo#148325
This fix resolves an issue where the payment button becomes locked when customers select "Pick-up in store" as their shipping method if the store has added a multi-line description to that option. The problem occurred because the system was incorrectly counting the description text as pickup locations. The fix ensures the system properly identifies actual pickup locations instead.
Original PR description
To reproduce ============ - Website > Shipping methods > Pick-up in store - Add a description displayed on the eCommerce - add at least 3 or 4 lines with "enter" in between the lines. - from the shop select Pick-up in store, the payment button will be locked Problem ======= - The method `_disablePayButtonNoPickupPoint` checks if there are pickup points in a shipping method based on the count of children in the selected method - The description will be counted as child which breaks the checking Solution ======== check the existence of `.o_list_pickup_locations` instead opw-3628025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146606
This fix corrects how exchange rates are applied when calculating price differences on purchase bills. Previously, the system used today's date for the exchange rate, which could differ from the bill date and cause inconsistent accounting entries. Now all price difference calculations use the bill date exchange rate, ensuring consistent and accurate financial records.
Original PR description
Currently, the price difference amls are currently using today's date (so the date the bill is confirmed) for the exchange rate. It is weird, as the balance of those price difference amls then depends on the confirmation date of the bill. It is also weird, as they may also then use a different exchange rate than the other amls (that are using the bill date exchange rate). The fix is to use the bill date exchange rate. opw-3596209 Forward-Port-Of: odoo/odoo#147852 Forward-Port-Of: odoo/odoo#146840
This fix prevents module categories from creating circular dependencies, which was causing the system to freeze and making it impossible to upgrade or install modules. The system now validates that a module category cannot reference itself or create circular chains, allowing normal module operations to work smoothly.
Original PR description
Description of the issue/feature this PR addresses: - Update a module category to reference itself as parent OR - Update multiple module categories to create a circular dependency (A -> B -> A) Current behavior before PR: - Upgrade a module is impossible - Un/Install a module is impossible - Infinite loop: https://github.com/odoo/odoo/blob/15.0/odoo/addons/base/models/ir_module.py#L900 Desired behavior after PR is merged: - Circular dependencies not possible - Module can be upgrade and un/install Retarget of: https://github.com/odoo/odoo/pull/134485 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141820
This fix resolves a system error that occurred when users deleted an invoice line and then changed the invoice currency. The error prevented the invoice from being saved properly. The issue has been corrected so invoices can now be updated without errors after line deletions.
Original PR description
Create an Invoice with 2 lines of product
Save
Delete one
Change currency
Save
Traceback will occur becasue of a ValueError
```
for command, line_id, line_vals in vals['invoice_line_ids']
ValueError: not enough values to unpack (expected 3, got 2)
```
opw-3672799This fix ensures that when users click on email links to access company-specific records, the system correctly identifies which company's data to show, even if the user isn't logged in yet. Previously, this caused errors when trying to view records that were only accessible from a specific company. Now the email link properly directs users to the right company context from the start.
Original PR description
A model can specify a preferred company (cid) when redirecting someone from a mail link. Before this commit, this cid was taken into account when redirecting only if the user is logged in. This raises an AccessError when trying to access a record only visible from a certain company. With this commit, even if the user is not logged in, the redirect link will take that preferred cid into account. opw-3613144 Forward-Port-Of: odoo/odoo#149115 Forward-Port-Of: odoo/odoo#147913
A placeholder text in the Spanish (Mexico) translation was accidentally translated, causing the system to fail when trying to use the translated version. This fix corrects the translation file to prevent the error and ensures the system works properly for Spanish-speaking users in Mexico.
Original PR description
A placeholder was accidentally translated, which causes an error when the msgstr is used (and "campo") can't be found. We directly fix it in the .po file because as of v17, the es_MX is no longer on Transifex now that LATAM (es_419) is the preferred default. opw-3654160 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from accidentally archiving (deactivating) languages that are essential to the system's operation, such as the language used by the Odoobot automation user or the database's default language. Previously, users could deactivate these critical languages, causing system errors when automated processes tried to run. Now the system blocks deactivation of languages that are actively in use by system components.
Original PR description
Before this commit user was able to archive the language used by superuser Odoobot by activating different language. Because of which whenever odoobot was in action then the user faced error. Steps to produce: - Install `contacts`. - Settings > Translations > Languages > Choose a language eg: English (UK). - Activate that language and switch to it. - In `contacts` change the language of each contact in the contacts to the newly selected language. - Settings > Translations > Languages > Choose English (US) and archive it. - Settings > User & Companies > User, Apply the filter of Inactive Users. After this commit user would not be able to archive the language used by superuser or the language in which there db was installed. Task-2896526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149147 Forward-Port-Of: odoo/odoo#143095
This fix resolves an error that occurred during testing when a user had no access to any applications. The issue was particularly common when testing individual features with demo users. The fix improves the error detection logic to correctly identify when the system is stuck in tablet mode, eliminating false error alerts.
Original PR description
Since [1], an error is raised when no app is detected on the clickbot. The issue with this is that it's possible for a user to no have access to any app. This occurs when we test single apps (web for instance) with demo user. The aim of the error is to detect if we are stuck on a tablet mode page. Now, we change the test on the ensureHomeMenu function, to don't have false positives, and detect correctly if we are stuck on a tablet mode page. Fixes runbot issue 52675 opw-3649047 [1] : 8f365824c9dddacf1b3a40688a30c8498df3d5d4 Forward-Port-Of: odoo/odoo#149044