Friday, June 21, 2024
4 changes · saas-17.2
Resolved issues and error corrections
Public website visitors can now complete chatbot lead generation without hitting an access error. This ensures email and phone details collected through live chat can be converted into sales leads as intended.
Original PR description
ChatBot can't create lead, because it can't access website.visitor, as a public user. In order to allow lead creation from given email and phone this commit adds sudo rights for this operation. [Reproduce] - Install: website_crm_livechat - Go to: Live Chat / Channels -> "Configure a channel" - Modify Channel Rules for "/contactus" regex to use Lead Generation Bot - Go to Live Chat / Configuration / Chatbots -> Lead Generation Bot script change to: 1. Message: "e", Step Type "Email" 2. Message: "p", Step Type "Phone" 3. Message: "c", Step Type "Create lead" - log out (or use incognito) -> go to contact us page - open chat, answer its questions (email, phone) - BUG: Access Error msg opw-3858298
This fixes a regression that prevented sales and purchase flows with reduced or negative quantities from being processed correctly. Inventory movements now adjust existing delivery chains without creating unnecessary extra steps, helping avoid incorrect stock transfers and order handling issues.
Original PR description
Following #156437, the mechanism to handle negative procurements was removed as it wasn't applicable with the new push flow. This was a mistakes, as : - The old pull flow is still available, so we…
Following #156437, the mechanism to handle negative procurements was removed as it wasn't applicable with the new push flow. This was a mistakes, as : - The old pull flow is still available, so we still need to be able to propagate a negative quantity. - Even with the new push flow, this introduced a regression as we couldn't process negative quantity PO/SO anymore. The main issue was that with the new push flow, the whole picking chain might not exist yet by the time a negative quantity procurement is generated. Let's take the following case, in 3 step delivery - Stock -> Packing: qty = 5, status = 'done' - Packing -> Output: qty = 5, status = 'assigned' Here, we have the first step that was already processed, so the move from Packing -> Output has been created, while the one from Output -> Customer isn't yet (i.e. it will be when Packing -> Output is done). That means that if we were to create a procurement of -1 qty, we'd want: - New: Packing -> Stock: qty = 1 (move back the excess qty) - Packing -> Output: qty = 4 (merge the quantity into the existing move) - NO Customer -> Output move, as the delivery move hasn't yet been created. To achieve this, in the case of negative procurements, we instead generate the whole push chain of negative move then try to merge them. Then, we remove moves that shouldn't have been created. Note: Also restores some tests that were disabled by the pull&push refactor now that it works again :roll_eyes: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes automatic purchasing for products with reordering rules where both minimum and maximum quantities are set to zero. These rules now correctly treat zero maximum as “buy enough to meet demand,” so purchase orders are created in the right rounded quantities instead of being skipped or under-ordered.
Original PR description
### Steps to reproduce: - Create a storable product with a vendor and using the buy route. - Create a reordering rule for that product: - min: 0.0 - max: 0.0 - multiple: 5.0 - Case 1: Create an SO…
### Steps to reproduce: - Create a storable product with a vendor and using the buy route. - Create a reordering rule for that product: - min: 0.0 - max: 0.0 - multiple: 5.0 - Case 1: Create an SO for 4 units - Case 2: Create an SO for 9 units ### Expected behavior: Case 1: A PO is created for 5 units. Case 2: A PO is created for 10 units. ### Current behavior: Case 1: No PO is created. Case 2: A PO is created for 5 units. ### Cause of the issue: Since saas-17.2 (commit https://github.com/odoo/odoo/commit/e5d39368ee84238081c7a6b7f116e481a83f46e7) the max quantity of orderpoints has a meaning of storing capacity. As such the remainder quantity of a procuremnt can not exceed the max quantity of the orderpoint because of these lines: https://github.com/odoo/odoo/blob/c8985212fb4c937b814aaf7fe2ddca992b01735c/addons/stock/models/stock_orderpoint.py#L287-L289 However, the max quantity of 0 is usually interpreted as "to satisfy the demand" and should not be considered as a maximal storing capacity. opw-3961033 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where opening an employee's work information in debug mode could show an error after clearing the working hours field. The change keeps the Employee Contracts screen usable for administrators and support teams when validating or troubleshooting employee contract data.
Original PR description
Steps to reproduce: ------------------- - Install `Employee Contracts` module - Go to `Employees` and open any employee with a contract - Click on `Work Information` tab - Set `Working Hours` to nothing and save - Activate debug mode - Click again on `Work Information` tab Issue: ------ Error : `Invalid props for component 'ContractWarningTooltip'`. Cause: ------ In debug mode, we activate the validation of the props, and since there are not declared on the widget component, it is raising an error. Solution: --------- Set the default props (`standardWidgetProps`) on the widget component. opw-3972488