Friday, November 24, 2023
11 changes · 17.0
Enhancements to existing features
Danish OIOUBL invoice XML exports now include invoice payment terms. This helps ensure electronic invoices carry clearer payment information for recipients and better align with expected Danish e-invoicing requirements.
Original PR description
The aim of this commit is handling the invoice payment terms in the oioubl xml file. task-id: 3422407 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Views that include an onboarding banner now open without waiting for the banner content to finish loading. This improves perceived speed for users, with the onboarding banner appearing shortly after the page is already available.
Original PR description
Views including an onboarding banner, used to wait for the `/onboarding/xyz` RPC response before mounting. This RPC is not needed to render the whole page and therefore should not be awaited. With this commit, the `/onboarding/xyz` call has been made asynchronous. This means that the view is rendered, and the onboarding banner is displayed when the response arrives. Example of onboarding flow: - Install account module - Go to the Invoice module - The `/onboarding/account_invoice` call should not be waited to render the view.
Discuss push-to-talk now supports a Chromium-based browser extension that can register a system-wide shortcut. This lets users talk during calls even when Odoo is not the active browser tab or window, reducing friction during multitasking.
Original PR description
Currently, discuss push-to-talk only works when the browser has focus because key events are not fired otherwise. This commit adds an extension for chromium-based browsers that allows to register a system-wide push-to-talk shortcut and adapts the rtc service in order to listen to the extension events.
The UPS payment integration in the online store has been updated to work with the latest button widget system. This improvement ensures the payment button displays and functions correctly with the current website interface, maintaining a smooth checkout experience for customers.
Original PR description
task-3568861 See also: - https://github.com/odoo/odoo/pull/139556 Forward-Port-Of: odoo/enterprise#49894
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