Friday, January 23, 2026
37 changes · saas-19.1
New functionality added to Odoo
This update adds support for the Caribbean Guilder (XCG) as a new currency option within Odoo. It's specifically configured as the default currency for Curaçao and Sint Maarten, expanding Odoo's currency coverage to include these regions. This change allows users to accurately record financial transactions in XCG.
Original PR description
Introduce the Caribbean Guilder (XCG) as an available currency and set it as the default currency for Curaçao and Sint Maarten. Related PR-https://github.com/odoo/enterprise/pull/104404 taskID-5490423 Forward-Port-Of: odoo/odoo#243955
This update introduces support for the Caribbean Guilder (XCG) currency in Odoo Enterprise. It’s now the default currency for Curaçao and Sint Maarten, aligning our financial data with the latest community standards. This change ensures accurate reporting and transactions for businesses operating in these regions.
Original PR description
Align enterprise currency data with the community with addition of new currency XCG. Related PR-https://github.com/odoo/odoo/pull/243955 taskID-5490423 Forward-Port-Of: odoo/enterprise#104404
Resolved issues and error corrections
This update corrects a problem where the avatar card didn't accurately display the user's local time when viewing from different time zones. The fix ensures that the avatar card correctly reflects the user's timezone, improving the user experience across different locations. This was a minor bug impacting how users perceive time-sensitive information.
Original PR description
The `Avatar card shows local timezone` ensure partner local time is shown in the avatar card when the user that consults it has a different tz. This test also ensures that nothing is shown when timezone are the same. However, the assertion expects to find the node containing the text in the DOM while it's not rendered when both tz are the same. This commit fixes the issue. runbot-238383 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 update fixes an issue where role mentions would disappear when editing messages in Odoo. The fix ensures that role mentions are correctly preserved during the editing process, improving communication and collaboration within the system. This resolves a previous bug that prevented users from accurately referencing team members in their messages.
Original PR description
**Current behavior before PR:** Editing a message with a role mention would cause the mention to be lost. **Desired behavior after PR is merged:** Role mentions are now preserved when editing a message. task-4702960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245080 Forward-Port-Of: odoo/odoo#218992
This update fixes an issue where keyboard navigation within the website builder's image cropping tool was unreliable. Now, users can properly validate or dismiss the cropper using keyboard shortcuts (Enter/Escape), improving the user experience and accessibility. This ensures a smoother workflow for editing website images.
Original PR description
Steps to reproduce: - Select an image in the website builder. - Open the cropping tools. - Press Enter. - Try to discard the cropper. Before this commit, focus stayed on the toolbar crop button so `Enter` opened another cropper, `Escape` closed the sidebar, and the cropper buttons were not reachable via keyboard. After this commit, the cropper grabs focus and handles `Enter/Escape` itself so keyboard interactions validate or dismiss the cropper. task-5432043 Forward-Port-Of: odoo/odoo#244484 Forward-Port-Of: odoo/odoo#240910
This update prevents duplicate 'Applicant created' messages appearing in the recruitment chatter when a new applicant is added. The previous system was creating the same log entry multiple times, leading to a cluttered view. This change ensures a cleaner and more accurate record of applicant creation events.
Original PR description
Steps to reproduce: 1. Create a new applicant in recruitment. 2. Open the applicant’s chatter. 3. See multiple “Applicant created” messages for the same creation. Bug cause: The applicant creation flow posts the `mt_applicant_new` subtype more than once (create + extra write/track), and the frontend renders the subtype description, so each duplicate post shows “Applicant created” again. Solution: - Post the `mt_applicant_new` subtype only once during applicant creation. - Avoid re-posting it in subsequent writes/tracking so chatter shows a single creation log. Task Id: 5454691 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 update fixes an issue where test bank statement imports created actual records in the database, even when the test failed. The change ensures that test imports don't trigger reconciliation processes, preventing unintended data creation. This improves the reliability of the test environment.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to Accounting dashboard 1) - On "Bank" journal card, select "Import File" option in dropdown menu - Upload a file containing a lot of statements…
**Steps to reproduce:**
- Install Accounting
- Go to Accounting dashboard
1) - On "Bank" journal card, select "Import File" option in dropdown menu
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
2) - Open "Bank" journal
- Select "Import records" in the cog menu
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
3) - Open "Bank" journal
- Click on "Upload" button
- Upload a file containing a lot of statements (e.g. more than 170)
- Test the import with "Test" button
**Issue:**
The issue happens when the test import fails.
Even if it was a test, all the records are created in the database.
**Cause:**
During a test import the records should not be reconciled after creation.
However, by default, "auto_statement_processing" property is True and trigger the reconciliation.
When an error is raised during the test import, a rollback is made on a previous savepoint.
But a commit can be done in "_cron_try_auto_reconcile_statement_lines" method, which results in the records being created for real.
**Solution:**
Set "auto_statement_processing" property to False for Test import.
For use case 1) and 2), we make sure that we follow the same flow than use case 3).
opw-5436937
Forward-Port-Of: odoo/enterprise#104954This update fixes an issue where link styles within the HTML Editor were not consistently inheriting font sizes. Now, links automatically inherit the font size from their parent elements, creating a more visually aligned and user-friendly experience. This change prepares for a future update that will remove a specific styling variable, simplifying the design.
Original PR description
Ensure that a simple link can inherit from an ancestor `font-size` defined using the Editor toolbar, overriding the `mass_mailing` Design Tab `--link-font-size` special variable. That variable will be removed in the future, because it is more natural that a link font-size is aligned with its container. task-5868086 Forward-Port-Of: odoo/odoo#245225
This update ensures that admin users retain their intended default options when reviewing courses, regardless of edits or deletions made by other users. This prevents unintended changes to review settings and maintains a consistent experience for administrators. The change was previously addressed in another PR but has been re-implemented to avoid code duplication.
Original PR description
*: website_slides The default values for the admin user should not be changed by editing or deleting others' messages in courses. task-5326273 Forward-Port-Of: odoo/odoo#245127 Forward-Port-Of: odoo/odoo#236475
This update resolves an issue where the invite input field automatically gained focus, disrupting other dialogs like the call permission dialog. Now, the input only focuses when it's active and the user is interacting with the system. The code has also been reorganized for better testing.
Original PR description
**Current behavior before PR:** - The invite input always tried to autofocus, in turn stealing focus from dialogs like the call-permission dialog. **Desired behavior after PR is merged:** - Autofocus only when the input exists and the context is active. - Moved `mockPermissionsPrompt` to `mail_test_helpers`. **Part of task-**[5227387](https://www.odoo.com/odoo/project/1519/tasks/5227387) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236248
This update improves the speed at which scale readings are delivered, particularly in Point of Sale (PoS). By directly returning the scale result upon the initial action, the system now provides weight data immediately when the 'get weight' button is pressed. This enhances the user experience and efficiency.
Original PR description
In order to get the first scale weight faster, we now return the result directly on the action call. This also fixes the get weight button in PoS as it will now actually provide the weight.
A recent test for our live chat feature was intermittently failing due to a timing issue during high load. This change increases the test's waiting period to ensure it correctly identifies the expected behavior. This improves the reliability of our live chat testing process.
Original PR description
The `Only two quick actions are shown` live chat test awaits the first posted message because to avoid conflict with the reaction being added afterwards. To do so, the test uses the `waitForSteps` helper. However, during high load, 200ms might be too short to receive the notification, leading to the test failing. This commit increases the timeout. runbot-237587 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 update resolves a technical issue that could cause Odoo upgrades to fail when setting up manual one-to-many fields. The fix ensures that Odoo properly checks if the related inverse field is set up before processing, preventing a 'KeyError' and ensuring smoother upgrades. This improves the stability and reliability of Odoo installations.
Original PR description
When ``setup`` a manual one2many field, if its ``inverse_name`` field hasn't been ``setup`` and is also a manual field which might be ``pop`` when ``setup``, the one2many field can be ``setup`` successfully. But when computing ``setup_inverses`` when ``init_models``, the ``inverse_name`` will cause a ``KeyError``. ``invf = registry[self.comodel_name]._fields[self.inverse_name]`` Reproduce: see https://github.com/odoo/odoo/pull/240085 This commit simply checks the ``setup`` for the inverse field of the one2many field. 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 Forward-Port-Of: odoo/odoo#245240
This update fixes an issue where employee appraisals weren't automatically selecting the correct company template when the employee lacked a department. The fix ensures that appraisals consistently use the appropriate template based on the employee's company, improving appraisal accuracy and consistency. This resolves a previous bug impacting appraisal setup.
Original PR description
### Issue: When having a template with a company but no department, it's not selected by new appraisal. ### Steps to reproduce: - Have an employee whose appraisal date is today. - Have only one…
### Issue: When having a template with a company but no department, it's not selected by new appraisal. ### Steps to reproduce: - Have an employee whose appraisal date is today. - Have only one template, with the company of the employee but no department - Run the cron "Appraisal: Run employee appraisal" - Open the Appraisals app - Click on the newly created appraisal - It doesn't have the template ### Cause: - In `_compute_appraisal_template()`, only the department of the appraisal is used to compute the template. But `_create_new_appraisal()` doesn't include the department in `appraisal_values` to create the appraisal. So `appraisal.department_id` is `False` and the template from the department is ignored. - Another issue is if the employee has no department, then the appraisal also has no department. Then no template is selected by the search domain. ### Solution: - Include `department_id` in `appraisal_values` - Modify the search domain to include the case where the appraisal has no department opw-5477450 Forward-Port-Of: odoo/enterprise#104470
This update fixes a display issue in the appointment calendar for Ukrainian and Polish users. Previously, month names were shown in the genitive case, which is incorrect. The fix ensures month names are displayed in the nominative case, aligning with standard calendar conventions and grammatical rules.
Original PR description
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word…
In the appointment calendar, the "Month Year" (e.g. January 2026) is displayed at the top of the calendar selector as is standard for calendars. Unfortunately in some languages, the word month word used depends on grammatical situation. Steps to reproduce: - activate Ukrainian (or Polish) language - Preview (i.e. the website view) of any appointment - Change the preview into Ukrainian (or Polish) Expected result: Calendar month at top of calendar is shown in the nominative case: e.g. January 2026 = січень 2026 (in Ukrainian) Actual result: Calendar month is shown in the genitive case (e.g. "of January", as in "the 12th of January): e.g. January 2026 = січня 2026 (in Ukrainian) Fix is to switch from the "MMMM Y" format (i.e. month based on grammar context) to "LLLL Y" (i.e. stand alone month) which will use the correct month case. Ref: https://www.unicode.org/reports/tr35/tr35-dates.html#dfst-month Note that for most languages this won't make a difference since there is usually only 1 way of writing a month. opw-5474705 picture diff (for January 2026): before fix: <img width="1168" height="468" alt="image" src="https://github.com/user-attachments/assets/36754439-e664-40f3-9c5b-7c9c76cd7cca" /> after fix: <img width="1215" height="492" alt="image" src="https://github.com/user-attachments/assets/82f0665e-fe70-4b9f-b1d4-f420b52db38f" /> Forward-Port-Of: odoo/enterprise#104942
This update ensures that the demo data used in the product expiry tests is specific to the test environment, rather than relying on the main Odoo demo data. This resolves a test failure and provides more reliable results for developers working on this module. It's a minor fix that improves the stability of the testing process.
Original PR description
Use test specific data instead of relying on demo data. Runbot Error : [232852](https://runbot.odoo.com/odoo/runbot.build.error/232852?debug=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229730
This update optimizes the Odoo database by removing unnecessary default settings in the Spanish accounting module (l10n_es_edi_facturae). This reduces data storage and improves performance, particularly for businesses with multiple companies using different localization settings. The change ensures correct handling of user-defined values, maintaining data integrity.
Original PR description
On multi-company databases, having the defaults value on `account.move` selection fields unnecessary bloat the database for other companies with different fiscal package (localization). Moreover those two selection fields (`l10n_es_payment_means` and `l10n_es_edi_facturae_reason_code`) are not required, meaning the user can still set the value to `False` and we must be sure to handle that case anyway. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242539
This update resolves an issue where rapid receipt printing via USB printers occasionally caused errors. The fix prevents multiple threads from accessing the printer simultaneously, ensuring reliable ESC/POS printing. This improves the overall stability of receipt generation.
Original PR description
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS…
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS status ERROR ? root: Could not set configuration: [Errno 16] Resource busy ``` This would cause `python-escpos` to be disabled and fallback to just CUPS printing. The issue was caused by two threads trying to access the printer at the same time, which could happen in two ways: - IoT thread with `python-escpos` and CUPS try to access the printer at the same time. - Two IoT threads with `python-escpos` try to access the printer at the same time (this can happen if two receipt actions are received at the same time). Both of these scenarios should now prevented: - Now, if we are using `python-escpos`, we also use it to print the receipt as well as checking the status. CUPS is never used so there should be no interference from it. - We now have an `escpos_lock` (per printer, not global) that is acquired when accessing the printer via `python-escpos`. This ensures that different threads cannot both try to access the printer at the same time. task-5490942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244370 Forward-Port-Of: odoo/odoo#244031
This update fixes a bug that prevented portal users from another company from being mentioned in chat conversations. The issue stemmed from how access permissions were handled based on the currently active company. The fix ensures that portal users can be mentioned regardless of the company they belong to, improving collaboration across integrated accounts.
Original PR description
* = test_discuss_full Before this commit, mentioning a portal user from another company would result in an access error. Steps to reproduce: 1. Install `hr_holidays` module. 2 Have a portal user in company A. 3. Switch the active company to company B. 4. In any chatter, try to mention said portal user. This happens because portal user read access depends on the current active company (see `res_users_rule`). The access error happens since [1], which added user information to the partner's default Store fields. [1] https://github.com/odoo/odoo/pull/212173 task-5499827 Forward-Port-Of: odoo/odoo#245224
This update aligns a small icon used in the Odoo Enterprise SaaS subscription visuals with established design guidelines. Ensuring consistency in our branding materials strengthens our overall professional image and user experience. This is a minor visual improvement.
Original PR description
This `network_light.svg` wasn't quite aligned with Milky picto's design guidelines. In this PR the pictogram has been tweaked in order for it to follow the guidelines. task-5126719 Forward-Port-Of: odoo/enterprise#104356 Forward-Port-Of: odoo/enterprise#95895
This update resolves an issue preventing proper employee filtering within the l10n_ch_hr_payroll module. By using 'sudo' for filtering, the system now reliably processes payroll data regardless of the user's specific role (Payroll or Assistant). This ensures consistent and accurate payroll processing.
Original PR description
We perform the filtering with sudo so that it can be done even in cases where the user is not a Payroll/Assistant. This is primarily to fix the following runbot error, but in general to avoid blocking errors where they shouldn't happen. Runbot Error: 237851
This update fixes a bug that prevented users from successfully uploading attachments to expense records. The issue stemmed from a restriction in how Odoo handles attachment records, specifically when an attachment wasn't linked to an expense. The fix ensures attachments are correctly associated with expenses, improving the user experience.
Original PR description
Currently, an exception occurs when a user tries to open expenses or upload an attachment on expenses after following the steps described below. - Create an attachment with an `image/PDF` file and set the resource model as `hr.expense` - Go to expense > Create a new expense and upload the same `image/PDF` file This issue occurs because when a user creates an attachment without specifying a `res_id`, it defaults to `0`. In the previous version, `0` was allowed in the record set. However, after the changes introduced in [1], `falsy` values like `0` are strictly disallowed in the record set. This commit fixes the issue by reading only the `read_group` attachments that have a valid `res_id`, effectively ignoring attachments without a `res_id`. [1]: https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f sentry-7201563878
This update resolves an issue where incorrect data IDs within Odoo could trigger errors. The fix adds a filter to ensure all IDs used for browsing `ir.model.data` are valid, preventing potential disruptions to the system. This improves stability and reliability.
Original PR description
Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields:…
Since https://github.com/odoo/odoo/pull/227477, using falsy ids ids illegal
This commit adds an additional filter to the domain used to browse `ir.model.data` to compute the following fields: `(menus|views|reports)_by_module` in order to avoid selecting any that would contain a falsy `res_id` and thus cause the above-mentioned assertion to fail.
One way to reproduce this in a new trial:
- Create a new trial with several modules: `account`, `crm`, `project`, `sales`
- Install `web_studio`
- Uninstall `base_automation`
- Traceback
```
File “/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py”, line 5200, in browse
assert all(ids) or all(isinstance(x, NewId) or x for x in ids), “Invalid falsy real id”
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```
This is due to an `ir.model.data` containing a falsy res_id in the internal code of `saas_trial` (`installed-17`)
This fix will avoid any additional traceback like this one.
opw-5865316This update resolves a minor UI issue related to the ActivityWatch timesheet download screen within the Enterprise version of Odoo. The fix ensures a smoother and more reliable user experience when downloading timesheet data. This improves the usability of a key reporting feature.
Original PR description
This PR fixes some minor stuff that didn't make it into the previous PR.
A technical error preventing mail template creation was fixed. The issue stemmed from a validation process unaware of rental order functionality, causing a template creation failure. The fix involved moving a necessary method to the `sale_renting` module to ensure compatibility.
Original PR description
The mail template `mail_template_sale_cart_recovery` creation fails in some cases if there is a rental order in the database. Indeed, during a template creation, the first record of the corresponding model is used to validate the template validity. In this case, the template is only meant for e-commerce orders and there won't be any e-commerce rental order without `website_sale_renting` but the validation is not aware of functional specificities, leading to a traceback because the method `_get_rental_pricing_description` doesn't exist when only `sale_renting` and `website_sale` are installed. To avoid this error, we move the method to `sale_renting`, even though there is no real life flows where this was breaking (except templates validation ofc). Was fixed first with c3f5dafa23a8b1fd36eaedd83a575b717e5e9377 but moved back into `website_sale_renting` by mistake with fd1d7f91e7e60a20a5401201ff89a7e875faad82
This update fixes a warning message appearing in Point of Sale when expiration dates are disabled. The issue stemmed from a missing field in the product data, preventing accurate lot number retrieval. The fix ensures the system correctly handles this scenario, improving the user experience.
Original PR description
Steps to reproduce: = - Install only `point_of_sale` with demo data. - Ensure `Settings->Inventory->Traceability->Expiration Dates` is unchecked. - Open POS. - Click a product that uses lots. Issue: = - PoS always shows the warning “The existing serial/lot numbers could not be retrieved. Continue without checking the validity of serial/lot numbers?” even though lots are available. - Terminal error:`AttributeError: 'stock.lot' object has no attribute 'expiration_date'` Reason: = - When *Expiration Dates* is unchecked and the `product_expiry` module is not installed, the `expiration_date` field is not available (it is defined in `product_expiry` module by inheriting `stock.quant` model). Fix: = - Check field existence using the model’s _fields registry before accessing `expiration_date`, to prevent traceback. runbot-234958, 234959, 234960, 234961, 234964
This update resolves an issue where enlarging icons in the bills list view also disrupted the layout of the invoicing dashboard. The fix utilizes a new setting to display larger icons only when needed, ensuring a consistent and professional appearance for users.
Original PR description
As a part of task-5258726 the icons of no-content help in bills list view were enlarged. The icons used there were also used in the module dashboard, so enlarging them messed the dashboard styling. This commit fixes this issue by using a prop `largeIcons` on the `BillGuide` componenet to make it with large icons when needed only (in the bills list view no content help). task-5801970 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245209
This update resolves an issue where the website's cookie consent settings weren't being saved correctly after changing the 'I agree' button style to 'Default'. The fix ensures that the user's consent is properly recorded when this style change is applied, maintaining consistent cookie consent management.
Original PR description
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape…
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape to "Default" (this applies the `.btn-primary` class). & Save 4. Accept the cookies & refresh -> The cookie bar appears again because the consent was not saved. Cause: ====== The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup. By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written. Solution: ========= Override the event to avoid side effects on hide. opw-5484578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244875 Forward-Port-Of: odoo/odoo#243562
This update fixes a potential discrepancy in tax reporting within the Point of Sale module. Previously, the total tax base amounts in reports could slightly differ from the sum of individual line items due to rounding. This change ensures more accurate tax calculations and reporting, improving the reliability of financial data.
Original PR description
Before this commit, the total base amounts of taxes might be different from summing the base amounts of each line, due to rounding issues. opw-5408201 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244280
This update fixes a potential issue in the Point of Sale reporting where rounding errors could incorrectly identify small cash differences as non-zero. Previously, the system didn't account for currency rounding, leading to inaccurate cash difference calculations and unintended removal of transactions. This ensures more precise reporting of cash flow.
Original PR description
Before this commit, when calculating the cash difference in the report, the code did not account for currency rounding. This could lead to situations where a very small cash difference, due to rounding errors, was not recognized as zero, resulting in the unintended removal of cash moves. opw-5489958 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245251
This update addresses a technical issue preventing Odoo from correctly importing a standard exception within the Requests library. The fix involves installing a specific version of Requests and adding a necessary import statement. This resolves an error that was caused by a recent change in the Requests library itself, ensuring Odoo continues to function smoothly.
Original PR description
Installing `requests==2.25.1` and using the following line of code:
from requests.exceptions import JSONDecodeError
It raises the following error:
ImportError: cannot import name 'JSONDecodeError' from 'requests.exceptions' (python3.10/site-packages/requests/exceptions.py)
It was removed from the following commit in the `requests` package:
https://github.com/psf/requests/commit/db575eeedcfdb03bf31285afd3033e301df8b685
This change fixes this error importing the original exception from `json` package
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
Forward-Port-Of: odoo/odoo#245075This update prevents excessive email notifications to managers when employees submit expenses. Previously, managers received emails for every state change, which was causing spam. Now, a weekly email is only sent if a manager has outstanding expenses awaiting approval, streamlining the approval process and reducing unnecessary communication.
Original PR description
When an employee submits an expense and assigns a manager, an approval activity is scheduled. However, email notifications are now disabled to avoid spamming the assigned managers. * Prevent notifying the expense manager when expense state changes. * Email 'Next expense is waiting your approval' is scheduled to be sent to the manager once a week if the manager has any expenses left to approve. task-4676396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244995 Forward-Port-Of: odoo/odoo#210614
This update fixes a situation where quality checks wouldn't display a helpful message if no IoT device was connected. Now, users will receive a notification when a quality check requires an IoT device and one isn't configured, preventing confusion and ensuring accurate data collection.
Original PR description
We now display a notification when no device is configured for a measure quality check. opw-5409775 Forward-Port-Of: odoo/enterprise#105207
This update improves the product information displayed in the Point of Sale system. It now includes the product's internal code (default_code) in the product name shown in the product info popup, making it easier for staff to identify and track products. This change enhances clarity and efficiency within the sales process.
Original PR description
This commit adds the default_code (internal reference) to the display name of the product in the product info popup. opw-5493827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244068
This update resolves a bug that prevented website tour tests from running correctly when the header template was changed to 'Sidebar'. The fix ensures the Website Builder remounts properly before the tour continues, preventing the builder from resetting to its initial state and disrupting the test flow.
Original PR description
When changing the header template to 'Sidebar', the loading screen disappears but the WebsiteBuilder component remounts asynchronously. If the tour proceeds to the theme tab before the remount completes, the builder resets to the Edit tab (its initial state), breaking the test flow. We wait for the builder to remount, and add `.editor_enable` class to the body of the iframe, so then nothing disrupts the flow. runbot-234504 Forward-Port-Of: odoo/odoo#245271 Forward-Port-Of: odoo/odoo#243518
This update resolves an issue where users would encounter errors when uploading corrupted or encrypted PDF files for quotation document headers and footers. The fix prevents the system from crashing when encountering these files, ensuring a smoother user experience when creating quotes.
Original PR description
Currently, an error occurs when uploading `encrypted or incomplete` PDF files (missing EOF marker) while creating a quotation document header or footer. **Steps to reproduce:** - Install the…
Currently, an error occurs when uploading `encrypted or incomplete` PDF files (missing EOF marker) while creating a quotation document header or footer. **Steps to reproduce:** - Install the `sale_pdf_quote_builder` module. - Navigate to: Sales > Configuration > Headers/Footers. - Upload encrypted file [1], or incomplete file [2]. **Error:** `PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm` `PyPDF2.errors.PdfReadError: EOF marker not found` **Root cause:** At [3], `_get_form_fields_from_pdf` and `_ensure_document_not_encrypted` directly call `pdf.PdfFileReader`, when it fails to read or decrypt the file, Python raises an error. **Fix:** This commit prevents errors when users upload unreadable or encrypted PDF files. [1]: https://drive.google.com/file/d/1moSlwXHkqcV6_7zHBNhLMLi-9Ye_xDGJ/view?usp=sharing [2]: https://drive.google.com/file/d/16O4LLH8dL0RWmbOx4HrcooFUyesWaVi-/view?usp=sharing [3]: https://github.com/odoo/odoo/blob/694f1d0fb03b56dd41a59eb676e56622634cc91b/addons/sale_pdf_quote_builder/utils.py#L11 sentry-6928220164 opw-5227601 Forward-Port-Of: odoo/odoo#245264 Forward-Port-Of: odoo/odoo#230712
This update resolves an issue where internal users without sales permissions would encounter errors when accessing their sales orders through the /my page. The change mirrors a previous fix, ensuring a smoother experience for all users within the Odoo system. This improves stability and prevents potential disruptions to sales workflows.
Original PR description
Avoid error when internal user (no sale permissions) see Orders at /my Similar to https://github.com/odoo/odoo/commit/5ebab949a06ec338cc28e912317a74bbfb3fe6ac @Tecnativa TT60025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245039