Tuesday, November 19, 2024
19 changes · 18.0
Enhancements to existing features
The Discuss app has been visually softened to reduce harsh contrast, especially in dark mode. This makes conversations easier on the eyes with gentler colors, lighter separators, fewer borders, and more comfortable sidebar spacing.
Original PR description
Especially in dark theme, UI had too much contrast, which makes using Discuss more exhausting than it should. PR makes the following improvements to make Discuss look more pleasing: - Dark theme:…
Especially in dark theme, UI had too much contrast, which makes using Discuss more exhausting than it should. PR makes the following improvements to make Discuss look more pleasing: - Dark theme: selected item is greyish rather than greenish - Discuss app borders and composer have half reduced opacity - Dark theme: background of conversation is slightly less dark - Message bubbles no longer have borders - White theme: date separator is slightly less visible - Discuss sidebar channel items have more vertical spacing Before (white)  After (white)  Before (dark)  After (dark) 
The point of sale IoT box image is being updated to a newer Raspberry Pi operating system release. This should prevent startup hangs related to display initialization and fix a log rotation configuration issue that could stop a service from starting.
Original PR description
Backport of #187206. For the next IoT box image, we will upgrade to the latest version of RPi OS Lite. This fixes an issue on bootup where the display is not initalised (hangs waiting on `dev-dri-card0/start`). Also removes the `wtmp` and `btmp` paths from `logrotate.conf`. These paths were duplicated from existing logrotate config files, causing the service to fail to start. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Orders paid with the on-site payment option are now confirmed automatically instead of remaining pending. This ensures related delivery or collection steps are created promptly, reducing manual follow-up and improving the customer experience.
Original PR description
As on_site payment provider is a custom one, transaction is created as pending. Therefore, SO is not confirmed and picking is not created which is not convenient for the customer. task-4267776
The code upgrade command is now easier to automate, with cleaner output, clearer required options, and better handling of progress and dirty files. This helps developers and release teams run upgrade preparation more safely and predictably.
Original PR description
Moved the logs/progress on stderr so it is possible to silent them using a shell redirection `2>/dev/null`. Simplified what is written on stdout so it is scriptable. Moved `sys.stdout.isatty()`…
Moved the logs/progress on stderr so it is possible to silent them using a shell redirection `2>/dev/null`. Simplified what is written on stdout so it is scriptable. Moved `sys.stdout.isatty()` outside of `print_progress` so the function is evaluated once, and not everytime we print a progress. Should speedup the scripts a bit on runbot. Moved the `print_progress` in scripts inside the loop, so it doesn't try to `print_progress(..., 0)` and crash on a division by 0. The runner now takes care of logging 0% and 100%, along with the script name. Changed `-t/--test` for `--dry-run`, for consistency with other posix commands such as rsync. Made so it exits 1 when there are dirty files. Added a `--script` option to run a single script. Useful in development when we want to test a single script and not run all the scripts of a given version. Removed the default of `--from`, we couldn't agree on a sensitive default value. `--from` (or `--script`) is now required. Used mature `parse_version` from the tools, which is suitable to parse odoo versions. Added a long text that describes what "code upgrade" is. It is used as the module docstring and the --help description. Used cross-plateform \r instead of unix specific \033. Skipped `__pycache__` folders, not strickly necessary as `.pyc` files would nevertheless be skipped via `AVAILABLE_EXT`. Replaced some string manipulation on paths by pathlib.
Subscription billing now better coordinates invoice creation and payment processing to reduce conflicting updates during automated runs. This helps high-volume systems process recurring invoices and payments more reliably, with fewer interruptions from database conflicts.
Original PR description
Before this commit, amount_to_invoice was computed in the cron when the invoice was created as it depends on qty_invoiced. Unfortunately, the compute would be triggered and the ORM would try to write on the sale.order record at the same time than the cron would continue his job. it would end up with concurrent updates. This commit ensure that the compute method is inhibited during the cron and is triggered at the end of it. task 4216148
Salary configurator dropdowns such as company car, company bike, and spouse income can no longer be cleared to an empty value. This helps ensure compensation configurations remain complete and avoids missing information during salary package setup.
Original PR description
Problem ---------- Dropdown fields in the salary configurator (like company car, company bike or spouse income) can be set to null with the red cross Objective ---------- Set these fields non-nullable : remove the cross Solution ---------- Add the "is_required" field for benefits like in personal infos. Remove the not hidden condition for the personal info drop down. task-4188242
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