Daily updates from Odoo
Monday, December 9, 2024
41 changes · 18.0
Enhancements to existing features
The Documents app now offers clearer folder navigation and a more consistent Home experience. Users can browse folders without unexpected panel expansion, see the folder context for targeted documents, and benefit from a cleaner paged view with fewer records loaded at once.
Original PR description
[IMP] documents improve search panel and home kanban view This commits brings changes to the search panel that should improve UX: - When coming from another app (e.g. Projects), the COMPANY folder…
[IMP] documents improve search panel and home kanban view This commits brings changes to the search panel that should improve UX: - When coming from another app (e.g. Projects), the COMPANY folder stays folded... -... and the name of the folder containing the targeted document is displayed below the breadcrumbs, right before the cogwheel. - "Home" background changes when you hover or select it, the same way as for the folders. - Deselect 'Home'* (if selected) when adding a search item. - Clear search and order by `last_accessed_date` when clicking on 'Home'. - When users navigate through COMPANY folders via the Kanban or the List view, and COMPANY is folded, the search panel does not expand the visited folders. - Clicking on the caret before the folder name, fold/unfold the folder without selecting it (setting it as the active folder). - Clicking on a folder name in the search panel just select it (no folding/unfolding). - Main folders like 'COMPANY', that name is preceded by an icon, also have a caret for folding/unfolding. - Kanban view: limit pager size to 40 records. * actually, it's just a visual trick: removing the active class from the 'Home' header element. task-4293935
Resolved issues and error corrections
Emoji reactions in Mail are now styled so reactions from others are less visually prominent in dark theme. This makes it easier for users to distinguish their own highlighted reactions while keeping the light theme unchanged.
Original PR description
When message has emoji reactions, they have slightly different visual whether the current user has reacted or not: When the user has reacted, this is highlighted. This works great in white them, but in dark theme the non-self reacted visual was more highlighted, which goes against the intend of highlighting self-reactions more. The problem is that non-self reactions are too distracting in dark theme, which isn't the case in white theme, This comes from borders being too visible. The color of default `border` is too much in dark theme. This commit fixes the issue by using `border-secondary`, which has reduced opacity in dark theme. In white theme, this is unchanged. Before <img width="868" alt="Screenshot 2024-12-09 at 13 03 23" src="https://github.com/user-attachments/assets/963f6b65-a280-4be9-b15f-8a1cdbd562a5"> After <img width="864" alt="Screenshot 2024-12-09 at 13 03 31" src="https://github.com/user-attachments/assets/5c43b705-d750-4370-af5b-2f3ab3dac51e">
This fixes an issue where installing batch picking could unintentionally change the appearance of empty-screen messages across Odoo. The styling is now limited to the intended stock batch and fleet views, keeping other screens visually consistent.
Original PR description
**[FIX] stock_{picking_batch,fleet}: scope no content helper**
Since [1], a CSS rule was changing the size of all the no content
helpers throughout Odoo when `stock_picking_batch` was installed.
This commit fixes that by scoping the rule to its original intent.
opw-4370026
[1]: https://github.com/odoo/odoo/commit/06d1d48199ccfc79a80aea314f75d649b3149dba#diff-87ad06e3496be4ac6761b7052a11d9e9f1464e291d305405aae839f1a4d2ba9cR1
---
In order to achieve this, we needed to add support for the class attribute for graph and pivot views. It is only a matter of RNG validation as the code already support the parsing of the `class` attribute. The following commit is therefore added:
**[FIX] base,web: class attr for `<graph/>` & `<pivot/>`**
Before this commit, the class attribute for `<graph/>` and `<pivot/>` views
was not allowed.
As there is no valid reason not to do so, this commit now allows it.This fix ensures that when a screen component fails while loading, Odoo avoids leaving users with a partially displayed and inconsistent page. Instead, the web client replaces the failed view with a safe blank component so the interface remains stable.
Original PR description
Before this commit, if a component raised an error on it's onMounted hook, the rest of the onMounted hooks of all the other components would not execute. This is a desired behaviour, if an error is raised, we need to stop the execution. The issue with this, is that the error component (and the others), are already in the DOM, and since the onMounted hook functions haven't been executed, this leaves an inconsistent state. This commit will allow the action service to identify this particular case, and mount an BlanckComponent, to avoid having an inconsistent view.
The self-order interface now shows the product information icon when a public product description exists. This lets kiosk and self-order customers view helpful product details before ordering, reducing confusion and improving the ordering experience.
Original PR description
Problem: The `public_description` field is not loaded in `_load_pos_data_fields`, which prevents the product information icon from appearing in the self-order interface, thus hiding the public description from users. Solution: Ensure the `public_description` field is loaded so that the product info icon is displayed, allowing users to view the product's public description. Steps to reproduce: - Add a Public description to a product. - Open the Kiosk/Self-order interface. - The info icon is not visible, and the product description cannot be viewed. opw-4250442 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Chat windows now use the full mobile screen correctly in Safari instead of being constrained by a desktop-style shape. This keeps longer conversation names and header content visible, making mobile chat usable and consistent across browsers.
Original PR description
Chat window have their style improved recently [1]: their size and aspect-ratio have changed. The aspect-ratio is intended for desktop use. In mobile, it should take whole height and width of screen.…
Chat window have their style improved recently [1]: their size and aspect-ratio have changed. The aspect-ratio is intended for desktop use. In mobile, it should take whole height and width of screen. This works well in almost all browsers: `w-100 h-100` seems to take precedence over explicit aspect-ratio. On Safari however, it seems to comply with given aspect-ratio even if this means cropping the content. This is unintentional and makes chat windows barely useable. Steps to reproduce: - Open a chat window with a relatively long conversation name on safari browser in small screen => The header content on the left is cropped. This commit fixes the issue by putting the `aspect-ratio` in a non-mobile rule. That way `w-100 h-100` will be used correctly in Safari browser as in all other browsers. [1]: https://github.com/odoo/odoo/pull/188665 Before / After <img width="233" alt="Screenshot 2024-12-09 at 11 46 10" src="https://github.com/user-attachments/assets/b60a306d-1357-41cc-874e-da0529e40b4c"> <img width="233" alt="Screenshot 2024-12-09 at 11 46 32" src="https://github.com/user-attachments/assets/efd5a75a-73a8-4f79-b273-56516bd4996e">
Spellcheck indicators in the Odoo HTML editor now appear only when the user is actively focused on the editor. This keeps red spelling underlines from staying visible in places where rich text content is being viewed but not edited, making screens cleaner and less distracting.
Original PR description
This commit fixes the behavior of spellcheck on the WYSIWIG component, which previously enabled this only on focus. Since we use this element in many scenarios accross Odoo, we don't want red lines to keep their visibility all the time, when the WYSIWIG is not directly focused. ~~A test has been introduced, since the contenteditable attribute was not correctly accessed by the hook.~~
This fix updates an internal website editor test so it matches the allowed customization behavior for button styles. It helps keep quality checks active for the website editor and reduces the risk of regressions in future updates.
Original PR description
In this commit, we fix the test_tour in order to reactivate it from v18. The probleme that is fixed in this commit is that we can't customize a "secondary" button in the sidebar of web editor tools but it is allowed with "custom" button. runbot-error-id~109213 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 fixes an issue where expanding a table in the HTML editor could cause the row picker to jump around and add rows too quickly. The table resizing controls now stay stable, making table editing smoother and less frustrating for users.
Original PR description
**Problem**: When creating a table and expanding its size, its position shifts upon reaching the window border due to the following code:…
**Problem**: When creating a table and expanding its size, its position shifts upon reaching the window border due to the following code: https://github.com/odoo/odoo/blob/1f4a85386eb258b08a3a6f43f1f3910598f005c4/addons/html_editor/static/src/core/overlay.js#L55-L57 The resize mechanism keeps the bottom of the table picker aligned with the top of the target element. When hovering over the gray square to add rows, the table expands upward (due to the position change), triggering a hover event again. This results in rapid row additions, causing the picker to jump back and forth, creating a poor user experience. **Solution**: Allow dynamic enabling or disabling of position changes during resizing, to match the fixed overlay positioning as prior versions (approved by the Product Owner). **Steps to reproduce**: 1. Open the editor and insert a table. 2. Start adding rows by hovering over the table's resize picker. 3. As the picker moves above the target element, try to hover to add more rows. 4. Observe that rows are rapidly added during mouse movement, and the picker jumps back to the bottom, causing chaotic behavior. opw-4351695 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change ensures email templates handle empty dynamic placeholders correctly by converting certain template tags into a safer format. It prevents broken rendering when a placeholder has no value, improving reliability for users editing or sending templated emails.
Original PR description
**Problem**: Self-closing `t` tags do not render properly, leading to issues in templates where the tag is opened but never closed. **Solution**: Extend the fix introduced in the following commit: https://github.com/odoo/odoo/commit/26b922ef5cad42da7e188195e919e54878d472fc to also cover `t` tags, ensuring proper conversion to open/closed tag format. **Steps to reproduce**: 1. Open Email templates. 2. Add a dynamic placeholder with no default value. 3. If the record has no value for that attribute, the `t` tag is opened but never closed, causing rendering issues. opw-4376109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where opening a project could take users straight to a new sales order form instead of the expected sales order list. The change ensures the selected project shortcut uses its own settings, so users can still navigate and adjust the project top bar as intended.
Original PR description
Before this commit, when the user creates a new billable project and change the order of the embedded actions inside the topbar of that project to put `Sales orders` embedded action first to be able…
Before this commit, when the user creates a new billable project and change the order of the embedded actions inside the topbar of that project to put `Sales orders` embedded action first to be able to load that action first, the context of that embedded action is not given the `doAction` rpc and so the view loaded in the form view of SO to be able to create a new SO. The problem is if the user does not want to create a SO, it will not be able to change the first action to load for that project since the topbar is not visible in the form view. This commit makes sure the context of the embedded action to load is given to `doAction` rpc. Steps to reproduce the issue: ============================ 1. Install Sales and project apps 2. Create new billable project 3. go inside that project to see the tasks of that project and open the top bar 4. display the `Sales Order` embedded actions inside the top bar of that project 5. reorder the embeddded actions inside the top bar to first load `Sales Order` action when we open that project. 6. Go back to the project kanban view 7. Click on that project Expected Behavior ----------------- The list view of sale.order model should be displayed Current Behavior ---------------- The form view of sale.order model is opened to be able to create a new SO for that project. task-4295738
This fix makes an automated online shop test wait for the page address to fully update before checking it. It reduces false test failures, helping teams trust release checks without changing the customer shopping experience.
Original PR description
In this commit, we fix a undeterministic behavior about check the pathname of window in function assertPathName. In this function, we check the url of the window but the url can changes few ms after the DOM has been loaded. So the check can occurs after the DOM has been loaded. To avoid this behavior, we wait for the pathname instead of check it direclty. runbot-error-id~70316
Applications received by email now create the candidate under the same company as the related job. This prevents recruitment records from being split across companies and avoids errors that could block incoming applications.
Original PR description
When an application is received through email, an `hr.candidate` is created without `company_id`. The default for this field is self.env.company. When processing an email this will be the company of OdooBot. `hr.applicant` on the other hand, will compute its default company based on the linked `hr.job`.
Because of this, it's possible that these two records are created in different companies leading to:
File ".../addons/hr_recruitment/models/hr_applicant.py", line 351, in create
raise ValidationError(_("You cannot create an applicant in a different company than the candidate"))
Fix it by creating the candidate in the same company the job is in.
opw-4384806This fix allows scheduled automated tasks to run even when assigned to a non-administrator user. It prevents jobs from failing due to overly strict permissions when recording their progress, improving reliability for routine background operations.
Original PR description
Step to reproduce: - Set any non-admin user as the cron scheduler - The cron won't run as the permission required to create the ir.cron.progress are admin 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 fixes an issue where document actions with no group restrictions were hidden from users. These actions now correctly appear globally, helping teams access expected document workflows such as creating vendor bills.
Original PR description
**Current behavior:** Having some embedded action for `documents.document` which has no `groups_ids` set will result in that action not ever appearing in the actions bar/menu in the documents app.…
**Current behavior:**
Having some embedded action for `documents.document` which has no `groups_ids` set will result in that action not ever appearing in the actions bar/menu in the documents app.
**Expected behavior:**
In the absence of any records in the `groups_ids` relation, the actions should be exposed globally.
**Steps to reproduce:**
*`-i documents_account` for example*
1. In technical settings, open the embedded actions list view
2. Edit the `Create Vendor Bill` action so that it has an empty `groups_ids` field
3. Open the documents app, click on the finance tab on the left sidebar
4. Click on one of the demo documents, observe in the actions menu for the record that the create vendor bill action is no longer present
**Cause of the issue:**
The domain was constructed incorrectly, as the
`('field', 'in', [False] + X.ids)`
pattern does not work when `'field'` is itself a m2m recordset.
**Fix:**
Split this domain leaf into 2 so we can check for membership as well as falsy-ness.
opw-4342841Users limited to a branch company can now open contact records without being blocked by a company access error. This prevents unnecessary disruption for teams working in branch-based company setups.
Original PR description
Steps to reproduce 1. Install account_followup and contacts 2. Have a branch company 3. Have a user with only the branch in its allowed companies (setting in the "Access rights" tab) 4. With this user, go to Contacts and click on any contact. ** Access Error: Access to unauthorized or invalid companies. ** Cause Commit https://github.com/odoo/enterprise/commit/fb59524a95b0f78112002d1e4d5ad3d6c301de7e modified the way company dependent fields work, which reveals an access error issue: a user may not have access to the root company of the currently selected company. Change Currently `.with_company(self.env.company.root_id.id)` has no effect, remove it to fix access error. opw-4368736
The Knowledge app now lets users create new records from externally embedded views without hitting an error. This restores expected behavior for teams using embedded Knowledge views and prevents interruptions when adding content.
Original PR description
This commit fixes an issue with the external embedded views in Knowledge where the `New` button would raise a traceback. The issue was introduced in the big Knowledge refactor via #67083. This was caused by the action service when the doAction was called inside the createRecord of the ReadonlyEmbeddedViewComponent. The views returned by the find method called upon the action's views array were always undefined. This meant that we never found the correct view to use which raised the traceback. To fix this, the arrow function given to the find method has been updated so that it returns a correct value. task-4367683
The Documents app now silently handles cases where a document access link is used after the document has already been deleted. This prevents confusing “missing record” messages and keeps document cleanup flows smooth for users.
Original PR description
The goal of this commit is to avoid getting an error message when using the /documents/touch/ route for an access_token that no longer exists. This bug was detected in the document_delete_tour where this route is used when the document has already been deleted. This caused a "missing record" message to appear. This commit fixes this behavior.
Dragging a document shortcut to My Drive now places it in My Drive instead of leaving it in the original folder. This makes document organization behave as users expect and reduces confusion when moving shortcuts.
Original PR description
**Before this PR**: Dragging a shortcut to My Drive would create the shortcut within the current folder. **After this PR**: The shortcut will be created in My Drive, rather than remaining in the original folder. **Task**-4313298
Urban Piper order statuses in the POS ticket screen now refresh without requiring staff to reload the POS. This helps teams see when kitchen orders are completed in real time, reducing confusion and manual checks.
Original PR description
Steps to Produce: - Configure Urban Piper in your POS. - Open the particular session. - Configure preparation display. - Place test order and accept in through POS. - Order gets placed in Kitchen display. - Done the order from Kitchen Display. - Order status does not get updated in POS without reloading it. Issue: - Order status was not updated when the order was done from the Kitchen display. Fix: - Initially, only draft orders were fetched from the server but now all orders are been fetched from server that belongs to urbanPiper. task- 4320193
A timing issue in the document deletion flow was corrected so the automated deletion check waits for recent access tracking before removing items. This helps keep document deletion behavior reliable and prevents false failures in quality checks.
Original PR description
The logAccess method is a debounce function with a 1000ms delay, which is a good idea to avoid flooding the network in case a user clicks incessantly in the browser. The bug identified in the document_delete_tour tour is that this method is called AFTER the selected item has been deleted... only because of this "debounce". The tour engine is faster than the 1 second it takes µfor the debounce to be executed BEFORE the deletion of the selected document(s). The solution is therefore that this debounce is directly executed when the document deletion modal opens.
Users can now change a document or folder's parent location directly instead of relying only on drag and drop. When company folders are pinned or moved, the system better preserves the right access for previous owners or document managers without unnecessarily spreading those permissions to every child item.
Original PR description
Commit 1: Follow-up of previous owner keeps and `edit` permission on the documents set as company root. When moving a folder in Company, to pin it, and we add the previous owner or the document manager as member for them to keep access, we do not want to add the member on all children (default behavior). Adding a parameter to skip member propagation is more convenient than checking for partner existence before adding/editing them. Tests are adapted. Commit 2: It is not convenient nor necessary to restrict moving documents to using drag & drop. Note that we keep the action for the webclient as it will call action_create_shortcut or action_move_documents (with the same arguments list). Task-4365165
Miscellaneous changes
Return newly created leaves after calling `hr.leave._split_leaves()` to improve inheritability by other modules --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187633 Forward-Port-Of: odoo/odoo#186948
Original PR description
Return newly created leaves after calling `hr.leave._split_leaves()` to improve inheritability by other modules --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187633 Forward-Port-Of: odoo/odoo#186948
Current behaviour: --- When you make content of type article in eLearning, then add an animation on scroll on an element, when you put the article in fullscreen, the animations do not trigger. Steps to reproduce: --- 1. Go to eLearning 2. Select a course with articles 3. Click on Go to website 4. Go on the article content 5. Open the editor 6. Drag and drop the columns block at the end 7. Select "feature one" and add an animation on scroll 8. After saving, scroll, the animation wo
Original PR description
Current behaviour: --- When you make content of type article in eLearning, then add an animation on scroll on an element, when you put the article in fullscreen, the animations do not trigger. Steps…
Current behaviour: --- When you make content of type article in eLearning, then add an animation on scroll on an element, when you put the article in fullscreen, the animations do not trigger. Steps to reproduce: --- 1. Go to eLearning 2. Select a course with articles 3. Click on Go to website 4. Go on the article content 5. Open the editor 6. Drag and drop the columns block at the end 7. Select "feature one" and add an animation on scroll 8. After saving, scroll, the animation works 9. Click on "Fullscreen" 10. Scroll again, animation doesn't trigger Cause of the issue: --- In website_slide, fullscreen mode, the right scrollable element is not `#wrapwrap`, but `.o_wslide_fs_article_content` Note: --- If the animation is not complete, but the page is scrolled at maximum, animation intensity can be lowered in the editor panel, so that the animation can finish earlier. opw-4151770 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184717
In a list view, first manually resize a column. Doing so, the table can either overflow (if the column has been extended), or be smaller that the available space. Then, resize the page. Before this commit, the table kept is previous width, i.e. it could not benefit from the potential available space that came from resizing the window. With this commit, we force the whole widths computation to be reset after a window resize. Followup of https://github.com/odoo/odoo/pull/170511 opw~4318312
Original PR description
In a list view, first manually resize a column. Doing so, the table can either overflow (if the column has been extended), or be smaller that the available space. Then, resize the page. Before this commit, the table kept is previous width, i.e. it could not benefit from the potential available space that came from resizing the window. With this commit, we force the whole widths computation to be reset after a window resize. Followup of https://github.com/odoo/odoo/pull/170511 opw~4318312 task~4221195 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#189875
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records.This [file](https://github.com/odoo/odoo/pull/180029/commits/7b6fb92891e58c3d1de1cb9bd9b4c28354ba6f92) was merged last week. comm PR odoo/odoo#182706 ent PR odoo/enterprise#71421 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I co
Original PR description
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records.This [file](https://github.com/odoo/odoo/pull/180029/commits/7b6fb92891e58c3d1de1cb9bd9b4c28354ba6f92) was merged last week. comm PR odoo/odoo#182706 ent PR odoo/enterprise#71421 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#183731
Versions -------- - 16.0+ Steps (18.0+) ------------- 1. Enable credit limits via Accounting settings; 2. log in as a user with access to Sales but not Accounting; 3. create a Sales Order; 4. add a product. Issue ----- Access Error. Cause ----- Commit de302c2 changed the way company dependent fields are handled. Instead of computing them via `_compute_company_dependent`, they are now stored in the database. Before this this change, any `groups` restriction added to a field
Original PR description
Versions -------- - 16.0+ Steps (18.0+) ------------- 1. Enable credit limits via Accounting settings; 2. log in as a user with access to Sales but not Accounting; 3. create a Sales Order; 4. add a product. Issue ----- Access Error. Cause ----- Commit de302c2 changed the way company dependent fields are handled. Instead of computing them via `_compute_company_dependent`, they are now stored in the database. Before this this change, any `groups` restriction added to a field wasn't actually checked. After this change, it does get checked, leading to the access error. Solution -------- 1. Use `sudo` to access `partner_id.credit`. 2. When calling the `_build_credit_warning_message`, pass the sales order with `sudo`. opw-4367393 Forward-Port-Of: odoo/odoo#189970 Forward-Port-Of: odoo/odoo#189209
Currently, a traceback occurs when the user changes the SMS iap URL and tries to test SMS mailing. To reproduce this issue: 1) Install `mass_mailing_sms` 2) Add 'B' in the SMS `IAP` URL from the `settings/technical/iap` 3) Open any SMS marketing record and click on the `Test` button Error:- ``` ValueError: unsupported format character 'B' (0x42) at index 152 ``` When the user gives the 'B' in the URL string, it is converted to `%B%` in the URL. As it leads to a traceback as `%s
Original PR description
Currently, a traceback occurs when the user changes the SMS iap URL and tries to test SMS mailing. To reproduce this issue: 1) Install `mass_mailing_sms` 2) Add 'B' in the SMS `IAP` URL from the `settings/technical/iap` 3) Open any SMS marketing record and click on the `Test` button Error:- ``` ValueError: unsupported format character 'B' (0x42) at index 152 ``` When the user gives the 'B' in the URL string, it is converted to `%B%` in the URL. As it leads to a traceback as `%s` is used to format two strings. https://github.com/odoo/odoo/blob/a98a8859696f5a69afe2954a3f5493b611ee252b/addons/sms/tools/sms_api.py#L59 This error occurs when using the old-style string formatting (%s) within an f-string. When using f-strings, we don't need to mix them with the % formatting method. We can replace the `%` formatting with the `format` method. sentry-6072287605 Forward-Port-Of: odoo/odoo#187827
Steps to reproduce: - Open the Notes/To-Do App. - Type some content in the document. - On a new line, insert a table. - Resize the table so there is blank space on its right side. - Select some content and the entire table, ensuring the mouse pointer ends up in the blank space on the right side of the table. - Press `Ctrl + C` - A traceback error occurs. Description of the issue/feature this PR addresses: When selecting content with mouse and ending pointer in empty space to righ
Original PR description
Steps to reproduce: - Open the Notes/To-Do App. - Type some content in the document. - On a new line, insert a table. - Resize the table so there is blank space on its right side. - Select some content and the entire table, ensuring the mouse pointer ends up in the blank space on the right side of the table. - Press `Ctrl + C` - A traceback error occurs. Description of the issue/feature this PR addresses: When selecting content with mouse and ending pointer in empty space to right of a table, pressing Ctrl+C triggers `onCopy`. It tries to clone the closest element of endContainer as a table, but if `closestElement` is not a table, it causes a traceback. Desired behavior after PR is merged: The traceback no longer occurs when copying a selection near a table. task-4357182 Forward-Port-Of: odoo/odoo#189416 Forward-Port-Of: odoo/odoo#188758
Release notes: https://github.com/odoo/owl/releases/tag/v2.5.2 Forward-Port-Of: odoo/odoo#189448 Forward-Port-Of: odoo/odoo#189410
Original PR description
Release notes: https://github.com/odoo/owl/releases/tag/v2.5.2 Forward-Port-Of: odoo/odoo#189448 Forward-Port-Of: odoo/odoo#189410
…anges In previous commit [1], we made changes to handle better the invoicing address partner and the commercial partner. This broke facturx constraints. [1]: https://github.com/odoo/odoo/commit/053c6de8e48ff3fea469531cf32352d88111469e task-no Forward-Port-Of: odoo/odoo#189907
Original PR description
…anges In previous commit [1], we made changes to handle better the invoicing address partner and the commercial partner. This broke facturx constraints. [1]: https://github.com/odoo/odoo/commit/053c6de8e48ff3fea469531cf32352d88111469e task-no Forward-Port-Of: odoo/odoo#189907
The DIN 5008 layout was not properly addressing reports on invoices and delivery slips. On invoices/pro-forma, the reports were not addressed to the correct partners (commercial partner instead of invoice partner). In the delivery slips the reports were not addressed to the delivery partner. This led to functionally and legally incorrect reports. task-4089521 Forward-Port-Of: odoo/odoo#189951 Forward-Port-Of: odoo/odoo#183775
Original PR description
The DIN 5008 layout was not properly addressing reports on invoices and delivery slips. On invoices/pro-forma, the reports were not addressed to the correct partners (commercial partner instead of invoice partner). In the delivery slips the reports were not addressed to the delivery partner. This led to functionally and legally incorrect reports. task-4089521 Forward-Port-Of: odoo/odoo#189951 Forward-Port-Of: odoo/odoo#183775
Version: - 17.0 Steps to reproduce: - Click on the Connect button, which redirects to the authentication wizard. - On the authorization page, click on the Cancel button. issue: - Clicking on the Cancel button does not return an authorization code, causing a traceback error. solution: - Added a condition to handle the Cancel action. If the user clicks Cancel, redirect to the provider form view without causing an error. opw-4377802 Forward-Port-Of: odoo/odoo#189757 Forward-Port-O
Original PR description
Version: - 17.0 Steps to reproduce: - Click on the Connect button, which redirects to the authentication wizard. - On the authorization page, click on the Cancel button. issue: - Clicking on the Cancel button does not return an authorization code, causing a traceback error. solution: - Added a condition to handle the Cancel action. If the user clicks Cancel, redirect to the provider form view without causing an error. opw-4377802 Forward-Port-Of: odoo/odoo#189757 Forward-Port-Of: odoo/odoo#189526
**Current behavior:** Enabling the "Display Lots & Serial Numbers on Delivery Slips" setting, then creating an RFQ for a product with lot/SN tracking and a reference (`default_code`) + receiving the product, and finally printing the delivery slip will result in the product display name appearing twice on the delivery slip. **Expected behavior:** One time, the name. **Steps to reproduce:** 1. Enable "Display Lots & Serial Numbers on Delivery Slips" 2. Create a SN/Lot tracked product w
Original PR description
**Current behavior:** Enabling the "Display Lots & Serial Numbers on Delivery Slips" setting, then creating an RFQ for a product with lot/SN tracking and a reference (`default_code`) + receiving the product, and finally printing the delivery slip will result in the product display name appearing twice on the delivery slip. **Expected behavior:** One time, the name. **Steps to reproduce:** 1. Enable "Display Lots & Serial Numbers on Delivery Slips" 2. Create a SN/Lot tracked product with a reference 3. Create a purchase order, confirm and receive the product 4. On the receipt, click the `Print` button -> 2x name **Cause of the issue:** `description != move_line.product_id.name">` Won't ever be true if there is a reference, as the description at this point is like: `product_id.default_code + product_id.name` **Fix:** Compare description to the `display_name` which will include this kind of extra stuff. opw-4165301 Forward-Port-Of: odoo/odoo#188078
*: l10n_account_edi_ubl_cii_tests Previously, we always set code 30 "Credit transfer" for both customer invoices and credit notes. When you set this code to 30, the UBL rule BR-61 [1] fail if you don't set the payee's bank account number. It's not handy to be forced to set the bank account number while we don't really know if the payment will happen through credit transfer at this stage. We now set code 57 "Standing agreement" for refunds, which seems more general and still a valid meth
Original PR description
*: l10n_account_edi_ubl_cii_tests Previously, we always set code 30 "Credit transfer" for both customer invoices and credit notes. When you set this code to 30, the UBL rule BR-61 [1] fail if you don't set the payee's bank account number. It's not handy to be forced to set the bank account number while we don't really know if the payment will happen through credit transfer at this stage. We now set code 57 "Standing agreement" for refunds, which seems more general and still a valid method. [1]: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-61/ task-no Forward-Port-Of: odoo/odoo#189549
Steps to reproduce: 1. Have a VAT number (or company registry) with dots (e.g.: BE1234.678.28) 2. Import a valid SODA file with the same VAT number 3. Error: "The imported document doesn't seem to correspond to this company's VAT number nor company id" Why it happens: This happens because the regex was taking only the first matching group (1234 in the example above). Solution: Instead of searching the first group of the regex, we can subtract all chars and only keep digits to have a v
Original PR description
Steps to reproduce: 1. Have a VAT number (or company registry) with dots (e.g.: BE1234.678.28) 2. Import a valid SODA file with the same VAT number 3. Error: "The imported document doesn't seem to correspond to this company's VAT number nor company id" Why it happens: This happens because the regex was taking only the first matching group (1234 in the example above). Solution: Instead of searching the first group of the regex, we can subtract all chars and only keep digits to have a valid Belgian VAT number that can be used when checking correspondence between the company VAT and the imported SODA file VAT. opw 4347926 Forward-Port-Of: odoo/enterprise#75297 Forward-Port-Of: odoo/enterprise#75111
Steps to reproduce the bug: - Create a storable product “P1.” - Set up a quality point: - Control Per: By operation - Operation: Receipts - Product: P1 - Create a receipt for two units of P1. - Mark the receipt as "To Do." - Click on "Quality Check" → Fail. - Click on action → Scrap: - Scrap 1 unit of P1. - Confirm. Problem: A quality check is created for the scrapped move. This should not happen. opw-4345679 Forward-Port-Of: odoo/enterprise#75243 Forward-Port-Of: odoo/enterpr
Original PR description
Steps to reproduce the bug: - Create a storable product “P1.” - Set up a quality point: - Control Per: By operation - Operation: Receipts - Product: P1 - Create a receipt for two units of P1. - Mark the receipt as "To Do." - Click on "Quality Check" → Fail. - Click on action → Scrap: - Scrap 1 unit of P1. - Confirm. Problem: A quality check is created for the scrapped move. This should not happen. opw-4345679 Forward-Port-Of: odoo/enterprise#75243 Forward-Port-Of: odoo/enterprise#75160
CSS problem with currency symbol in the monetary field amount, when being on the reconciliation widget, click on a statement and then try to match an existing entries. When clicking on this line, the currency of the amount in the manual operations page was in the amount. task: 4260301 Forward-Port-Of: odoo/enterprise#74511
Original PR description
CSS problem with currency symbol in the monetary field amount, when being on the reconciliation widget, click on a statement and then try to match an existing entries. When clicking on this line, the currency of the amount in the manual operations page was in the amount. task: 4260301 Forward-Port-Of: odoo/enterprise#74511
Steps to reproduce ================== - Open any form view - Drag and drop a new html field at the start of the form view => It goes to the bottom Cause of the issue ================== The generated xpath was `<xpath expr="//form[1]/sheet[1]" position="inside"/>` This puts the new element at the end of the sheet Solution ======== If we want to insert something at the start of the sheet, we need to put it before it's first child. If the sheet is empty, we can use inside like p
Original PR description
Steps to reproduce ================== - Open any form view - Drag and drop a new html field at the start of the form view => It goes to the bottom Cause of the issue ================== The generated xpath was `<xpath expr="//form[1]/sheet[1]" position="inside"/>` This puts the new element at the end of the sheet Solution ======== If we want to insert something at the start of the sheet, we need to put it before it's first child. If the sheet is empty, we can use inside like previously opw-4339407 Forward-Port-Of: odoo/enterprise#75323 Forward-Port-Of: odoo/enterprise#75276
Fixing a traceback when selecting text, because the t-on-click was triggered but the target had no attribute. task: 4260301 Forward-Port-Of: odoo/enterprise#74957 Forward-Port-Of: odoo/enterprise#74509
Original PR description
Fixing a traceback when selecting text, because the t-on-click was triggered but the target had no attribute. task: 4260301 Forward-Port-Of: odoo/enterprise#74957 Forward-Port-Of: odoo/enterprise#74509
Steps to reproduce =================== - Open the resource schedule, and go into day mode. - Switch to tomorrow, and click new. - The start date has been changed but not the end date, which is still now +duration. - Which creates a default duration of `-23:00 hours`. Second issue: - Open the resource type appointment and then create the booking from the Gantt view using the new button. - We get the wrong appointment type there. Technical =========== - Earlier, the stop was c
Original PR description
Steps to reproduce =================== - Open the resource schedule, and go into day mode. - Switch to tomorrow, and click new. - The start date has been changed but not the end date, which is still…
Steps to reproduce =================== - Open the resource schedule, and go into day mode. - Switch to tomorrow, and click new. - The start date has been changed but not the end date, which is still now +duration. - Which creates a default duration of `-23:00 hours`. Second issue: - Open the resource type appointment and then create the booking from the Gantt view using the new button. - We get the wrong appointment type there. Technical =========== - Earlier, the stop was calculated based on the current time instead of `start` in the default_stop. we set stop datetime inside `onAddClicked` by default to start + 1 hour to override the calendar.event's default_stop. - Earlier, we fell into the condition of fetching only the user appointment when we were not providing any resources inside the default_get method, which led to having the user-based appointment instead of the resource-based one. Here, we added a separate condition to fetch the resource-based when going through the action of resource gantt. After this PR =================== - This PR addresses the issue and fixes it by adding the default stop for 1 hour after the start time and assigning the correct appointment type. Task-4330924 Forward-Port-Of: odoo/enterprise#74883 Forward-Port-Of: odoo/enterprise#74144