Tuesday, October 11, 2022
111 changes · master
Enhancements to existing features
The web editor now preserves certain Odoo-generated elements when users copy and paste content from the editor. This helps users move designed content without losing important structure or formatting due to paste cleanup.
Original PR description
Purpose Allow users to copy/paste specific elements that are generated by Odoo instead of sanitizing it on paste. task-2984686 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The live chat visitor banner has been reorganized so its display data is handled in a more consistent internal model. This makes the feature easier to maintain and evolve without changing the visible experience for website visitors or operators.
Original PR description
\* = website_livechat + Create VisitorBannerView model + Pass record as props + Turn other props on component into fields on model + Remove export default Task-3004301.
The demo data for project timesheets has been updated so approved time off is shown with corresponding timesheet entries. This makes sample data more realistic and helps users better understand how time off appears in timesheet reporting.
Original PR description
In this commit before, timesheets are not generated for approved time off. So we have entered the timesheet regarding the approved time off. task-2960247
The mail enterprise swipe view code was reorganized so its behavior lives in the underlying model layer rather than the visual component. This internal cleanup should make the mail interface easier to maintain and evolve without changing the user experience.
Original PR description
Task-3004296.
Helpdesk now hides ticket deadlines when a ticket is in a folded stage, reducing clutter in ticket views. Stage configuration is also filtered by the currently selected companies, helping users see only relevant Helpdesk stages in multi-company setups.
Original PR description
Before this commit, in the helpdesk tickets list view the deadline was visible even when folded in kanban is enable So in this commit, the deadline will not be visible when folded in kanban is enable task-2995118
Resolved issues and error corrections
This fixes an issue in the website editor where background image positioning could preview or save inaccurately after page editing moved into an iframe. The positioning overlay now uses the same page viewport, helping users place backgrounds reliably while editing website pages.
Original PR description
With commit [1], the edition of website pages was moved in the backend inside an iframe while the editor is instanced outside. A lot of the pre-existing code was adapted to support that transition but the background position option was left untouched. This leads to the position not being accurate because the overlay for positioning the background is outside the iframe which makes the viewport different, resulting in an inaccurate preview and positioning. To fix this, this commit moves the background position overlay inside the iframe, insuring that the viewport and position of the background is accurately previewed and set. [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b task-2687506
Miscellaneous changes
The Costs Analysis Report now handles missing work center hourly costs without causing a server error. This prevents report generation from failing when cost data has not been filled in, improving reliability for manufacturing users.
Original PR description
This commit fixes server error on Costs Analysis Report when Work Center Costs per hour is None. QWeb is unable to render None Type as currency. Impacted versions: 10.0, 11.0
Forward-Port-Of: odoo/odoo#102902
Original PR description
Forward-Port-Of: odoo/odoo#102902
Before: it won't work with extension in uppercase: .XML or .XML.P7M We check the regex in upper case instead. opw-2703669 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#102692 Forward-Port-Of: odoo/odoo#100465
Original PR description
Before: it won't work with extension in uppercase: .XML or .XML.P7M We check the regex in upper case instead. opw-2703669 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#102692 Forward-Port-Of: odoo/odoo#100465
Before this commit, most of the backend redirections to the WebsitePreview, introduced in [1], were using ir.actions.url with the get_client_action_url util, which was not optimal. This commit changes that to use a new get_client_action method, which returns the ir.actions.client record. It will execute the action directly, avoid to redirect the router before, and improve performances. Also, it allows to solve bugs, as: - The back navigation from the WebsitePreview to the ListViews. Go
Original PR description
Before this commit, most of the backend redirections to the WebsitePreview, introduced in [1], were using ir.actions.url with the get_client_action_url util, which was not optimal. This commit changes that to use a new get_client_action method, which returns the ir.actions.client record. It will execute the action directly, avoid to redirect the router before, and improve performances. Also, it allows to solve bugs, as: - The back navigation from the WebsitePreview to the ListViews. Going through the /web controller would add an entry in the history, and going back on it would reload the client action. [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b task-2687506 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#100747
Before this commit, some functions overrode the save function of the form controller. The issue is that this function is only called when the button save is clicked, and not when we save differently (for example, when clicking on the breadcrumb). To avoid this mistake the save function on the form controller was renamed to: `saveButtonClicked`, and the code that overrode the function now override the save function of the Record, that it's called at each time a save is perform. Forward-Port-O
Original PR description
Before this commit, some functions overrode the save function of the form controller. The issue is that this function is only called when the button save is clicked, and not when we save differently (for example, when clicking on the breadcrumb). To avoid this mistake the save function on the form controller was renamed to: `saveButtonClicked`, and the code that overrode the function now override the save function of the Record, that it's called at each time a save is perform. Forward-Port-Of: odoo/odoo#102534
Impacted versions: 15.0 Steps to reproduce: Visit https://github.com/odoo/odoo/blob/15.0/doc/cla/sign-cla.md and click on odoo/odoo link on LOC 12. Current behavior: Redirects to https://github.com/odoo/odoo/blob/15.0/odoo/odoo, which returns 404 Expected behavior: Should redirect to https://github.com/odoo/odoo. This patch fixes issue #101056 Forward-Port-Of: odoo/odoo#102301
Original PR description
Impacted versions: 15.0 Steps to reproduce: Visit https://github.com/odoo/odoo/blob/15.0/doc/cla/sign-cla.md and click on odoo/odoo link on LOC 12. Current behavior: Redirects to https://github.com/odoo/odoo/blob/15.0/odoo/odoo, which returns 404 Expected behavior: Should redirect to https://github.com/odoo/odoo. This patch fixes issue #101056 Forward-Port-Of: odoo/odoo#102301
OPW-2976150 Forward-Port-Of: odoo/odoo#102831 Forward-Port-Of: odoo/odoo#102460
Original PR description
OPW-2976150 Forward-Port-Of: odoo/odoo#102831 Forward-Port-Of: odoo/odoo#102460
Before this commit, in a grouped list view with at least one group_operator and optional fields, the aggregated values in the header are shifted one column to the right. Why is this? Adding the +1 to the colspan in the group header for optional fields is always added on the left side (group name). Solution: The +1 should be added on the left side (group name) if there is no aggregated value otherwise on the right side (pager). Before: TH TH TH TH TH AGG AGG TH AGG AGG TH TH TH OP 0
Original PR description
Before this commit, in a grouped list view with at least one group_operator and optional fields, the aggregated values in the header are shifted one column to the right. Why is this? Adding the +1 to…
Before this commit, in a grouped list view with at least one group_operator and optional fields, the aggregated values in the header are shifted one column to the right. Why is this? Adding the +1 to the colspan in the group header for optional fields is always added on the left side (group name). Solution: The +1 should be added on the left side (group name) if there is no aggregated value otherwise on the right side (pager). Before: TH TH TH TH TH AGG AGG TH AGG AGG TH TH TH OP 0 1 2 3 4 5 6 7 8 9 10 11 12 13 [ TH 6 ][TH][TH][TH][TH][TH][ TH 3 ] [ group name ][ aggregate cells ][ pager] After TH TH TH TH TH AGG AGG TH AGG AGG TH TH TH OP 0 1 2 3 4 5 6 7 8 9 10 11 12 13 [ TH 5 ][TH][TH][TH][TH][TH][ TH 4 ] [ group name ][ aggregate cells ][ pager ] 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#102653
Forward-Port-Of: odoo/odoo#102674
Original PR description
Forward-Port-Of: odoo/odoo#102674
When an electronic payment is done in the POS, the payment lines contains the status of the electronic payment and the corresponding button to perform actions. We are now correctly display those informations. 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#102866
Original PR description
When an electronic payment is done in the POS, the payment lines contains the status of the electronic payment and the corresponding button to perform actions. We are now correctly display those informations. 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#102866
Description of the issue/feature this PR addresses: Adapts the layouts of the immediate production and the production's backorder to match the new grid css for groups. Current behavior before PR: Immediate production:  Production backorder:  Desired behavior after
Original PR description
Description of the issue/feature this PR addresses: Adapts the layouts of the immediate production and the production's backorder to match the new grid css for groups. Current behavior before PR: Immediate production:  Production backorder:  Desired behavior after PR is merged: Immediate production:  Production backorder:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102881
The fix at [1] had to be adapted anyway since the conversion to OWL. As a result it was possible to drop snippets below the mailing area. [1]: https://github.com/odoo/odoo/pull/77724/commits/65b67d66de72fab390b8887c12532b840d47c95f task-3002441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102914
Original PR description
The fix at [1] had to be adapted anyway since the conversion to OWL. As a result it was possible to drop snippets below the mailing area. [1]: https://github.com/odoo/odoo/pull/77724/commits/65b67d66de72fab390b8887c12532b840d47c95f task-3002441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102914
This fixes a bug that occurred when using BACKSPACE to remove the last character of a text node, if said character was preceded by a space and said text node was succeeded by a `<br>`. The space was removed along with the character. This was simply due to a missing state restoration rule to handle this specific case. task-2990229 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102861
Original PR description
This fixes a bug that occurred when using BACKSPACE to remove the last character of a text node, if said character was preceded by a space and said text node was succeeded by a `<br>`. The space was removed along with the character. This was simply due to a missing state restoration rule to handle this specific case. task-2990229 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102861
For testing purpose, temporarily deactivate collaboration conflict detection. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102944
Original PR description
For testing purpose, temporarily deactivate collaboration conflict detection. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102944
Before this commit, the user was not notified when he closed the tab or the browser while modifying a record. Now, the user will be asked to confirm the close if there is at least one invalid field. task id: 2994132 Forward-Port-Of: odoo/odoo#102434
Original PR description
Before this commit, the user was not notified when he closed the tab or the browser while modifying a record. Now, the user will be asked to confirm the close if there is at least one invalid field. task id: 2994132 Forward-Port-Of: odoo/odoo#102434
Followup of #102259 Instead of adding a class to remove field borders, we want the opposite: hide the borders by default, except when specified specifically with a `.o_field_highlight` class (on a parent or the field itself). This makes it much easier to add field borders on specific parts of the ui (just add the class in the template), rather than having to _remove_ the class through a js override, which is far less discoverable. I converted all the new rules to work opposite as before, s
Original PR description
Followup of #102259 Instead of adding a class to remove field borders, we want the opposite: hide the borders by default, except when specified specifically with a `.o_field_highlight` class (on a parent or the field itself). This makes it much easier to add field borders on specific parts of the ui (just add the class in the template), rather than having to _remove_ the class through a js override, which is far less discoverable. I converted all the new rules to work opposite as before, same for the JS logic which added the class based on mobile device detection (size + touch support). Forward-Port-Of: odoo/odoo#102823
- remove redundant tooltips - m2o links are internal, not external Forward-Port-Of: odoo/odoo#101155
Original PR description
- remove redundant tooltips - m2o links are internal, not external Forward-Port-Of: odoo/odoo#101155
By switching from `table` to CSS grid for form view layouts, we have introduced several changes that make several views in Odoo weird to parse visually (or downright broken). This PR aims to correct a few of these (as much as I could find + as was reported). The general idea of these changes goes as follow: - `group` elements are now **grids**, which means to you must be (sometimes) more declarative than before regarding layout and "column spanned" by your view elements - `<group>` elements
Original PR description
By switching from `table` to CSS grid for form view layouts, we have introduced several changes that make several views in Odoo weird to parse visually (or downright broken). This PR aims to correct…
By switching from `table` to CSS grid for form view layouts, we have introduced several changes that make several views in Odoo weird to parse visually (or downright broken).
This PR aims to correct a few of these (as much as I could find + as was reported). The general idea of these changes goes as follow:
- `group` elements are now **grids**, which means to you must be (sometimes) more declarative than before regarding layout and "column spanned" by your view elements
- `<group>` elements have 2 columns unless specified otherwise in their `col` attribute
- rows of the grid are filled by content as it comes; so a `field` will take 2 "columns": one for its label, one for its input **but** a field without label (or a div) will take only 1 column.
The "guidelines" you can use to adapt views:
- fields without labels (`nolabel="1"`) (or other elements that are "single elements", such as `div`s which might contain a text warning, etc.) only take one column => you will usually want to either specify that they should take 2 columns (via `colspan="2"`) or move them outside of a `group` altogether (x2many embedded lists, html/text fields and non-field noodes are good candidates for that)
- if you want to have 2 fields inside the same column (e.g. a label, then a checkbox field + another nolabel field that is only visible if the checkbox is checked): use the following structure
```xml
<group>
<group>
<label for="my_bool" string="Enable Spending Limit"/>
<div class="o_row">
<field name="my_bool" class="oe_inline" />
<field name="spending_limit" />
</div>
</group>
</group>
```
Note that this _only_ applies to elements inside groups: outside of groups, it remains the jungle it was before.
Forward-Port-Of: odoo/odoo#102119Forward-Port-Of: odoo/odoo#102274
Original PR description
Forward-Port-Of: odoo/odoo#102274
Analytic distributions that contain mandatory plans should be blocked from posting. However, automatic flows (for example subscription invoices) should not be blocked. For this reason, the context is used to determine whether the distribution should be validated. Forward-Port-Of: odoo/odoo#101990
Original PR description
Analytic distributions that contain mandatory plans should be blocked from posting. However, automatic flows (for example subscription invoices) should not be blocked. For this reason, the context is used to determine whether the distribution should be validated. Forward-Port-Of: odoo/odoo#101990
Items with tax "GST Only - Import" does not appear on tax report Add "BOX 11" tag to "GST Only" tax. opw-2919731 Forward-Port-Of: odoo/odoo#98717
Original PR description
Items with tax "GST Only - Import" does not appear on tax report Add "BOX 11" tag to "GST Only" tax. opw-2919731 Forward-Port-Of: odoo/odoo#98717
Introduce dark-mode for enterprise odoo webclient. enterprise: - https://github.com/odoo/enterprise/pull/31128 task-2710677 --- An `rd-design` team project. Contributors: anso[@]odoo brd[@]odoo xlu[@]odoo sri[@]odoo Thanks to the `rd-mobile-team` for the technical support. adr[@]odoo app[@]odoo res[@]odoo rfr[@]odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#99755
Original PR description
Introduce dark-mode for enterprise odoo webclient. enterprise: - https://github.com/odoo/enterprise/pull/31128 task-2710677 --- An `rd-design` team project. Contributors: anso[@]odoo brd[@]odoo xlu[@]odoo sri[@]odoo Thanks to the `rd-mobile-team` for the technical support. adr[@]odoo app[@]odoo res[@]odoo rfr[@]odoo -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#99755
Since o_form_view class is not placed on the same element, depending if the form is displayed in a dialog or not, some styles were not applied in form views. Now, the selector will match all cases and dialogs will be stylized as expected. Forward-Port-Of: odoo/odoo#102834
Original PR description
Since o_form_view class is not placed on the same element, depending if the form is displayed in a dialog or not, some styles were not applied in form views. Now, the selector will match all cases and dialogs will be stylized as expected. Forward-Port-Of: odoo/odoo#102834
When the payment views were updated with commit odoo/odoo@f7b8f075, a hook was improperly renamed to `code`, which doesn't help to figure out its purpose. This commit renames it to `provider_credentials` which better fits its role. While doing so, the view files are also renamed and/or split by model to increase their readability. See also: - https://github.com/odoo/enterprise/pull/32490 Forward-Port-Of: odoo/odoo#102585
Original PR description
When the payment views were updated with commit odoo/odoo@f7b8f075, a hook was improperly renamed to `code`, which doesn't help to figure out its purpose. This commit renames it to `provider_credentials` which better fits its role. While doing so, the view files are also renamed and/or split by model to increase their readability. See also: - https://github.com/odoo/enterprise/pull/32490 Forward-Port-Of: odoo/odoo#102585
Before this commit, when clicking on a mail failure in the messaging menu in mobile, it crashed. `NotificationGroupView` is already destroyed, so it crashed due to attempting to close messaging menu although it no longer exists. Actually this code can simply be removed, because opening the document already closes messaging menu. Task-3013202 Forward-Port-Of: odoo/odoo#102916
Original PR description
Before this commit, when clicking on a mail failure in the messaging menu in mobile, it crashed. `NotificationGroupView` is already destroyed, so it crashed due to attempting to close messaging menu although it no longer exists. Actually this code can simply be removed, because opening the document already closes messaging menu. Task-3013202 Forward-Port-Of: odoo/odoo#102916
Before this commit, when clicking on category in category bar, the search bar was (re-)focused. It was flickering, especially when device prompt a soft keyboard, such as on mobile. This commit fixes the issue by not (re-)focusing the search bar when clicking on a category from the category bar. Task-3013819 Forward-Port-Of: odoo/odoo#102962
Original PR description
Before this commit, when clicking on category in category bar, the search bar was (re-)focused. It was flickering, especially when device prompt a soft keyboard, such as on mobile. This commit fixes the issue by not (re-)focusing the search bar when clicking on a category from the category bar. Task-3013819 Forward-Port-Of: odoo/odoo#102962
Task-3013832 Forward-Port-Of: odoo/odoo#102965
Original PR description
Task-3013832 Forward-Port-Of: odoo/odoo#102965
*: website_livechat Task-3006246 Task-3010911 Forward-Port-Of: odoo/odoo#102906
Original PR description
*: website_livechat Task-3006246 Task-3010911 Forward-Port-Of: odoo/odoo#102906
Fixing some demo data from US having an Italian VAT. Also, a partner's name and VAT has been changed not to be too similar to one of our actual clients. Now the Engie Italia's VAT is used. Forward-Port-Of: odoo/odoo#102904
Original PR description
Fixing some demo data from US having an Italian VAT. Also, a partner's name and VAT has been changed not to be too similar to one of our actual clients. Now the Engie Italia's VAT is used. Forward-Port-Of: odoo/odoo#102904
Before this commit, there was a conflict between 2 of the ways to open the WebsitePreview iframe. First, introduced with [1], when a user click on the 'edit in backend' systray button, the URL he was on is stored to be used later if the user click on the "Website Preview" breadcrumb. When he will click on that breadcrumb entry, we want him to go back to where he was, not on the homepage. Second, some records in form views have a "Go to website" stat button that will go to the website
Original PR description
Before this commit, there was a conflict between 2 of the ways to open the WebsitePreview iframe. First, introduced with [1], when a user click on the 'edit in backend' systray button, the URL he was…
Before this commit, there was a conflict between 2 of the ways to open the WebsitePreview iframe. First, introduced with [1], when a user click on the 'edit in backend' systray button, the URL he was on is stored to be used later if the user click on the "Website Preview" breadcrumb. When he will click on that breadcrumb entry, we want him to go back to where he was, not on the homepage. Second, some records in form views have a "Go to website" stat button that will go to the website preview action, loading the iframe with the URL of the record from the form view. Before this commit, the second flow was not working if the user previously click on "Edit in backend" on a record (first flow described). Indeed, if that "last url" was set, it would always be used, ignoring the requested one from the second flow. Step to reproduce: - Go to a record in the website preview, like a product - Click on edit in backend - You land on the product form view, and that url was saved in JS - From there, navigate to another record through the form view, like a m2o relation or a stat button, or by whatever other mean, but don't hard reload the page (F5) - For the example, let's say you landed on a blog post record - Click on "Go to website" on that blog post form view -> You land on the product page you were initially, not on the requested blog post page. Courtesy of @rdeodoo [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b task-2687506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101970
Fix several bugs introduced by [97692](https://github.com/odoo/odoo/pull/97692) Forward-Port-Of: odoo/odoo#101115
Original PR description
Fix several bugs introduced by [97692](https://github.com/odoo/odoo/pull/97692) Forward-Port-Of: odoo/odoo#101115
Prior to this fix it was possible to edit a media that was not editable because no check existed for such a thing. task-2962912 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102384 Forward-Port-Of: odoo/odoo#102067
Original PR description
Prior to this fix it was possible to edit a media that was not editable because no check existed for such a thing. task-2962912 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102384 Forward-Port-Of: odoo/odoo#102067
Some onboarding tours were conflicting between themselves, with some common steps. This commit introduces the possibility to skip a step depending on the current DOM, making dynamic tours and ensuring tours compatibility Forward-Port-Of: odoo/odoo#102449
Original PR description
Some onboarding tours were conflicting between themselves, with some common steps. This commit introduces the possibility to skip a step depending on the current DOM, making dynamic tours and ensuring tours compatibility Forward-Port-Of: odoo/odoo#102449
Due to a previous fix, attachments uploaded through media dialog would appear in the attachments of mail marketting. That fix prevents attachments from 'dangling' and being garbage collected later. That fix is now limited to the mail composer in this commit as attachments are only garbage collected for that model, for now. related commit: c112361bf9e2f5e7b087c5e5b9a31879856b1da4 task 3003939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr F
Original PR description
Due to a previous fix, attachments uploaded through media dialog would appear in the attachments of mail marketting. That fix prevents attachments from 'dangling' and being garbage collected later. That fix is now limited to the mail composer in this commit as attachments are only garbage collected for that model, for now. related commit: c112361bf9e2f5e7b087c5e5b9a31879856b1da4 task 3003939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102816 Forward-Port-Of: odoo/odoo#101858
Of course I managed to cherry-pick the wrong version of the code, without the fix that I asked for in https://github.com/odoo/odoo/pull/102586#discussion_r990832167 Forward-Port-Of: odoo/odoo#102819
Original PR description
Of course I managed to cherry-pick the wrong version of the code, without the fix that I asked for in https://github.com/odoo/odoo/pull/102586#discussion_r990832167 Forward-Port-Of: odoo/odoo#102819
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102510
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102510
On portal, 1. Except for registering components, the portal should be readonly 2. Don't open sm form when click it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102637
Original PR description
On portal, 1. Except for registering components, the portal should be readonly 2. Don't open sm form when click it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102637
Description of the issue/feature this PR addresses: When a warehouse is renamed, associated route's name aren't renamed accordingly Current behavior before PR: When a warehouse is renamed, route's name doesn't change Desired behavior after PR is merged: When a warehouse is renamed, route's name change accordingly --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102456
Original PR description
Description of the issue/feature this PR addresses: When a warehouse is renamed, associated route's name aren't renamed accordingly Current behavior before PR: When a warehouse is renamed, route's name doesn't change Desired behavior after PR is merged: When a warehouse is renamed, route's name change accordingly --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102456
*: website_event The `website_event.menu_edit_menu` menuitem was added on "website_event" module to the 'custom menus' registry so it can be displayed by the `website_custom_menus` service if the event page has menus to edit. The goal of this commit is to move this code to "website" by using a generic `custom_menu_edit_menu` menuitem that will be cloned to edit every content menu on the current page with the corresponding `EditMenuDialog`. task-2973149 Forward-Port-Of: odoo/odoo#1027
Original PR description
*: website_event The `website_event.menu_edit_menu` menuitem was added on "website_event" module to the 'custom menus' registry so it can be displayed by the `website_custom_menus` service if the event page has menus to edit. The goal of this commit is to move this code to "website" by using a generic `custom_menu_edit_menu` menuitem that will be cloned to edit every content menu on the current page with the corresponding `EditMenuDialog`. task-2973149 Forward-Port-Of: odoo/odoo#102728
Before this commit 1) click on a record in a list view 2) change the html field of a record 3) click on the top right arrow to change the next record 4) click on the top right arrow to change the previous record 5) click on the top right arrow to change the previous record The value is not updated corretly at step 4, retaining the value from the previous record. The wrong value is then saved at step 5. After this commit Properly reset the HtmlField property `currentEditingValue` whe
Original PR description
Before this commit 1) click on a record in a list view 2) change the html field of a record 3) click on the top right arrow to change the next record 4) click on the top right arrow to change the previous record 5) click on the top right arrow to change the previous record The value is not updated corretly at step 4, retaining the value from the previous record. The wrong value is then saved at step 5. After this commit Properly reset the HtmlField property `currentEditingValue` when the update of props value does not comes from the editor. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102271
Before the fix it was not possible to create an invoice with an individual partner and send it to the government. Also the 'type' of the receiver is a required property to send to the government. There is no mention of it being optional in the API (https://sdk.invoicing.eta.gov.eg/documents/invoice-v1-0/#receiver). Now it's possible to send such invoice and the 'type' of the receiver is always sent. opw-2979515 Forward-Port-Of: odoo/odoo#102627
Original PR description
Before the fix it was not possible to create an invoice with an individual partner and send it to the government. Also the 'type' of the receiver is a required property to send to the government. There is no mention of it being optional in the API (https://sdk.invoicing.eta.gov.eg/documents/invoice-v1-0/#receiver). Now it's possible to send such invoice and the 'type' of the receiver is always sent. opw-2979515 Forward-Port-Of: odoo/odoo#102627
Followup to inventory back2basics task 2882539 - order stock.move.line tree (Moves History) view by "id desc" for better performance (prev: create_date is not indexed) - order stock.valuation.layer tree (Valuation) view by "id desc" for better performance (prev: date is not indexed) - hide "Moved Quantity" column when in current valuation (not at date) - remove the action: "Set" and print: "Count Sheet" from stock.quant.view when not in "Inventory Adjustment" related view - Fix "Inventory
Original PR description
Followup to inventory back2basics task 2882539 - order stock.move.line tree (Moves History) view by "id desc" for better performance (prev: create_date is not indexed) - order stock.valuation.layer tree (Valuation) view by "id desc" for better performance (prev: date is not indexed) - hide "Moved Quantity" column when in current valuation (not at date) - remove the action: "Set" and print: "Count Sheet" from stock.quant.view when not in "Inventory Adjustment" related view - Fix "Inventory At Date"/"Valuation At Date" button visibility issue that came up due to OWL refactoring Task: 2965586 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#100268
Description of the issue/feature this PR addresses: Simplify the tooltips for 'Security Lead Time for Purchase' and 'Days to Purchase' in the 'Advanced Scheduling' part of Inventory configuration. Task : 2985735 Current behavior before PR:  Desired behavior after PR is merged:  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#102577
This commit updates some tooltips in workcenters and operations forms ENT PR: odoo/enterprise#32519 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102672
Original PR description
This commit updates some tooltips in workcenters and operations forms ENT PR: odoo/enterprise#32519 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102672
This PR improves the style of the kanabn actiivty popover after the wowl refactoring. It focuses on: - Restoring button hover style - Restoring scrol behavior for multiple activities - Truncating the text of activty summary/name - Centering mark done buttons task-2998139 enterprise: https://github.com/odoo/enterprise/pull/32302 Forward-Port-Of: odoo/odoo#101759
Original PR description
This PR improves the style of the kanabn actiivty popover after the wowl refactoring. It focuses on: - Restoring button hover style - Restoring scrol behavior for multiple activities - Truncating the text of activty summary/name - Centering mark done buttons task-2998139 enterprise: https://github.com/odoo/enterprise/pull/32302 Forward-Port-Of: odoo/odoo#101759
Steps to reproduce: A) Share a payment link and pay with PayU Latam (you'll be redirected to their checkout page) B) Make sure that your first payment attempt with Pay U Latam fails (they provide the cards info to simulate successful and failed payments) C) After the first failed attempt, stay on the same checkout page and do a second attempt (this time a successful attempt) D) Click on 'Go back to the website of the shop' (still on the checkout page). Current behavior: Odoo will show 'Yo
Original PR description
Steps to reproduce: A) Share a payment link and pay with PayU Latam (you'll be redirected to their checkout page) B) Make sure that your first payment attempt with Pay U Latam fails (they provide the…
Steps to reproduce: A) Share a payment link and pay with PayU Latam (you'll be redirected to their checkout page) B) Make sure that your first payment attempt with Pay U Latam fails (they provide the cards info to simulate successful and failed payments) C) After the first failed attempt, stay on the same checkout page and do a second attempt (this time a successful attempt) D) Click on 'Go back to the website of the shop' (still on the checkout page). Current behavior: Odoo will show 'Your payment has been canceled' Expected behvavior: Odoo will show 'Your payment has been confirmed' Explanation: After the first payment failur payulatam calls the webhook to cancel the transaction but after it lets the user the possibilty to retry the same payment again and if the payment succeed it calls the webhook again to confirm the transaction but it can not as the transaction is already in a canceled state. To prevent this issue we allow the payulatam webhook to set the transaction from canceled to done. opw-2994527 Forward-Port-Of: odoo/odoo#102013
**Steps to reproduce:** - Connect with a company that uses the dollar as currency - Go to invoicing → Configuration → accounting → currencies - Enable euro currency - Create a new Purchase Agreement: - Agreement type: “Blanket Order” - Currency: “euro" - Add any product: - Qty: 1 - Price: 10 - save - Print → Call for tenders **Problem:** The price is displayed in the current company device instead of the Purchase agreements currency opw-2991
Original PR description
**Steps to reproduce:**
- Connect with a company that uses the dollar as currency
- Go to invoicing → Configuration → accounting → currencies
- Enable euro currency
- Create a new Purchase Agreement:
- Agreement type: “Blanket Order”
- Currency: “euro"
- Add any product:
- Qty: 1
- Price: 10
- save
- Print → Call for tenders
**Problem:**
The price is displayed in the current company device instead of the Purchase agreements currency
opw-2991156
Forward-Port-Of: odoo/odoo#102538Currently, when creating/editing Journal Entries, changing taxes or balances (with taxes) triggers a save in order to generate an automatic balancing line. See this PR : https://github.com/odoo/odoo/pull/102040 But in some cases (like the non-deductible taxes in Belgium), the tax line is linked to the base line account (or its partner). Which is why we also need to trigger a save when changing the account (or partner) on a line with taxes. This also fixes a bug that prevented the Jour
Original PR description
Currently, when creating/editing Journal Entries, changing taxes or balances (with taxes) triggers a save in order to generate an automatic balancing line. See this PR : https://github.com/odoo/odoo/pull/102040 But in some cases (like the non-deductible taxes in Belgium), the tax line is linked to the base line account (or its partner). Which is why we also need to trigger a save when changing the account (or partner) on a line with taxes. This also fixes a bug that prevented the Journal Entries from being posted. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102573
The computation of the taxes in the context of quick encoding wasn't working properly. * The value was not updated in the widget when it was updated programatically. * The payment terms were created twice because of the `new` method on account.move.line * The taxes should be updated both when we create a new line manually and when we update the quick encoding fields To test and reproduce: use a tax of 21% with an invoice line of 100.0 --- I confirm I have signed the CLA and read the
Original PR description
The computation of the taxes in the context of quick encoding wasn't working properly. * The value was not updated in the widget when it was updated programatically. * The payment terms were created twice because of the `new` method on account.move.line * The taxes should be updated both when we create a new line manually and when we update the quick encoding fields To test and reproduce: use a tax of 21% with an invoice line of 100.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102650
This PR purpose is to ensure that tests are created on OWL Components that have been created in the context of the OWL migration PR odoo/odoo#100729. This PR also addresses some bugs that have been discovered during tests writings. task-3001470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101967
Original PR description
This PR purpose is to ensure that tests are created on OWL Components that have been created in the context of the OWL migration PR odoo/odoo#100729. This PR also addresses some bugs that have been discovered during tests writings. task-3001470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101967
Before this commit product revaluation form has alignment issues Current behavior before PR: https://www.awesomescreenshot.com/image/33174642?key=5b91469ae2cf6f6d56445716d959ae8d Desired behavior after PR is merged: <img width="735" alt="image" src="https://user-images.githubusercontent.com/15212149/195034899-62079488-a784-4480-87ba-2d665d5e7882.png"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103002
Original PR description
Before this commit product revaluation form has alignment issues Current behavior before PR: https://www.awesomescreenshot.com/image/33174642?key=5b91469ae2cf6f6d56445716d959ae8d Desired behavior after PR is merged: <img width="735" alt="image" src="https://user-images.githubusercontent.com/15212149/195034899-62079488-a784-4480-87ba-2d665d5e7882.png"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103002
Fix alignment issues by moving buttons next to their related fields in Authorize.net payment provider view Forward-Port-Of: odoo/odoo#103016
Original PR description
Fix alignment issues by moving buttons next to their related fields in Authorize.net payment provider view Forward-Port-Of: odoo/odoo#103016
View styling, no functional change Forward-Port-Of: odoo/odoo#103044
Original PR description
View styling, no functional change Forward-Port-Of: odoo/odoo#103044
Before this commit, trying recover a connection that didn't exist anymore would cause a traceback. This commit fixes this issue. Forward-Port-Of: odoo/odoo#103050
Original PR description
Before this commit, trying recover a connection that didn't exist anymore would cause a traceback. This commit fixes this issue. Forward-Port-Of: odoo/odoo#103050
Due to migration from Bootstrap 4 to 5, rounded badges look bad. No unification of badge styles, some are rounded and some are squared. Tags style should be unified and adjusted for Bootstrap 5 with this commit. task-3001057 Forward-Port-Of: odoo/odoo#102474
Original PR description
Due to migration from Bootstrap 4 to 5, rounded badges look bad. No unification of badge styles, some are rounded and some are squared. Tags style should be unified and adjusted for Bootstrap 5 with this commit. task-3001057 Forward-Port-Of: odoo/odoo#102474
This commit adds an implementation of the UserMenu item's type 'switch' for the BurgerMenu (used in smaller screen). Forward-Port-Of: odoo/odoo#102890
Original PR description
This commit adds an implementation of the UserMenu item's type 'switch' for the BurgerMenu (used in smaller screen). Forward-Port-Of: odoo/odoo#102890
Commit [1] and [2] introduced an assets pregeneration to speed up the testing suite on runbot. It seems like it was chosen to always pregenerate the assets when a module was installed/upgraded. This was done in the `test_assetsbundle` module to only impact the tests flows, but it was not correct as it was not only impacting the tests flows but also regular runbot usage. Indeed, any `all` runbot (the default one) will have that module installed. It means that any module operation through regu
Original PR description
Commit [1] and [2] introduced an assets pregeneration to speed up the testing suite on runbot. It seems like it was chosen to always pregenerate the assets when a module was installed/upgraded. This…
Commit [1] and [2] introduced an assets pregeneration to speed up the testing suite on runbot.
It seems like it was chosen to always pregenerate the assets when a module was installed/upgraded. This was done in the `test_assetsbundle` module to only impact the tests flows, but it was not correct as it was not only impacting the tests flows but also regular runbot usage. Indeed, any `all` runbot (the default one) will have that module installed.
It means that any module operation through regular flow in those DB will trigger the assets pregeneration.
One of the problem is then that during a theme switch through the website builder (or configurator), assets would be pregenerated, adding ~40 seconds to the processing time.
Since that theme install was already taking ~30 seconds on `all` runbot, it sometimes now total over 60 seconds, triggering the `CPU Time Limit`. You can find some benchmark and metrics on this commit PR.
Obviously, that's not fine because runbot, despite being our testing tool/platform, is also one of our main demo tool.
That's especially true around the OXP period, where people are recording video on it but will also use it to show demo to the customers.
Finally, there is no reason to not limit this assets pregeneration to the test mode anyway.
Note that sometimes, the theme install is failing and responding with a 502 error after a long time, this is yet unsure if this was the cause but it was during this investigation that this commit fix was found. It is probably the cause though.
[1]: https://github.com/odoo/odoo/commit/c764c38d7caf300dce7509e87d2bd268eee0161d
[2]: https://github.com/odoo/odoo/commit/d47cf37b688117d6b2514b9b620787aa66312c61
----------------
**Benchmark**
Theme install without this commit (no fail) -> Just under a minute: 66 seconds between the click on theme install and the reload, 44 seconds exactly according to the logs for the `button_choose_theme` call
> **20:39:26**,735 138 INFO 20135288 [...]: **Unload theme** ['theme_paptic'] for website 1 from template.
> **20:39:33**,723 138 INFO 20135288 [...]: **Pregenerating assets bundles**
> **20:39:58**,876 138 INFO 20135288 [...]: **JS Assets bundles generated in 25.08273196220398 seconds**
> **20:40:13**,753 138 INFO 20135288 [...]: **CSS Assets bundles generated in 14.87694263458252 seconds**
> **20:40:14**,271 138 INFO 20135288 [...]: **Registry loaded in 46.747s**
> **20:40:14**,283 138 INFO 20135288 [...]: "POST /web/dataset/call_kw/ir.module.module/**button_choose_theme** HTTP/1.0" 200 - 12105 3.800 **44.013**
> **20:40:32**,958 138 INFO 20135288 [...]: "[32mGET **/website/force/1**?path=%2Fen%2F HTTP/1.0[0m" 303 - 13 0.003 0.006
Theme install without this commit (fail) -> Goes over the minute limit
It takes 34secs until the modules are loaded, then 25 seconds to generate the JS bundles, and then timeout (>60s) during the CSS bundles generation.
> **20:42:02**,151 138 INFO 20135288 [...]: **Unload theme** ['theme_cobalt'] for website 1 from template.
> **20:42:37**,535 138 INFO 20135288 [...]: **729 modules loaded** in 33.94s, 14402 queries (+14402 extra)
> **20:42:40**,209 138 INFO 20135288 [...]: **Pregenerating assets bundles**
> **20:43:05**,125 138 INFO 20135288 [...]: **JS Assets bundles generated** in 24.843814849853516 seconds
> **20:43:10**,126 138 INFO 20135288 [...]: Worker (138) **CPU time limit (60) reached.**
> **20:43:10**,126 138 ERROR 20135288-16-0-design_theme odoo.service.server: Worker (138) Exception occurred, exiting...
> Traceback (most recent call last):
> File "/data/build/odoo/odoo/service/server.py", line 1081, in run
> t.join()
> File "/usr/lib/python3.10/threading.py", line 1089, in join
> self._wait_for_tstate_lock()
> File "/usr/lib/python3.10/threading.py", line 1109, in _wait_for_tstate_lock
> if lock.acquire(block, timeout):
> File "/data/build/odoo/odoo/service/server.py", line 1011, in signal_time_expired_handler
> raise Exception('CPU time limit exceeded.')
> Exception: CPU time limit exceeded.
Theme install with this commit -> Well under the minute: 36 seconds between the click on theme install and the reload, 29 seconds exactly according to the logs for the `button_choose_theme` call
> **23:04:38**,162 17 INFO 20158556 [...]: **Unload theme** ['theme_zap'] for website 1 from template.
> **23:05:09**,648 17 INFO 20158556 [...]: **729 modules loaded** in 30.43s, 14098 queries (+14098 extra)
> **23:05:12**,179 17 INFO 20158556 [...]: **Registry loaded in 33.434s**
> **23:05:12**,190 17 INFO 20158556 [...]: "POST /web/dataset/call_kw/ir.module.module/**button_choose_theme** HTTP/1.0" 200 - 22524 5.398 **28.817**
> **23:05:14**,126 15 INFO 20158556 [...]: "[32mGET **/website/force/1**?path=%2Fen%2F HTTP/1.0[0m" 303 - 19 0.008 0.012
Here is both logs from which I extracted (and minimized) those info:
- http://runbot57.odoo.com/runbot/static/build/20135288-16-0/logs/run.txt (current 16.0, without this commit)
- http://runbot132.odoo.com/runbot/static/build/20158556-16-0/logs/run.txt (with this commit)
Forward-Port-Of: odoo/odoo#102994When two building blocks are one above another, if there is no padding between them, we notice that the move handle of the columns of the lower block is located on the upper block. This is a problem when the upper block is in grid mode because since the mouse is above it, the drag is considered over this grid, instead of the block from which the column comes from. The column is therefore "trapped" in the grid, which is unconvenient. This commit solves this issue by "canceling" the over if the
Original PR description
When two building blocks are one above another, if there is no padding between them, we notice that the move handle of the columns of the lower block is located on the upper block. This is a problem when the upper block is in grid mode because since the mouse is above it, the drag is considered over this grid, instead of the block from which the column comes from. The column is therefore "trapped" in the grid, which is unconvenient. This commit solves this issue by "canceling" the over if the start of the drag falls in this situation. More precisely: if the first dropzone to detect the "over" event when we start to drag a column is a grid dropzone that is glued to this column, then the over is canceled. task-3013882 Forward-Port-Of: odoo/odoo#103004
The Masonry and Big Boxes snippets don't have a background option because their blocks are supposed to take the whole space, so a background is not really necessary. But since the addition of the grid mode, these blocks can be placed more freely and a background may therefore be necessary. This commit adds the background option to these snippets. task-3014939 Forward-Port-Of: odoo/odoo#103048
Original PR description
The Masonry and Big Boxes snippets don't have a background option because their blocks are supposed to take the whole space, so a background is not really necessary. But since the addition of the grid mode, these blocks can be placed more freely and a background may therefore be necessary. This commit adds the background option to these snippets. task-3014939 Forward-Port-Of: odoo/odoo#103048
Description of the issue/feature this PR addresses: outdated reference doc (under addons/account_edi for v15.0) Current behavior before PR: redundant googling Desired behavior after PR is merged: refer to the correct ref for further correction as fits --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101911
Original PR description
Description of the issue/feature this PR addresses: outdated reference doc (under addons/account_edi for v15.0) Current behavior before PR: redundant googling Desired behavior after PR is merged: refer to the correct ref for further correction as fits --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101911
This PR fixed various bugs in v16.0 . task-2999323 Forward-Port-Of: odoo/odoo#101520
Original PR description
This PR fixed various bugs in v16.0 . task-2999323 Forward-Port-Of: odoo/odoo#101520
Before this commit, While creating project from configuration billable was not set true after enabling all fields from settings in project After this commit, using context in action billable was set true task-2995118 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#101940
Original PR description
Before this commit, While creating project from configuration billable was not set true after enabling all fields from settings in project After this commit, using context in action billable was set true task-2995118 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#101940
Fees charged by payment providers are shown when choosing a payment option (provider or token) on a payment form. Before this commit, the fees badge was not shown next to tokens, which could be understood as fee-free. With this commit, the fees badge will also appear next to tokens. task-2854120 Forward-Port-Of: odoo/odoo#102671
Original PR description
Fees charged by payment providers are shown when choosing a payment option (provider or token) on a payment form. Before this commit, the fees badge was not shown next to tokens, which could be understood as fee-free. With this commit, the fees badge will also appear next to tokens. task-2854120 Forward-Port-Of: odoo/odoo#102671
Tour failed due to the always edit feature task-3012774 Forward-Port-Of: odoo/odoo#102893
Original PR description
Tour failed due to the always edit feature task-3012774 Forward-Port-Of: odoo/odoo#102893
Forward-Port-Of: odoo/odoo#102907
Original PR description
Forward-Port-Of: odoo/odoo#102907
Forward-Port-Of: odoo/odoo#103073
Original PR description
Forward-Port-Of: odoo/odoo#103073
Currently, when posting accounting entries from an expense report, the accounts set on the expense entries were not taken over in the account move lines. Also, the employee was not set as the vendor of the purchase receipt (account move). This PR makes sure that both the accounts on the expenses, as well as the vendor (employee) is set on the account move created from an expense report. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-
Original PR description
Currently, when posting accounting entries from an expense report, the accounts set on the expense entries were not taken over in the account move lines. Also, the employee was not set as the vendor of the purchase receipt (account move). This PR makes sure that both the accounts on the expenses, as well as the vendor (employee) is set on the account move created from an expense report. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#102570
Some snippets have a "hard coded" background color which doesn't change when we want to put a preset color (theme). We have to delete the back- ground first before being able to choose a preset color. This commit fixes this behaviour by putting a preset color by default on the concerned snippets (instead of a fixed color). These snippets are searchbar and text highlight. See [1] for the following of this fix. [1]: https://github.com/odoo/design-themes/pull/563 task-2824393 Forwa
Original PR description
Some snippets have a "hard coded" background color which doesn't change when we want to put a preset color (theme). We have to delete the back- ground first before being able to choose a preset color. This commit fixes this behaviour by putting a preset color by default on the concerned snippets (instead of a fixed color). These snippets are searchbar and text highlight. See [1] for the following of this fix. [1]: https://github.com/odoo/design-themes/pull/563 task-2824393 Forward-Port-Of: odoo/odoo#90749
Steps to reproduce: - Belgian company install(l10n_be_hr_contract_salary) - create a contract for a new employee (CP200 38h) - set wage to 1000$ - generate and access salary simulation link - edit advantages ( fuel card ) - gross salary changes but not double holiday pay Fix: trigger the compute when gross salary changes opw-2999243 Forward-Port-Of: odoo/enterprise#32513
Original PR description
Steps to reproduce: - Belgian company install(l10n_be_hr_contract_salary) - create a contract for a new employee (CP200 38h) - set wage to 1000$ - generate and access salary simulation link - edit advantages ( fuel card ) - gross salary changes but not double holiday pay Fix: trigger the compute when gross salary changes opw-2999243 Forward-Port-Of: odoo/enterprise#32513
Forward-Port-Of: odoo/enterprise#32672
Original PR description
Forward-Port-Of: odoo/enterprise#32672
the bank statement list view has a clickable link to the bank recon that causes a flicker Forward-Port-Of: odoo/enterprise#32678
Original PR description
the bank statement list view has a clickable link to the bank recon that causes a flicker Forward-Port-Of: odoo/enterprise#32678
Steps : Go to planning > next week > publish > publish. Issue : ValueError: cannot compare False with datetime. Cause: In PlanningSlot._create_work_entries(), we make a query to get slots, to which we left join HRWorkEntries, and we aggregate those values in work_entry_ids. If one doesn't have any, the resulting row will contain [None]. Then we call browse those work_entry_ids and write on them. So we get hr.work.entry(None,...).write(vals). This causes issue in later treatments.
Original PR description
Steps : Go to planning > next week > publish > publish. Issue : ValueError: cannot compare False with datetime. Cause: In PlanningSlot._create_work_entries(), we make a query to get slots, to which we left join HRWorkEntries, and we aggregate those values in work_entry_ids. If one doesn't have any, the resulting row will contain [None]. Then we call browse those work_entry_ids and write on them. So we get hr.work.entry(None,...).write(vals). This causes issue in later treatments. Fix : Filter the actual ids. Forward-Port-Of: odoo/enterprise#32608
There are a 2 issues related to the bank recon that are resolved in this PR. Both result in the inability to add/remove matching entries to the prepared journal entry list. 1. After clicking the validate button, the next statement line is selected - clicking a matching entry does nothing. 2. When setting an unmatched, to check record as checked - the statement line remains active - but clicking a matching entry does nothing Forward-Port-Of: odoo/enterprise#32603
Original PR description
There are a 2 issues related to the bank recon that are resolved in this PR. Both result in the inability to add/remove matching entries to the prepared journal entry list. 1. After clicking the validate button, the next statement line is selected - clicking a matching entry does nothing. 2. When setting an unmatched, to check record as checked - the statement line remains active - but clicking a matching entry does nothing Forward-Port-Of: odoo/enterprise#32603
Before this commit, the remaining budget was wrongly calculation because in some case the allocated budget could be the one estimated and so the amount could be less than 0, and so if the budget spent does not spent more than the amount set on the allocated budget then the value in the remaining budget should not the allocated budget minus the budget spent, otherwise the remaining budget will show the budget spent was (budget allocated + budget spent) and so the value will be negative and
Original PR description
Before this commit, the remaining budget was wrongly calculation because in some case the allocated budget could be the one estimated and so the amount could be less than 0, and so if the budget spent does not spent more than the amount set on the allocated budget then the value in the remaining budget should not the allocated budget minus the budget spent, otherwise the remaining budget will show the budget spent was (budget allocated + budget spent) and so the value will be negative and in red. This commit reviews the calculation to really show the budget remaining. Also, since the allocated budget could be a negative amount, the columns have been renamed to be clearer as before. The columns in the Budget section have been renamed as follow: Allocated => Forecast Spent => Actual Remaining => Difference Task-2948441 Forward-Port-Of: odoo/enterprise#30677
1) Before this commit, the planning feature was enabled on `Field Service` project. This commit ensures that: - The feature is disabled for that project. - This behavior gets not reverted by mistake by adding the necessary tests. 2) Added the test cases for this point -the 'planning' and 'documents' features should be disabled on the default 'field service' project -the 'billable' feature should be enabled by default on non-fsm projects -the 'worksheets' feature should be enabled by def
Original PR description
1) Before this commit, the planning feature was enabled on `Field Service` project. This commit ensures that: - The feature is disabled for that project. - This behavior gets not reverted by mistake by adding the necessary tests. 2) Added the test cases for this point -the 'planning' and 'documents' features should be disabled on the default 'field service' project -the 'billable' feature should be enabled by default on non-fsm projects -the 'worksheets' feature should be enabled by default on fsm projects task-2995118 Forward-Port-Of: odoo/enterprise#32190
This commit fix Time Rounding's fields width and change label from minutes to min. task-2999323 Forward-Port-Of: odoo/enterprise#31980
Original PR description
This commit fix Time Rounding's fields width and change label from minutes to min. task-2999323 Forward-Port-Of: odoo/enterprise#31980
This PR cleans the journal audit report table by: - removing the yellow background - removing the useless borders on the lines - adding a border between the rows in the header, and around the whole table Forward-Port-Of: odoo/enterprise#32611
Original PR description
This PR cleans the journal audit report table by: - removing the yellow background - removing the useless borders on the lines - adding a border between the rows in the header, and around the whole table Forward-Port-Of: odoo/enterprise#32611
Before this revision, the spreadsheet revisions were not deleted when a spreadsheet was removed. This caused the following issue: - Install `dashboard` and `spreadsheet_dashboard_crm` - Edit the dashboard with id 1 and make a modification => a spreadsheet revision is created with `res_model` = `spreadsheet.dashboard` and `res_id` = 1 - Remove `dashboard` => The spreadsheet revision is still present. - Install `spreadsheet_dashboard_account` - Try to display dashboard with id = 1 => Boom, re
Original PR description
Before this revision, the spreadsheet revisions were not deleted when a spreadsheet was removed. This caused the following issue: - Install `dashboard` and `spreadsheet_dashboard_crm` - Edit the dashboard with id 1 and make a modification => a spreadsheet revision is created with `res_model` = `spreadsheet.dashboard` and `res_id` = 1 - Remove `dashboard` => The spreadsheet revision is still present. - Install `spreadsheet_dashboard_account` - Try to display dashboard with id = 1 => Boom, revision mismatch. With this revision, we remove the spreadsheet revisions when a spreadsheet is removed. Forward-Port-Of: odoo/enterprise#32680
Currently, when no name is specified for a followup contact address, there is no placeholder. This means that the display_name for this partner is "{company_name}, ". This commit overrides the _get_name() method in order to add a placeholder for the followup address type. Task id=2996493 Forward-Port-Of: odoo/enterprise#32676
Original PR description
Currently, when no name is specified for a followup contact address, there is no placeholder. This means that the display_name for this partner is "{company_name}, ".
This commit overrides the _get_name() method in order to add a placeholder for the followup address type.
Task id=2996493
Forward-Port-Of: odoo/enterprise#32676This PR purpose is to ensure that tests are created on OWL Components that have been created in the context of the OWL migration PR odoo/enterprise#31596. This PR also addresses some bugs that have been discovered during tests writings. task-3001470 Forward-Port-Of: odoo/enterprise#32445
Original PR description
This PR purpose is to ensure that tests are created on OWL Components that have been created in the context of the OWL migration PR odoo/enterprise#31596. This PR also addresses some bugs that have been discovered during tests writings. task-3001470 Forward-Port-Of: odoo/enterprise#32445
XSLT files are used to transform the CFDI data to prepare for signing. Since we have a local copy of the XSLT file, we use that one instead. This avoids the problem that might arise on the runbot nightly builds when retrieving the XSLT fails. Forward-Port-Of: odoo/enterprise#32654
Original PR description
XSLT files are used to transform the CFDI data to prepare for signing. Since we have a local copy of the XSLT file, we use that one instead. This avoids the problem that might arise on the runbot nightly builds when retrieving the XSLT fails. Forward-Port-Of: odoo/enterprise#32654
task: Forward-Port-Of: odoo/enterprise#32628
Original PR description
task: Forward-Port-Of: odoo/enterprise#32628
Some payroll views that used groups for styling reasons started breaking after a change in the JS framework that drops table. This commit fixes them. task-3011059 Forward-Port-Of: odoo/enterprise#32510
Original PR description
Some payroll views that used groups for styling reasons started breaking after a change in the JS framework that drops table. This commit fixes them. task-3011059 Forward-Port-Of: odoo/enterprise#32510
In `no_send` mode the user isn't interested in using the OCR feature, so its banners are now hidden. Forward-Port-Of: odoo/enterprise#32217
Original PR description
In `no_send` mode the user isn't interested in using the OCR feature, so its banners are now hidden. Forward-Port-Of: odoo/enterprise#32217
task-2998139 community: https://github.com/odoo/odoo/pull/101759 Forward-Port-Of: odoo/enterprise#32302
Original PR description
task-2998139 community: https://github.com/odoo/odoo/pull/101759 Forward-Port-Of: odoo/enterprise#32302
This commit changes employee_ratio tooltip. COM PR: odoo/odoo#102672 Forward-Port-Of: odoo/enterprise#32519
Original PR description
This commit changes employee_ratio tooltip. COM PR: odoo/odoo#102672 Forward-Port-Of: odoo/enterprise#32519
Adapt the layout of the form view Steps to reproduce: * Open Accounting * Open Configuration Menu * Select Accounting Reports in (Management section) * Select Balance Sheet record * Select Current Assets record * Select balance record in list view => BUG Forward-Port-Of: odoo/enterprise#32480
Original PR description
Adapt the layout of the form view Steps to reproduce: * Open Accounting * Open Configuration Menu * Select Accounting Reports in (Management section) * Select Balance Sheet record * Select Current Assets record * Select balance record in list view => BUG Forward-Port-Of: odoo/enterprise#32480
task-2939972 See also: - https://github.com/odoo/documentation/pull/2749 Forward-Port-Of: odoo/enterprise#31387
Original PR description
task-2939972 See also: - https://github.com/odoo/documentation/pull/2749 Forward-Port-Of: odoo/enterprise#31387
The method used an arithmetic trick to extract a +/- sign It now uses another trick that will never attempt to divide by zero Task-id: None - correction pad Forward-Port-Of: odoo/enterprise#32665
Original PR description
The method used an arithmetic trick to extract a +/- sign It now uses another trick that will never attempt to divide by zero Task-id: None - correction pad Forward-Port-Of: odoo/enterprise#32665
**[IMP] account_asset: Set correct name for tab** The "Asset" tab in Deferred expense/revenue for view should be respectively "Expense" and "Revenue" Also concentrate more the display of the duration fields **[FIX] account_asset: Fix smart buttons box always on** As a field wasn't invisible, the box display was on. But without any smart button it shouldn't **[FIX] account_asset: Fix smart buttons overflowing text** As the text was too long, it was overflowing improperly on
Original PR description
**[IMP] account_asset: Set correct name for tab** The "Asset" tab in Deferred expense/revenue for view should be respectively "Expense" and "Revenue" Also concentrate more the display of the duration fields **[FIX] account_asset: Fix smart buttons box always on** As a field wasn't invisible, the box display was on. But without any smart button it shouldn't **[FIX] account_asset: Fix smart buttons overflowing text** As the text was too long, it was overflowing improperly on others Signed-off-by: Julien Alardot (jual) <jual@odoo.com> Forward-Port-Of: odoo/enterprise#32640
`mass_mailing_sale_subscription` does not have an explicit dependency on `mass_mailing_sale`, but the `super()` call in `_mailing_get_default_domain()` depends on it, otherwise it fails because there is no such method in `base` model. No dependency means `mass_mailing_sale` is not guaranteed to be installed, though! <details> <summary>stacktrace</summary> ``` File "/home/odoo/src/odoo/addons/mass_mailing/models/mailing.py", line 1199, in _get_default_mailing_domain mailing_d
Original PR description
`mass_mailing_sale_subscription` does not have an explicit dependency on `mass_mailing_sale`, but the `super()` call in `_mailing_get_default_domain()` depends on it, otherwise it fails because there…
`mass_mailing_sale_subscription` does not have an explicit dependency on `mass_mailing_sale`, but the `super()` call in `_mailing_get_default_domain()` depends on it, otherwise it fails because there is no such method in `base` model.
No dependency means `mass_mailing_sale` is not guaranteed to be installed, though!
<details>
<summary>stacktrace</summary>
```
File "/home/odoo/src/odoo/addons/mass_mailing/models/mailing.py", line 1199, in _get_default_mailing_domain
mailing_domain = self.env[self.mailing_model_name]._mailing_get_default_domain(self)
File "/home/odoo/src/enterprise/mass_mailing_sale_subscription/models/sale_order.py", line 12, in _mailing_get_default_domain
domain = super()._mailing_get_default_domain(mailing)
AttributeError: 'super' object has no attribute '_mailing_get_default_do
```
</details>
In order to not change dependencies in a stable branch, the parent domain from `mass_mailing_sale` is inlined, as there's not much to duplicate.
The dependency can be changed in master later.
Forward-Port-Of: odoo/enterprise#32086Use the o_field_highlight class to make sure that fields in sidepanels for page properties (knowledge) or e.g. filter edition (spreadsheet). Forward-Port-Of: odoo/enterprise#32597
Original PR description
Use the o_field_highlight class to make sure that fields in sidepanels for page properties (knowledge) or e.g. filter edition (spreadsheet). Forward-Port-Of: odoo/enterprise#32597
See also: - https://github.com/odoo/odoo/pull/102585 Forward-Port-Of: odoo/enterprise#32490
Original PR description
See also: - https://github.com/odoo/odoo/pull/102585 Forward-Port-Of: odoo/enterprise#32490
The next invoice date and end date are tracked, whereas the start date is not. Tracking this field would however ease the understanding of a subscription history. Forward-Port-Of: odoo/enterprise#32604
Original PR description
The next invoice date and end date are tracked, whereas the start date is not. Tracking this field would however ease the understanding of a subscription history. Forward-Port-Of: odoo/enterprise#32604
Introduce dark-mode for enterprise odoo webclient. depends on: - https://github.com/odoo/odoo/pull/99755 task-2710677 --- An `rd-design` team project. Contributors: anso[@]odoo brd[@]odoo xlu[@]odoo sri[@]odoo Thanks to the `rd-mobile-team` for the technical support. adr[@]odoo app[@]odoo res[@]odoo rfr[@]odoo Forward-Port-Of: odoo/enterprise#31128
Original PR description
Introduce dark-mode for enterprise odoo webclient. depends on: - https://github.com/odoo/odoo/pull/99755 task-2710677 --- An `rd-design` team project. Contributors: anso[@]odoo brd[@]odoo xlu[@]odoo sri[@]odoo Thanks to the `rd-mobile-team` for the technical support. adr[@]odoo app[@]odoo res[@]odoo rfr[@]odoo Forward-Port-Of: odoo/enterprise#31128
[IMP] account_invoice_extract: remove OCR success banner [FIX] account_invoice_extract: remove hotkeys for buttons in status bar [IMP] hr_{expense,recruitment}_extract: uniformize OCR banners Forward-Port-Of: odoo/enterprise#32521
Original PR description
[IMP] account_invoice_extract: remove OCR success banner
[FIX] account_invoice_extract: remove hotkeys for buttons in status bar
[IMP] hr_{expense,recruitment}_extract: uniformize OCR banners
Forward-Port-Of: odoo/enterprise#32521Forward-Port-Of: odoo/enterprise#32408
Original PR description
Forward-Port-Of: odoo/enterprise#32408
The recent switch from tables to css grids for form views `group` nodes has introduced several inconsistencies/issues with several views accross modules - these will not be the last fixes. Forward-Port-Of: odoo/enterprise#32293
Original PR description
The recent switch from tables to css grids for form views `group` nodes has introduced several inconsistencies/issues with several views accross modules - these will not be the last fixes. Forward-Port-Of: odoo/enterprise#32293
Currently, in social_marketing, when we try to add a stream on small devices, the social platform cards are shown in single line and get out of the screen. This commit fixes the issue by 'wrapping' the cards in next line if there is not enough space. Also, as a side improvement, the width is now fixed at 90px, so that when wrapped, the cards look aligned properly (having same width). Also, Change the `o_social_media_cards` class property so that the tour works as before (to display the b
Original PR description
Currently, in social_marketing, when we try to add a stream on small devices, the social platform cards are shown in single line and get out of the screen. This commit fixes the issue by 'wrapping' the cards in next line if there is not enough space. Also, as a side improvement, the width is now fixed at 90px, so that when wrapped, the cards look aligned properly (having same width). Also, Change the `o_social_media_cards` class property so that the tour works as before (to display the bubble in the proper position). task-2893410 Forward-Port-Of: odoo/enterprise#30501
Forward-Port-Of: odoo/enterprise#32633
Original PR description
Forward-Port-Of: odoo/enterprise#32633
This PR addresses several layout issue in planning task-3011343 Forward-Port-Of: odoo/enterprise#32546
Original PR description
This PR addresses several layout issue in planning task-3011343 Forward-Port-Of: odoo/enterprise#32546
The field `work_entry_source` was added in #19189 but is only available when `hr_work_entry` is installed - which `hr_contract_salary` doesn't depend on - causing a traceback when trying to submit the salary configuration. Forward-Port-Of: odoo/enterprise#32648
Original PR description
The field `work_entry_source` was added in #19189 but is only available when `hr_work_entry` is installed - which `hr_contract_salary` doesn't depend on - causing a traceback when trying to submit the salary configuration. Forward-Port-Of: odoo/enterprise#32648
Forward-Port-Of: odoo/enterprise#32616
Original PR description
Forward-Port-Of: odoo/enterprise#32616
*: appointment, iot, quality_control_worksheet Before this commit, some functions overrode the save function of the form controller. The issue is that this function is only called when the button save is clicked, and not when we save differently (for example, when clicking on the breadcrumb). To avoid this mistake the save function on the form controller was renamed to: `saveButtonClicked`, and the code that overrode the function now override the save function of the Record, that it's call
Original PR description
*: appointment, iot, quality_control_worksheet Before this commit, some functions overrode the save function of the form controller. The issue is that this function is only called when the button save is clicked, and not when we save differently (for example, when clicking on the breadcrumb). To avoid this mistake the save function on the form controller was renamed to: `saveButtonClicked`, and the code that overrode the function now override the save function of the Record, that it's called at each time a save is perform. Forward-Port-Of: odoo/enterprise#32454
The call to `join_spreadsheet_session` is done twice. Once by `onWillStart(() => this.onWillStart());` in the parent action and once in child. Forward-Port-Of: odoo/enterprise#32595
Original PR description
The call to `join_spreadsheet_session` is done twice. Once by `onWillStart(() => this.onWillStart());` in the parent action and once in child. Forward-Port-Of: odoo/enterprise#32595