Tuesday, November 19, 2024
15 changes
13 changes
Resolved issues and error corrections
Users can now create a record with rich text content, save it, edit the description, and save again without hitting a validation error. This prevents an interruption in common workflows such as creating and updating project tasks.
Original PR description
Before this commit, when editing a record that was created and saved using the "new" button, a ValidationError was raised. To reproduce the error: - go to task in project - click on new button - set the title - set the description - save - change the description - save => Validation error task-4299855 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Clicking a message notification now reuses an existing Odoo or Discuss tab when possible instead of opening a new browser tab every time. This keeps users' browsers cleaner and makes it easier to jump back into the relevant conversation.
Original PR description
When enabled, message notifications are sent as a native notification. However, the notification opens a new tab each time a notification is clicked. This behavior is not natural and leads to many opened tabs which is cumbersome. This PR fixes this behavior: - If a tab is opened on discuss, open the channel in this tab. - If a tab is opened in Odoo, open in a chat window. - Only open a new tab if no Odoo tab is available. task-4295517
This fixes an issue where materials added from the catalog in Shop Floor did not always create the required Pick Component operation for two-step manufacturing. The system now applies the same quantity update logic for newly added materials as it does for existing ones, helping manufacturing workflows proceed correctly.
Original PR description
When created through the catalog, updates the raw move after its creation, that way the logic is the same regardless the move is created or updated. It fixes an issue in the Shop Floor where created raw move doesn't trigger the creation of the Pick Component operation when manufacture is in 2 steps. See Enterprise PR for more information. Enterprise PR: odoo/enterprise#71791
Restaurant orders can now have their bill printed from the action button without causing an error during payment validation. This keeps the checkout flow working smoothly for staff after printing a customer bill.
Original PR description
Steps: - Open the restaurant interface. - Add items to any table order. - Print the bill using the action button. - Attempt to validate a payment. - An error message appears. Issue: - A traceback occurs when printing the bill from the action button. - After printing the bill via the action button, adding a payment line to the order becomes restricted. Cause: - An error occurs due to an increment in the bill print count. Fix: - Prevent incrementing the bill print count when using the action button. task-4231943
This fix ensures Safari users can change font size and font style from the HTML editor toolbar without the dropdown disappearing or losing the text selection. It improves editing reliability for users working in Safari.
Original PR description
Issue: ====== We can't change font size and font style in safari broswer. Origin of the issue: ==================== In safari clicking in dropdown-item in the toolbar will produce the following flow: - `pointerdown` event - It will trigger the `blur` the event with null selection - Since the item has the class `user-select-none` it will trigger the selectionchange with null selection too since we shouldn't select that element. In chrome here there is no selectionchange event because the element is not selectable so chrome doesn't care and do nothing. - Now the selection is changed to null so the toolbar will appear and no `click` callback of the item is called because the element is already destroyed. Solution: ========= We add prevent on the `pointerdown` event so it doesn't trigger the blur and the selectionchange and we remove the `user-select-none` since it becomes useless. opw-4299373
Fixes an error that occurred when recruiters tried to refuse an applicant from the Recruitment app. The refusal flow now works correctly and provides a smoother user experience, helping teams manage candidates without interruption.
Original PR description
STEP TO REPRODUCE: ================== 1- Recruitment > All apllicants 2- Select one applicant 3- Click on refuse You will have a traceback In this commit, this issue is fixed and the UX was fixed too. 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
Spanish localization now applies the correct fiscal position automatically for customers in the Canary Islands, Ceuta, and Melilla. This prevents these regions from being treated like mainland Spain or EU intra-community cases, improving tax accuracy on invoices.
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
This fix ensures payment errors are properly passed to the right handler so customers see the actual issue instead of a misleading or duplicate message. It improves the checkout experience for PayPal payments by making failures clearer and reducing repeated notifications.
Original PR description
**[FIX] payment: return a rejected promise on RPC error during payment** This commit addresses the issue of RPC errors not triggering a promise rejection when initiating or processing the payment. This caused issues with PayPal not being able to pass the error to its error handler when a problem occurred during payment processing. For example, the error message "order id was not provided" would be shown instead of the actual RPC error message. --- **[FIX] payment_paypal: show message on RPC error during order completion** This commit fixes RPC errors occurring during order completion not being caught and not triggering a promise rejection. A simple "ValidationError" toaster notification was shown. --- **[FIX] payment_paypal: show RPC error messages only once** RPC errors occurring during payment were shown in a modal by the generic error handler of `payment` and again by the error handler of PayPal. RPC errors are now filtered out by the handler of PayPal.
Shop Floor now correctly opens on the first available work center when no specific work center is preselected, reducing operator confusion. Adding extra components from the Shop Floor catalog now also creates the required Pick Component transfer in two-step manufacturing flows, helping ensure inventory movements stay accurate.
Original PR description
# [FIX] mrp_workorder: always select first option > Depending of the selected work centers in the Shop Floor view, different work center buttons will be visible ("All Mo", "My WO", "Assembly 1", ...)…
# [FIX] mrp_workorder: always select first option
> Depending of the selected work centers in the Shop Floor view, different work center buttons will be visible ("All Mo", "My WO", "Assembly 1", ...) When no work center are selected by default, the first one should be the selected one, but for now, in this case it's always "All MO" who is selected.
This commit fixes that, the first button/WC will always the selected one if there is no WC id in the context.
# [FIX] mrp_workorder: don't set qty for component added from catalog in the Shop Floor.
> Description
> ===========
>
> Before this commit, the quantity of a new move raw added through the catalog in Shop Floor was set directly in `_get_new_catalog_line_values`.
With this commit, it is not the case anymore, that way, if we should pick the component (production in 2 steps), the picking will be correctly created (before this fix, the picking was created only after an updated by `_get_new_catalog_line_values`.)
>
> How to reproduce
> ================
>
> - In Inventory settings, enable "Multi-Steps Routes";
> - In your warehouse configuration, select the 2 steps options for the manufacture;
> - Create a product with a BoM with at least a component;
> - Create a second product component (but not as a part of the BoM;)
> - Add quantity in stock for both components;
> - Create and confirm a MO for the product with the BoM;
> - Go in the MO's transfer and validate the "Pick Component" picking;
> - Go in Shop Floor, and for this MO, add the second component: click on the gear icon, "Add Component", search your component and click on it.
>
> If you check your MO in the back end, you'll see no "Pick Component" transfer was created for the added component. That said, if you add more quantity for this component (still through the Shop Floor catalog), you'll see the transfer will be created but 1 qty will be missing.
>
> Explanation
> ===========
>
> When in 2 steps manufacture, if a component line is added and the demand is greater than the actual quantity, a Pick Component transfer will be created for this product.
In the catalog, when using it through the Shop Floor, the raw move is
created with an equal quantity and demand, which means no Pick Component
transfer is needed.
That said, when updating an existing raw move through the Shop Floor
catalog, the demand is updated BEFORE the actual quantity, resulting of
the creating/update of the Pick Component transfer.
>
> To fix this issue, the quantity is not set directly during the move creation but will be updated just after (see related community fix.)
Community PR: odoo/odoo#183532Users can now send and print the partner ledger report even after the follow-up feature has been uninstalled. This prevents an error that interrupted reporting workflows and improves reliability for Accounting users.
Original PR description
Currently, a traceback occurs when the user tries to send the `partner ledger` report after uninstalling the `account_followup`. To reproduce this issue: 1) Install `Accounting` 2) Uninstall…
Currently, a traceback occurs when the user tries to send the `partner ledger` report after uninstalling the `account_followup`. To reproduce this issue: 1) Install `Accounting` 2) Uninstall `account_followup` 3) Open the `partner ledger` report from the reporting 4) Click the `send` button and then `send & print` button Error:- ``` 'res.partner' object has no attribute '_get_partner_account_report_attachment' ``` The `_get_partner_account_report_attachment` method is defined in `account_followup` and is referenced in `account_reports`. https://github.com/odoo/enterprise/blob/6100796466f356053dde87110c80812c2dcba3ba/account_followup/models/res_partner.py#L295 When the user uninstalls the `followup` it leads to the above traceback when the below line of code executes. https://github.com/odoo/enterprise/blob/6100796466f356053dde87110c80812c2dcba3ba/account_reports/wizard/account_report_send.py#L250 We can resolve this issue by moving the code from `account_followup` to `account_reports`. As we can see that `account_followup` depends on `account_reports`. sentry-6069400574
Uploading some vendor bills for Indian companies could fail when a rounding difference was present. The invoice extraction logic now handles the updated tax totals structure correctly, preventing the error and allowing affected bills to be uploaded.
Original PR description
A traceback may occur when the user tries to upload a vendor bill. Where the invoice has an Indian company and a rounding error. Error:- ``` KeyError: 'groups_by_subtotal' ``` This is because of the major refactor done from the below commit to calculate the tax_totals in the `account.tax` https://github.com/odoo/odoo/commit/73d585a85b093db07e4eb5541aaa03e74af5fd62 Initially, we have a `groups_by_subtotal` in tax_totals, but after the refactor we return subtotals containing `tax_groups`. The code has been adjusted according to the above commit by take the maximum `tax_group` based on `tax_amount_currency` and added the `fixed_round_error` to resolve this issue. sentry-5963987892
Belgian payroll provider fields are now hidden for companies outside Belgium, preventing users from seeing country-specific options that do not apply to them. This reduces confusion when managing employees and work entry types across companies in different countries.
Original PR description
*= group_s + partena + ucm before this commit the specific fields were visible even in case that the user shouldn't see them because for exemple he is in a US company this commit fix this issue by adding invisible depends on company country note: the work entry type is still visible if no country is set task-4286122
Point of Sale employees who log in without a full user account will no longer be prompted to create new products when scanning an unknown barcode. This keeps product creation restricted to authorized users and aligns barcode scanning behavior with the existing POS menu permissions.
Original PR description
Currently if employees (without users) log into the register and use the barcode reader, if the barcode isn't found in the database, they will be prompted with the create product screen Steps to…
Currently if employees (without users) log into the register and use the barcode reader, if the barcode isn't found in the database, they will be prompted with the create product screen Steps to reproduce: ------------------- * Connect to the db with Mitchell Admin * Open the **Point of Sale** App * Select **Configuration** > **Settings** * Select the Furniture shop * Enable **Log in with Employees** * Open Furniture shop session * Select an employee that is not a user as employee (Abigail Peterson for ex) * Either select the barcode icon and present a barcode to the camera or go into debug mode and enter the barcode in the debug window and select scan. Prefer to use a barcode not in the db. > Observation: A popup appear to create a product Why the fix: ------------ Currently employees are able to create product if the underlying user who is connected has the group `base.group_system`. https://github.com/odoo/enterprise/blob/3bf3400a60436e9f07f23c6ba11e5749e4c00459/pos_barcodelookup/static/src/overrides/components/barcode_reader/barcode_reader.js#L8 Employees do not have the right to create products. This commit https://github.com/odoo/odoo/commit/e10768b6ce5c82e67e14641233dc9deefb48f8ba already removed the rights to see the create product button from the menu. We follow the same logic to block the creation process when scanning barcodes. opw-4255570 Community PR:https://github.com/odoo/odoo/pull/187184
2 changes
Resolved issues and error corrections
This update fixes an issue where email notifications were sent prematurely when creating sales orders, leading to inaccurate quotation documents. The change ensures the sales order is confirmed after the order line is created, preventing work on potentially cancelled quotations. This improves data accuracy and user experience.
Original PR description
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app > New > Enable 'Billable' in the project's settings - New Task > Set any Customer - Sales Order Item > Search More > New > Add product then save - Click 'Sales Order' button Coupled with https://github.com/odoo/odoo/pull/183586 You'll see in the chatter that the confirmation email is sent before the product is added to the sales order, resulting in a $0 quotation document being sent to the customer. This happens because we confirm the SO at the same time as we create it (After pressing the New button). Instead we would rather confirm the SO on save, after the order line creation. The SO confirmation is necessary because we don't want people to work on tasks/projects that are still in quotation since they could hypothetically still be cancelled. opw-4190402
This update resolves an error that occurred when editing barcode scanning records, specifically during rapid switching between the barcode view and the detailed record. The fix ensures the barcode component correctly updates database information, preventing a 'undefined record' error. This improves the reliability of the barcode scanning feature.
Original PR description
### Steps to reproduce: - Create a delivery order for 2 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend by clicking on the…
### Steps to reproduce: - Create a delivery order for 2 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend by clicking on the prodcut name. - Come back to the record the faster you can. #### > Error in Owl lifecycle: undefined record in get moveIds ### Cause of the issue: Since the barcode app relies on stock move line's data to generate its main component it is necessary to split moves in DB when you exit the barcode app in order to rerender the main component with appropriate data the next time you enter the barcode. Currently this split is done `onWillDestroy`: https://github.com/odoo/enterprise/blob/c97daa0127725411ba16ed8c94e6b31a0f4e1cc3/stock_barcode/static/src/components/main.js#L105-L107 https://github.com/odoo/enterprise/blob/c97daa0127725411ba16ed8c94e6b31a0f4e1cc3/stock_barcode/static/src/models/barcode_picking_model.js#L1327-L1329 However, if you come back to the barcode app fast enough you will start the creation of a new barcode main component before this rpc call has ended, in turn you will modify the content of the component before it has even mounted (even prior to the assignment of this.record) and owl will therefore destroy that component and recreate a new one with the appropriate content. But since this non-mounted component is destroyed it triggers the onWillDestroy and since it has no record yet it triggers an error by trying to access `this.moveIds`: https://github.com/odoo/enterprise/blob/c97daa0127725411ba16ed8c94e6b31a0f4e1cc3/stock_barcode/static/src/models/barcode_picking_model.js#L656-L658 ### Fix: Since we only want to trigger our `_onExit` method to update DB's data if the component has been mounted and since the `this.record` will always exist in that case, we should use the onWillUnmount hook rather than the onWillDestroy. Follow-up of c16acf3617442d3048f6a1246a2bc826af3c02fd (fixed in forward ports post 17.0). opw-4232106