Friday, February 16, 2024
110 changes · master
Enhancements to existing features
This update removes outdated internal module markers from mail and live chat JavaScript files because they are no longer needed. It should not change how users experience chat or messaging, but it helps keep the codebase simpler and easier to maintain.
Original PR description
They are not necessary since: https://github.com/odoo/odoo/pull/142858 PR enterprise: https://github.com/odoo/enterprise/pull/56692
The tooltip on product favorite star icons now clearly explains the action, showing whether users can add or remove an item from favorites. This small wording improvement helps users understand the control across product, inventory, website sales, and point of sale screens.
Original PR description
_*= stock, website_sale, point_of_sale Before these commit: -> There is a tooltip 'favorite' displayed for the star icon which is not more explicit about the star icon. After these commit: -> Changed the tooltip displayed for the star icon to: "add to favorites / remove from favorites" task-3476798
Survey pages in one-page mode now hide section headings when there is no description and no visible question to show. This makes surveys cleaner for respondents, especially when conditional questions or random question settings would otherwise leave blank section titles on the page.
Original PR description
Purpose ======= In one page display, hide the empty sections. Empty sections are sections without description and without any question to be displayed. This can happen because they simply doesn't…
Purpose ======= In one page display, hide the empty sections. Empty sections are sections without description and without any question to be displayed. This can happen because they simply doesn't have any question or their questions are conditionnally hidden. Specifications ============== The one_page display is the only question layout where multiple sections can be displayed at once on a page. Using this display in combination with conditional questions can result in empty sections (without any visible questions) because of the triggering conditions. In these specific cases, the sections were still displayed resulting in unnecessary floating sections titles. Solving this by only showing the sections when they have a description or when they have at least one visible question. When the survey is set to random, there is no difference between conditional questions and the other questions. In this case, showing the section if it has a description or if the random questions count of the section is higher than 0 and there is at least one question in the section no matter if it is conditional or not. Task-3414382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The employee filter is removed from the Time Off dashboard search, so users focus on their own information by default. This makes the dashboard clearer for employees and avoids suggesting access to other employees' leave data.
Original PR description
remove employee in search bar; only you will see your own dashboard. task : 3679662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds automated checks for how restaurant tables are merged and unmerged in the Point of Sale restaurant flow. It helps ensure merged tables remain reliable across order completion, edit mode changes, and page reloads.
Original PR description
Tour steps: implement the test for mergin table in PoS check that table are merge are unmerge when order finalize unlink merge table in edit mode table merge still after reloading page tasks id : 367492 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A leftover internal test label was removed from the web condition tree tests after a previous conversion. This keeps the test suite configuration tidy and helps avoid confusion for maintainers, with no expected impact on users or business workflows.
Original PR description
This commit removes the odoo-module tag from the condition_tree tests file which was mistakenly left after its conversion.
The Time Off module was simplified by removing a field that was no longer used. This reduces maintenance overhead without changing how employees or managers request and approve leave.
Original PR description
TaskID: 3704510
This update cleans up how Odoo Mail detects when message-related panels and lists become visible. It helps avoid unnecessary loading behavior, including a search issue that could trigger extra loading when views appeared or disappeared.
Original PR description
Remove init param, the value should be undefined until it is set. Adapt caller by checking for explicit boolean when necessary. Pass value to callback to allow not naming the hook's return when the value is only used inside the callback. Fix an issue where search would load more both on becoming visible and invisible.
The Belgian reports app now offers the option to generate 325 forms directly from the forms list instead of through a separate menu item. This reduces menu clutter and makes the workflow easier for users who manage 325/281.50 forms.
Original PR description
The aim of this commit is moving the button to generate 325 forms. Before this commit, we had 2 menu items for the 325/281.50 forms. It was clearly too much. This commit removes the menu item that allows users to generate a new form and add it as a button in the list view. no task id
The payment and UPS website sales modules were updated to follow Odoo's newer process for uninstalling provider modules. This helps ensure these modules can be removed cleanly and consistently, reducing maintenance friction for administrators.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/154179
Luxembourg payroll tax logic has been moved into salary rule data, making the setup easier to understand and maintain in hosted environments. This reduces confusion for users who can review payroll rules but cannot change underlying code on SaaS.
Original PR description
Purpose ======= Even if the end_user is a tech, that he knows the code, as long as it's on the saas, he just can't do anything. Calling method in the rules is counter intuitive, you think that you have the hand, can check a parameter or not, but in fact you can't do anything. TaskID: 3748649
When a completed field service task is opened, the related products view now automatically focuses on products that were added. The action label was also renamed from “Choose Products” to “Add Products,” making the workflow clearer for users.
Original PR description
…oducts' Before these commit: -> There is no default filter 'Added Product' when opening the stat button once task is marked as done. -> Rename 'Choose Products' action into 'Add Products' because it sounds a bit more natural. After these commit: -> Set the default filter 'Added Product' when opening the stat button once task is marked as done. -> Renamed to Add products. task-3476798
Timesheets dated in the future no longer appear in the "To Validate" menus. This reduces confusion because future timesheets cannot be validated yet, so managers only see entries they can act on.
Original PR description
Before this commit, the timesheets that were dated in the future could be visible in the "To Validate" menus. However, it is not possible to validate such timesheets as they are dated in the future, which could lead to confusion for the user. To make things clear, this commit hides the timesheets that are dated in the future from the "To Validate" menus. task-3703516
This update removes now-unneeded technical markers from the enterprise messaging code. It does not change how users interact with messages, attachments, chat windows, or the messaging menu, but it keeps the codebase aligned with recent platform improvements and easier to maintain.
Original PR description
They are not necessary since: https://github.com/odoo/odoo/pull/142858 PR community: https://github.com/odoo/odoo/pull/154164
The VoIP codebase was updated to remove outdated internal module markers that are no longer needed. This keeps the code simpler and aligned with the current platform behavior, with no expected change for users.
Original PR description
.js files are now treated as odoo modules by default if they are under /static/src or /static/tests. This commit removes the now useless odoo module declarations from VoIP's codebase. References: https://github.com/odoo/odoo/pull/142858
This update adds or corrects messages shown in the website editor when users edit shared areas that appear on multiple pages. It helps prevent confusion by making clear that dragged-and-dropped content will be applied across all related pages, not just the current one.
Original PR description
* website_helpdesk When the `oe_structure_<id>` ID is added inside a shared view (rendered on multiple records pages), it needs to inform the user that the elements drag & drop here will be replicated on all other pages. Otherwise, the user has no clue what's going on, he just sees some areas on a record page, but when saved it is applied on all record pages. Some occurences were missing that hint. opw-3671051
The Documents interface has been simplified by removing an outdated styling rule for the message panel. This keeps the layout aligned with the newer shared spacing behavior and reduces the chance of inconsistent visual spacing.
Original PR description
Since the spacing in the chatter now relies on the parent `.o-mail-Chatter-top, o-mail-Chatter-content` there is no more need to target the topbar specifically. task-3675376 Community PR: https://github.com/odoo/odoo/pull/149832 task-3675376
Resolved issues and error corrections
This change fixes a misspelling of “warehouse” in the Manufacturing bill of materials overview controls. It improves wording consistency and avoids small user-facing text mistakes in the interface.
Original PR description
Fixes a small typo where "wharehouse" should be "warehouse". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Features or functions removed from Odoo
This update removes obsolete list view logic that is no longer used after earlier model changes. It has no expected impact on day-to-day users, but helps keep the web interface code simpler and easier to maintain.
Original PR description
In the ListRenderer, the onCreateAction and onFocusIn functions are no longer used since the new RelationalModel. So we're going to remove them in this commit. 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
Code cleanup and technical improvements
This change updates internal web tests for how field data is interpreted, moving them to a newer testing approach. It helps keep the web module easier to maintain and supports future reliability without changing day-to-day user workflows.
Original PR description
task 3705027
Miscellaneous changes
**[FIX] web: fix text color of popover and badge light if dark background** Steps to reproduce the first bug (popover): - Install the e-commerce on your website. - Go to the "Customizable Desk" product page. - Click on "Edit" to go in edit mode. - Click on the "Theme" tab. - Click on the 4th color of the theme colors and choose "black". - Save the page to leave edit mode. - Click on the "Add to cart" button. - Hover over the cart in the navbar to make the popover appear. - Bug: All t
Original PR description
**[FIX] web: fix text color of popover and badge light if dark background** Steps to reproduce the first bug (popover): - Install the e-commerce on your website. - Go to the "Customizable Desk"…
This fixes an issue where selecting an emoji in live chat could insert it in the wrong place when the chat runs inside an embedded interface. Users can now add emojis without disrupting the text they have already typed.
Original PR description
Before this PR: `document.activeElement` returns wrong value when the root element is a shadow DOM. Steps to reproduce: - type something in live chat window - click on emoji picker and select an emoji - emoji is pasted before the text After this PR: Using `getRootNode()` to get the proper root. This method returns the object's root, which optionally includes the shadow root if it is available.
This fix ensures country-specific payroll modules load with the right payroll and accounting dependencies. It helps prevent installation or configuration issues when companies use localized payroll features without needing unnecessary accounting components.
Original PR description
l10n_xx_hr_payroll shouldn't depend on account and should depend on hr_payroll l10N_xx_hr_payroll_account should depend on l10n_xx_hr_payroll and account
This fixes a setup issue in the US payroll accounting test module when demo data is not installed. It prevents no-demo test builds from failing because the module incorrectly assumed demo company data was available.
Original PR description
When no demo data, we still have the main_company. It causes an issue when installing this module, as it expects the demo data. The whole no demo data build fails because of it. We should change what we make the check on.
This fix removes a duplicate Lithuania-specific Intrastat region setting because the same setting is now managed centrally. It helps keep accounting configuration consistent and reduces the risk of conflicting setup options.
Original PR description
In the previous commit https://github.com/odoo/enterprise/commit/77ff6f595d5c6f2ec297b7dddff866a77e3b87ed, the field intrastat_region_id was moved from l10n_be_intrastat to account_intrastat. The l10n_lt_intrastat localization was forgotten and is being removed in this commit. The field intrastat_region_id can indeed be defined only once in account_intrastat instead of all localizations. The view of the intrastat region (visible in the settings) was defined in account_intrastat, and is therefore no longer needed specifically in the l10n_lt_intrastat module task-3691571
Restaurant table bookings now process correctly when they arrive through live notifications. This prevents errors that could interrupt booking updates in the point-of-sale restaurant appointment flow.
Original PR description
When receiving websocket message with a new table booking, we tried to access the pos_store object from the wrong variable, which caused an error. Is now fixed by using the correct variable.
Unused code for an Expenses button in project updates has been removed because the button is no longer shown. This is a small cleanup that helps keep the project expense integration easier to maintain without changing user-facing behavior.
Original PR description
The 'Expenses' stat button is no more used in the right side panel of project updates. task-3724796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change removes an obsolete field from the manufacturing planning module that pointed to data that no longer exists. It helps prevent confusion and potential errors in internal planning data without changing day-to-day user workflows.
Original PR description
The `sequence` fields on `mrp.production.schedule` is a related field to something that doesn't exist (sequence on product). This commits removes it as it is not used anymore (see 97b764fd8032c93a812f7c1f97e75035570c58d5)
This update reorganizes how spreadsheet pivot tables are handled so Odoo can support multiple pivot types in the future. It keeps current pivot behavior while making the spreadsheet feature easier to extend and maintain.
Original PR description
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
The automated tests for the web clipboard-copy field were moved to a newer testing framework. This is an internal quality update that helps developers maintain the feature more reliably without changing how users copy content.
Original PR description
This commit refactor the copy_clipboard_field tests from QUnit to hoot. task-3705027
Spreadsheet pivot filters were reorganized into their own internal component. This makes the spreadsheet pivot area easier to maintain and prepares it to support different pivot types more flexibly, without changing the user experience.
Original PR description
This commit introduce a new ui plugin to manage global filters in pivot. This is a step to make the pivot ui agnostic of the pivot type. Task: 3748727
The Danish audit trail functionality is being folded into the main Danish localization module to simplify maintenance. This cleanup should make the Danish localization easier to manage without changing day-to-day business workflows.
Original PR description
The module l10n_dk_audit_trail has been added in stable. This PR will do the clean up by merging the two modules. task: 3710399 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet pivot table commands were reorganized so the system can support multiple pivot table types more easily in the future. This is mainly an internal cleanup that keeps existing pivot behavior aligned with the updated data migration flow.
**[FIX] web: fix text color of popover and badge light if dark background** Steps to reproduce the first bug (popover): - Install the e-commerce on your website. - Go to the "Customizable Desk" product page. - Click on "Edit" to go in edit mode. - Click on the "Theme" tab. - Click on the 4th color of the theme colors and choose "black". - Save the page to leave edit mode. - Click on the "Add to cart" button. - Hover over the cart in the navbar to make the popover appear. - Bug: All the popover texts are not visible because they are white and the background is white. Steps to reproduce the second bug (badge light): - Install the e-commerce on your website. - Go to the "Customizable Desk" product page. - Click on "Edit" to go in edit mode. - Click on the "Theme" tab. - Click on the 4th color of the theme colors and choose "black". - Save the page to leave edit mode. - Bug: The text of the "extra price" badge is not visible because both text and background are white. These two issues existed because the text color of those elements depended on the body's background color. With this commit, the text color for those elements is now determined by their respective backgrounds. This commit is a follow-up to this commit [1]. We also add the handling of the text-muted color to ensure it remains visible if a modal has a dark background while the body background color is light. Before this commit, we only handled the opposite case (dark body and light modal). This commit also fixes the text color of the button in a file input of a form when the background color of the <body> is dark. Similar to the other elements fixed in this commit, the text color of this button could be invisible because it was the same color as its background. [1]: https://github.com/odoo/odoo/commit/308b91c58b00300fd8dc52b9b4e2f7d1ab31f7b7 opw-3570774 _______________________________________________ **[FIX] web, website_sale: fix products page with a dark body background** Steps to reproduce the bugs: - Install the e-commerce on your website. - Go to the "/shop" page. - Click on "Edit" to enter edit mode. - Click on the "Customize" tab. - Choose "Cards" for the "Style" option. - Enable the "Product Description" toggle. - Click on the "Theme" tab. - Click on the 4th color of the theme colors and choose "black". - Save the page to exit edit mode. - Bug 1: The product description and the price in the product cards are not visible. - Bug 2: The scrollbar below the category buttons has the same color as its background. - Click on the "Mobile Preview" button in the backend navbar. - Click on the "Filters" button on the page to show the offcanvas. - Bug 3: The text color in the offcanvas is not visible and the background color of the inputs is the "body" background color instead of the "offcanvas" background color. opw-3570774 Forward-Port-Of: odoo/odoo#153930 Forward-Port-Of: odoo/odoo#150420
### Steps to reproduce * install `l10n_ch_reports` * switch to a Swiss company * enable "QR Codes" in Settings > Accounting > Customer Payments * create and confirm two invoices for a Swiss partner * on the invoice list view, select and attempt to print the two invoices at once You should be met with traceback. opw-3697569 Forward-Port-Of: odoo/odoo#153903 Forward-Port-Of: odoo/odoo#153461
Original PR description
### Steps to reproduce * install `l10n_ch_reports` * switch to a Swiss company * enable "QR Codes" in Settings > Accounting > Customer Payments * create and confirm two invoices for a Swiss partner * on the invoice list view, select and attempt to print the two invoices at once You should be met with traceback. opw-3697569 Forward-Port-Of: odoo/odoo#153903 Forward-Port-Of: odoo/odoo#153461
[FIX] membership : Members module is not visible without Accounting Steps to reproduce: 1- Install Members module while Accounting is uninstalled Current behavior before PR: When you install Members module without having Accounting module you will not be able to access Members module as it will be hidden on the dashboard. This happens because of the access rights that the Member module has as it is having the access right group of the Accounting module `group_account_user`. Desired be
Original PR description
[FIX] membership : Members module is not visible without Accounting Steps to reproduce: 1- Install Members module while Accounting is uninstalled Current behavior before PR: When you install Members module without having Accounting module you will not be able to access Members module as it will be hidden on the dashboard. This happens because of the access rights that the Member module has as it is having the access right group of the Accounting module `group_account_user`. Desired behavior after PR is merged: Now the Members module has the access right group of Invoicing module `group_account_invoice` which is the only dependency module that Members need. So it will be visible and accessible from the dashboard once installed opw-3627010 Forward-Port-Of: odoo/odoo#153938 Forward-Port-Of: odoo/odoo#146373
Before this PR, users receive a traceback whenever they try to save the empty sequence number in the invoice. After this PR, traceback will not come and the old sequence number will be reassigned. Forward-Port-Of: odoo/odoo#153829
Original PR description
Before this PR, users receive a traceback whenever they try to save the empty sequence number in the invoice. After this PR, traceback will not come and the old sequence number will be reassigned. Forward-Port-Of: odoo/odoo#153829
**Desired behavior after PR is merged:** Enhancing the job posting with an XML tag for the title of the position so it can be used for the google rich search. opw-3713519 Forward-Port-Of: odoo/odoo#153682
Original PR description
**Desired behavior after PR is merged:** Enhancing the job posting with an XML tag for the title of the position so it can be used for the google rich search. opw-3713519 Forward-Port-Of: odoo/odoo#153682
Currently, links in the website editor always open in the iframe except for a few exceptions defined in `_isTopWindowURL` As the enable_editor parameter is only valid for the parent window containing the iframe clicking a link with `<a href="?enable_editor=1" has no effect. To fix this for the two cases we do have this message, we add `@` as the root of the path of the url. Which indicated we want to open a "back-end" route, which will be set in the parent window. We also fix the exhibi
Original PR description
Currently, links in the website editor always open in the iframe except for a few exceptions defined in `_isTopWindowURL` As the enable_editor parameter is only valid for the parent window containing the iframe clicking a link with `<a href="?enable_editor=1" has no effect. To fix this for the two cases we do have this message, we add `@` as the root of the path of the url. Which indicated we want to open a "back-end" route, which will be set in the parent window. We also fix the exhibitor version of this pop-up not showing up. task-3607615 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143162
Since commit [1], it is now possible to order the columns in mobile view independently from the desktop view. When moving a column with an arrow, if we are in mobile view, mobile order classes are added on the columns, which only changes the order on mobile without affecting desktop. But if we move on desktop view, then these classes are removed. While it works well when using the arrows, this behavior is not the same when moving the columns with the drag and drop. This means that drag and dr
Original PR description
Since commit [1], it is now possible to order the columns in mobile view independently from the desktop view. When moving a column with an arrow, if we are in mobile view, mobile order classes are…
Since commit [1], it is now possible to order the columns in mobile view independently from the desktop view. When moving a column with an arrow, if we are in mobile view, mobile order classes are added on the columns, which only changes the order on mobile without affecting desktop. But if we move on desktop view, then these classes are removed. While it works well when using the arrows, this behavior is not the same when moving the columns with the drag and drop. This means that drag and dropping a column - in the same snippet does not reset the mobile order classes; - in another snippet does not reset the classes in it and does not fill the gap left in the previous snippet if it was ordered. This means that in the same snippet, there can be both columns with and without the mobile order classes. This causes some issues: 1) Removing such snippets or their ordered columns causes a traceback. Indeed, the `onRemove` code considers that all columns have the mobile order classes if we remove one, which is why it fails when it is not the case. 2) The arrows on the mobile overlay are not always correct and can also be missing, because they depend on the order classes. 3) In mobile view, changing the order of the columns adds inconsistent mobile classes on them, because of the columns that already have one. This commit improves the drag and drop by also taking mobile ordered elements into account, as it is the root cause of the mentioned issues: - When a column is moved, the order classes of all the other columns in the snippet where it was dropped are removed (so it behaves the same way as with the arrows). - When moving an ordered column in another snippet, the gap it left in its previous snippet is now filled. This commit also fixes the issues for already dropped blocks in existing DBs, by - adding a check when removing to avoid the first issue; - removing the mobile classes at the start if they are inconsistent. [1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba opw-3697962 Forward-Port-Of: odoo/odoo#153957 Forward-Port-Of: odoo/odoo#152487
**Issue Description**: From versions 16.3 to the master branch, a sub-task should never be assigned to a project automatically. However, when accessing `Sub-tasks` through the smart button and creating a new one, the context pass variable such as `'default_project_id': 4`. This leads to the sub-task being created with an assigned project immediately. **Steps to Reproduce**: 1. Open `Project` app. 2. Enter any project, then navigate to any task. 3. Within the task, go to `sub-task` tab. 4
Original PR description
**Issue Description**: From versions 16.3 to the master branch, a sub-task should never be assigned to a project automatically. However, when accessing `Sub-tasks` through the smart button and…
**Issue Description**: From versions 16.3 to the master branch, a sub-task should never be assigned to a project automatically. However, when accessing `Sub-tasks` through the smart button and creating a new one, the context pass variable such as `'default_project_id': 4`. This leads to the sub-task being created with an assigned project immediately. **Steps to Reproduce**: 1. Open `Project` app. 2. Enter any project, then navigate to any task. 3. Within the task, go to `sub-task` tab. 4. At the top center of the page, click on 'Sub-task' smart button. 5. Then, create a new sub-task using the 'New' button. 6. You will observe that the sub-task is immediately assigned to a project, which should not happen. **Proposed Solution**: By removing the passing of the default_project_id variable from the context when open a sub-task action, we ensure that sub-tasks are not automatically assigned to a project, as intended. opw-3708537 Forward-Port-Of: odoo/odoo#154101 Forward-Port-Of: odoo/odoo#153349
pos*: point_of_sale, pos_restaurant The current approach to book/release a table isn't so intuitive, knowing that when selecting an empty table from the floor plan: - an empty order is created on that table, displaying it as booked on the floor plan - as long as the order remains empty, we display a "Release table" button in order to delete the related empty order and display the table as free on the floor plan Here is the change brought by this commit: - Change the "Release table" butt
Original PR description
pos*: point_of_sale, pos_restaurant The current approach to book/release a table isn't so intuitive, knowing that when selecting an empty table from the floor plan: - an empty order is created on that table, displaying it as booked on the floor plan - as long as the order remains empty, we display a "Release table" button in order to delete the related empty order and display the table as free on the floor plan Here is the change brought by this commit: - Change the "Release table" button to "Book table" - Don't create an empty order on the table until User either: - hits "Book table" - starts adding products to the cart - Table can be released by deleting the order - Deleting the last order on the table, redirects User to the floor plan task-id: 3624323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149598 Forward-Port-Of: odoo/odoo#145896
Current behavior: When printing the bill before the order has been paid, the QRCode to get the invoice shouldn't be shown. Steps to reproduce: - Activate the option "Show QR Code" in the POS settings - Create a new order - Add some products - Click on "Bill" button - The QRCode is shown opw-3703720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153835 Forward-Port-Of: odoo/odoo#152918
Original PR description
Current behavior: When printing the bill before the order has been paid, the QRCode to get the invoice shouldn't be shown. Steps to reproduce: - Activate the option "Show QR Code" in the POS settings - Create a new order - Add some products - Click on "Bill" button - The QRCode is shown opw-3703720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153835 Forward-Port-Of: odoo/odoo#152918
**Current behavior before PR:** - When coupen code template is selected and we drag text block then text will not be visible because of bg color as the background color and text color are same. - When selecting multiple blocks, the link button sometimes fails to disappear, and sometimes, after selection clicking on a line, the link button does not reappear because the code resides within the `_updateEditorUi` function, and this function is not invoked upon a selection change
Original PR description
**Current behavior before PR:** - When coupen code template is selected and we drag text block then text will not be visible because of bg color as the background color and text color are same. -…
**Current behavior before PR:** - When coupen code template is selected and we drag text block then text will not be visible because of bg color as the background color and text color are same. - When selecting multiple blocks, the link button sometimes fails to disappear, and sometimes, after selection clicking on a line, the link button does not reappear because the code resides within the `_updateEditorUi` function, and this function is not invoked upon a selection change. Therefore, after modifying the selection, the user must wait for the `_updateEditorUi` function to be triggered, which happens upon a click or keydown event. **Desired behavior after PR is merged:** - Now in coupen code we can see text in text block. - Now the link button will disappear on multiple block selection and it will be reappear on single block. as we moved code to updateToolbar which is triggered on selection change. task-3514347 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153914 Forward-Port-Of: odoo/odoo#136099
Currently an error occurs when the user is generating Post Journal Entries of an employee whose work email is not specified. Steps to Reproduce: - Install `hr_expense` module. - Open Expenses > Expense Reports. - Open a report of employee whose work email is not specified. - Make sure the status of the selected recordset is `Approved` - Now click on the `Post Journal Entries` button. - The error is generated. Traceback on sentry: ``` KeyError: ('ir.model.data', <function IrModelD
Original PR description
Currently an error occurs when the user is generating Post Journal Entries of an employee whose work email is not specified. Steps to Reproduce: - Install `hr_expense` module. - Open Expenses >…
Currently an error occurs when the user is generating Post Journal Entries of an employee whose work email is not specified.
Steps to Reproduce:
- Install `hr_expense` module.
- Open Expenses > Expense Reports.
- Open a report of employee whose work email is not specified.
- Make sure the status of the selected recordset is `Approved`
- Now click on the `Post Journal Entries` button.
- The error is generated.
Traceback on sentry:
```
KeyError: ('ir.model.data', <function IrModelData._xmlid_lookup at 0x7f2a26dd7010>, 'hr.open_view_employee_tree')
File "odoo/tools/cache.py", line 99, in lookup
r = d[key]
File "<decorator-gen-8>", line 2, in __getitem__
File "odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
ValueError: External ID not found in the system: hr.open_view_employee_tree
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1824, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-17.1/hr_expense_extract/models/hr_expense.py", line 194, in action_sheet_move_create
return super().action_sheet_move_create()
File "addons/hr_expense/models/hr_expense_sheet.py", line 542, in action_sheet_move_create
self._check_can_create_move()
File "addons/hr_expense/models/hr_expense_sheet.py", line 638, in _check_can_create_move
action = self.env['ir.actions.actions']._for_xml_id('hr.open_view_employee_tree')
File "odoo/addons/base/models/ir_actions.py", line 191, in _for_xml_id
record = self.env.ref(full_xml_id)
File "odoo/api.py", line 580, in ref
res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
File "odoo/addons/base/models/ir_model.py", line 2188, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)
File "<decorator-gen-43>", line 2, in _xmlid_lookup
File "odoo/tools/cache.py", line 104, in lookup
value = d[key] = self.method(*args, **kwargs)
File "odoo/addons/base/models/ir_model.py", line 2181, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
```
This error arises at [1] when it attempts to access the xml id with the view`hr.open_view_employee_tree`but due to recent changes in forward port of master this view has been removed [2] as it wasn't used anywhere; but in [3] `hr.open_view_employee_tree` was used and due to this now the error is generated.
This commit fixes the above issue by using view `hr.open_view_employee_list_my`
instead of the removed view `hr.open_view_employee_tree`.
Link: [1]-https://github.com/odoo/odoo/blob/4126dcc08ef22f2b644559ba24bd4ce093684f1c/addons/hr_expense/models/hr_expense_sheet.py#L638
[2]-https://github.com/odoo/odoo/commit/abd909498e4fd519ff8431ea9d7d09da4fc7c59a
[3]-https://github.com/odoo/odoo/commit/2c0b01e79e81e6a28ca5f610ad14d4cb8fd5d756
sentry-4968357276
opw-3724071
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153766Reverting this commit https://github.com/odoo/odoo/commit/1ea3719ec0ce77c8d24c69179be0accd5655f545 because it's not the right fix. Forward-Port-Of: odoo/odoo#153830
Original PR description
Reverting this commit https://github.com/odoo/odoo/commit/1ea3719ec0ce77c8d24c69179be0accd5655f545 because it's not the right fix. Forward-Port-Of: odoo/odoo#153830
## Description When searching with a domain that contains a relational field whos comodel is `res.users`, with a *pathological* domain of `not ilike` `'some_string'`, the ORM will call a `_name_search` on `res.users` with no limit to resolve the leaf when calling `_where_calc`. The current implementation in the `web` module overrides the `_name_search` to implement a spec to propose the current user as a first suggestion, but to do that it first execute the query (the list conversion), and then
Original PR description
## Description When searching with a domain that contains a relational field whos comodel is `res.users`, with a *pathological* domain of `not ilike` `'some_string'`, the ORM will call a…
## Description When searching with a domain that contains a relational field whos comodel is `res.users`, with a *pathological* domain of `not ilike` `'some_string'`, the ORM will call a `_name_search` on `res.users` with no limit to resolve the leaf when calling `_where_calc`. The current implementation in the `web` module overrides the `_name_search` to implement a spec to propose the current user as a first suggestion, but to do that it first execute the query (the list conversion), and then manipulates the list of ids to insert the current user first. (1c2ce8c213754aa47c51d68b6a8acd4770588864) On large databases with many `res.users`, where the condition matches all users besides 1, this is a probably Seq.Scan on the `res_users` table. Then this gigantic list of `ids` will be injected by the ORM into the main query to satisfy the original domain. This incurs not only bandwidth costs, but also usually leads to bad plans, ending up most likely into a Seq.Scan on the original table. The worse of it, in the case of a `web_search_read`, there is a `search_count`, so this whole fiasco is repeated once more. The nail in the coffin, is that the result isn't even needed, when resolving a comodel's `_name_search`, we care about the subset, the internal order is irrelevant. ## Solution The ORM calls the `_name_search` without a limit, while in general the `name_search` is called with a limit from the front-end, therefor we can use it as a discriminant -> If no limit, don't suggest `uid` first. ## Affected versions saas-16.3 -> master (saas-17.2) ## Reference task-3610657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152488
Steps to reproduce =================== 1. Create single-line questions like numbers and single-line text. 2. Test the survey. 3. Press the 'enter' key on a single line input. The form reloads and does not submit. Technical ========== With commit https://github.com/odoo/odoo/commit/7109f480ec27e929a43c4bae78912bad42458e90, a next button is added before the submit button, so when you press enter on single-line questions the first button of the form is clicked which refreshes the page w
Original PR description
Steps to reproduce =================== 1. Create single-line questions like numbers and single-line text. 2. Test the survey. 3. Press the 'enter' key on a single line input. The form reloads and does not submit. Technical ========== With commit https://github.com/odoo/odoo/commit/7109f480ec27e929a43c4bae78912bad42458e90, a next button is added before the submit button, so when you press enter on single-line questions the first button of the form is clicked which refreshes the page without any action. Ref-https://github.com/odoo/odoo/blob/66b4e080e29551d1c74cdc4b3d9ccba92ce81dd1/addons/survey/static/src/js/survey_form.js#L116 After this PR ================= We can submit the form with the 'enter' key from single-line input. Task-3650231 Forward-Port-Of: odoo/odoo#149003
**Steps to reproduce:** - Open any course. - Open full-screen window. - Click on exit fullscreen - The progress bar color is mixed up with the background. **Issue:** In Odoo primary color is changed from v17.0 **Solution:** Applied bg-info class to progress bar for better visibility. **Task**-3721175 Forward-Port-Of: odoo/odoo#152815
Original PR description
**Steps to reproduce:** - Open any course. - Open full-screen window. - Click on exit fullscreen - The progress bar color is mixed up with the background. **Issue:** In Odoo primary color is changed from v17.0 **Solution:** Applied bg-info class to progress bar for better visibility. **Task**-3721175 Forward-Port-Of: odoo/odoo#152815
task-3725221 Forward-Port-Of: odoo/odoo#154006
Original PR description
task-3725221 Forward-Port-Of: odoo/odoo#154006
Forward-Port-Of: odoo/odoo#154195
Original PR description
Forward-Port-Of: odoo/odoo#154195
In this commit ============================================= Before if all the lines were of service the error was displayed in a banner after error in response was received, but now before sending request the lines are checked if at least one line is of product and error is raised. Issue in this: https://github.com/odoo/odoo/pull/153522/commits/c81595db6a7a135a3289751a9b881b2f947bc6d2 Forward-Port-Of: odoo/odoo#154120
Original PR description
In this commit ============================================= Before if all the lines were of service the error was displayed in a banner after error in response was received, but now before sending request the lines are checked if at least one line is of product and error is raised. Issue in this: https://github.com/odoo/odoo/pull/153522/commits/c81595db6a7a135a3289751a9b881b2f947bc6d2 Forward-Port-Of: odoo/odoo#154120
Install `l10n_ar` Switch to an AR company Create a new currency => the field `l10n_ar_afip_code` is not visible Go on an existing one => it is visible The compute is not triggered before the save. We should add a default to have the fiscal_code. We can even remove the compute (and keep the store=False), to avoid duplicating the code. Linked to runbot error 45392, 45417 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after
Original PR description
Install `l10n_ar` Switch to an AR company Create a new currency => the field `l10n_ar_afip_code` is not visible Go on an existing one => it is visible The compute is not triggered before the save. We should add a default to have the fiscal_code. We can even remove the compute (and keep the store=False), to avoid duplicating the code. Linked to runbot error 45392, 45417 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#153521
Steps to reproduce: ------------------- 1. Install sale_project with demo data 2. Create a user with no access rights other than Project/User 3. With that user, navigate to the 'AGR - S00064 - Sales Order' project > Project Update 4. In the Right Side Panel, at the bottom of the 'Sale Order Items' section, click on 'Load More' This will give an access rights error. The reason is that while we load the first five SOLs with sudo rights, we don't use sudo for subsequents items, thus leadin
Original PR description
Steps to reproduce: ------------------- 1. Install sale_project with demo data 2. Create a user with no access rights other than Project/User 3. With that user, navigate to the 'AGR - S00064 - Sales Order' project > Project Update 4. In the Right Side Panel, at the bottom of the 'Sale Order Items' section, click on 'Load More' This will give an access rights error. The reason is that while we load the first five SOLs with sudo rights, we don't use sudo for subsequents items, thus leading to an access right error. This PR adds two sudos to avoid that error. Forward-Port-Of: odoo/odoo#154025
## Description Domains of the form ```python [('stored_Many2X.id', '=/!=/in/not in', list_of_ids)] ``` will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table. There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
## Fix
Remove the `.id` from left leafs of domains that if the field is stored, and the `comodel` doesn't have `ir.rule` associated with it, or the `ir.rule` application is redundant/not needed.
task-3735923
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#153464Since PR #137969, the `save` button is no longer available in schedule activity wizard. This PR makes `schedule` button available for call activities like other activities (except meeting), so user can create a call activity without going to calendar view. Before this PR:  After this PR:  task-3668732
Original PR description
Since PR #137969, the `save` button is no longer available in schedule activity wizard. This PR makes `schedule` button available for call activities like other activities (except meeting), so user can create a call activity without going to calendar view. Before this PR:  After this PR:  task-3668732 Forward-Port-Of: odoo/odoo#152893
This fixes a bug where trying to set the default name value of an expense report when created from the expense tree view would traceback. Step to reproduce: - Create 2+ new expenses having the same payment_mode (E.G. 'own_account') - Clear the date field of an expense so at least one of the expense has a date and one has no date - Press the 'Create Report' button on the expense tree view Current behaviour: Traceback due to bool > Date comparison Expected behaviour: We don't set a d
Original PR description
This fixes a bug where trying to set the default name value of an expense report when created from the expense tree view would traceback. Step to reproduce: - Create 2+ new expenses having the same payment_mode (E.G. 'own_account') - Clear the date field of an expense so at least one of the expense has a date and one has no date - Press the 'Create Report' button on the expense tree view Current behaviour: Traceback due to bool > Date comparison Expected behaviour: We don't set a default report name, as it is required the user will be forced to set one manually. 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#154062 Forward-Port-Of: odoo/odoo#152852
Steps to reproduce ================== - Install account_accountant - Go to settings - Enable Budget Management - Go to Accounting > Reporting > Management > Budgets Analysis - Switch to the graph view - Change the measure to "Planned amount" and then back to "Practical amount" => The practical_amount measure is undefined, The theoritical_amount measure is missing. Cause of the issue ================== The view is defined as follows: ```xml <graph string="Budget Lines"
Original PR description
Steps to reproduce ================== - Install account_accountant - Go to settings - Enable Budget Management - Go to Accounting > Reporting > Management > Budgets Analysis - Switch to the graph…
Steps to reproduce
==================
- Install account_accountant
- Go to settings
- Enable Budget Management
- Go to Accounting > Reporting > Management > Budgets Analysis
- Switch to the graph view
- Change the measure to "Planned amount" and then back to "Practical amount"
=> The practical_amount measure is undefined,
The theoritical_amount measure is missing.
Cause of the issue
==================
The view is defined as follows:
```xml
<graph string="Budget Lines" sample="1">
<field name="crossovered_budget_id" type="row"/>
<field name="planned_amount" type="measure" string="Planned amount"/>
<field name="theoritical_amount" type="measure" string="Theoretical amount"/>
<field name="practical_amount" type="measure" string="Practical amount"/>
</graph>
```
The theoritical_amount and practical_amount are non stored fields and thus are skipped inside `computeReportMeasures` unless they are passed in `activeMeasures | additionalMeasures`. [0]
When parsing the graph view, the last field of type measure is passed to the graph model and is the one that will be used initially. [1]
This is why the practical_amount is initially defined.
Solution
========
We simply need to keep track of fields of type measure. This was the case in 14.0 but got lost in the conversion.
---
[0]: https://github.com/odoo/odoo/blob/e7a9ebec3176c37485643fcda2381e489a1df86f/addons/web/static/src/views/helpers/utils.js#L49-L60
[1]: https://github.com/odoo/odoo/blob/0fb64bef16914937cf4a1d1618fb58ade6d16f14/addons/web/static/src/views/graph/graph_arch_parser.js#L63
opw-3713613
Forward-Port-Of: odoo/odoo#153967
Forward-Port-Of: odoo/odoo#153599Description of the issue/feature this PR addresses: This commit allow to inherit the method _get_orderpoint_locations to filter in which location compute orderpoints imrpoving performance and usability --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150256
Original PR description
Description of the issue/feature this PR addresses: This commit allow to inherit the method _get_orderpoint_locations to filter in which location compute orderpoints imrpoving performance and usability --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150256
**Current behavior:** Creating a new company and trying to switch to the l10n_ee accounting localization package will result in a validation error, preventing the installation. **Expected behavior:** The package should be installed and automatically activated for the active company. **Steps to reproduce:** 0. Install the l10n_ee accounting module 1. Create a new company such that no fiscal localization package is active by default, then switch to this new company in the selection in
Original PR description
**Current behavior:** Creating a new company and trying to switch to the l10n_ee accounting localization package will result in a validation error, preventing the installation. **Expected behavior:**…
**Current behavior:** Creating a new company and trying to switch to the l10n_ee accounting localization package will result in a validation error, preventing the installation. **Expected behavior:** The package should be installed and automatically activated for the active company. **Steps to reproduce:** 0. Install the l10n_ee accounting module 1. Create a new company such that no fiscal localization package is active by default, then switch to this new company in the selection in the top right 2. In Accounting settings, select the Estonia fiscal localization package and save (this causes the exception) **Cause of the issue:** Certain tax accounts in the module do not have their names fully updated. They all were labeled as "0% ..." instead of their true percentages like all other tax accounts. **Fix:** Update the names of the offending tax accounts so that they are fully reflective of their true %. Associated with https://github.com/odoo/enterprise/pull/56496 opw-3683538 Forward-Port-Of: odoo/odoo#151515
Current behavior: When you make an order in the PoS with different lots for the same product, the lots are not correctly selected in the picking. And only one lot is affected by the order. Steps to reproduce: - Create a product with tracking by lot, and 2 lots with some quantity - Create a PoS order with 2 lines of the same product, and select a different lot for each line - Validate the order - Close the PoS session - Check the picking, and the lot quantities Note: This partly reve
Original PR description
Current behavior: When you make an order in the PoS with different lots for the same product, the lots are not correctly selected in the picking. And only one lot is affected by the order. Steps to reproduce: - Create a product with tracking by lot, and 2 lots with some quantity - Create a PoS order with 2 lines of the same product, and select a different lot for each line - Validate the order - Close the PoS session - Check the picking, and the lot quantities Note: This partly revert this part of commit : https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81#diff-0ef4eb66998f308afe5f09748bc2af04ad79e9647507c25fe9007e03a79a1249L265-L303 And also make sure that the original created line quantity is set to 0 so that the each lot has a line, and the total quantity is correct. opw-3621363 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148517
Prior to this commit, automatic printing was only functional when a printer was configured with the Point of Sale. It did not support web printing. This commit rectifies this issue, allowing automatic printing to work seamlessly with or without a physical printer setup, supporting web printing. opw-3706400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154066
Original PR description
Prior to this commit, automatic printing was only functional when a printer was configured with the Point of Sale. It did not support web printing. This commit rectifies this issue, allowing automatic printing to work seamlessly with or without a physical printer setup, supporting web printing. opw-3706400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154066
Before this commit, all members are not received through invitation notification, leading to badly named channel when its name depends on members. This commits fixes the issue by fetching full channel info whenever necessary. Forward-Port-Of: odoo/odoo#153533
Original PR description
Before this commit, all members are not received through invitation notification, leading to badly named channel when its name depends on members. This commits fixes the issue by fetching full channel info whenever necessary. Forward-Port-Of: odoo/odoo#153533
1. Make sure to return archived users in partner format. 2. Remove the condition to check for archived users in suggestion code. The condition made no sense since the refactoring (that's the opposite of what we want, and it didn't compare the partner records correctly). The feature is broken since https://github.com/odoo/odoo/pull/133065/ because it "fixed" the way records are compared. Making the condition we don't want in the first place actually working and excluding OdooBot (ins
Original PR description
1. Make sure to return archived users in partner format. 2. Remove the condition to check for archived users in suggestion code. The condition made no sense since the refactoring (that's the opposite of what we want, and it didn't compare the partner records correctly). The feature is broken since https://github.com/odoo/odoo/pull/133065/ because it "fixed" the way records are compared. Making the condition we don't want in the first place actually working and excluding OdooBot (instead of allowing it). 3. Since archived partners are displayed anyway since the refactoring, and nobody complained, let's consider it a wanted feature. Archived partners are given lowest priority and moved to the bottom. task-3747277 Forward-Port-Of: odoo/odoo#154228 Forward-Port-Of: odoo/odoo#154078
You have to unlock the order before cancelling it. Introduced by 17bece3e797913bcba8dd7e07fc8541c0a45e3f7 Fixes #153987 Forward-Port-Of: odoo/odoo#154259
Original PR description
You have to unlock the order before cancelling it. Introduced by 17bece3e797913bcba8dd7e07fc8541c0a45e3f7 Fixes #153987 Forward-Port-Of: odoo/odoo#154259
Steps to reproduce: - - Calendar > create an all_day meeting with an additional attendee - Save > Edit > change starting date to a later day > traceback Cause of the issue: - The write call of the method _onchange_date is applied to a pseudo record. However, the write method expects a record with an integer id to correctly _send_mail_to_attendees down the line. https://github.com/odoo/odoo/blob/31100f22ad7e31daea65de446439b090f70ad9de/addons/calendar/models/calendar_event.py#L548-L556
Original PR description
Steps to reproduce: - - Calendar > create an all_day meeting with an additional attendee - Save > Edit > change starting date to a later day > traceback Cause of the issue: - The write call of the method _onchange_date is applied to a pseudo record. However, the write method expects a record with an integer id to correctly _send_mail_to_attendees down the line. https://github.com/odoo/odoo/blob/31100f22ad7e31daea65de446439b090f70ad9de/addons/calendar/models/calendar_event.py#L548-L556 Fix: - Since we don't want to send_mail_to_attendees anyway, we skip this part of the write method using the already existing contextual escape 'is_calendar_event_new'. opw-3733753 - --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154095 Forward-Port-Of: odoo/odoo#153430
Issue: ------ On the calendar application, it is not possible to create a 15-minute event directly from a selection using the mouse. An event with a default duration of one hour is created. Cause: ------ The fullcalendar library detects two events: - a date selection - a click The date selection is correct, but the size of the "rectangle" is the same (15 minutes is the smallest unit in terms of size). As a result, a click using a default time is detected. Solution: ---------
Original PR description
Issue: ------ On the calendar application, it is not possible to create a 15-minute event directly from a selection using the mouse. An event with a default duration of one hour is created. Cause: ------ The fullcalendar library detects two events: - a date selection - a click The date selection is correct, but the size of the "rectangle" is the same (15 minutes is the smallest unit in terms of size). As a result, a click using a default time is detected. Solution: --------- We can use `preventDefault` to block the second event (the click) because the event is the same. Note: ----- This fix is safer than patching the `FullCalendar` library (which may change in future versions). opw-3743945 Forward-Port-Of: odoo/odoo#154135
'date_deadline' is always present in a 'stock.move' and in some specific cases, can prevent the merge of moves in the same transfer. In the example bellow, new moves are added to the same transfer every day (for each scheduler run), but the moves are not merged together. There is 2 thing we could d oto fix this situation: - Create a new transfer for each date_deadline - Merge the move with distinct date_deadline Usually, it makes sense to not merge moves with distinct date_deadline, but it
Original PR description
'date_deadline' is always present in a 'stock.move' and in some specific cases, can prevent the merge of moves in the same transfer. In the example bellow, new moves are added to the same transfer…
'date_deadline' is always present in a 'stock.move' and in some specific cases, can prevent the merge of moves in the same transfer. In the example bellow, new moves are added to the same transfer every day (for each scheduler run), but the moves are not merged together. There is 2 thing we could d oto fix this situation: - Create a new transfer for each date_deadline - Merge the move with distinct date_deadline Usually, it makes sense to not merge moves with distinct date_deadline, but it also makes sense to not create a new resupply transfer every day. So for now, we treat this situation as a limitation, but we still provide a workaround: By adding a system parameter, we give the possibility to the user to ignore the date_deadline when merging moves. ## HOW TO REPRODUCE: - Create new Warehouse 'Warehouse 2' WH2 - Create Custom Route to resupply 'WH/Stock' from 'Transit' From 'WH2/stock' (see screenshot) - Create product P1 (storable, with custom route selected) - Create reordering rule on default warehouse, with min=1, max=1, route=custom route - Create Sale Order for 10 units of P1, confirm => New Receipt from 'Transit' -> 'WH/Stock' generated - Wait 1 day (alternative is to increment the Lead Time on the Stock Rules). - Create Sale Order for 10 units of P1, confirm => Same Receipt used, 2 lines are present. OPW-3633551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154276 Forward-Port-Of: odoo/odoo#151499
The model `l10n_pl_tax_office` has a group to be able to access it. The Many2one that refers to it, `l10n_pl_reports_tax_office_id`, does not. Currently, it is not really an issue as the accounting's settings are invisible if you don't have the group, but it creates a warning in a test and is more robust Linked to runbot error 24602, 24721 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154294 Forward-Port-Of: odoo/
Original PR description
The model `l10n_pl_tax_office` has a group to be able to access it. The Many2one that refers to it, `l10n_pl_reports_tax_office_id`, does not. Currently, it is not really an issue as the accounting's settings are invisible if you don't have the group, but it creates a warning in a test and is more robust Linked to runbot error 24602, 24721 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154294 Forward-Port-Of: odoo/odoo#153660
In Peppol Bis 3, the value on PartyTaxScheme/CompanyID should be prefixed with a 2 letters code representing the country of the partner. Currently, filling a VAT without this country code will lead to the error: "[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the pr
Original PR description
In Peppol Bis 3, the value on PartyTaxScheme/CompanyID should be prefixed with a 2 letters code representing the country of the partner. Currently, filling a VAT without this country code will lead…
In Peppol Bis 3, the value on PartyTaxScheme/CompanyID should be prefixed with a 2 letters code representing the country of the partner. Currently, filling a VAT without this country code will lead to the error: "[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’." On the other hand, some extra-european countries use Peppol Bis 3 but do not prepend their VAT with the country code (i.e. Australia). To allow such cases, we automatically add the country code when it's missing. To prevent regression, we also add a contraint mimicking the schematron: we check that the final value of the PartyTaxScheme/CompanyID is prefixed with a 2 letters code. This way, the constraint is independant from the code. Forward-Port-Of: odoo/odoo#154233 Forward-Port-Of: odoo/odoo#151352
CLA for enterprise PR --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154317 Forward-Port-Of: odoo/odoo#153820
Original PR description
CLA for enterprise PR --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154317 Forward-Port-Of: odoo/odoo#153820
### Steps to reproduce issue: 1. Select a Contact 2. Click on Smart Button "Loyalty Cards" 3. Create a new Loyalty Coupon 4. Save 5. Receive an error: > The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead. > > Model: Loyalty Coupon (loyalty.card) > Constraint: loyalty_card_program_id_fkey ### Explanation: The model given to `program_id` by the `default` attribute is not always `loyalty.program`. In the
Original PR description
### Steps to reproduce issue: 1. Select a Contact 2. Click on Smart Button "Loyalty Cards" 3. Create a new Loyalty Coupon 4. Save 5. Receive an error: > The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead. > > Model: Loyalty Coupon (loyalty.card) > Constraint: loyalty_card_program_id_fkey ### Explanation: The model given to `program_id` by the `default` attribute is not always `loyalty.program`. In the case of the issue, for example, the model is `res.partner`. https://github.com/odoo/odoo/blob/a3201d636505dc1976d3f0ee7f8cbf65d2488966/addons/loyalty/models/loyalty_card.py#L27 ### Suggested fix: The creation of `loyalty.card` from `res.partner` Smart Button is not intended, therefore we will remove this option and set the Smart Button as invisible if `loyalty_card_count` is null. opw-3707588 Forward-Port-Of: odoo/odoo#154258 Forward-Port-Of: odoo/odoo#152644
This commit follows [1], which attempted to fix CORS errors occurring when we access the `cssRules` property of stylesheets, to detect scss compilation errors and display a warning to the user. [1] doesn't seem to be enough, as we faced another source of CORS errors. Indeed, in non-secure http, the error is raised even if the origin is the same. We never want this access to crash anyway, as it's a nice to have feature, and if reading `cssRules` is forbidden, there's nothing the user can do
Original PR description
This commit follows [1], which attempted to fix CORS errors occurring when we access the `cssRules` property of stylesheets, to detect scss compilation errors and display a warning to the user. [1] doesn't seem to be enough, as we faced another source of CORS errors. Indeed, in non-secure http, the error is raised even if the origin is the same. We never want this access to crash anyway, as it's a nice to have feature, and if reading `cssRules` is forbidden, there's nothing the user can do anyway. For those reasons, we decided to simply protect the code with a try/catch. [1] odoo/odoo#152696 opw 3746910 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#154347
**Steps to reproduce** 1. Visit the website and open the event tab. 2. Access an event with the talks and exhibitor sub-menu. 3. Select the talks sub-menu and search for a talk -> Even if the talk exists, the search count shows zero -> The same thing happens in the exhibitor sub-menu **Technical** When searching for the talk or the exhibitor we didn't send the search_count due to this, it is always showing zero. A variable `sponsors` is renamed to `sorted_sponsors` as it was redeclar
Original PR description
**Steps to reproduce** 1. Visit the website and open the event tab. 2. Access an event with the talks and exhibitor sub-menu. 3. Select the talks sub-menu and search for a talk -> Even if the talk exists, the search count shows zero -> The same thing happens in the exhibitor sub-menu **Technical** When searching for the talk or the exhibitor we didn't send the search_count due to this, it is always showing zero. A variable `sponsors` is renamed to `sorted_sponsors` as it was redeclared in the loop before the return dict **After this PR** Now the search_count will display the accurate result. Task-3659940 Forward-Port-Of: odoo/odoo#147876
It's confusing to allow resubmitting electronic invoices. When invoices are rejected the user will probably make changes to them in Odoo. Resubmitting will use the old, saved tax response data in l10n_br_edi_avatax_data which won't be correct anymore for the new configuration. Instead, the user should reset to draft, redo tax computation and then resubmit. task-3711015 Forward-Port-Of: odoo/enterprise#56576
Original PR description
It's confusing to allow resubmitting electronic invoices. When invoices are rejected the user will probably make changes to them in Odoo. Resubmitting will use the old, saved tax response data in l10n_br_edi_avatax_data which won't be correct anymore for the new configuration. Instead, the user should reset to draft, redo tax computation and then resubmit. task-3711015 Forward-Port-Of: odoo/enterprise#56576
Before this, a subscription with partial exemptions wouldn't be automatically invoiced. It's caused by field dependencies added by sale_subscription that cause the order totals to be recomputed after confirmation. More specifically, sale.order.line.discount is made to depend on subscription_state, which gets written to during action_confirm(). Because of this _invoice_sale_orders() will filter out the payment transaction because _get_partial_payment_subscription_transaction() considers it a p
Original PR description
Before this, a subscription with partial exemptions wouldn't be automatically invoiced. It's caused by field dependencies added by sale_subscription that cause the order totals to be recomputed after confirmation. More specifically, sale.order.line.discount is made to depend on subscription_state, which gets written to during action_confirm(). Because of this _invoice_sale_orders() will filter out the payment transaction because _get_partial_payment_subscription_transaction() considers it a partial payment. opw-3562613 Forward-Port-Of: odoo/enterprise#55579
Create a branch In the system parameters, switch account_online_synchronization.proxy_mode to sandbox Add a bank with plaid for example and follow the different steps Switch to the branch only and try to access the accounting app Access error raises: """ Sorry, Mitchell Admin (id=2) doesn't have 'read' access to: - Bank Connection, Plaid (account.online.link: 2, company=parent nico) Blame the following rules: - Account online link company rule Note: this might be a multi-company
Original PR description
Create a branch In the system parameters, switch account_online_synchronization.proxy_mode to sandbox Add a bank with plaid for example and follow the different steps Switch to the branch only and try to access the accounting app Access error raises: """ Sorry, Mitchell Admin (id=2) doesn't have 'read' access to: - Bank Connection, Plaid (account.online.link: 2, company=parent nico) Blame the following rules: - Account online link company rule Note: this might be a multi-company issue. Switching company may help - in Odoo, not in real life! If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. """ This occurs because the mentioned record rule allow access to the `account.online.link` record only from the same company opw-3725198 Forward-Port-Of: odoo/enterprise#56136
How to reproduce: - Open a planned transfer in the Barcode App; - Scan a non-reserved product => A confirmation dialog is shown; - Discard or close the confirmation dialog => Traceback! It happens because rejected promises have to be handle which is not the case here. To fix that, resolve the promise anyway. task-3677142 Forward-Port-Of: odoo/enterprise#55979
Original PR description
How to reproduce: - Open a planned transfer in the Barcode App; - Scan a non-reserved product => A confirmation dialog is shown; - Discard or close the confirmation dialog => Traceback! It happens because rejected promises have to be handle which is not the case here. To fix that, resolve the promise anyway. task-3677142 Forward-Port-Of: odoo/enterprise#55979
Bug === 1. Open the comments modal of a LInkedIn post 2. Click on "Reply" on a comment without answer => Traceback Task-3748995 Forward-Port-Of: odoo/enterprise#56773 Forward-Port-Of: odoo/enterprise#56689
Original PR description
Bug === 1. Open the comments modal of a LInkedIn post 2. Click on "Reply" on a comment without answer => Traceback Task-3748995 Forward-Port-Of: odoo/enterprise#56773 Forward-Port-Of: odoo/enterprise#56689
Fix translation for account_asset / wizard There was fixed strings without translation - gain - loss - gain/loss Forward-Port-Of: odoo/enterprise#56774 Forward-Port-Of: odoo/enterprise#56481
Original PR description
Fix translation for account_asset / wizard There was fixed strings without translation - gain - loss - gain/loss Forward-Port-Of: odoo/enterprise#56774 Forward-Port-Of: odoo/enterprise#56481
On a view, drag and drop a new related field. Go into one m2o field. Before this commit, it was possible to select a field of type "properties". This is not supported by python at the time. To do so, one would have to reflect the property "definition" of the python field. Also, some code would have to be written to create that other field, related as well that'd contain the properties' definition. After this commit, to make things simpler, we just blacklist property fields in the related
Original PR description
On a view, drag and drop a new related field. Go into one m2o field. Before this commit, it was possible to select a field of type "properties". This is not supported by python at the time. To do so, one would have to reflect the property "definition" of the python field. Also, some code would have to be written to create that other field, related as well that'd contain the properties' definition. After this commit, to make things simpler, we just blacklist property fields in the related field selector. opw-3730900 Forward-Port-Of: odoo/enterprise#56749 Forward-Port-Of: odoo/enterprise#56597
### Before: Before this fix, entering a search term in the bar caused pagination to malfunction. The issue stemmed from the offset not resetting to 0 upon entering a search term, leading to incorrect behavior. Additionally, the total count failed to update with search inputs. ### After: This PR resolves the issue by resetting the offset to 0 upon search term entry and updating the total count using the domain passed to the _fetchPagerTotal method. Task ID: [3631981](https://www.odoo
Original PR description
### Before: Before this fix, entering a search term in the bar caused pagination to malfunction. The issue stemmed from the offset not resetting to 0 upon entering a search term, leading to incorrect behavior. Additionally, the total count failed to update with search inputs. ### After: This PR resolves the issue by resetting the offset to 0 upon search term entry and updating the total count using the domain passed to the _fetchPagerTotal method. Task ID: [3631981](https://www.odoo.com/web#id=3631981&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#56669 Forward-Port-Of: odoo/enterprise#53122
We got a feedback from a Belgian partner that we don't have a xml declaration in the xml report. opw-3745820 Forward-Port-Of: odoo/enterprise#56764 Forward-Port-Of: odoo/enterprise#56727
Original PR description
We got a feedback from a Belgian partner that we don't have a xml declaration in the xml report. opw-3745820 Forward-Port-Of: odoo/enterprise#56764 Forward-Port-Of: odoo/enterprise#56727
For email address to be considered in the UPS request, the `M` needs to be capitalized. UPS documentation for reference: UPS documentation for reference: https://developer.ups.com/api/reference?loc=en_US#operation/Shipment!path=ShipmentRequest/Shipment/ShipTo/EMailAddress&t=request opw-3487959 Forward-Port-Of: odoo/enterprise#56475
Original PR description
For email address to be considered in the UPS request, the `M` needs to be capitalized. UPS documentation for reference: UPS documentation for reference: https://developer.ups.com/api/reference?loc=en_US#operation/Shipment!path=ShipmentRequest/Shipment/ShipTo/EMailAddress&t=request opw-3487959 Forward-Port-Of: odoo/enterprise#56475
Purpose ======= defaultdict.get(key) returns None if the key doesn't exist instead of default factory value This could lead to traceback in rules like result = categories.get("BASIC") + categories.get("ALW") Easily fixed with result = categories.get("BASIC", 0) + categories.get("ALW", 0) or better result = categories["BASIC"] + categories["ALW"] But could be more robust, find a way to override get or use try catch to return default value instead of None Forward-Port-Of: odoo
Original PR description
Purpose
=======
defaultdict.get(key) returns None if the key doesn't exist instead of default factory value
This could lead to traceback in rules like
result = categories.get("BASIC") + categories.get("ALW")
Easily fixed with
result = categories.get("BASIC", 0) + categories.get("ALW", 0) or better
result = categories["BASIC"] + categories["ALW"]
But could be more robust, find a way to override get or use try catch to return default value instead of None
Forward-Port-Of: odoo/enterprise#56501
Forward-Port-Of: odoo/enterprise#56384Steps to reproduce: 1. install `l10n_pos_res_cert` and set up Fiskaly 2. set up a PoS restaurant 3. set the language to German 4. open a PoS session and make an order error: ``` error parsing request body: amounts_per_vat_rate.0.amount: Does not match pattern '^-?\d+(.\d{2,5})$' ``` The issue is similar to that fixed in https://github.com/odoo/enterprise/pull/46682 It comes from the fact that formatCurrency method is used to convert the amounts to string. However it adds language
Original PR description
Steps to reproduce:
1. install `l10n_pos_res_cert` and set up Fiskaly
2. set up a PoS restaurant
3. set the language to German
4. open a PoS session and make an order
error:
```
error parsing request body: amounts_per_vat_rate.0.amount: Does not match pattern '^-?\d+(.\d{2,5})$'
```
The issue is similar to that fixed in https://github.com/odoo/enterprise/pull/46682
It comes from the fact that formatCurrency method is used to convert the amounts to string. However it adds language specific formatting. In this case Fiskaly expects `12.50` but `12,50` is sent.
opw-3724456
Forward-Port-Of: odoo/enterprise#56619
Forward-Port-Of: odoo/enterprise#56498**Current behavior:** Creating a new company and trying to switch to the l10n_ee accounting localization package will result in a validation error, preventing the installation. **Expected behavior:** The package should be installed and automatically activated for the active company. **Steps to reproduce:** 0. Install the l10n_ee accounting module 1. Create a new company such that no fiscal localization package is active by default, then switch to this new company in the selection in
Original PR description
**Current behavior:** Creating a new company and trying to switch to the l10n_ee accounting localization package will result in a validation error, preventing the installation. **Expected behavior:**…
**Current behavior:** Creating a new company and trying to switch to the l10n_ee accounting localization package will result in a validation error, preventing the installation. **Expected behavior:** The package should be installed and automatically activated for the active company. **Steps to reproduce:** 0. Install the l10n_ee accounting module 1. Create a new company such that no fiscal localization package is active by default, then switch to this new company in the selection in the top right 2. In Accounting settings, select the Estonia fiscal localization package and save (this causes the exception) **Cause of the issue:** Certain tax accounts in the module do not have their names fully updated. They all were labeled as "0% ..." instead of their true percentages like all other tax accounts. **Fix:** Update the names of the offending tax accounts so that they are fully reflective of their true %. Associated with https://github.com/odoo/odoo/pull/151515 opw-3683538 Forward-Port-Of: odoo/enterprise#56496
- According the SRI, the payment method is available in customer and vendor documents (invoices, debit notes and purchase liquidation), we leave it visible in view and pdf report for the documents excluding credit notes Forward-Port-Of: odoo/enterprise#56447 Forward-Port-Of: odoo/enterprise#52855
Original PR description
- According the SRI, the payment method is available in customer and vendor documents (invoices, debit notes and purchase liquidation), we leave it visible in view and pdf report for the documents excluding credit notes Forward-Port-Of: odoo/enterprise#56447 Forward-Port-Of: odoo/enterprise#52855
Steps to reproduce: - Change language to French for example - Install accounting - Go to the "Tax Report" - Options will display "With Draft Entries" or "Posted Entries Only" Issue: The terms are not exported since we were using t-esc. Cause: Replace the ternary operator with an t-if and t-else. opw-3356916 Forward-Port-Of: odoo/enterprise#55952 Forward-Port-Of: odoo/enterprise#53142
Original PR description
Steps to reproduce: - Change language to French for example - Install accounting - Go to the "Tax Report" - Options will display "With Draft Entries" or "Posted Entries Only" Issue: The terms are not exported since we were using t-esc. Cause: Replace the ternary operator with an t-if and t-else. opw-3356916 Forward-Port-Of: odoo/enterprise#55952 Forward-Port-Of: odoo/enterprise#53142
When a subscription code is already linked to a database and you try to use it on another database, the message displaying that this subscription code is already used and provides the informations of what to do is not correctly displayed. Forward-Port-Of: odoo/enterprise#56618 Forward-Port-Of: odoo/enterprise#47326
Original PR description
When a subscription code is already linked to a database and you try to use it on another database, the message displaying that this subscription code is already used and provides the informations of what to do is not correctly displayed. Forward-Port-Of: odoo/enterprise#56618 Forward-Port-Of: odoo/enterprise#47326
Following the fix done in #50763, this changes achieves a better behavior of the fix, where we make a better calculation to know when we should rotate the text when we don't have space to display it horizontally. Forward-Port-Of: odoo/enterprise#56151
Original PR description
Following the fix done in #50763, this changes achieves a better behavior of the fix, where we make a better calculation to know when we should rotate the text when we don't have space to display it horizontally. Forward-Port-Of: odoo/enterprise#56151
How to reproduce: 1. Select a file/doc. 2. click on the split tool button 3. opens the PDF split view 4. press control+k (shows command palette) Before this commit: List all the commands, but those which are related to 'DocumentsKanbanRenderer' are not working. Technical Reason: PDF splitter is a dialog, the context of the Kanban Renderer stays in the background, 'Select all' and other command logic related to the 'DocumentsKanbanRenderer', do not work in PdfManager because of not ha
Original PR description
How to reproduce: 1. Select a file/doc. 2. click on the split tool button 3. opens the PDF split view 4. press control+k (shows command palette) Before this commit: List all the commands, but those which are related to 'DocumentsKanbanRenderer' are not working. Technical Reason: PDF splitter is a dialog, the context of the Kanban Renderer stays in the background, 'Select all' and other command logic related to the 'DocumentsKanbanRenderer', do not work in PdfManager because of not having the state of it. After this commit: Showing commands related to the PdfManager only. Task-3623653 Forward-Port-Of: odoo/enterprise#53438
To reproduce: Having installed `l10n_mx_edi_landing`, go to landed costs. Create a new one => `l10n_mx_edi_customs_number` is not visible The reason being that the `fiscal_country_code` is not computed at creation. We should add a default. Forward-Port-Of: odoo/enterprise#56296
Original PR description
To reproduce: Having installed `l10n_mx_edi_landing`, go to landed costs. Create a new one => `l10n_mx_edi_customs_number` is not visible The reason being that the `fiscal_country_code` is not computed at creation. We should add a default. Forward-Port-Of: odoo/enterprise#56296
In odoo/odoo@7e012dd, `_get_custom_rendering_context_values` was refactored and renamed `_get_extra_payment_form_values`. `sale_order_id` was mainly used for reconciliation in the transaction route and was removed from the extra payment form values as it was not needed anymore. Unfortunately, Stripe still needs `sale_order_id` for subscriptions, to compute whether the tokenization is required. This commit adds `sale_order_id` back in the extra payment form values when the Subscription app
Original PR description
In odoo/odoo@7e012dd, `_get_custom_rendering_context_values` was refactored and renamed `_get_extra_payment_form_values`. `sale_order_id` was mainly used for reconciliation in the transaction route and was removed from the extra payment form values as it was not needed anymore. Unfortunately, Stripe still needs `sale_order_id` for subscriptions, to compute whether the tokenization is required. This commit adds `sale_order_id` back in the extra payment form values when the Subscription app is installed. --- Steps to reproduce: 1. Configure Stripe; 2. Create a subscription with at least one recurrent product; 3. Generate a payment link and try to pay. Forward-Port-Of: odoo/enterprise#56623
Install website, knowledge and website_knowledge, open any knowledge article and publish it to website visitor, then as a visitor access the public link of that article. In case the article had a emoji on top, that emoji and the title overlaps. This is a partial revert of commit 7a8fde881229 which introduced those changes in the layout to correct this same bug, also in 16.4, about the title icon and the title text overlapping. Reading the history, it seems that a generic frontend layout pr
Original PR description
Install website, knowledge and website_knowledge, open any knowledge article and publish it to website visitor, then as a visitor access the public link of that article. In case the article had a emoji on top, that emoji and the title overlaps. This is a partial revert of commit 7a8fde881229 which introduced those changes in the layout to correct this same bug, also in 16.4, about the title icon and the title text overlapping. Reading the history, it seems that a generic frontend layout problem arose in 16.4 in july, that 7a8fde881229 fixed the bug but in knowledge only and that since then the generic frontend layout problem got resolved, obsoleting 7a8fde881229 here in december. References: 7a8fde881229 ([FIX] (website_)knowledge: fix various layout issues) Task-3525618 Forward-Port-Of: odoo/enterprise#56439 Forward-Port-Of: odoo/enterprise#52315
When the user tries to sync all the templates from `WhatsApp Business Account` the number of templates in the stat button is not updated. Steps to produce: - Create a `WhatsApp Business Account` - Click on `Sync Templates` Problem: The compute function `_compute_templates_count` is responsible for updating the `templates_count` field. But this compute function has no dependencies on it. So it will be called when the page is reloaded. Solution: The function `button_sync_wha
Original PR description
When the user tries to sync all the templates from `WhatsApp Business Account` the number of templates in the stat button is not updated. Steps to produce: - Create a `WhatsApp Business Account` - Click on `Sync Templates` Problem: The compute function `_compute_templates_count` is responsible for updating the `templates_count` field. But this compute function has no dependencies on it. So it will be called when the page is reloaded. Solution: The function `button_sync_whatsapp_account_templates` returns a `display_notification` for displaying the Template Created and Updated count. After this, we will reload the page using `soft_reload`. Task - 3619128 Forward-Port-Of: odoo/enterprise#51460
Before this commit, clicking on the 'Settle due accounts' button would result in an error. This issue was introduced during a recent refactor. This commit fixes the error, allowing the 'Settle due accounts' functionality to work as expected. opw-3744969 Forward-Port-Of: odoo/enterprise#56592
Original PR description
Before this commit, clicking on the 'Settle due accounts' button would result in an error. This issue was introduced during a recent refactor. This commit fixes the error, allowing the 'Settle due accounts' functionality to work as expected. opw-3744969 Forward-Port-Of: odoo/enterprise#56592
Steps to reproduce: - In the Barcode app - Create a new transfer - Scan a product and validate the picking - Select the picking again (remove the ready filter to see it) - "This picking is already done is displayed" and the validate btn isn't displayed but it's still possible to scan products and validate using barcode command Fix: prevent validate if the picking is already done opw-3547770 Forward-Port-Of: odoo/enterprise#56564 Forward-Port-Of: odoo/enterprise#52764
Original PR description
Steps to reproduce: - In the Barcode app - Create a new transfer - Scan a product and validate the picking - Select the picking again (remove the ready filter to see it) - "This picking is already done is displayed" and the validate btn isn't displayed but it's still possible to scan products and validate using barcode command Fix: prevent validate if the picking is already done opw-3547770 Forward-Port-Of: odoo/enterprise#56564 Forward-Port-Of: odoo/enterprise#52764
When using the timesheet smart button (.. Hours recorded) to navigate from helpdesk team form view to the timesheet grid view, the context is not reused so data are missing in the timesheet view. When creating new row, the project was not set by default and a condition in the `default_get` cold ne be evaluated properly. task-3504557 Forward-Port-Of: odoo/enterprise#56571 Forward-Port-Of: odoo/enterprise#48796
Original PR description
When using the timesheet smart button (.. Hours recorded) to navigate from helpdesk team form view to the timesheet grid view, the context is not reused so data are missing in the timesheet view. When creating new row, the project was not set by default and a condition in the `default_get` cold ne be evaluated properly. task-3504557 Forward-Port-Of: odoo/enterprise#56571 Forward-Port-Of: odoo/enterprise#48796
When we use the mode `on_validation` for deferred entries, the first entry that puts the total amount on the deferred account is happening at the end of the month of the move. When we have a vendor bill on Feb 1, 2024, and the amount is deferred from Feb 1, 2024 to Mar 31, 2024, we will have the following moves: [Feb 29, 2024] $1000 from Expenses to Deferred Expenses [Feb 29, 2024] $500 from Deferred Expenses to Expenses [Mar 31, 2024] $500 from Deferred Expenses to Expenses That me
Original PR description
When we use the mode `on_validation` for deferred entries, the first entry that puts the total amount on the deferred account is happening at the end of the month of the move. When we have a vendor…
When we use the mode `on_validation` for deferred entries, the first entry that puts the total amount on the deferred account is happening at the end of the month of the move. When we have a vendor bill on Feb 1, 2024, and the amount is deferred from Feb 1, 2024 to Mar 31, 2024, we will have the following moves: [Feb 29, 2024] $1000 from Expenses to Deferred Expenses [Feb 29, 2024] $500 from Deferred Expenses to Expenses [Mar 31, 2024] $500 from Deferred Expenses to Expenses That means that during the whole month of February we have the total amount on our Expenses account, except on the last day. In order to improve this, we now defer the original move on the same accounting date of the move, such that during that month at most the deferred part is on the Revenue/Expense account (on the last day). [task-3725621](https://www.odoo.com/web#id=3725621&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#56554 Forward-Port-Of: odoo/enterprise#56052
Avatax doesn't allow all state transitions. For example, if an invoice is committed it can't be committed again. If an invoice is voided, it can't be committed. These state transitions shouldn't happen in Odoo when things go well, but bugs and concurrent access errors can stop any of our normal flows at any point. For example, a subscription gets automatically charged, does the payment, generates the invoice and commits the invoice in Avatax. However, the transaction fails to commit in Odoo b
Original PR description
Avatax doesn't allow all state transitions. For example, if an invoice is committed it can't be committed again. If an invoice is voided, it can't be committed. These state transitions shouldn't…
Avatax doesn't allow all state transitions. For example, if an invoice is committed it can't be committed again. If an invoice is voided, it can't be committed. These state transitions shouldn't happen in Odoo when things go well, but bugs and concurrent access errors can stop any of our normal flows at any point. For example, a subscription gets automatically charged, does the payment, generates the invoice and commits the invoice in Avatax. However, the transaction fails to commit in Odoo because of a concurrent access error. Next time an invoice with the same Avatax Code is generated the tax calculation will fail with this error: odoo.exceptions.UserError: Odoo could not fetch the taxes related to Draft Invoice (* 123456) (M123456). Please check the status of `Journal Entry 123456` in the AvaTax portal. DocStatus is invalid for this operation. Errors like this can then break the automatic subscription renewal. Since there's many reasons a flow can crash it's better to make Avatax as idempotent as possible. The source of truth for invoice state is Odoo, regardless of what's in Avatax. To achieve this we'll fully switch to the createoradjust [1] endpoint that was previously introduced for test environments [2]. This endpoint allows almost all state transitions and should avoid the majority of blocking errors. [1] https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/CreateOrAdjustTransaction [2] 12039763a3a8f27a1d69bebb6d661ad20ce3537b cc @tfr-odoo Forward-Port-Of: odoo/enterprise#56573
We revert the PRs below because it generates issues in the accounting application when the ocr is detecting someone else as contact, and it cannot overrule the one we detected in Documents: In odoo/enterprise#39292, we have implemented: If not explicitly defined on the documents.share, when receiving a document by email, we set the contact to the partner corresponding to the email sender. If no partner exists with that email, a new one is created. In odoo/enterprise#50379, we have partial
Original PR description
We revert the PRs below because it generates issues in the accounting application when the ocr is detecting someone else as contact, and it cannot overrule the one we detected in Documents: In…
We revert the PRs below because it generates issues in the accounting application when the ocr is detecting someone else as contact, and it cannot overrule the one we detected in Documents: In odoo/enterprise#39292, we have implemented: If not explicitly defined on the documents.share, when receiving a document by email, we set the contact to the partner corresponding to the email sender. If no partner exists with that email, a new one is created. In odoo/enterprise#50379, we have partially reverted the change: When receiving a document from an unknown contact, we no longer create a new partner. However, if the contact is known, we assign the already existing partner to the document. We revert here the last part that is to assign the author of the message to the document if the author is a known partner. However, we keep the tests introduced in odoo/enterprise#39292 with some minor adaptations. How to reproduce: - install documents with demo data - send an email with an attachment to the inbox alias (that create a document when receiving an email) from an email of an existing partner. It can be simulated using odoo_mail_gate.py. - find the document received and select it - in the document inspector, the contact should be empty but it is not Task-3672520 Forward-Port-Of: odoo/enterprise#56138 Forward-Port-Of: odoo/enterprise#55035
**Steps to reproduce:** 1- Install Documents module 2- Go to documents list view 3- Click on the dropdown menu for additional fields selection **Current behavior before PR:** The dropdown menu for additional fields selection in documents list view is interfered with the table cells so the user will not be able to select the wanted option. This is happening because the table row in this list is having a css value for position property which is relative.  **Desired behavior after PR is merged:** The view has been adjusted by removing the css style for the data-row in document list view.  opw-3682703 Forward-Port-Of: odoo/enterprise#56104 Forward-Port-Of: odoo/enterprise#54854
Records added via a .csv file should always have an ID set, otherwise, they will not have a corresponding xmlid created for them (issue reproducible in standard). This change probably requires a local migration script and thus the increase of subversion (I'll work on it if this gets approved). Updating a db with this module already installed, results in duplicated entries in `l10n_at_saft_account`. A simple script would match the existing records with newly created xmlids. This issue is al
Original PR description
Records added via a .csv file should always have an ID set, otherwise, they will not have a corresponding xmlid created for them (issue reproducible in standard). This change probably requires a…
Records added via a .csv file should always have an ID set, otherwise, they will not have a corresponding xmlid created for them (issue reproducible in standard). This change probably requires a local migration script and thus the increase of subversion (I'll work on it if this gets approved). Updating a db with this module already installed, results in duplicated entries in `l10n_at_saft_account`. A simple script would match the existing records with newly created xmlids. This issue is also raising an error during upgrades because our scripts expect all csv data to have the `id` field: https://github.com/odoo/upgrade/blob/d861ce33eef5c51996005664353021be779121bd/migrations/base/0.0.0/pre-models-load-csv.py#L44 Here's the [traceback group](https://upgrade.odoo.com/web#id=1073&cids=1&menu_id=107&action=178&model=upgrade.request.traceback.group&view_type=form). Tests conducted on [upg-1289502](https://upgrade.odoo.com/web#id=1289502&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form). <s>I have also taken the liberty to remove quotation marks to be more in line with the current standard in Odoo repos.</s> Forward-Port-Of: odoo/enterprise#56212
How to reproduce: 1. Select a file/doc. 2. Move to trash ( by trash bin icon). 3. Go to trash workspace. 4. Preview the file/doc. 5. Restore the file. 6. Now, try to preview it from the inspector. 7. It throws an error Technical Reason: Before version 17.0, Inside `_toggleArchive`, we were triggering the event to close the preview, but In 17.0 `_toggleArchive` is removed after this [commit](https://github.com/odoo-dev/enterprise/commit/2254eb07fd42ec88341d9d7ac92f09a379c6fa55#diff-78
Original PR description
How to reproduce: 1. Select a file/doc. 2. Move to trash ( by trash bin icon). 3. Go to trash workspace. 4. Preview the file/doc. 5. Restore the file. 6. Now, try to preview it from the inspector. 7. It throws an error Technical Reason: Before version 17.0, Inside `_toggleArchive`, we were triggering the event to close the preview, but In 17.0 `_toggleArchive` is removed after this [commit](https://github.com/odoo-dev/enterprise/commit/2254eb07fd42ec88341d9d7ac92f09a379c6fa55#diff-78d9f8faf609f35072d4b2617a9e13b3f137a679efb2c46c84acf29da4edfe46L426), So the preview remains open. After this commit: No traceback will appear, and the preview will be closed, after clicking on the restore button. Task-3619214 Forward-Port-Of: odoo/enterprise#52226
Currently, when a lock date is set, all default expressions in the db are evaluated, causing some issues when there are different localizations installed. This commit limits the computation to only those expressions that exist on reports that are available to the current company. Forward-Port-Of: odoo/enterprise#56519
Original PR description
Currently, when a lock date is set, all default expressions in the db are evaluated, causing some issues when there are different localizations installed. This commit limits the computation to only those expressions that exist on reports that are available to the current company. Forward-Port-Of: odoo/enterprise#56519
The dependencies were not set properly, causing inheritance errors during installation. Forward-Port-Of: odoo/enterprise#56385 Forward-Port-Of: odoo/enterprise#56159
Original PR description
The dependencies were not set properly, causing inheritance errors during installation. Forward-Port-Of: odoo/enterprise#56385 Forward-Port-Of: odoo/enterprise#56159
Commit https://github.com/odoo/odoo/commit/fd294f9a44f3e029fc83d2bf8610cf286abe017a did not choose the right solution, so our tests fail on Feb 12 and 13 We therefore unlink the leaves before running our tests. Forward-Port-Of: odoo/enterprise#56476
Original PR description
Commit https://github.com/odoo/odoo/commit/fd294f9a44f3e029fc83d2bf8610cf286abe017a did not choose the right solution, so our tests fail on Feb 12 and 13 We therefore unlink the leaves before running our tests. Forward-Port-Of: odoo/enterprise#56476
Problem: When a user books an appointment, whose up-front payment is enabled, and provides answers to the questions from the website,the user is unable to remove the booking because a ValidationError occurs due to the answers not getting deleted before the booking gets deleted. Solution: When a booking gets deleted, its answers should also get deleted to prevent errors. Steps to reproduce on Runbot: 1. Install Appointments and ecommerce 2. For the dental care appointment, edit and ena
Original PR description
Problem: When a user books an appointment, whose up-front payment is enabled, and provides answers to the questions from the website,the user is unable to remove the booking because a ValidationError occurs due to the answers not getting deleted before the booking gets deleted. Solution: When a booking gets deleted, its answers should also get deleted to prevent errors. Steps to reproduce on Runbot: 1. Install Appointments and ecommerce 2. For the dental care appointment, edit and enable "Up-front payment" 3. On the website, book an appointment for dental care and proceed to payment 4. Attempt to remove the booking and a ValidationError occurs "The operation cannot be completed: The answer inputs must be linked to a meeting or to a booking." opw-3671511 Forward-Port-Of: odoo/enterprise#55387
Before this commit:- When we drag and drop a file from the inspector in the existing workspace. The file is duplicated. After this commit:- Now, the drag-and-drop behavior for the inspector has been disabled to prevent file duplication. Task-3635421 Forward-Port-Of: odoo/enterprise#56531 Forward-Port-Of: odoo/enterprise#52756
Original PR description
Before this commit:- When we drag and drop a file from the inspector in the existing workspace. The file is duplicated. After this commit:- Now, the drag-and-drop behavior for the inspector has been disabled to prevent file duplication. Task-3635421 Forward-Port-Of: odoo/enterprise#56531 Forward-Port-Of: odoo/enterprise#52756
Rental search bar filtering didn't properly consider the website warehouse: * fetching all SOLs of the company regardless of their warehouse * computing the available quantity of products with the wrong contextual key, not restricting the quantities to the website warehouse. (correct context key is warehouse, not warehouse_id, cf `_get_domain_locations` in stock/models/product.py) Forward-Port-Of: odoo/enterprise#43224
Original PR description
Rental search bar filtering didn't properly consider the website warehouse: * fetching all SOLs of the company regardless of their warehouse * computing the available quantity of products with the wrong contextual key, not restricting the quantities to the website warehouse. (correct context key is warehouse, not warehouse_id, cf `_get_domain_locations` in stock/models/product.py) Forward-Port-Of: odoo/enterprise#43224