Daily updates from Odoo
Wednesday, November 27, 2024
16 changes
1 change
Resolved issues and error corrections
This update fixes display and scrolling problems in the email editor used by Email Marketing and Marketing Automation. Users should have a smoother editing experience, with the snippet sidebar no longer hiding scrollbars, overlapping content, or extending beyond dialogs.
Original PR description
This PR fixes multiple issues related to the mass_mailing_html_field used in `marketing_automation` and in `mass_mailing` modules. 1) The iframe scrollbar is hidden behind the snippets sidebar in fullscreen mode - concerns: mass_mailing, marketing_automation 2) In fullscreen mode, the iframe is not scrollable while dragging a snippet from the sidebar - concerns: mass_Mailing, marketing_automation 3) The snippets sidebar overlaps with the content - concerns: mass_mailing, marketing_automation 4) The snippets sidebar height in a dialog is too big - concerns: marketing_automation See individual commits for further explanation. task-4178640 Co-authored-by: Astik Singh <assi@odoo.com> Co-authored-by: Damien Abeloos <abd@odoo.com> Co-authored-by: Mahdi Cheikh Rouhou <macr@odoo.com> Co-authored-by: Shubham Thanki <shut@odoo.com>
3 changes
Resolved issues and error corrections
Amazon order processing tests now fail clearly when an order-processing error occurs instead of hiding it through an automatic rollback. Test data was also corrected so invalid Amazon order identifiers are caught, improving confidence that Amazon sales workflows behave as expected.
Original PR description
While testing, if we get an error while trying to process an order, `rollback` is called, we prevent this by raising the exception. Moreover, in the test data, the AmazonOrderId was a dict instead of a string, that error was silently ignored (test passed, but shouldn't).
This update adjusts an internal timesheet test after company-based employee access rules were restored. It helps ensure timesheet functionality continues to be validated correctly in multi-company setups, with no direct change expected for everyday users.
Original PR description
This reverts commit 73223682daaaa6d2ed2f062705917a59716209b4 since the multi-company rule in `hr.employee` and `hr.employee.public` models has been re-introduced.
Fixes the bulk approval action for time off allocations that require two approvers, so requests in the first approval stage now move forward as expected. This helps managers process employee leave allocations reliably without manual workarounds or stalled requests.
Original PR description
Steps to reproduce the bug: 1. Create a new time off type and set `approval` to By employee's approver and time off officer. 2. Create a new allocation: * Use the time off type created above. * Set the number of days to 20. 3. Save the created allocation. 4. Go to `Management -> Allocations`. 5. Select the created allocation and press on the actions cog. 6. Press on `Approve Allocations`. 7. The allocation state doesn't change to `second approval`. The action `Approve Allocations` doesn't take into account the allocations that are in the first stage of approval. To fix the issue, `Approve Allocations` action is updated to take these allocations into account. Also, `action_validate` and `action_approve` are both now being combined into `action_approve`. task-4207884
9 changes
Resolved issues and error corrections
This fixes an issue in automated website editor walkthroughs where actions could lose track of earlier input changes between steps. Keeping the action context consistent from the start makes these tours more reliable and helps prevent false test failures around link editing.
Original PR description
The setupEventActions defines an element (environment) in which the history of actions is retained. If this element changes at each step of the tour, then it is for example not possible to "blur" a previously altered input. This environment must be defined at the beginning of the tour.
The portal chatter setup no longer shows an error just because a user cannot access a related discussion at initialization. Access is still checked when messages are actually loaded, reducing false failures while preserving the normal permission checks.
Original PR description
Since the `chatter_init` route is only responsible for checking the valid partner in the case of a public user, there is no need to raise `NotFound` if there is no access to the thread. Checking for access to the thread and raise if it's needed is done when fetching the messages. reported on [this build error](https://runbot.odoo.com/web/#id=99087&menu_id=405&cids=1&model=runbot.build.error&view_type=form)
This fix ensures that when inventory tracking is disabled for a product, the hidden Lot/Serial Number valuation setting is also turned off. This prevents confusing receipt errors that incorrectly ask users to enter serial numbers for products that are no longer tracked.
Original PR description
**Steps to reproduce the bug:**
- Create a storable product “P1”:
- Set it to be tracked by Serial Number (SN).
- Enable Valuation by Lot/SN.
- Save.
- Disable inventory tracking.
**Problem:**
The Valuation by Lot/SN option becomes invisible but is not actually disabled. For example, when processing a receipt, a user error occurs, requiring a serial number to be set.
opw-4330877This fix prevents an error when a point of sale receipt printer connected through an IoT box is unavailable and staff choose browser printing instead. The receipt should now open the browser print dialog as expected, helping sales continue without interruption.
Original PR description
Introduced in #184138. When you try to print a receipt using an IoT box that isn't available, there is the option to print using the browser as a fallback. However, clicking this option produces a traceback. Steps to reproduce: - Configure a POS to use an IoT Box Receipt Printer (e.g. the default [Shop] Receipt Printer) - Make sure the IoT box is not reachable - Make an order and try to print the receipt, it should fail and the dialog will appear asking if you would like to use the web printer - Select OK, and a traceback will appear Expected behaviour: - There is no traceback and the browser printing dialog appears --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could stop users from sending point-of-sale receipts through WhatsApp. The receipt-sending flow now handles the expected receipt image information correctly, helping staff share receipts without interruption.
Original PR description
Currently, an exception is generated when the user tries to send a POS order receipt on WhatsApp. Error ``` TypeError: PosOrder.action_sent_receipt_on_whatsapp() takes 3 positional arguments but 4…
Currently, an exception is generated when the user tries to send a POS order receipt on WhatsApp.
Error
```
TypeError: PosOrder.action_sent_receipt_on_whatsapp() takes 3 positional arguments but 4 were given
File "odoo/http.py", line 2363, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
```
This is because of the recent refacre code with the commit [1]. method `_sendReceiptToCustomer` calls Python RPC where 4 arguments passed see [2], but the Python method was not dapted with chages of commit [1].
This commit fixes the above issue by setting `ticket_image` and `basic_image` as optional arguments and adapting the Python method according to these changes.
[1] - https://github.com/odoo/odoo/commit/47ec8957334aa37fd9b1d2267681fbd44064809f
[2] - https://github.com/odoo/odoo/blob/2eec78d10380893bd9dbfcef407de50c231cc3bb/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt_screen.js#L111-L116
sentry-5662499209
Related ent PR- https://github.com/odoo/enterprise/pull/74145Scanning a package during an internal transfer now uses the package's actual stock location instead of the broader source location. This prevents validation errors when packages are stored in sublocations and makes barcode transfers more reliable.
Original PR description
### Before this PR: If you create new internal transfer with src location WH/Stock and than you scan a package that is on a sublocation of WH/Stock , the source location on the line is not set as the location of the package so when you validate in this situation an error pops because Odoo try to take the package from a different location of the package ### After this PR: The right location id is taken from the stock.quant and put on the line created
The Gantt view now handles cases where certain time scales, such as month or year, are not available but still selected. This prevents users from seeing a crash and keeps planning views usable with customized configurations.
Original PR description
The attribute scales of the gantt view specifies which scales are available in the view. This means that for instance "year" or "month" can be absent from scales. If that happens and that "year" or "month" is the selected range, a crash occurs when rendering the GanttRendererControls component:
TypeError: Cannot read properties of undefined (reading 'groupHeaderFormatter')
Here we assign to each range a function groupHeaderFormatter so that we can call it independently from the available scales.Users can now create loans with a 0% interest rate without running into an error during calculation. This helps accounting teams accurately record interest-free loans and avoids a blocker in the loan setup process.
Original PR description
Problem: Users are not allowed to set a zero interest rate on a loan. Steps to reproduce: 1. Go to accounting accounting > loans > new 2. Set any name and any amount in the borrowed field 3. Click on Calculate 4. Set interest rate to 0% and click Apply Explication: The library we were using "loanpy" does not handle the case where the interest rate is zero if the loan_type is `annuity`, and we ended up dividing zero by zero, throwing an error. The fix: If the interest is zero, we override the loan's type from `annuity` (the default) to `linear`, as the linear formula is better suited for the zero interest case. opw-4298272
Fixes an issue that caused an error when sending point-of-sale receipts to customers through WhatsApp. This restores the expected receipt sharing flow for cashiers and avoids failed customer communications after checkout.
Original PR description
Currently, an exception is generated when the user tries to send a POS order receipt on WhatsApp. error: ``` TypeError: PosOrder.action_sent_receipt_on_whatsapp() takes 3 positional arguments but 4…
Currently, an exception is generated when the user tries to send a POS order receipt on WhatsApp.
error:
```
TypeError: PosOrder.action_sent_receipt_on_whatsapp() takes 3 positional arguments but 4 were given
File "odoo/http.py", line 2363, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
```
This is because of the recent refacre code with the commit [1]. method `_sendReceiptToCustomer` calls Python RPC where 4 arguments passed see [2] but the method `action_sent_receipt_on_whatsapp` of `whatsapp_pos' is not dapted with chages of commit [1].
This commit will fix the above issue by adapting arguments when calling `action_sent_receipt_on_whatsapp`.
[1] - https://github.com/odoo/odoo/commit/47ec8957334aa37fd9b1d2267681fbd44064809f
[2] - https://github.com/odoo/odoo/blob/2eec78d10380893bd9dbfcef407de50c231cc3bb/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt_screen.js#L111-L116
sentry-5662499209
Related community PR - https://github.com/odoo/odoo/pull/1878293 changes
Resolved issues and error corrections
This update fixes a problem where some Odoo clients using Quadrum or SW Sapien were receiving rejected CFDI invoices due to excessive schemaLocation headers. The change now only includes the necessary headers, ensuring invoices comply with Mexican tax regulations and avoid rejection.
Original PR description
Problem: ======== when using pacs : Quadrum, SW Sapien some clients get their CFDI rejected because the schemaLocation is is containing more headers than needed. Solution: ========= We will only keep the needed schemaLocation for customer invoice, so headers for Payment and External Trade will be removed. opw-4168509 Forward-Port-Of: odoo/enterprise#72450
This update ensures that tests for the account import process run consistently, regardless of whether the `xlrd` library is installed. Previously, tests were skipped when `xlrd` was available, leading to unreliable test results. This change utilizes `openpyxl` for XLSX files, guaranteeing test execution.
Original PR description
Since `xlrd >= 2.0` dropped XLSX support, we use `openpyxl` to open XLSX files if the `xlrd >= 2.0` is installed.[^1] However, the tests in `account_base_import` are skipped unless `xlrd.xlsx` can be imported. As a result, they are not run on runbot, where `xlrd >= 2.0` is installed. We therefore need to avoid skipping them if openpyxl is installed. runbot-108001 [^1]: https://github.com/odoo/odoo/pull/169245 Forward-Port-Of: odoo/enterprise#74608
This update ensures that the system correctly validates the origin and destination pairs before adding a reference number to delivery requests. This prevents errors and ensures accurate order processing, particularly when dealing with multiple locations.
Original PR description
validate origin/destination pairs before adding ReferenceNumber to the request