Monday, January 29, 2024
22 changes · 17.0
Resolved issues and error corrections
This fixes an issue where IoT devices could remain stuck in hotspot mode instead of joining a saved Wi-Fi network after startup. The connection process now uses the system network manager, improving reliability on newer Debian-based devices.
Original PR description
Use the NetworkManager to connect to wifi access point Why: In Debian bookworm the wpa_supplicant is no more used directly. wpa_supplicant is managed by the NetworkManager, as a consequence the script connect_to_wifi.sh fails its wifi connection and the IOT stay stuck in its access point mode. Before: When the IOT is powered, it seeks for network, cabled first, wireless second if it has the credentials in the file ~/wifi_network.txt If not cabled, and the wifi credentials are in ~/wifi_network.txt the IOT remains stuck in its access point Now: With the same configuration at power up, the IOT connect to the access point given in ~/wifi_network.txt mool --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users sending Mexican electronic invoices will now see a clear message if the company has no valid certificate instead of encountering a system error. This helps accounting teams understand what setup is missing and continue once the certificate is configured.
Original PR description
Currently, an error occurs when the user tries to send and print an invoice. Steps to produce: - Create a database without a demo and install `EDI for Mexico (l10n_mx_edi)`. - Go to Accounting >…
Currently, an error occurs when the user tries to send and print an invoice.
Steps to produce:
- Create a database without a demo and install `EDI for Mexico (l10n_mx_edi)`.
- Go to Accounting > Customers > Invoices > Click New
- Add Customer and Product > Confirm it
- Click `Send & Print` button > Click `Send & Print` in the send wizard
Stack Trace:
```
ValueError: not enough values to unpack (expected 1, got 0)
File "odoo/models.py", line 5830, in ensure_one
_id, = self._ids
ValueError: Expected singleton: res.company()
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 28, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "addons/account/wizard/account_move_send.py", line 712, in action_send_and_print
return self._process_send_and_print(
File "addons/account/wizard/account_move_send.py", line 657, in _process_send_and_print
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "addons/account/wizard/account_move_send.py", line 574, in _generate_invoice_documents
self._call_web_service_before_invoice_pdf_render(invoices_data_web_service)
File "home/odoo/src/enterprise/17.0/l10n_mx_edi/wizard/account_move_send.py", line 92, in _call_web_service_before_invoice_pdf_render
invoice._l10n_mx_edi_cfdi_invoice_try_send()
File "home/odoo/src/enterprise/17.0/l10n_mx_edi/models/account_move.py", line 1432, in _l10n_mx_edi_cfdi_invoice_try_send
self.env['l10n_mx_edi.document']._send_api(
File "home/odoo/src/enterprise/17.0/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1971, in _send_api
errors = root_company._l10n_mx_edi_cfdi_check_config()
File "home/odoo/src/enterprise/17.0/l10n_mx_edi/models/res_company.py", line 71, in _l10n_mx_edi_cfdi_check_config
self.ensure_one()
File "odoo/models.py", line 5833, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
This is because at [1], we get an empty record in the root_company because we have not added any valid certificates in the company setting. Before the refactor with https://github.com/odoo/enterprise/pull/45231 in V17, [2] is present, and it shows an error to the user.
This commit solves the above issue by showing a message to the user when a valid
certificate is not found in the company. Apart from that, this commit also adds
the certificate to the test case of the Mexican Localization Reports.
[1]-https://github.com/odoo/enterprise/blob/ba260fd4c87b0bf3575ccbffaad7aaca0696b047/l10n_mx_edi/models/l10n_mx_edi_document.py#L500 [2]-https://github.com/odoo/enterprise/blob/c87a8c51173bccbeffaecc0b4e5671d1a74f06c5/l10n_mx_edi/models/l10n_mx_edi_document.py#L129-L130
sentry-4719634588,4729692933,4729689997This update improves the reliability of Mexico's electronic invoice (CFDI) processing in Odoo. The changes fix issues where certificates were being checked multiple times unnecessarily, reduce errors when no certificates are configured, and standardize how the Mexican timezone is handled across the system. These improvements make the invoicing process more efficient and less prone to errors.
Original PR description
**[FIX] l10n_mx_edi: Remove reference to account_edi** **[IMP] l10n_mx_edi: Get the Mexican timezone from the same method.** The timezone is hardcoded at multiple places. It's less error prone to get the timezone everywhere from the same method. **[FIX] l10n_mx_edi: Don't fetch twice certificate + fix empty root_company** The certificate was fetched first when checking the config of the company, then when finding the certificate to use when processing the cfdi. Also, when we try to send a CFDI when no certificate are configurated, a traceback is raised. This is because the root_company is the one having some certificate. If no certificate, the root_company is empty and then, an ensure_one raises an error. sentry-4719634588,4729692933,4729689997
Users now receive a confirmation email when they cancel an appointment, providing proof that the cancellation was processed. This applies to both the person canceling the appointment and all attendees when the appointment is linked to a calendar meeting.
Original PR description
The author should always be notified when he cancels an appointment. The mail works as a proof that the cancellation has been taken into account. task-3505819 Forward-Port-Of: odoo/enterprise#55130 Forward-Port-Of: odoo/enterprise#47724
Fixed an issue where users could upload non-PDF files in the PDF split page, which caused the system to crash. Now the system only allows PDF files to be uploaded, preventing errors and improving the user experience.
Original PR description
Before this commit: When a user attempts to upload a file other than pdf in the PDF split page, it gives a traceback. After this commit: Now, user can only upload pdf files. Task-3613032 Forward-Port-Of: odoo/enterprise#55266 Forward-Port-Of: odoo/enterprise#52225
Users without Planning app access can now add timesheets to tasks linked to planning slots without encountering permission errors. The fix allows the system to properly recalculate planning hours during timesheet entry by using elevated permissions for internal calculations, while maintaining proper user access controls.
Original PR description
To reproduce on runbot: - Edit user 'demo' (Marc Demo): * remove access to 'Planning' app - Connect as 'demo' user - Go to app "Project", click on project "AGR" - Click on task "Senior Architect (Invoice on Timesheets)" (or any task linked to sale order line having some planning slots linked) in "Timesheet" tab, add a new line for: * Employee: Walter Horton * Description: implementation * Duration: 1.0 - Save An Access Error is shown: ``` Access Error Sorry, Marc Demo (id=6) doesn't have 'read' access to: - Planning Shift (planning.slot) ``` When encoding a timesheet we're going to recompute field `planning_hours_planned` which manually adds related planning.slot to be recomputed, some for which the user may not have the rights to read them; this commit set the `slot_properties` to be computed as sudo() to let the records recompute correctly. OPW-3691977 OPW-3695518
This update improves the performance of deleting attachments in large databases, which was taking up to 1 second per operation. The fix addresses slowdowns that occurred during routine tasks like asset generation or when removing records with attachments. This change makes these operations significantly faster, improving overall system responsiveness.
Original PR description
In large database when you unlink an attachment (during assets generate for exemple or unlink record with attachments) can be take 1 second. Forward-Port-Of: odoo/enterprise#54261 Forward-Port-Of: odoo/enterprise#54213
A recent update to the calendar view prevented start and end dates from being calculated properly when users toggled the all-day event option. This fix restores the automatic date calculation by adjusting how the all-day toggle button works, ensuring that event dates are computed correctly when users make changes.
Original PR description
In 17.0 the calendar view was revamped and the boolean field `all_day` started being rendered with the boolean_toggle widget. This widget, however, behaves differently than the boolean widget without passing explicit props. This caused the onchange call not to be made after this change. This commit fixes this by passing the autosave option as False on the field. task-3669879 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 corrects how the "small" text size option works in the website editor. Previously, small text appeared disproportionately tiny when used within larger text (like titles), which looked odd. The fix restores proper Bootstrap behavior where small text scales appropriately based on its context, while preserving the ability to create very small text when needed through new custom options. Some existing websites may see minor visual changes to how small text appears.
Original PR description
Before this commit, since [1], the "small" class behavior of Bootstrap was changed to use a fixed value instead of being dependent on the context (using `em` units). This was a bad choice, given the…
Before this commit, since [1], the "small" class behavior of Bootstrap was changed to use a fixed value instead of being dependent on the context (using `em` units).
This was a bad choice, given the fact that the "small" class could be used in the past with its previous behavior in custo but also in default Odoo layouts, where it could be use in more legit cases that the one Odoo currently offers: instead of applying the class to a whole paragraph, applying it to part of a title.
In that case, since [1], we can have a big title ... with a very small text next to it, which may be strange. Of course, the proper way to achieve a big title with a smaller text next to it would be to not use "small" but another hx font-size, but the legit bootstrap behavior which is to use their "small" class is thus broken.
This commit keeps the current possibilities (big title with very small text next to it) but does it by using new custom Odoo classes instead of changing the Bootstrap "small" one. That way, legit custo in previous versions (or trying to use default Bootstrap in this version) will be supported.
Note that this commit will impact existing 17.0 users though: if they actually configured a big title with small inner text... those will become big title with slightly smaller inner text (the default Bootstrap behavior). Worse: a big title whose size was reduced using the font-size selector and choosing "small" will now become a big title. We think this is worth the risk (see PR description for more visual details).
However, notice that "legit" use case of the "small" font-size in 17.0 will be kept untouched: e.g. adding a small text on its own or next to a paragraph: the "smaller" Bootstrap behavior is now computed based on the ratio of the configured base and small font-sizes.
Note that some additional "bugs" were found investigating this:
- Form descriptions use the "small" class for no reason and should probably not be possible to customize ("font style"-wise) anyway.
- The use of the "small" *tag* should probably be reviewed in all Odoo layouts and/or its interaction with the editor be fixed.
[1]: https://github.com/odoo/odoo/commit/194f73a9bbad8c3c3fb5c378e7bdfa704aaacdc0
| Before this PR | After this PR |
| -------- | -------- |
|  |  |
|  |  |
=> Legit use cases untouched, weird use cases impacted (should be rare, especially see also the weird margin-top in the second one), custo use case (@JKE-be 's case) solved.This fix resolves an access error that occurred when upgrading to version 17.0 if an administrator user was in a different company than their employee record. The system now properly allows administrators to access expense records during upgrades, since they have the authority to switch between companies anyway. This prevents upgrade failures for users with the appropriate permissions.
Original PR description
To reproduce: - Create an employee record for the connected admin user - Switch the user's company to another one (or the employee's company) - Upgrade to 17.0 A user who has the correct rights can…
To reproduce: - Create an employee record for the connected admin user - Switch the user's company to another one (or the employee's company) - Upgrade to 17.0 A user who has the correct rights can change his company anytime to see employees from other companies So it doesn't make sense to have access right error during an upgrade. In this line: https://github.com/odoo/odoo/blob/140e58c5a68db674fc1d240147e4d669b29f2cad/addons/hr_expense/models/hr_expense_sheet.py#L385 The call to parent_id.user_id fail upgrades to 17.0 if the parent and the user have different companies. Since Administrator-level users are not restricted, we put the check on that at the top to avoid errors during upgrades to 17.0. Note: in 17.1, it was made possible to have a manager from another company: https://github.com/odoo/odoo/pull/112768/commits/b841a24fc11cb83ca8e95fce7a83648d87cb90e3 Description of the issue/feature this PR addresses: Current behavior before PR: During upgrade, the Administrator doesn't have access rights to employees if he's not in the same company. Desired behavior after PR is merged: Since the admin can change companies to access other employees, it should not be blocking during the upgrade. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects how dates are calculated in the accounting module to properly account for each user's time zone instead of always using UTC. This was causing incorrect date handling for users in Latin America and other regions with negative time zones, which could lead to transactions being recorded on the wrong date.
Original PR description
Before this commit, the date was being considered in UTC instead of the time zone of the current user. This is problematic in LATAM, where the time zone is negative. Forward-Port-Of: odoo/odoo#150370 Forward-Port-Of: odoo/odoo#149971
This fix resolves a bug where orders would be repeatedly sent to the preparation display when reopening a table after navigating away. The issue was caused by incorrect variable reference in the order tracking system. Now orders are properly tracked and won't be resent unnecessarily.
Original PR description
Prior to this commit, when adding a product to an order, navigating back to the floor screen, and subsequently reopening the table, clicking on "Order" would send the order to the preparation display again. The issue stemmed from the fact that "this" was being added to "ordersToUpdateSet" in posStore, whereas "order" should be added to that set. opw-3687977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150674
This fix resolves an issue where product labels would not print for items measured in units other than the standard unit (such as grams). Previously, only products with standard unit measurements would appear in the label printout. Now all products, regardless of their unit of measure, will print correctly when generating labels from a transfer.
Original PR description
Steps to reproduces: - Create two products one with UoM units and the other grams - Create and confirm an SO with these two products - Set quantities and validate the transfer - Click "Print labels" Bug: only products with UoM units are printed because "quantity_by_product" is overwritten with only those products moved qty Fix: print a single label for the other UoMs opw-3676642 Forward-Port-Of: odoo/odoo#151192 Forward-Port-Of: odoo/odoo#150407
This fix resolves an error that occurred when updating contracts that don't have an employee assigned. The system now checks whether a contract has an employee before attempting to recalculate work entries, preventing crashes during contract management operations.
Original PR description
When updating contracts, work entries are recomputed automatically for the employee linked to that contract. However some contracts might not have an employee, which raises an error. Added a check to recompute work entries only if the contract has an employee. Task: 3614495 Forward-Port-Of: odoo/odoo#150932 Forward-Port-Of: odoo/odoo#148419
Fixed an issue where the text formatting toolbar would disappear when users moved their cursor away from selected text. Now the toolbar remains visible and accessible even when the cursor moves away from the selection, making it easier to apply formatting changes to selected content without losing the toolbar.
Original PR description
Current Behavior before PR: When we have some text in selection and we move away from the selection the the toolbar disappear. Desired behavior after this PR is megerd: The toolbar is still visible when we move far from the selected text. task-3054229 Forward-Port-Of: odoo/odoo#117645
The calendar system has been updated to notify appointment authors when important actions occur, such as when someone books or cancels an appointment. This ensures authors receive confirmation that their appointment actions have been processed successfully, improving visibility and reliability of the calendar system.
Original PR description
In some case, the author should be notified. For example, in the case someone books or cancels an appointment. The author should be notified as it's a proof that the action worked correctly. task-3505819 Forward-Port-Of: odoo/odoo#151099 Forward-Port-Of: odoo/odoo#136153
The HR dashboard was displaying all leave allocations regardless of whether they were currently valid, causing clutter with outdated leave types. This fix ensures only active and relevant leave allocations appear on the dashboard, providing employees with a cleaner and more accurate view of their current time-off options.
Original PR description
Before this commit, the displayed allocation on the dashboard were all the ones linked to allocations regardless of their validity period. This resulted with an overloaded dashboard with leave types that are not supposed to be displayed.
This fix resolves an error that occurred when trying to update the purchase quantity in a purchase order for subcontracted products after partial receipt and backorder cancellation. The system was incorrectly attempting to create a new picking when none was needed, causing the operation to fail. The fix prevents unnecessary picking creation, allowing users to successfully adjust purchase quantities in these scenarios.
Original PR description
**Steps to reproduce the bug:** - Create a storable product P1: - Create a BoM: - type: subcontracting - Add vendor - Add any component - Create a purchase order with 3 units of P1 - Confirm the…
**Steps to reproduce the bug:**
- Create a storable product P1:
- Create a BoM:
- type: subcontracting
- Add vendor
- Add any component
- Create a purchase order with 3 units of P1
- Confirm the purchase order
- Go to the picking
- receive 2 units of P1 and validate it
- create a backorder
- Cancel the backorder
- Try to update the purchased qty in the PO line
**Problem**:
A user error is triggered:
“Nothing to check the availability for.”
When updating the quantity in the purchase order line, the
"_create_or_update_picking" function is called to search for a linked
picking and update its quantity. However, in our case, since no picking
can be updated, a new picking is created:
https://github.com/odoo/odoo/blob/783048616362702f/addons/purchase_stock/models/purchase.py#L271-L272
Subsequently, the moves are confirmed:
https://github.com/odoo/odoo/blob/e38ed7c780d35fb9d5d799ac783048616362702f/addons/purchase_stock/models/purchase.py#L277
However, as the product is subcontracted, the "action_assign" function
is called: https://github.com/odoo/odoo/blob/4055293873132d56fe3787c77e499808b136f300/addons/mrp_subcontracting/models/stock_move.py#L105-L106
Since there is no move in the confirmed state, a user error is
triggered: https://github.com/odoo/odoo/blob/d45996c9155b9576c74aa8c6c6f718f8ab4d0af6/addons/stock/models/stock_picking.py#L450-L453
**Solution**:
When updating the quantity in the purchase order, if no picking requires
an update, it is better to avoid creating a new picking.
opw-3616381
Forward-Port-Of: odoo/odoo#150013This fix ensures that when images are displayed as embedded data (for private/non-public images), they now properly apply styling options like CSS classes that were previously being ignored. This makes embedded images display consistently with how they appear in other contexts.
Original PR description
Commit[1] implemented a way to output an image as its raw representation `<img src="data:image/png;base64......." />` It is useful for integrating an image of a record not accessible publicly. However the original commit forgot to allow the img node to handle the options passed to the field. Classes in particular were absent After this commit, the options are handled correctly, and the image in raw mode has the right classes. opw-3517861 [1]: f8b901d04b6c5874b56576f9b89899b2812296f2 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#151302 Forward-Port-Of: odoo/odoo#150140
This update fixes a bug where the moderation queue counter wasn't properly updating when moderators flagged forum posts. The issue occurred because a code reference wasn't updated when the underlying element was renamed. This ensures moderators now see the correct count of flagged posts that need review.
Original PR description
When flagging a post, moderators should see the flagged moderation queue counter appear/increment. We renamed the span in 21531bd9 and forgot to update this reference. Task-3349373 Forward-Port-Of: odoo/odoo#149645
This update fixes a configuration issue with Switzerland's VAT import tax that was causing system validation errors. The fix adds the required tax distribution lines that were missing, ensuring the tax system functions correctly for Swiss operations.
Original PR description
The tax with xmlid vat_0_import was missing its repartition lines which caused validation errors. This PR adds empty repartition lines to fix this problem. Forward-Port-Of: odoo/odoo#151052 Forward-Port-Of: odoo/odoo#150874
This fix resolves a compatibility issue that was preventing Odoo from running properly on Point of Sale IoT devices. By updating the cryptography module to version 36.0.2, the system will now work correctly on IoT hardware for Odoo versions 15, 16, and 17.
Original PR description
Currently the version of the cryptography module installed with the version of pyOpenssl 22.0.0 does not allow the execution of the Odoo server on the iot for versions 15, 16 and 17. With this change we explicitly give the version of the cryptography module 36.0.2 which corrects this problem. 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