Wednesday, May 15, 2024
18 changes
1 change
Resolved issues and error corrections
The Chilean electronic invoicing point-of-sale setup now skips an unnecessary database lookup when there are no records to load. This reduces wasted processing during POS data loading and helps keep startup behavior efficient without changing user-facing workflows.
Original PR description
Previously, to avoid loading records when loading data into point_of_sale we used a domain with a falsy value `[('id', '=', False)]` but this required a query to the database.
Now we return False for the domain and if the domain is false we don't search for records. no record search.17 changes
Resolved issues and error corrections
Fixed an issue where LinkedIn posts containing videos prevented images from displaying in the social media feed. The system now properly distinguishes between video and image content, ensuring both types of media are shown correctly when syncing LinkedIn posts to Odoo.
Original PR description
Current behavior:
---
When rendering a linkedin feed, if one of the posts includes a video, no images will be displayed.
Steps to reproduce:
---
1. Go to Configuration > Social Media
2. Link a linkedin account
3. Make a post with an image on linkedin
4. Make a post with a video
5. Go to feed
6. Neither the video nor the image is displayed
Cause of the issue:
---
When getting the image URNs with
`post.get('content', {}).get('media', {}).get('id') `
you can get a video URN in the shape of
`'urn:li:video:abcdefghijklmnop1234'`
opw-3775212This update fixes failing tests in the Dutch tax reporting module (l10n_nl_reports_sbr_icp). The issue was caused by an outdated reference that wasn't properly updated during a code migration. By correcting this reference and adding the necessary tag, the tests can now run properly without being blocked.
Original PR description
Changed the chart_template_ref that wasn't adapted for a fw-port. Also added the tag, so the test's requests are not blocked in 17+ runbot-64732 runbot-62320 Forward-Port-Of: odoo/enterprise#62375
This fix corrects where the automatic deletion rule was applied in the HR contract documents module. The ondelete setting was incorrectly placed in one model and has been moved to the correct location, ensuring data is properly managed when records are deleted.
Original PR description
The ondelete was not in the right model. task-3928257
This fix resolves a critical issue that occurs when upgrading from version 16.0 to 17.0 if certain HR document records have been deleted from the database. The problem was caused by a dependency chain where some records were set to be forcefully created while others were not, causing the upgrade process to fail. By ensuring all dependent records are forcefully created, the upgrade now completes successfully even if records are missing.
Original PR description
The record `documents_hr_contract.documents_hr_documents_contracts` has `forcecreate=1` and there is a chain of dependency of these 3 records: 1.…
The record `documents_hr_contract.documents_hr_documents_contracts` has `forcecreate=1` and there is a chain of dependency of these 3 records:
1. `documents_hr_contract.documents_hr_documents_contracts` [--> 2.](https://github.com/odoo/enterprise/blob/17.0/documents_hr_contract/data/documents_tag_data.xml#L12)
2. `documents_hr.documents_hr_documents` [--> 3.](https://github.com/odoo/enterprise/blob/17.0/documents_hr/data/documents_facet_data.xml#L7)
3. `documents_hr.documents_hr_folder`
But for the latter 2 records **forcecreate=0**. All of these records are set `noupdate=1`. That is why during upgrade the latter 2 records will be skipped from creation if they are missing in db, but it will try to create the 1st one because of that forcecrete=1. This will cause dependency issue if the db is missing the other 2 records.
For solving the issue we set `forcecreate=1` to the latter 2 records.
**Steps to reproduce:**
1. Install modules documents_hr, documents_hr_contract in version `16.0`
2. Delete the document facet `documents_hr.documents_hr_documents`
3. Delete the document folder `documents_hr.documents_hr_folder`
4. Try to upgrade to `17.0`
You will see similar traceback to this:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
...
...
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 693, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 613, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 569, in _tag_root
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/documents_hr_contract/data/documents_tag_data.xml:10, somewhere inside
<record id="document_tag_signature_request" model="documents.tag" forcecreate="1">
<field name="name">Signature Request</field>
<field name="facet_id" ref="documents_hr.documents_hr_documents"/>
<field name="sequence">15</field>
</record>
```This update fixes how child assets calculate their lifetime duration. Previously, child assets weren't properly inheriting lifetime information from their parent assets. The fix ensures that asset lifetime values are correctly updated throughout the entire asset hierarchy, improving the accuracy of asset depreciation calculations.
Original PR description
Child asset has an `asset_lifetime_days` that depends on it's parent's. So, we need to add `recursive=True` to the field. Forward-Port-Of: odoo/enterprise#62351
This update fixes two issues with dragging and dropping content blocks when previewing websites on mobile devices. First, it restores the visual preview of dragged blocks that was missing in mobile view. Second, it fixes automatic page scrolling when dragging blocks near the top or bottom of the mobile preview. These fixes ensure the mobile editing experience works as smoothly as desktop editing.
Original PR description
**[FIX] web_editor: fix drag and drop in mobile preview** Steps to reproduce the bug: - In "Website" edit mode. - Click on the "Mobile preview" button in the right panel. - Drop the "Text-Image" and…
**[FIX] web_editor: fix drag and drop in mobile preview** Steps to reproduce the bug: - In "Website" edit mode. - Click on the "Mobile preview" button in the right panel. - Drop the "Text-Image" and "Image-Text" snippets. - Drop the "Alert" snippet (so an inner content). - Drag the "Alert" snippet and hover the dropzones. - Bug: There is no "preview" of the dragged snippet, like in desktop view. In this commit [1], the "drag and drop" feature of snippets was adapted following the relocation of the website preview into an iframe (see commit [2]). Later, another commit [3] moved the overlay of the snippets into the iframe. It is this latter commit that introduced the bug. Indeed, since the overlay is within the iframe, the jQuery Draggable "Helper" is also within the iframe when a snippet is dragged from the page (as opposed to from the snippets menu). Therefore, it is no longer necessary to consider the offset of the iframe when computing the dropzones (as done in [1]). [1]: https://github.com/odoo/odoo/commit/457e655ff7f4651f185bd7544b8384e2d0ee8ef8 [2]: https://github.com/odoo/odoo/commit/59b96b0742fe8da31eecf896f7a6157811d49de5 [3]: https://github.com/odoo/odoo/commit/872bb20b3ac08cf82613e15e6634a2e7593ccf7a task-3854032 Forward-Port-Of: odoo/odoo#162099 ---------------------------------------- **[FIX] web: fix smooth scroll on drag within an iframe** Steps to reproduce the bug: - In "Website" edit mode. - Click on the "Mobile Preview" button in the right panel. - Drag and drop 3 "Text-Image" snippets onto the page. - Scroll the page while dragging a "Text" snippet by keeping the mouse within the top area of the phone preview. - Bug: The page does not scroll up automatically. In fact, the bug is that the top and bottom areas that trigger the page scroll are those of the main window instead of those of the iframe. In the following commit [1], the necessary adaptations had already been made for the automatic scrolling to work when the dragged element is outside of an iframe and needs to be dropped into an iframe. But later another commit [2], removed jQueryUI draggable and droppable component to use our own implementation of the feature in OWL, but without keeping the adaptation made by commit [1]. [1]: https://github.com/odoo/odoo/commit/457e655ff7f4651f185bd7544b8384e2d0ee8ef8 [2]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76 task-3854032
This update prepares Odoo for compatibility with Python 3.12 and Ubuntu Noble by fixing code that no longer works with the latest versions of Python and key libraries like lxml. The changes address import issues, deprecated features, and syntax warnings to ensure the system runs smoothly on modern platforms.
Original PR description
This pr contains a second set of fix for ubuntu noble, mainly regarding python 3.12 and lxml 5.2 For easier forwardport, the pr is split in multiple parts ## This PR ### [FIX] base, tools: adapt…
This pr contains a second set of fix for ubuntu noble, mainly regarding python 3.12 and lxml 5.2 For easier forwardport, the pr is split in multiple parts ## This PR ### [FIX] base, tools: adapt optcode for python ### [FIX] mail: addapt lxml.html.defs Will be useful when using new package lxml_hmtl_clean. Done in another ### [FIX] test_lint: adapt for pylint 3.0.0 ## Other pr ### [FIX] *: SyntaxWarning: invalid escape sequence Automatic fix in all versions - [x] 15.0 https://github.com/odoo/odoo/pull/163493 https://github.com/odoo/enterprise/pull/61571 - [x] 16.0 https://github.com/odoo/odoo/pull/163753 https://github.com/odoo/enterprise/pull/61658 - [x] 16.3 https://github.com/odoo/odoo/pull/163754 https://github.com/odoo/enterprise/pull/61659 - [x] 16.4 https://github.com/odoo/odoo/pull/163755 https://github.com/odoo/enterprise/pull/61660 - [x] 17.0 https://github.com/odoo/odoo/pull/163756 https://github.com/odoo/enterprise/pull/61661 - [x] 17.1 https://github.com/odoo/odoo/pull/163757 https://github.com/odoo/enterprise/pull/61662 - [x] 17.2 https://github.com/odoo/odoo/pull/163758 https://github.com/odoo/enterprise/pull/61663 - [x] master https://github.com/odoo/odoo/pull/163759 https://github.com/odoo/enterprise/pull/61664 ### [FIX] netsvc: silent utcnow errors (temp) - [x] done in #163794 (easier forwardport, may conflict) ### [FIX] tests: avoid to fork in multithread - [x] #163562 ### [FIX] ast - [x] 15.0: mute warning #163559 (python 3.7 - Python 3.13) - [x] 16.0+: fix it #163487 (python 3.8 - python 3.14 + ) ### [FIX] packaging of lxml_html_clean - [ ] Will be done in #163788 ### [FIX] root xpath deprecation warning - [x] done in https://github.com/odoo/enterprise/pull/61570 Forward-Port-Of: odoo/odoo#165247 Forward-Port-Of: odoo/odoo#162438
A bug in the Kenya EDI device driver was causing message numbers to exceed the maximum allowed value (255), resulting in system errors. This fix resets the message number after each transmission to prevent the overflow and ensure reliable device communication.
Original PR description
In production we are encountering an issue wherein the message number is exceeding the maximum value (255). This results in an error when converting the integer into its byte value representation. The solution to this is to reset the message number upon each send. task-id: none Forward-Port-Of: odoo/odoo#165242
This update fixes a bug that caused the spreadsheet application to crash whenever users right-clicked on a cell. The issue was introduced in a recent update and has now been resolved, allowing users to access context menus normally without encountering errors.
Original PR description
Steps to reproduce: - create a new spreadsheet - right click any cell => boom `Cannot read properties of undefined (reading 'id')` Bug introduced by odoo/enterprise@31401c7 opw-3900571 X-original-commit: odoo/enterprise@78218c9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165270 Forward-Port-Of: odoo/odoo#165183
Fixed a bug in the web editor where deleting content across empty lines would incorrectly remove all text before the empty line. The issue occurred when users selected and deleted text that spanned multiple paragraphs including an empty one. The fix ensures the editor correctly identifies which content should be removed by recalculating the selection position after handling empty lines.
Original PR description
Issue: ====== The whole content is removed when deleting empty line Steps to reproduce the issue: ============================= - Go to to-do - Add some text in the first line - Keep the second line…
Issue: ====== The whole content is removed when deleting empty line Steps to reproduce the issue: ============================= - Go to to-do - Add some text in the first line - Keep the second line empty - Add some text in the third line - Select some prefix of the third line with the second line too - delete - All the content before the empty line is removed Origin of the issue: ==================== We are in this case: `<p>abc</p>` `<p>[<br></p>` `<p>d]ef</p>` - The `startContainer` in this case is the `p` element and not the `br` so we will not insert the `zws` node inside the `p`. - We assign `next` as the text node containing `ef` - Extract content will remove all the content inside the second `p` element and will be like this `<p>abc</p>` `<p></p>` `<p>ef</p>` - We set selection at the end of the `start` node `<p>[]</p>`so it's like we set the selection in `<p>[]ef</p>` so now `getRange` will return `startContainer=endContainer=textNode(ef)` so `joinWith` is equal to next which is the text node containing `ef` - In the join `while` loop , we have `doJoin=true`, `next` always truthy, `next.previousSibling` will never be equal to `joinWith` since `next=joinWith` so it will keep deleting until we don't have anymore previousSiblings which is basically remove everything before. Note: This doesn't happen in the case the second line has some text because we insert a `zws` before the text node. Solution: ========= Since we apply `fillEmpty` on `start` after extracting the content, we need to get the range after we insert the `br` again to make sure we get the correct `startContainer` and `endContainter`. opw-3878575 Forward-Port-Of: odoo/odoo#165104
Fixed a bug that caused an error when deleting time off requests from the calendar view. The system now properly handles different types of record objects when processing deletions, ensuring the calendar works smoothly regardless of how the record data is formatted.
Original PR description
Steps to reproduce: ------------------- Delete a time off request from day/week/month scale on the calendar view. Issue: ------ A traceback appears. Cause: ------ In the `deleteRecord` method, the record parameter is sometimes a proxy object (with a `resId` and `data`) or sometimes the record itself (with an `id` and a `raw_record`). This triggers a problem when for example we want to access `record.data.can_cancel` if we are in the case of a record and not a proxy record. The override is not compatible with its use in web. Solution: --------- Take into account that the method can accept several "record types". opw-3891206
Fixed an issue where payment terms created in a parent company could not be used when creating invoices in a branch company. Previously, the system only looked for exact company matches, but now it properly recognizes payment terms defined in parent companies, making multi-company setups more flexible and user-friendly.
Original PR description
To reproduce the issue: 1) Create a company MAIN, and a branch BRANCH 2) Create a payment term in MAIN, with company_id = MAIN 3) Make MAIN your active company 4) Create a new invoice, and try to assign it the payment term created in 2). ==> It's not possible. This is because the company check ran for the payment term assigned to an invoice only check for equality of the company ; it does not consider the fact the payment term could be defined in a parent of the current branch. This fix makes it possible to use payment terms defined for the parent companies. Forward-Port-Of: odoo/odoo#164767
A faulty test in the Google Calendar module has been removed. This test was incorrectly assuming that event organizers would always appear in a specific position in the attendees list, which caused unreliable test results. Removing this test improves the reliability of the Google Calendar synchronization testing.
Original PR description
This commit removes the dead and undeterministic test added by mistake after an unsucessful merge. This test assumes that the organizer of the event might always be on the position 0 of the attendees list but it is not always the case. Issue from: odoo/odoo#164408 Forward-Port-Of: odoo/odoo#165346
This update fixes a bug in the leave allocation system where overtime duration checks were not working correctly. The fix ensures that when employees are allocated leave time, the system properly validates overtime durations, preventing potential errors in leave management and payroll calculations.
Original PR description
This is an extension of odoo/odoo#160055 as this issue is also present for allocations --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165249
This update fixes an issue where automated tests for the Spanish EDI TBAI module were being skipped during testing. The tests were missing a required configuration tag that tells the system to run them. This ensures the module's functionality is properly validated.
Original PR description
The class doesn't have the post_install tag, and so, is skipped. runbot-25903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165240
Fixed an issue where course invitation emails were not being translated into each recipient's preferred language. The system now automatically translates invitation emails on a per-recipient basis when sending to multiple attendees, while preserving the ability for users to customize the email message before sending.
Original PR description
Problem: when adding attendees to a course, the sent email is not translated into the recipient's language. Fix: Upon sending, translate the email on a per recipient basis, but **only when** the final message to sent is exactly the same as the template. (i.e. the body was not edited from the dialog box) This is a compromise to permit emails being translated while not breaking the following 2 current features: * there can be many recipients (with different languages) * the body is pre-filled with a template but can be edited further by the user directly from the dialog box. opw-3862369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162237
This fix resolves an access rights error that occurred when sales administrators without full system administration tried to create downpayments on confirmed quotations. The issue happened because the system was trying to create a downpayment product without the necessary permissions. The fix adds proper permission handling so downpayment creation works smoothly for authorized sales users.
Original PR description
To reproduce: - Connect as Marc Demo (Administrator for Sales, wihout Administration) for access rights - Create a quotation, confirm it - Create a downpayment of 50%. => Access Right Error. The reason being that we define the Downpayment product if we don't have one on the company. We should add a sudo here. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165454