Thursday, October 10, 2024
8 changes · 18.0
Resolved issues and error corrections
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
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
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 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 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