Thursday, February 29, 2024
45 changes · saas-17.1
Enhancements to existing features
This update enhances how Odoo generates PDF reports by creating attachments more efficiently. Previously, attachment values needed to be manually overridden for some reports. This change introduces a new process to prepare these attachment values during PDF generation, ensuring consistent and accurate attachment creation without altering the core report functionality.
Original PR description
Description of the issue/feature this PR addresses: Previously, an `ir_actions_report` refactor landed on: - [ ] https://github.com/odoo/odoo/pull/85150 It totally makes sense to create `ir.attachment` from the streams if needed during PDF generation. For some of the projects we still need to override attachment values. This PR provides a hook to prepare attachment values needed for attachments creation during the pdf report generation. Nothing changes in the sense of business logic. Ping @smetl @xmo-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153086 Forward-Port-Of: odoo/odoo#138159
This update makes it easier for developers to customize how clicks are handled within the Odoo dropdown menu. Previously, changes required extensive modifications, but now a simpler approach allows for quicker and more efficient updates. This improves the overall flexibility and maintainability of the Odoo web interface.
Original PR description
With this commit, overriding the `onWindowClick` function from `dropdown.js` becomes much simpler. Previously, it necessitated overriding the entire function, but now it can be done with minimal effort by just overriding this specific part. task-3717014 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155326 Forward-Port-Of: odoo/odoo#154315
Resolved issues and error corrections
Fixed an issue where restoring a Project task description history could crash if the description had previously been emptied. Users can now use Restore History repeatedly without interruption, improving reliability when reviewing or reverting task content.
Original PR description
**Steps**: - Open Project > Task - Add a description > save - Perform 'Action > Restore History' - Observe that the description is set to null - Perform 'Action > Restore History' again **Issue**: - We get a type error and the code crashes **Cause**: - We get the value of field as 'False' which is a boolean value, which is then used further in a replace function which is only applicable for string values. Hence it gives type error **Fix**: - By passing the null value of string instead of a 'False' value we can correct this issue. **Technical Explanation**: - In our case the description field becomes empty and hence the value of self[field_name] is set to 'False'. - The same functionality of 'Restore History' is used in Knowledge. In there, this error doesn't occur because for that, the body will never be empty as a default `<br>` is given with when it will not have any value. **Task**-3731400
Miscellaneous changes
Before this commit, answer's partner for 360 feedbacks were set as the employee's user partner or the employee's private email. This meant that all employees with no user would get the feedback request through their private email instead of their work email. However, it's not a wanted behaviour. This commit changes the way the answer's partner is determined, taking first the work partner, then the user partner if no work partner is found. task-3627757 based on ticket-3612515 Forward-Port-
Original PR description
Before this commit, answer's partner for 360 feedbacks were set as the employee's user partner or the employee's private email. This meant that all employees with no user would get the feedback request through their private email instead of their work email. However, it's not a wanted behaviour. This commit changes the way the answer's partner is determined, taking first the work partner, then the user partner if no work partner is found. task-3627757 based on ticket-3612515 Forward-Port-Of: odoo/enterprise#53518 Forward-Port-Of: odoo/enterprise#52235
This update corrects a technical issue within the HR Skills module that caused errors when accessing a duplicate tab name ('Work Information') in the employee record view. Previously, the system would crash due to a conflicting XML definition. This fix ensures the tab is removed smoothly without any errors, improving stability and user experience.
Original PR description
Description of the issue/feature this PR addresses: When hr_skills is installed we have 2 tabs/page with the same name in xml (Work Information and Resume). As "Work Information" is defined in hr modules hr_skills must be updated.  - In employee form - Open studio - Click on "Work Information" tab/page - Remove "Work Information" tab/page view Current behavior before PR: - Traceback due to invalid xpath expression (or error depending of version and/or module installed - Invalid xpath due to duplicated name for a node Desired behavior after PR is merged: - Tab is removed without traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154776 Forward-Port-Of: odoo/odoo#154731
This update fixes an issue where route rules for dropshipping could be inconsistent between two companies. The change ensures that route company settings always align with the associated rule company, preventing errors and improving data reliability within the inventory management system. This maintains accurate stock tracking and order fulfillment processes.
Original PR description
### Steps to reproduce:
- Create two companies:
- (ex. Daughter Company)
- (ex. Mother Company)
- Install **Inventory** app and **stock_dropshipping** module
- In the settings of both companies:
- enable **Multi-Step Routes**
- enable **Dropshipping** option
- Using the **Daughter Company**, go to **Routes** > **Dropship** route
- When You try to set Company to Daughter Company, it's _**possible**_ to do so even thought the rules belonging to the Dropship route belongs to two companies: Daughter Company and Mother Company which is **_NOT_** consistent
### Discuss
- We constraint the route company to always be consistent with the rule(s) company and vice verca
opw-3648535
Forward-Port-Of: odoo/odoo#154403
Forward-Port-Of: odoo/odoo#149894This update fixes a bug where the 'Validate' button was missing from the Pivot View in Timesheets. The changes enhance the Pivot component's flexibility, allowing for customized button layouts and ensuring the button is always displayed. This improves usability for users working with pivot data.
Original PR description
**Steps:** - Open Timesheets - Go to To Validate > All Timesheets - Pivot View is rendered **Issue:** The validate button is not rendered when the pivot view is loaded **Solution:** The changes…
**Steps:** - Open Timesheets - Go to To Validate > All Timesheets - Pivot View is rendered **Issue:** The validate button is not rendered when the pivot view is loaded **Solution:** The changes introduced in these files are aimed at enhancing the customization and flexibility of the Pivot component in the web application. By adding the buttonTemplate prop to the PivotController and utilizing it in the PivotRenderer template, developers can dynamically choose the template for rendering buttons within the pivot view. This change is particularly beneficial for scenarios where different button layouts or styles are required based on specific use cases or user preferences. Additionally, the introduction of a default value for buttonTemplate in the PivotView configuration ensures a smooth fallback mechanism if a custom template is not explicitly provided. Overall, these adjustments contribute to a more adaptable and extensible Pivot component, catering to diverse application requirements. **Task**-3623493 Forward-Port-Of: odoo/odoo#155547 Forward-Port-Of: odoo/odoo#147054
This update fixes an issue where channel mentions weren't consistently working across all messaging channels (channels, chats, and groups). The team has removed unnecessary data fetching and added a test to ensure channel mentions function correctly, particularly within live chat where access was previously restricted.
Original PR description
1. channel mention should work for channels, chats, and groups, even if there is a group restriction for the channel. 2. channel mention in livechat is disabled because the visitor can't get access to the channel. 3. remove the fetch and search for channel mentions in livechat so that there is no extra rpc call for unuseful data. 4. add a test for the channel mention in thread. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155380
This update resolves an issue where long attachment filenames in forms (like the 'Mail Template' field) caused labels to be incorrectly 'squashed' or truncated. The fix allows the form layout to handle longer filenames gracefully, ensuring labels are displayed correctly. This improves the user experience when uploading large files.
Original PR description
Since Odoo v16, we also use grid in the form layout (inner group). In a group we use the CSS `grid-template-columns` with the value of: * `fit-content(150px)`: for the first column (TLDR: col max…
Since Odoo v16, we also use grid in the form layout (inner group).
In a group we use the CSS `grid-template-columns` with the value of:
* `fit-content(150px)`: for the first column (TLDR: col max 150px)
* `1fr`: for the second column (TLDR: take the "remaining" max space)
```css
.o_form_view .o_inner_group {
grid-template-columns: fit-content(150px) 1fr;
}
```
These rules at the first glance seem correct.
But due to "big word"/language, some unbreakable text is overflowing, to avoid this, we have added the `text-break` BS class.
So now all text can be "squash"/wrap if there is no space available.
The problem is when we have a text be too long and unbreakable in the second column, the label (first column) is squashed to see only one or two characters.
In our case, the bug happens when we upload a file with a big filename to an "Attachement" (`many2many_binary`) field.
On the `many2many_binary` field there is a custom CSS rules:
```css
.o_attachment .caption {
white-space: nowrap;
}
```
that force the text to not wrap on the next line, and so the grid takes the width of the file name as its min value for the width of the second column, and "squash"/wrap the first column.
This commit fixes the issue by allowing the second column to be smaller than the `max-content` width using the css `minmax(0, 1fr)`.
Steps to reproduce:
* Open "Marketing automation" app
* Create a New campaign ("New" button)
* Click on "ADD NEW ACTIVITY"
* Select the "Mail Template" field
* Create and edit a "Mail Template"
* Click on the "Options" tab
* Upload an attachment with a long name => BUG, all labels (first column) are "squashed"
Note:
* the `text-break` class is equivalent to:
```css
.text-break {
word-wrap: break-word !important;
word-break: break-word !important;
}
```
* when we use `Xfr` (X a positive numeric value `1fr` in our case) outside a `minmax()` notation, the GRID specs[1] specifies that it should be converted to `minmax(auto, Xfr)`.
* also the `auto`[2] in the case of `minmax(auto, Xfr)`the value represents the largest minimum size (in our case, the file name).
[1]: https://www.w3.org/TR/css-grid-2/#valdef-grid-template-columns-flex
[2]: https://www.w3.org/TR/css-grid-2/#valdef-grid-template-columns-auto
task-3644267
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#155420This update ensures that customer names are consistently printed on reprinted receipts, resolving an issue where they were missing. This change aligns with user expectations and provides a more complete and accurate record of transactions, regardless of loyalty program usage.
Original PR description
Before this commit, due to a recent change, the customer name was not being printed on reprinted receipts. This was inconsistent with user expectations, as they expected to see the customer name on the receipt, regardless of whether a loyalty program was in place or not. With this commit, we ensure that the customer name is always printed on reprinted receipts, aligning the system behavior with user expectations. opw-3760165 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155543
This update fixes a potential issue where point of sale orders were sometimes duplicated, particularly when using scales. The change relaxes a comparison rule to avoid errors caused by minor quantity rounding differences, ensuring order accuracy and preventing lost sales. This improves the reliability of the point of sale system.
Original PR description
Before this commit, it was possible to capture an order twice due to the rounding difference in quantity, especially when users use a scale. With this commit, it uses a more relaxed condition and remove the quantity from the orderline comparison. Given that the system checks the payments and with the same product and price units, it's unlikely that two orders will have the same payment amount. opw-3735436 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155513
This update reverts a previous change that was no longer needed in the newer version of Odoo. The update ensures that sale prices are calculated correctly, as the new system now only sends essential data, eliminating unnecessary recalculations. This improves the efficiency and accuracy of sales transactions.
Original PR description
This reverts commit 789186a43c0234c7b3cb308b1b6673adeedbb308. The fix is not necessary in 17+ since the new onchange only sends the necessary information and not the whole x2m record data. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155550
This update resolves an issue where transient messages (temporary emails) were incorrectly showing a date in the message sidebar. The fix removes this display, ensuring transient messages are presented without extraneous date information. This improves the clarity and usability of the email interface.
Original PR description
**Before this PR:** Squashed transient messages had date displayed in the sidebar of the message. This was introduced by this commit: 631ae1c **After this PR:** Squashed transient messages would not have date in the message sidebar. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154594
This update resolves a printing error that occurred when generating DIN5008 repair orders with a specific document layout. The fix removes a reference to a deleted field, preventing a traceback during the printing process. This ensures that repair orders can be printed correctly.
Original PR description
### Steps to reproduce * install `l10n_din5008_repair` * set the document layout to din5008 * create a Repair order and attempt to print it You should be met with a traceback. opw-3718479 Forward-Port-Of: odoo/odoo#153648
A recent test related to channel subscriptions was failing due to a timing issue between channel creation and bus subscription updates. This update adjusts the test's timing to ensure the channel is created before the subscription, resolving the test failure. This ensures the core subscription functionality operates correctly.
Original PR description
Since [1], the `Channel subscription is renewed when channel is added from invite` test was sometimes failing. The bus subscription is refreshed when the user joins a channel at the same time or after the initial bus subscription. Usually, the channel is created at the same time than the bus subscription. When it is not the case, the test fails. This PR fixes the issue by patching the date so that the channel is clearly created before the bus subscription. As a result, there will be no subscription initially. fixes runbot-57787 [1]: https://github.com/odoo/odoo/pull/153666
This update removes specific print-related CSS rules from the survey addon that were previously causing issues in the Odoo backend. These rules were designed for the frontend survey views and didn't impact the core Odoo interface. This ensures a cleaner and more stable Odoo experience.
Original PR description
PURPOSE ======= The survey addon assets contain some global rules for print mode, that are present in the global backend stack. In Odoo 15.2, we put these rules in `survey_templates_results.scss`.…
PURPOSE ======= The survey addon assets contain some global rules for print mode, that are present in the global backend stack. In Odoo 15.2, we put these rules in `survey_templates_results.scss`. Then, in later versions of Odoo we updated it wih more 'print mode' global rules. As these rules are specific to the survey addon, we don't want them to affect the (whole) Odoo backend. HOW TO FIX ========== It seems rules defined in `survey_templates_results.scss` are not used in survey backend views, but specific to frontend views. `survey_templates_results.scss` is also part of the `survey.survey_assets` bundle. This bundle is loaded only for the following frontend views: - Survey: main page (take survey) - Survey: custom 403 page - Survey: void content - Survey: login required - Survey: expired - Survey: Access Code page - Survey: print page - Survey: result statistics page Among them, views that are not intended to be printed are not negatively impacted by the css rules for print mode. A solution would therefore be to remove `survey_templates_results.scss` from the backend stack. see https://github.com/odoo/odoo/commit/03641610c2b4a6b832ea87795fd21e1d7af10b59 see https://github.com/odoo/odoo/pull/135683 see https://github.com/odoo/odoo/pull/146812 task-3666858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155126 Forward-Port-Of: odoo/odoo#148296
This update brings the Odoo spreadsheet component to the latest version (17.1.6), addressing several technical improvements and bug fixes. These changes enhance the spreadsheet's functionality and stability, ensuring a smoother user experience within Odoo.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b29861875 [REL] 17.1.6 https://github.com/odoo/o-spreadsheet/commit/684956d91 [FIX] Migration: Propagate datafilter correction on every version Task: 3728009 https://github.com/odoo/o-spreadsheet/commit/d5fb81831 [FIX] migration: Fix migration steps Task: 3771209 https://github.com/odoo/o-spreadsheet/commit/b794ec2c8 [FIX] Find&Replace: Do not reset the search when iterating through search results Task: 3743879 https://github.com/odoo/o-spreadsheet/commit/c16dbe42c [IMP] cssPropertiesToCss: don't use `Object.entries()` https://github.com/odoo/o-spreadsheet/commit/5a7a69ade [FIX] selection_inputs_manager: arrow keys when broken ranges https://github.com/odoo/o-spreadsheet/commit/cf70a5b00 [IMP] formula: add INT function Task: 3756478
This update fixes a data error that incorrectly listed the phone codes for the Democratic Republic of the Congo (CD) and The Republic of the Congo (CG). The codes have been reversed to ensure accurate international dialing. This ensures correct contact information is recorded within the system.
Original PR description
Phone codes for the Democratic Republic of the Congo (CD) and The Republic of the Congo (CG) are the wrong way around, and ought to be reversed. This commit is based on a commit that was not merged in v14.0 in this PR: https://github.com/odoo/odoo/pull/133287 Forward-Port-Of: odoo/odoo#155557
This update fixes an issue where the correct analytic account wasn't being displayed when switching between assets. The previous code was using outdated data, leading to incorrect account assignments. This change ensures that assets are properly linked to the correct analytic accounts when navigating between them.
Original PR description
Steps to reproduce: - activate analytic - Create two assets with different analytic distribution - Open the first asset - Navigate to the second asset via the arrow Issue: The analytic account will not be displayed correctly Cause: In `jsonToData` the record used is the previous one. Solution: Use the record that will efectively be displayed opw-3698383 Forward-Port-Of: odoo/odoo#153681
This update corrects an issue where invoice totals were misaligned when printing invoices in the Arabic localization (l10n_ar). The fix adds more columns to the report to accurately display large invoice amounts. This ensures invoices are printed correctly and professionally for Arabic-speaking customers.
Original PR description
Steps to reproduce: [l10n_ar] - create an invoice with an invoice line having a big amount - confirm - print invoice Issue: The alignment of total is not correct Solution: In l10n_ar, we need more cols to be able to display the correct information. In the base report, the difference is not important visually (the line total is slightly longer) opw-3670830 Forward-Port-Of: odoo/odoo#152682
This update removes unnecessary code from the sale order process, streamlining how product warnings are handled. Previously, warnings were always loaded, even when products were already added to the order. This change ensures warnings are only added when specifically needed, improving efficiency and reducing potential confusion.
Original PR description
This is a fixup of: https://github.com/odoo/odoo/pull/149155 Warning is duplicated: https://github.com/odoo/odoo/blob/8ccde3f101cdb6ca41fe29cc5b4252f13745774a/addons/sale/models/sale_order_line.py#L1223-L1232 In the case where some products are already added to the SO before selecting the catalog, the warning props will always be loaded. However, since the warning props is a String but sale_line_warn can be false, it only need no be added if sale_line_warn is set. opw-3631511 Forward-Port-Of: odoo/odoo#155523
This update resolves an issue where users without access to the related record would receive an error when scheduling activities. The change removes a restriction that prevented activity assignment to users lacking access, ensuring activities can now be scheduled regardless of user permissions. This improves usability for scenarios where users need to view and manage activities related to records they don't directly own.
Original PR description
How to reproduce: - Install hr with demo data - Create a user without access to hr and turn it into an employee - Create a user for Abigail - Assign Abigail as manager of the new user - Click on…
How to reproduce: - Install hr with demo data - Create a user without access to hr and turn it into an employee - Create a user for Abigail - Assign Abigail as manager of the new user - Click on "onboarding plan" in the chatter of the new user - Then in the dialog, click on "Schedule" button You get the error "Assigned user test has no access to the document and is not able to handle this activity." because the new user has no access to the record employee on which those activities are scheduled. As activities for which the user has no access to the underlying record are now displayed in the systray (with no access to the record), we remove the check that prevent assigning an activity to a user on a record he has no access to. Technical note: before odoo/odoo#149965, activities scheduled manually were created with the flag "automated" set to True and when this flag is set the check that ensures that the user has access to the record is skipped. With odoo/odoo#149965, as the "automated" flag is set to False when scheduling activities manually, an error is trigerred if the user has no access to the underlying record. Here we always skip that test and mark the method as deprecated because the user can see the activity no matter the access he has on the underlying record. Task-3598836 Forward-Port-Of: odoo/odoo#155576
the headers of the xlsx report were not translated this commit fixes that by adding the missing translations into the controller task-3718923 Forward-Port-Of: odoo/enterprise#55761
Original PR description
the headers of the xlsx report were not translated this commit fixes that by adding the missing translations into the controller task-3718923 Forward-Port-Of: odoo/enterprise#55761
steps to reproduce: 1. Go to approvals with no rights 2. create a new approval request 3. add an approver -> the approver cannot be selected because the line is readonly expected behavior: the approver can be selected Explaination of the issue: The field can_edit_user_id is set to False when no user is selected because when you add a line no user is selected by default. behavior after the fix: the approver can be selected task-3602617 Forward-Port-Of: odoo/enterprise#54822
Original PR description
steps to reproduce: 1. Go to approvals with no rights 2. create a new approval request 3. add an approver -> the approver cannot be selected because the line is readonly expected behavior: the approver can be selected Explaination of the issue: The field can_edit_user_id is set to False when no user is selected because when you add a line no user is selected by default. behavior after the fix: the approver can be selected task-3602617 Forward-Port-Of: odoo/enterprise#54822
Bug === Currently, we can not login to Instagram, because a permission is missing. This commit adds the missing permission, and we upgrade from 10.0 to 17.0. Task-3761561 Forward-Port-Of: odoo/enterprise#57693 Forward-Port-Of: odoo/enterprise#57218
Original PR description
Bug === Currently, we can not login to Instagram, because a permission is missing. This commit adds the missing permission, and we upgrade from 10.0 to 17.0. Task-3761561 Forward-Port-Of: odoo/enterprise#57693 Forward-Port-Of: odoo/enterprise#57218
Issue: ====== Duration of rental product doesn't correspond to the range displayed in the daterange picker. Steps to reproduce the issue: ============================= - Install rental and ecommerce - Go to website/shop and add `rental search` snippet and save the page. - Select a period in the rental search and click on any product displayed. - The range is equal the the range selected but the duration in words isn't correct. Solution: ========= We call `_get_combination_info` wi
Original PR description
Issue: ====== Duration of rental product doesn't correspond to the range displayed in the daterange picker. Steps to reproduce the issue: ============================= - Install rental and ecommerce - Go to website/shop and add `rental search` snippet and save the page. - Select a period in the rental search and click on any product displayed. - The range is equal the the range selected but the duration in words isn't correct. Solution: ========= We call `_get_combination_info` with the `start_date` and `end_date` in the context to get the corrent `duration` and `unit`. opw-3601959 Forward-Port-Of: odoo/enterprise#57235 Forward-Port-Of: odoo/enterprise#52687
Forward-Port-Of: odoo/enterprise#57613
Original PR description
Forward-Port-Of: odoo/enterprise#57613
This fixes an issue with the common test class in hr_payroll_holidays which is set to inherit from the invoicing test common class while the module does not depend on the account module. Forward-Port-Of: odoo/enterprise#57202
Original PR description
This fixes an issue with the common test class in hr_payroll_holidays which is set to inherit from the invoicing test common class while the module does not depend on the account module. Forward-Port-Of: odoo/enterprise#57202
Based on last runbot counters Forward-Port-Of: odoo/enterprise#57731
Original PR description
Based on last runbot counters Forward-Port-Of: odoo/enterprise#57731
### Cause When validating an address, we take for granted that Avatax returns latitude and longitude, while it's optional. We started using Avatax's returned geocoordinates in `saas-16.2`, https://github.com/odoo/enterprise/commit/282b878d8c441aaf546e6ce5d5c7dbe9f831d5b2 ### Steps to reproduce * install `account_avatax` * in the settings, enable and setup Avatax. Make sure to enable Address Validation. * create a partner with the following address: - Street 1: 999 Canada Pl - Cit
Original PR description
### Cause When validating an address, we take for granted that Avatax returns latitude and longitude, while it's optional. We started using Avatax's returned geocoordinates in `saas-16.2`, https://github.com/odoo/enterprise/commit/282b878d8c441aaf546e6ce5d5c7dbe9f831d5b2 ### Steps to reproduce * install `account_avatax` * in the settings, enable and setup Avatax. Make sure to enable Address Validation. * create a partner with the following address: - Street 1: 999 Canada Pl - City: Vancouver - State: British Columbia (CA) - Zip: V6C 3B5 - Country: Canada * click the 'Validate' button, next to the country You should be met with a traceback: `KeyError: 'latitude'` Ticket link: https://www.odoo.com/web#model=project.task&id=3752775 opw-3752775 Forward-Port-Of: odoo/enterprise#57612
This commit(https://github.com/odoo/enterprise/commit/217594fe8ba00329b3eb5c68e3eca3b556127cde) removed a filter on products that are services and that shouldn't be in the intrastat report (for now). This commit adds again this filter. opw-3763306 opw-3764904 opw-3730803 Forward-Port-Of: odoo/enterprise#57701 Forward-Port-Of: odoo/enterprise#57607
Original PR description
This commit(https://github.com/odoo/enterprise/commit/217594fe8ba00329b3eb5c68e3eca3b556127cde) removed a filter on products that are services and that shouldn't be in the intrastat report (for now). This commit adds again this filter. opw-3763306 opw-3764904 opw-3730803 Forward-Port-Of: odoo/enterprise#57701 Forward-Port-Of: odoo/enterprise#57607
**Current behavior:** When creating a new helpdesk team, if you have selected Random or Balanced as an Assignment Method and delete the default user in the avatar selection box then switch to the Manual assignment method option, you will simultaneously be unable to assign a user (as the selection box disappears) and required to provide at least one user before being saving. **Expected behavior:** The form should not require a value for a field when the UI does not permit one to be entered.
Original PR description
**Current behavior:** When creating a new helpdesk team, if you have selected Random or Balanced as an Assignment Method and delete the default user in the avatar selection box then switch to the…
**Current behavior:** When creating a new helpdesk team, if you have selected Random or Balanced as an Assignment Method and delete the default user in the avatar selection box then switch to the Manual assignment method option, you will simultaneously be unable to assign a user (as the selection box disappears) and required to provide at least one user before being saving. **Expected behavior:** The form should not require a value for a field when the UI does not permit one to be entered. **Steps to reproduce:** 1. In the Helpdesk app, go to configuration -> Helpdesk Teams 2. Create a new team, select either Random or Balanced as the Assignment Method, delete the default value, then switch back to Manual assignment 3. Try to save the record **Cause of the issue:** member_ids is a required attribute of the helpdesk.team model despite the form view hiding the selection box when the Manual assignment option is selected (implying it is not required). **Fix:** Create an _onchange() method which populates the member_ids field with a default value when the user switches to Manual assignment with no member_ids assigned. opw-3672587 Forward-Port-Of: odoo/enterprise#57608 Forward-Port-Of: odoo/enterprise#55767
When generating work entries based on attendances, lunch time was not being taken into consideration, we fix this issue in the version where lunch time was introduced Forward-Port-Of: odoo/enterprise#57217
Original PR description
When generating work entries based on attendances, lunch time was not being taken into consideration, we fix this issue in the version where lunch time was introduced Forward-Port-Of: odoo/enterprise#57217
**Current behavior:** Modifying an email template associated with the Appraisals app will not result in that attachment being sent when a message is composed using that the template. **Expected behavior:** The attachment(s) of a certain template will be sent when an email is triggered that references that template. **Steps to reproduce:** 1. Modify an HR Appraisals email template so that it has some file attachment 2. In the Appraisals app, create a new appraisal that will use the mo
Original PR description
**Current behavior:** Modifying an email template associated with the Appraisals app will not result in that attachment being sent when a message is composed using that the template. **Expected…
**Current behavior:** Modifying an email template associated with the Appraisals app will not result in that attachment being sent when a message is composed using that the template. **Expected behavior:** The attachment(s) of a certain template will be sent when an email is triggered that references that template. **Steps to reproduce:** 1. Modify an HR Appraisals email template so that it has some file attachment 2. In the Appraisals app, create a new appraisal that will use the modified email template 3. Send the email, observe in the chatter sidebar or in the list of emails in settings that the attachment linked to the relevant template was not sent **Cause of the issue:** The attachment_ids field of the request.appraisal model was not passed as a kwarg to the action_invite() method, which is where the email gets composed and posted. **Fix:** Add the missing attachment_ids argument to this method. opw-3644820 Forward-Port-Of: odoo/enterprise#57402 Forward-Port-Of: odoo/enterprise#55977
Steps to reproduce the bug: - Go to Approvals - Create a new approval request - Set the start date after the end date - Save - the record is saved without any error or chenge in the dates Expected behavior: The system should not allow to save the record with the start date after the end date or it should show an error message Fix: Add constrains on the date fields to avoid saving the record with the start date after the end date and raise a ValidationError if the user tries to
Original PR description
Steps to reproduce the bug: - Go to Approvals - Create a new approval request - Set the start date after the end date - Save - the record is saved without any error or chenge in the dates Expected behavior: The system should not allow to save the record with the start date after the end date or it should show an error message Fix: Add constrains on the date fields to avoid saving the record with the start date after the end date and raise a ValidationError if the user tries to save the record with the start date after the end date task-3650931 Forward-Port-Of: odoo/enterprise#55851
Task-3770997 ## Description: If the execution of the code is abruptly interrupted during an incoming call invitation (e.g. by closing the page), when the call is reopened in the softphone, the correspondence details of the call get stuck in the invitation view. This commit prevents this from happening by also checking for the presence of an actual session as a condition to display the call invitation view. ## How to reproduce: 1. Configure a database with VoIP in production mode 2. Rec
Original PR description
Task-3770997 ## Description: If the execution of the code is abruptly interrupted during an incoming call invitation (e.g. by closing the page), when the call is reopened in the softphone, the correspondence details of the call get stuck in the invitation view. This commit prevents this from happening by also checking for the presence of an actual session as a condition to display the call invitation view. ## How to reproduce: 1. Configure a database with VoIP in production mode 2. Receive an incoming call invitation and refresh the page without accepting/rejecting it 3. Re-open the call and notice that it's stuck on the invitation view :(( Forward-Port-Of: odoo/enterprise#57618
In some countries the journal report is used as a section of the tax report to provide details about the computed tax amounts. One such detail is the split between the deductible and non-deductible part of the tax computed. In order to provide these details, we add two new columns to the tax overview in the journal report that indicate the amounts of the tax that are deductible or non-deductible. [task-3696656](https://www.odoo.com/web#id=3696656&cids=1&menu_id=4720&action=333&active_id
Original PR description
In some countries the journal report is used as a section of the tax report to provide details about the computed tax amounts. One such detail is the split between the deductible and non-deductible part of the tax computed. In order to provide these details, we add two new columns to the tax overview in the journal report that indicate the amounts of the tax that are deductible or non-deductible. [task-3696656](https://www.odoo.com/web#id=3696656&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#57596 Forward-Port-Of: odoo/enterprise#55010
**Before:** In the modified code, parts of the PivotController have been moved to PivotRenderer. However, the 'button template' is not extended in the pivot view, leading to issues rendering the validate button. **After:** By extending the correct class (PivotRenderer instead of PivotController) in the `TimesheetValidationPivotController`, we now have access to methods that were previously unavailable. Additionally, extending the `buttonTemplate` allows us to access the validate button, res
Original PR description
**Before:** In the modified code, parts of the PivotController have been moved to PivotRenderer. However, the 'button template' is not extended in the pivot view, leading to issues rendering the validate button. **After:** By extending the correct class (PivotRenderer instead of PivotController) in the `TimesheetValidationPivotController`, we now have access to methods that were previously unavailable. Additionally, extending the `buttonTemplate` allows us to access the validate button, resolving the rendering issue. This modification ensures that the TimesheetValidationPivotController now extends PivotRenderer, allowing it to access the necessary methods and resolve the rendering issue for the validate button. **Task**-3623493 Forward-Port-Of: odoo/enterprise#57591 Forward-Port-Of: odoo/enterprise#53165
Starshipit is the leading provider of integrated and automated fulfillment solutions for online businesses integrating with the leading carriers used in Australia and New Zealand, such as Australia Post, DHL, Aramex, CouriersPlease, and more This PR will add support to integrate with starshipit directly in Odoo, providing rates and shipping for users who need it. Task ID # 3041982 Forward-Port-Of: odoo/enterprise#47569
Original PR description
Starshipit is the leading provider of integrated and automated fulfillment solutions for online businesses integrating with the leading carriers used in Australia and New Zealand, such as Australia Post, DHL, Aramex, CouriersPlease, and more This PR will add support to integrate with starshipit directly in Odoo, providing rates and shipping for users who need it. Task ID # 3041982 Forward-Port-Of: odoo/enterprise#47569
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3: notification order 3, exclusive, has a responsible Obviously, each validation should be done by a different user (and not an admin), because all rules are exclusive. Also, each rule has a responsible in the example below, but really only rule 3's is part of the real use case and is the object of the fix.
Original PR description
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3:…
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3: notification order 3, exclusive, has a responsible Obviously, each validation should be done by a different user (and not an admin), because all rules are exclusive. Also, each rule has a responsible in the example below, but really only rule 3's is part of the real use case and is the object of the fix. Validate 0: 1 and 2 receives an activity Validate 1: activity of 1 is removed validate 2: activity of 2 is removed, 3 receives an activity (<=====) Before this commit, 3 did not receive an activity. This was because, in this flow the rule 3 is evaluated for validation because every rule before it had been validated. However, in that part of the code, we ensure that no rule below it in notification order is not validated, but we do it in the context of the current user. So, when validating rule 3, we couldn't see the validations for at least of previous rule that another part of the code had seen before. After this commit, the rule 3 receives an activity, and the whole flow works as expected. opw-3752133 Forward-Port-Of: odoo/enterprise#57604
This PR fixes an issue about an overflow property being applied to all the modal across Odoo, while it should only affect a single module. During the design and UX improvements of `mrp_workorder`, Commit[1] introduced an overflow property on the `modal-body` in order to fix a layout on modal that have hidden content that is meant to be displayed when clicking on a button. While this line provided a fix for the issue, it was not scoped to the module and would then affects the whole bac
Original PR description
This PR fixes an issue about an overflow property being applied to all the modal across Odoo, while it should only affect a single module. During the design and UX improvements of `mrp_workorder`, Commit[1] introduced an overflow property on the `modal-body` in order to fix a layout on modal that have hidden content that is meant to be displayed when clicking on a button. While this line provided a fix for the issue, it was not scoped to the module and would then affects the whole back-end. To fix this issue, we add the property as a utility class on the specific modal. Commit[1]: [6f9b089](https://github.com/odoo/enterprise/pull/45032/commits/6f9b08984949d7c2bd0d7ee2c8d493cd05a1289e) ticket-3671725 Forward-Port-Of: odoo/enterprise#57536 Forward-Port-Of: odoo/enterprise#57420
**Step to reproduce:** - Insert a view using /item list or /item kanban in knowledge - Open dropdown on any of the view - Click within that view anywhere outside dropdown - you notice that dropdown did't close **Issue:** Dropdown did't close when clicking within the embedded view. **Technical Reason:** There is a function called onWindowClick in the dropdown.js file, inside which we get different values in 'this.ui.activeElement' and 'this.nyActiveEl', so the dropdown doesn't
Original PR description
**Step to reproduce:** - Insert a view using /item list or /item kanban in knowledge - Open dropdown on any of the view - Click within that view anywhere outside dropdown - you notice that dropdown…
**Step to reproduce:** - Insert a view using /item list or /item kanban in knowledge - Open dropdown on any of the view - Click within that view anywhere outside dropdown - you notice that dropdown did't close **Issue:** Dropdown did't close when clicking within the embedded view. **Technical Reason:** There is a function called onWindowClick in the dropdown.js file, inside which we get different values in 'this.ui.activeElement' and 'this.nyActiveEl', so the dropdown doesn't close. **Before this commit:** When we insert an embedded view, and the user opens any dropdown and after that, if the user clicks within the embedded view that dropdown is not closing. **After this commit:** Removing the condition related to 'this.ui.activeElement' and 'this.myActiveEl' means that now, In the embedded view, when opening the dropdown menu, clicking within that view close the dropdown. task-3717014 Forward-Port-Of: odoo/enterprise#57471 Forward-Port-Of: odoo/enterprise#56366
Forward-Port-Of: odoo/enterprise#57575
Original PR description
Forward-Port-Of: odoo/enterprise#57575
**Current behavior:** Given a portal preview of a recurring sale order with an order line (for a recurring product) and a distinct optional product which is also recurring, if the optional product is added to the cart and then the order is brought back into the editor view, should the recurring plan for the order be changed, the optional product (which is now added to the order) will not have its price adjusted accordingly. **Expected behavior:** The optional product that has been add
Original PR description
**Current behavior:** Given a portal preview of a recurring sale order with an order line (for a recurring product) and a distinct optional product which is also recurring, if the optional product is…
**Current behavior:**
Given a portal preview of a recurring sale order with an order
line (for a recurring product) and a distinct optional product
which is also recurring, if the optional product is added to
the cart and then the order is brought back into the editor
view, should the recurring plan for the order be changed, the
optional product (which is now added to the order) will not
have its price adjusted accordingly.
**Expected behavior:**
The optional product that has been added to the order will have
its price adjusted to match the recurring plan selected for the
sale order.
**Steps to reproduce:**
1. Create two distinct recurring products and assign them
subscription prices for the same recurring plan timetable
2. Create a new sale order, adding one product to the order and
the other to the optional products tab
3. Preview the sale order and add the optional product to the
cart, then return to the editor view
4. Select a new recurring plan for the sale order where each
product has a different set price than the one which is
currently displayed on the order lines
5. The product which was initially added in an order line will
have its price adjusted accordingly, while the product
which was added from the optional products section will
remain static.
**Cause of the issue:**
In sale_management, the _compute_price_unit() method is
extended such that it filters SOLs which have order options
associated with them.
**Fix:**
Override the filter method from sale_management so that lines
which are associated with recurring products will end up having
their prices updated.
opw-3698798
Forward-Port-Of: odoo/enterprise#55710Before this commit: To reproduce the issue (v15 and >): 1. Install PoS and IoT 2. Enable Wordline and configure a worldline payment terminal on the IoT 3. Create 2 payment methods using the same Worldline payment terminal (for instance, if you have a specific meal/eco vouchers bank account) 4. Set them as available payment method of a PoS session 5. Open the PoS session 6. Click the "Last Transaction Status" on the top right => will cause a SEGFAULT on the Worldline driver cr
Original PR description
Before this commit: To reproduce the issue (v15 and >): 1. Install PoS and IoT 2. Enable Wordline and configure a worldline payment terminal on the IoT 3. Create 2 payment methods using the same Worldline payment terminal (for instance, if you have a specific meal/eco vouchers bank account) 4. Set them as available payment method of a PoS session 5. Open the PoS session 6. Click the "Last Transaction Status" on the top right => will cause a SEGFAULT on the Worldline driver crashing Odoo service After this commit: We first filter per IoT IP to perform the action once per IoT box Also added an error message if no worldline terminal is configured opw-3630370 Forward-Port-Of: odoo/enterprise#53511 Forward-Port-Of: odoo/enterprise#52340