Thursday, October 10, 2024
44 changes
Resolved issues and error corrections
This fixes internal website test scripts so they continue to work after a recent change removed an older text-matching method. It helps keep automated checks reliable without changing what users see in the product.
Original PR description
This PR replaces the uses of ":text" by ":contains", following the recent changes that removed the ":text" pseudo-class. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The color picker now displays RGBA color values with proper spacing between the blue and alpha values. This small formatting fix makes color information easier for users to read and understand.
Original PR description
Before this commit, the value of the RGBA in the colorpicker display was missing a spacing after the value for blue. This commit add the spacing after this value to make the text more readable by the user. task-4242209
Point of Sale users can once again find products by searching for their internal reference code. This restores expected search behavior from the previous version and helps cashiers locate items faster at checkout.
Original PR description
Problem: In the PoS interface, searching for products using the `default_code` (internal reference) does not return any results, while this functionality was available in version 17.0. Steps to reproduce: - Open PoS. - Attempt to search for any product using its `default_code` (internal reference). - No results are displayed. opw-4232415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where generated dates could be distributed incorrectly when a very large number of values was requested. The change improves the reliability of Odoo's internal data generation tools, reducing the risk of skewed or missing test data.
Original PR description
Before this commit `total_days/factor` could return 0 because PG truncates integer division. Casting total_days to a float and moving the floor's position fixes this issue, providing a correct date spread for `factors > (MAX_DATETIME-MIN_DATETIME).days` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale payment method settings now clear terminal-specific values when a user switches the integration type away from terminal payments. This prevents hidden or outdated terminal fields from blocking users from saving payment method changes.
Original PR description
[FIX] point_of_sale: ensure values are cleared when switching away from terminal payment method Problem: After a terminal provider is selected in "Integrate with" option, if the user change "Integration" option away from 'Terminal', the fields from terminal are still visible and getting validate. This makes record's changes cannot be saved if the fields are empty. Steps to Reproduce: 1. Install Point of Sale app. 2. Go to Configuration > Settings. Enable any "Payment Terminals". 3. Go to Configuration > Payment Methods. Click new or edit a record. 4. Select a journal 5. Select an "Integration" option "Terminal" 6. Select a terminal in "Integrate with" option 7. Switch an "Integration" option to None 8. Observe that the added fields does not disappear and is still getting validate when you save the record. Move from #182548: renaming branch --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Selected avatar tags now appear in bold within the dropdown list, making current choices clearer at a glance. This small visual fix helps users avoid confusion when reviewing or changing tag selections.
Original PR description
opw-4212924
The project burndown chart was adjusted to avoid an incorrect translation call. This reduces the risk of display or localization issues while keeping the chart behavior unchanged for users.
Original PR description
This PR removes a call to _t with a dynamic argument.
Merging accounts now keeps the translated account names from the accounts being combined. This prevents translated names, such as customer-facing labels in different languages, from being lost during account cleanup.
Original PR description
At the moment, when we merge accounts, we don't merge the account name's translations. This is a bit annoying since one account might have been called 'Account Receivable' in English, and another one might have been called 'Clientes' in Spanish. At the moment, the translations of the other accounts are lost. This commit makes us merge the translations when merging the accounts. taskid: 4210775
Repair order status badges now use distinct colors that better match each order state. This makes it easier for users to quickly identify whether a repair is draft, confirmed, under repair, done, or cancelled in list views.
Original PR description
Before: In list view, repair orders state badge is green when the state is 'done'. Otherwise, it is always blue. After: No change for state 'done'. Badge color is more adapted to other states: - blue remain for 'confirmed' - yellow is used for 'under_repair' - white/black is used for 'draft' - red is used for 'cancel' Task 4237694 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes an automated website event ticket sales test run more reliably by checking page elements sooner and waiting for them in the right order. It helps reduce false test failures without changing the customer-facing ticket purchase experience.
Original PR description
Decrease checkDelay to 100ms instead of 750ms by default. Add intermediate steps to ensure elements are in DOM before to continue the tour. Modify steps that are not logicals. 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 update adds country information to HR work entries so country-specific fields and groups display correctly. It helps ensure HR teams see the right payroll or work-entry details based on the employee's country setup.
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
Creating an employee from a candidate with recorded skills no longer triggers an error. This prevents duplicate skill records during employee creation, helping recruiters complete the hiring workflow without interruption.
Original PR description
Steps --- * Create a candidate * Give them a skill * *Create Employee* * => Traceback -> "Two levels for the same skill is not allowed" Cause --- * on `hr.employee.skill` we have a unique constraint on the skill employee pair * but when creating an employee we would attempt to create the skills twice, once through regular create and once from the override of `_update_employee_from_candidate` call in the write
Inventory forecast reports now show formatted help text correctly instead of exposing raw HTML. The Replenishments side panel now starts collapsed, reducing visual clutter and making the screen easier to navigate.
Original PR description
Various v18 bugfixes for MRP before the feature freeze. Current behaviour: 1. HTML help string markup for empty reports don't get parsed in some cases (such as the forecasted inventory report). 2. Replenishments sidepanel is expanded by default. Desired behaviour: 1. HTML help string markup gets parsed for every report view. 2. Replenishments sidepanel is collapsed by default. Task ID: [4154879](https://www.odoo.com/odoo/966/tasks/4154879)
Installing a chart of accounts could fail for companies that already had Point of Sale payment methods. The fix ensures related POS payment records are handled correctly, allowing accounting setup to complete without blocking the user.
Original PR description
When trying to install a CoA on a company that already have pos payment methods the installing would fail because it's trying to delete a journal linked to the payment methods
Steps to reproduce:
-------------------
* Create a new company, do not install CoA
* Create a PoS payment method
* Install any CoA
> Observation: You get an error saying you cannot delete some records
Why the fix:
------------
When we are unlinking account_journal records with this context `{MODULE_UNINSTALL_FLAG: True}` we make sure to also delete the pos_payment_method and pos_payment linked to that journal. This is done here https://github.com/odoo/odoo/blob/854c3b27aa5476c208572f19e64f8f3364bfc381/addons/account/models/chart_template.py#L202
opw-4245944
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes a Time Off issue where accrual plans that grant leave at the start of a period did not immediately credit the current period when an allocation began. Employees can now see and request newly accrued leave correctly, including allocations that started at zero days but have since earned time off.
Original PR description
Steps to reproduce: - Time off > Configuration > Accrual Plan > New - Set 'Accrued Gain Time' to 'At the start' - New Milestone > Set 'Milestone reached' to 0 days after... - Accrue 1 day Monthly on…
Steps to reproduce:
- Time off > Configuration > Accrual Plan > New
- Set 'Accrued Gain Time' to 'At the start'
- New Milestone > Set 'Milestone reached' to 0 days after...
- Accrue 1 day Monthly on the last day of the month > Save
- Management > Allocations > New
- Tick 'Accrual allocation' > Set the 'Accrual Plan' to your newly created plan
- Set the start date to today
- 0 days of allocation for 'Time off type' of your choice > Validate
- My time > Dashboard > Use 'Balance at the mm/dd/yyyy'
The accrual grants 1 day of leave for the upcoming month on the last day of each month, you will however notice that no leave is granted for the current month until we reach its last day. According to the logic of our accrual, 1 leave day should have been granted on the last day of the previous month so we should get our partial credit for the current month immediately instead.
The first step is to simply add the leave days of the corresponding period but this leads to other issues. When computing accruals that are granted at the start of start of the accrual period we use the already_accrued flag to avoid recomputations, but this flag can be raised by a call chain in the write method of hr.leave.allocation starting from _get_consumed_leaves.
This call chain passes through _process_accrual_plans, and invalidates the cache on its way out though _get_future_leaves_on. This notably happens when computing leaves_taken in _process_accrual_plans which can mess with the record's fields, including but not limited to the already_accrued flag which induces errors in the number_of_days we are trying to compute.
Also, the domain we use to restrict the leaves type that can be picked when asking for a leave prevents us from using allocations that start with 0 days. ('max_leaves', '>', 0) rules out these leaves, even after they have accrued enough time off to legitimately request a leave of this type. Disabling max_leaves = 0 does not seem to serve much purpose as a non-accrual leave starting with 0 days should only be able to fulfill the other conditions if it has 'allows_negative', in which case we would want it to show up anyway.
opw-4192703
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue where spreadsheet pivot tables could show a “see records” option for calculated fields when no underlying record existed. The change prevents users from opening an invalid record view and avoids a traceback, making spreadsheet reports more reliable.
Original PR description
Some methods in the pivot_model didn't handle the `NO_RECORD_AT_THIS_POSITION` constant returned by positional pivot formulas. This lead to a `see_record` visible where it shouldn't be, that caused a tracabeck. Task: [4210956](https://www.odoo.com/web#id=4210956&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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 change makes an automated website slides test wait until the page preview is fully ready before checking fullscreen mode. It reduces intermittent test failures, helping keep releases and updates more stable without changing user-facing behavior.
Original PR description
The tour full_screen_web_editor fails at step ":iframe .o_wslides_fs_main" (check we land on the fullscreen view) from time to time on the runbot. We could reproduce the problem locally by setting a timeout on that step below 1400 ms. As this step (like others) is loaded in the WebsitePreview iframe that set the attribute "is-ready" on the iframe node when some assets are loaded (website.assets_all_wysiwyg), we have added a step before, that wait for that (stepUtils.waitIframeIsReady()). With that change, the tour succeeed even if we set a very low timeout on the failing step. So it should solve the problem. Task-4222573
This fixes an issue where visitors booking appointments could be blocked from creating a contact record. Appointment scheduling now works more reliably for public users, reducing failed bookings and support friction.
Original PR description
Due to recent change introduced in 8b9a1a4462453bf64e7bc1307ededd0d127a27fa The customer variable can be non sudo for the public user when only using appointment module. Add a sudo to ensure contact creation. Task-4247116
This fixes an automated test for the Knowledge calendar command so it uses the standard editor tour helper. The change helps keep quality checks stable without changing how users work with Knowledge.
Original PR description
We use tour_helper editor instead of programmatic run().
This update improves manufacturing workflows by making Shop Floor entry behave consistently, showing clear pending status instead of a blank timer, and correcting weekly planning headers when weeks cross month boundaries. These fixes reduce confusion for production teams and make manufacturing planning displays more accurate.
Original PR description
Various v18 bugfixes for MRP before the feature freeze. Current behaviour: 1. Entering the Shop Floor from a WO searches the WOs in that workcenter by state by default. 2. The timer field is blank if the WO is in ready or pending states. 3. The month substring in the weekly MPS display column header shows the month of the starting date if the given period straddles two months. Desired behaviour: 1. Entering the Shop Floor from a WO reflects the same behaviour as entering from MO, which is the suppression of the default filter. (Depends on #68419) 2. 'Pending' text is displayed if the WO is in pending state. 3. It shows the month of the end date instead. Task ID: [4154879](https://www.odoo.com/odoo/966/tasks/4154879)
This fixes an issue where return transfers created from the Barcode app could fail because quantities were left empty. The app now pre-fills return quantities from the original transfer, helping warehouse staff process returns without errors.
Original PR description
Commit odoo/odoo@57b8b2487def4 make the return wizard fill the product quantity to 0 default. This break the return flow in the stock_barcode application as the return picking is created on the fly but empty so an error is raised. To encounter this, returns created via stock_barcode app have their quantities set to the original stock move ones. The return picking is thus fill according to the need.
This update corrects when Group S payroll options are shown for Belgian companies and improves related error handling. It helps payroll users see the right contract and work entry settings while reducing confusing errors.
Original PR description
In this commit, fixes visibility and error handling for belgium companies. task-4213306
This fix corrects a naming error that could cause recruitment document extraction to fail unexpectedly. It helps keep candidate processing stable and adds test coverage to prevent the issue from returning.
Original PR description
* traceback due to typo: applicant_id -> candidate_id task-4207776
The mobile app now handles the first-time permission response more cleanly when using native phone features. This prevents unnecessary startup errors, improving reliability for users opening the app or accessing permission-based features.
Original PR description
In the Native Mobile Apps when we use a Native method that requires a permission the promise is rejected on the first call. This commit avoids to generate `unhandledrejection` in this case.
When a new company is created, custom fields named x_company_id now receive the expected default company value. This keeps records aligned with the correct company and avoids manual setup or inconsistent defaults in Studio-created fields.
Original PR description
Create a field x_company_id on a model. Create a new Company. Before this commit, no ir_default was created for that field, studio only did for x_studio_company_id. After this commit, the fields named x_company_id have an ir_default created when a new company is created. task-4226351