Friday, November 24, 2023
7 changes · 17.0
Resolved issues and error corrections
Combo products in Point of Sale now update correctly when a customer with a custom pricelist is selected. This prevents each combo line from being recalculated separately and helps ensure the final order price matches the intended customer pricing.
Original PR description
Steps to reproduce: - create an order with a combo product - change the customer to a customer that has a custom pricelist Bug: Each combo orderline will be recalculated independently Fix: Extract the combolines price calculation from addComboLines. Modify the setPricelist method to use the new price calculation method for the combolines. 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
The manufacturing order overview now calculates real component costs using the quantity actually consumed, not the original planned amount. This gives businesses a more accurate view of production costs when consumption differs from the plan.
Original PR description
Steps to reproduce: - Create a BoM with a single component - Create a MO using that bom and confirm it - Set more consumed components than planned and validate the MO - Open the overview Issue: While the overview correctly displays the used quantity, the real cost column still uses the initial demand to compute its costs instead of the quantity used. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves a crash that occurred when users tried to start a timer in the timesheet application after applying grouping filters. The issue was caused by missing data parameters when switching between different view types. The fix ensures all necessary data is properly passed to the timer function, allowing users to start timers without errors regardless of their current grouping settings.
Original PR description
**Steps:** - Open Timesheet - In Grid View apply groupby - Switch to List View or Kanban View - Click on the start timer **Issue:** - on click of the start timer, we get a traceback **Cause:** - Due to some missing fields, the function is not able to get the correct values and so the values appear to be undefined. This is mainly because the parameters are wrongly passed. When the view is normally loaded, commonRecordParams are passed but when groupby is applied, commonGroupParams should be applied as it has some extended parameters. **Fix:** - passing commonGroupParams along with commonRecordParams so that we do not get the undefined values. task-3422009 Forward-Port-Of: odoo/enterprise#49872 Forward-Port-Of: odoo/enterprise#44063
This update fixes display problems in the appointment booking interface where resource information was not showing correctly. Specifically, when booking appointments without pictures or when selecting operators, the system was either showing the wrong resource details or not showing them at all. The fix ensures that the correct resource information displays in the right column during the time selection process.
Original PR description
When using 'resource_time' without pictures, the name of the variable within the resource loop in the select is 'resource', which is also the name of the resource described in the details right column. Therefore, the last resource was always shown. It should not be shown at all. Templates are updated to have unique names. Also, when selecting a user in operator screen (when website is installed and pictures are enabled), their info is not showing on the right column on time selection screen. We also remove isOperator as not strcitly useful but instead explicitely set resource to False in appointment_select_operator in order to make sure it is not used as a selected resource in other templates. This is necessary because of the loop on available resources using t-as="resource". This solution avoids renaming all instances in that template. Task-3588251
This update fixes two critical issues with Knowledge macros that were causing infinite loading loops and error messages. Users will now see macro buttons only when appropriate, and macros will execute smoothly without false error notifications when embedded views are present in articles.
Original PR description
The [refactoring] of knowledge macros introduced 2 kinds of errors that are fixed in this work: 1) An infinite loop during a macro if a Knowledge article is accessed by going back in the breadcrumbs from any Form view (the macro button should not be visible in that case since the controller of the Form view is not accessible after going back). 2) An error saying that the "record can not be found" whilst the macro is actually succeeding in loading the correct record, that is caused by the fact that an embedded view in an article can have breadcrumbs that make the macro advance too fast. See each commit for more details. [refactoring]: https://github.com/odoo/enterprise/commit/1fc6c7ef19462eda0cacfccb242f88e495f8ab1f task-3598754
The signature request counter was incorrectly including archived requests in its count. This fix ensures that only active signature requests (those with 'sent' or 'completed' status) are counted, providing accurate numbers in applications like recruitment where tracking pending requests is important.
Original PR description
Issue: ------ The purpose of the `signature_count` field is to count the number of signature requests. However, it counts signatures that have been archived. For example, in the recruitment application, when we want to see the number of requests sent to a job application. Solution: --------- Modify the domain to take status into account and display only signatures that are `sent` and `completed`. opw-3550893 Forward-Port-Of: odoo/enterprise#51255 Forward-Port-Of: odoo/enterprise#50907
Fixed a bug in the Belgian HR salary module where the system could incorrectly auto-fill a motorcycle or bike instead of a car when generating a salary simulation link. The wizard now properly filters to only suggest actual cars, preventing data entry errors for employees with multiple vehicles.
Original PR description
When you open the wizard to select generate a link, the car_id is auto completed throught the compute field. The compute takes the first fleet.vehicle where the employee or applicant is the driver or future driver, but does not check that the vehicle is of type car. So when the employee has a car and a bike or just a bike, it can put the bike in the car_id field (event if the domain on the field prevent from selecting anything else than car) Forward-Port-Of: odoo/enterprise#51300