Friday, October 28, 2022
52 changes · master
Enhancements to existing features
The Mail module has been updated to use the standard way of referencing a shared Odoo web component library. This is an internal modernization that helps keep the codebase consistent and easier to maintain, with no expected change for end users.
Original PR description
Use the standard import syntax for '@odoo/owl' task-3046123 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The analytic distribution setup form has clearer labels, group names, and tooltip text. These adjustments make the screen easier for users to understand when configuring analytic distribution rules.
Original PR description
Description of the issue/feature this PR addresses: improves form view of the analytical distribution Current behavior before PR: old UI Desired behavior after PR is merged: new UI --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update standardizes the internal names of many messaging and communication interface parts so they better match the underlying business models. It should not change day-to-day behavior for users, but it improves maintainability and consistency for future enhancements across chat, live chat, HR, SMS, and related apps.
Original PR description
[IMP] mail: rename ActivityBox to ActivityBoxView (component) Task-3046113 [IMP] mail: rename ActivityMarkDonePopoverContent (component) Task-3046122 [IMP] mail: rename AttachmentBox to…
This change makes search settings easier to extend across website pages, blogs, events, forums, and e-learning content. It helps partners and implementers customize search behavior more consistently without changing core code, improving maintainability for tailored websites.
Original PR description
*: website_blog, website_event, website_forum, website_slides With [1] it has been made easier for partners to extend search options. This task introduces similar inheritable functions for blog posts, events, forum posts, slides, pages and hybrid results. [1]: https://github.com/odoo/odoo/commit/d29f2f3ac5f8c3e8109287e0933609bdbe0cadb1 task-2897924
This update standardizes the internal names of several messaging interface components so they better match the underlying business data models. It affects mail-related experiences across Documents, Knowledge, Live Chat, Helpdesk Knowledge, and payroll test flows, with no expected functional change for end users.
Original PR description
[IMP] mail: rename ActivityBox to ActivityBoxView (component) Task-3046113 [IMP] mail: rename AttachmentBox to AttachmentBoxView (component) Task-3046129 [IMP] mail: *: rename ChatWindowHeader…
[IMP] mail: rename ActivityBox to ActivityBoxView (component) Task-3046113 [IMP] mail: rename AttachmentBox to AttachmentBoxView (component) Task-3046129 [IMP] mail: *: rename ChatWindowHeader (component) *: mail_enterprise Task-3046330 [IMP] mail, *: rename Composer (component) *: documents, knowledge, mail_enterprise, website_helpdesk_livechat Task-3046555 [IMP] mail, *: rename ComposerTextInput (component) *: documents, mail_enterprise, website_helpdesk_livechat Task-3046648 [IMP] mail, *: rename Discuss (component) *: mail_enterprise Task-3046685 [IMP] mail, *: rename FollowerListMenu (component) *: documents Task-3047236 [IMP] mail: rename Message (component) *: documents, mail_enterprise, test_l10n_be_hr_payroll_account, website_helpdesk_knowledge Task-3047352 [IMP] mail, *: rename MessageList (component) *: mail_enterprise Task-3047718 [IMP] mail, *: rename NotificationGroup (component) *: mail_enterprise Task-3047829 [IMP] mail, *: rename NotificationList (component) *: mail_enterprise Task-3047871 [IMP] mail, *: rename ThreadNeedactionPreview (component) *: mail_enterprise Task-3048021 Task-3047725 Community: https://github.com/odoo/odoo/pull/104548
The test suite now reuses existing reference records instead of recreating copied test data. This makes tests for approvals, documents, and live chat support easier to maintain and less likely to drift from real configuration.
Original PR description
*: approvals, documents, website_helpdesk_livechat. Before this PR, fake records where inserted with the `insertRecords` method. Most of them were copied from the ones available in xml files. This PR introduce a way to fetch records by their xml ids at the beginning of the test suite. Those records can then be accessed from `pyEnv.ref`. task-2869408 community: https://github.com/odoo/odoo/pull/103835
The mail enterprise component now uses Odoo's standard way of referencing a shared frontend library. This is an internal cleanup that improves consistency for developers without changing the user experience.
Original PR description
Use the standard import syntax for '@odoo/owl' task-3046123
Users now see helpful action buttons after completing statement reconciliation when visual effects are turned off. This gives accounting teams clearer guidance on where to go next and reduces confusion at the end of the workflow.
Original PR description
when effects are disabled, the user has no guidance on where to go next. This commit includes buttons in the notification panel
Resolved issues and error corrections
Task Analysis records now open in a properly designed form instead of an automatically generated layout. This makes the reporting details easier to read and gives users a more polished experience when drilling into project task data.
Original PR description
**Description of the issue/feature this PR addresses:** Currently for the report.project.task.user model there is no form views defined. so on clicking the tree view, when the form is opened, odoo is providing a default view, which is not currently aligned well. 1.Project -> Reporting -> Task Analysis 2. Click on any record/data in graph view 3. Tree will be opened now and click any record in tree to open form view. **Current behavior before PR:** User is getting a default form view, which is not aligned well. **Desired behavior after PR is merged:** Clean form view will be visible for the user. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
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#104161
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104161
[IMP] mail: rename ActivityBox to ActivityBoxView (component) Task-3046113 [IMP] mail: rename ActivityMarkDonePopoverContent (component) Task-3046122 [IMP] mail: rename AttachmentBox to AttachmentBoxView (component) Task-3046129 [IMP] mail: rename AttachmentDeleteConfirm (component) Task-3046160 [IMP] mail: rename CallActionList (component) Task-3046187 [IMP] mail: rename CallParticipantVideo to CallParticipantVideoView (component) Task-3046193 [IMP] mail: rename ChannelInvitationFormSelectablePartner (component) Task-3046287 [IMP] mail: rename ChannelInvitationFormSelectedPartner (component) Task-3046288 [IMP] mail: rename ChannelMember (component) Task-3046298 [IMP] mail: rename ChannelMemberList (component) Task-3046306 [IMP] mail: rename ChannelMemberListCategory (component) Task-3046307 [IMP] mail: *: rename ChatWindowHeader (component) *: hr, im_livechat, website_livechat Task-3046330 [IMP] mail: rename ChatWindowHiddenMenu (component) Task-3046358 [IMP] mail: rename ChatWindowHiddenMenuItem (component) Task-3046515 [IMP] mail, *: rename Composer (component) *: hr_recruitment, im_livechat Task-3046555 [IMP] mail: rename ComposerSuggestedRecipient (component) Task-3046598 [IMP] mail: rename ComposerSuggestedRecipientList (component) Task-3046624 [IMP] mail, *: rename ComposerTextInput (component) *: im_livechat Task-3046648 [IMP] mail: rename DeleteMessageConfirm (component) Task-3046661 [IMP] mail, *: rename Discuss (component) *: im_livechat Task-3046685 [IMP] mail: rename DiscussMobileMailboxSelection (component) Task-3046703 [IMP] mail: rename DiscussMobileMailboxSelectionItem (component) Task-3046709 [IMP] mail, *: rename DiscussSidebar (component) Task-3046719 [IMP] mail: rename DiscussSidebarMailbox (component) Task-3046732 [IMP] mail: rename DropZone (component) Task-3046739 [IMP] mail: rename FollowButton (component) Task-3047154 [IMP] mail: rename Follower (component) Task-3047203 [IMP] mail: rename FollowerListMenu (component) Task-3047236 [IMP] mail: rename FollowerSubtype (component) Task-3047272 [IMP] mail: rename MailTemplate (component) Task-3047314 [IMP] mail, *: rename Message (component) *: im_livechat, sms, snailmail, website_sale Task-3047352 [IMP] mail: rename MessageAuthorPrefix (component) Task-3047683 [IMP] mail, *: rename MessageList (component) *: hr_recruitment, website_livechat Task-3047718 [IMP] mail, *: rename MessageNotificationPopoverContent (component) *: sms Task-3047742 [IMP] mail: rename MessageSeenIndicator (component) Task-3047765 [IMP] mail, *: rename MessagingMenuTab (component) *: im_livechat Task-3047802 [IMP] mail: rename MobileMessagingNavbar (component) Task-3047806 [IMP] mail, *: rename NotificationGroup (component) *: sms, snailmail Task-3047829 [IMP] mail, *: rename NotificationList (component) *: im_livechat Task-3047871 [IMP] mail: rename NotificationRequest (component) Task-3047883 [IMP] mail, *: rename PersonaImStatusIcon (component) *: hr_holidays Task-3047969 [IMP] mail, *: rename ThreadIcon (component) *: hr_holidays, im_livechat Task-3047980 [IMP] mail, *: rename ThreadNeedactionPreview (component) *: im_livechat, rating, test_mail_full Task-3048021 [IMP] mail, *: rename ThreadTextualTypingStatus (component) *: im_livechat Task-3048042 [IMP] mail, *: rename ThreadTypingIcon (component) *: im_livechat Task-3048043 [IMP] snailmail: rename SnailmailError (component) Task-3048051 [IMP] website_livechat: rename VisitorBanner (component) Task-3048069 Task-3047725 Enterprise: https://github.com/odoo/enterprise/pull/33411
This corrects a typo in an internal method name used by stock transfers. It helps keep the stock module code consistent and easier to maintain, with no expected change to day-to-day user workflows.
Original PR description
issue #97863 previous PR #101825 can't be changed in stable version --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The dynamic placeholder result was not added in the editable dom in some situation. When the editor was in rollback mode `true` after a `commitChange` ( maybe because of a `_toInline` called) the result of the dynamic placeholder was rollback. task-3044924 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104169
Original PR description
The dynamic placeholder result was not added in the editable dom in some situation. When the editor was in rollback mode `true` after a `commitChange` ( maybe because of a `_toInline` called) the result of the dynamic placeholder was rollback. task-3044924 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104169
Steps to reproduce: - Install finish Finnish Localization(l10n_fi) module,Accounting - Verify accounting taxes (brutto: 24%|14%|10%) price_include checkbox is deselected Issue: Price_include field set to False Cause: Field in locale template view not defined, model defaults to False Solution: Field defined in tax template data and set to True for locale opw-2992952 Forward-Port-Of: odoo/odoo#103725
Original PR description
Steps to reproduce: - Install finish Finnish Localization(l10n_fi) module,Accounting - Verify accounting taxes (brutto: 24%|14%|10%) price_include checkbox is deselected Issue: Price_include field set to False Cause: Field in locale template view not defined, model defaults to False Solution: Field defined in tax template data and set to True for locale opw-2992952 Forward-Port-Of: odoo/odoo#103725
**Steps to reproduce the bug:** - Create a Storable product “P1”: - UOM: unit - Update the qty to 100 - Create an out transfert: - Product: P1 - Qty: 2 - UOM: dozens - Validate the transfert - Go to inventory > report > stock valuation - an SVL is created with Qty: 24 → 2 pack of 12 - Go back to the picking: - Unlock it - change the done qty from 2 to 3 - Lock the picking **Problem:** The quantity on the new SVL is not converted to the def
Original PR description
**Steps to reproduce the bug:** - Create a Storable product “P1”: - UOM: unit - Update the qty to 100 - Create an out transfert: - Product: P1 - Qty: 2 - UOM: dozens - Validate the transfert - Go to…
**Steps to reproduce the bug:**
- Create a Storable product “P1”:
- UOM: unit
- Update the qty to 100
- Create an out transfert:
- Product: P1
- Qty: 2
- UOM: dozens
- Validate the transfert
- Go to inventory > report > stock valuation
- an SVL is created with Qty: 24 → 2 pack of 12
- Go back to the picking:
- Unlock it
- change the done qty from 2 to 3
- Lock the picking
**Problem:**
The quantity on the new SVL is not converted to the default UoM set on the product.
In the write function of `stock.move.line` we calculate the difference between the old and the new qty (3 - 2), then, the `_create_correction_svl` is called:
https://github.com/odoo/odoo/blob/15.0/addons/stock_account/models/stock_move_line.py#L45-L48
without converting this quantity difference into the product uom, The `_create_out_svl` function is called with the `forced_quantity` parameter:
https://github.com/odoo/odoo/blob/15.0/addons/stock_account/models/stock_move_line.py#L66
As it is a forced quantity, it will not convert it:
https://github.com/odoo/odoo/blob/14.0/addons/stock_account/models/stock_move.py#L188
**Solution:**
Convert diff qty in the `_create_correction_svl`, to avoid converting it in every function it may call
opw-3041279
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#104096**Steps to reproduce the bug:** - Create a storable product “P1” - update the quantity to 10 - Go to inventory > configuration > warehouse Management > location - Select your location > current stock - Search the Product “P1” **Problem:** In `stock.quant’ list view > the available qty is displayed, but if you click on the line, the available qty is not displayed in the form view, only the qty counted is displayed opw-3018469 --- I confirm I have signed the CLA and read the
Original PR description
**Steps to reproduce the bug:** - Create a storable product “P1” - update the quantity to 10 - Go to inventory > configuration > warehouse Management > location - Select your location > current stock - Search the Product “P1” **Problem:** In `stock.quant’ list view > the available qty is displayed, but if you click on the line, the available qty is not displayed in the form view, only the qty counted is displayed opw-3018469 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103553
This commit purpose is to ensure that projects created from a SOL are created with `allow_billable` set to `True` task-2992614 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#101461
Original PR description
This commit purpose is to ensure that projects created from a SOL are created with `allow_billable` set to `True` task-2992614 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#101461
See also: - https://github.com/odoo/internal/pull/1870 task-2982347 Forward-Port-Of: odoo/odoo#102483
Original PR description
See also: - https://github.com/odoo/internal/pull/1870 task-2982347 Forward-Port-Of: odoo/odoo#102483
The payment terms printed on the invoice are ordered by date. However, the order was applied on the string version of the date, which caused issues. Fixed this by formatting the date to string after the ordering. Forward-Port-Of: odoo/odoo#104122
Original PR description
The payment terms printed on the invoice are ordered by date. However, the order was applied on the string version of the date, which caused issues. Fixed this by formatting the date to string after the ordering. Forward-Port-Of: odoo/odoo#104122
**Description of the issue/feature this PR addresses:** pos_config_ids field is added without string attribute and when the string is not given in the xml side in the view, currently the field label is shown as Pos Config, which is expected to be Point of Sales( as Odoo display's in other views) **Current behavior before PR:** Missing string attribute for the field and label is shown as Pos Config **Desired behavior after PR is merged:** Correct label for the field as per other views
Original PR description
**Description of the issue/feature this PR addresses:** pos_config_ids field is added without string attribute and when the string is not given in the xml side in the view, currently the field label is shown as Pos Config, which is expected to be Point of Sales( as Odoo display's in other views) **Current behavior before PR:** Missing string attribute for the field and label is shown as Pos Config **Desired behavior after PR is merged:** Correct label for the field as per other views --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103711
Since the settings in POS have been moved to the general settings, we have two way to access those general settings. First throug the general settings, second when you open the shortlist of settings editable by every pos manager and follow the link to the general ones. In the second case, when we arrive into the general settings, the settings displayed are not always the one of the POS config you come from, because by default it only show the settings of the latest pos config editted. So w
Original PR description
Since the settings in POS have been moved to the general settings, we have two way to access those general settings. First throug the general settings, second when you open the shortlist of settings editable by every pos manager and follow the link to the general ones. In the second case, when we arrive into the general settings, the settings displayed are not always the one of the POS config you come from, because by default it only show the settings of the latest pos config editted. So we are now checking if we are comming from a pos config to display the correct one. 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#104315
Without this, it will simply ignored the given `_text` variable as the t-nocache part is scroped. It means it can't access natively the variables outside of its scope unless those are passed to the scope through the `t-nocache-var_name` form. Basically, it resulted in the "My Cart" never shown next to the cart badge counter. Most of the time, this text is used in replacement of the `fa` icon, so it led to poor UI: a floating badge left alone. task-3044936 Forward-Port-Of: odoo/odoo#
Original PR description
Without this, it will simply ignored the given `_text` variable as the t-nocache part is scroped. It means it can't access natively the variables outside of its scope unless those are passed to the scope through the `t-nocache-var_name` form. Basically, it resulted in the "My Cart" never shown next to the cart badge counter. Most of the time, this text is used in replacement of the `fa` icon, so it led to poor UI: a floating badge left alone. task-3044936 Forward-Port-Of: odoo/odoo#104232
Steps to reproduce: In a base runbot with just contacts installed and the module "account_edi_ubl_cii". Go to contacts, Configuration, and Bank Accounts, try to create a bank account for any user. Issue: The creation throws an error and doesn't let us create any bank account. Solution: We need to add the missing decorator: @api.model_create_multi, which is needed when we work with vals_list. opw-3039048 Forward-Port-Of: odoo/odoo#104359
Original PR description
Steps to reproduce: In a base runbot with just contacts installed and the module "account_edi_ubl_cii". Go to contacts, Configuration, and Bank Accounts, try to create a bank account for any user. Issue: The creation throws an error and doesn't let us create any bank account. Solution: We need to add the missing decorator: @api.model_create_multi, which is needed when we work with vals_list. opw-3039048 Forward-Port-Of: odoo/odoo#104359
Also correct mistake in name of RDC in manifest. Modification in the COA (clearer name) + change made on some account about reconciliation, before this commit there was way to much reconcilable account, it's now corrected Demo company modified Menu item added task-id: 2350061 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103668 Forward-Port-Of: odoo/odoo#89672
Original PR description
Also correct mistake in name of RDC in manifest. Modification in the COA (clearer name) + change made on some account about reconciliation, before this commit there was way to much reconcilable account, it's now corrected Demo company modified Menu item added task-id: 2350061 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#103668 Forward-Port-Of: odoo/odoo#89672
Steps to reproduce ================== - Go to Project > My tasks - Drag a card to another column -> An error occurs Cause of the issue ================== `personal_stage_type_ids` was not changed to `personal_stage_type_id` opw-3036820 Forward-Port-Of: odoo/odoo#104201
Original PR description
Steps to reproduce ================== - Go to Project > My tasks - Drag a card to another column -> An error occurs Cause of the issue ================== `personal_stage_type_ids` was not changed to `personal_stage_type_id` opw-3036820 Forward-Port-Of: odoo/odoo#104201
This PR adds handling the generation of cover pages for snail-mails locally since Pingen v2 does not accept generating one during the initial request anymore. It also modifies the styling for the invoices sent with Snailmail in order for them to comply with Pingen's strict validation. This change requires multiple PR due to some style classes name being shared between different versions and each version requiring different tweaks to comply with Pingen's validation. Forward-Port-Of: odoo/odo
Original PR description
This PR adds handling the generation of cover pages for snail-mails locally since Pingen v2 does not accept generating one during the initial request anymore. It also modifies the styling for the invoices sent with Snailmail in order for them to comply with Pingen's strict validation. This change requires multiple PR due to some style classes name being shared between different versions and each version requiring different tweaks to comply with Pingen's validation. Forward-Port-Of: odoo/odoo#103381
Steps to reproduce: - Setup Wire transfer as Payment Provider - Create a sale from shop - Use Wire transfer as payment method - Go to Sales > Confirm the quotation - Create Invoice - Click 'Preview' to view invoice in customer portal view Issue: internal server error The `provider` field has been renamed to `provider_code` in b7f5eb54453737f371eda4ca897300b89abd9c2e opw-3031308 Forward-Port-Of: odoo/odoo#104089
Original PR description
Steps to reproduce: - Setup Wire transfer as Payment Provider - Create a sale from shop - Use Wire transfer as payment method - Go to Sales > Confirm the quotation - Create Invoice - Click 'Preview' to view invoice in customer portal view Issue: internal server error The `provider` field has been renamed to `provider_code` in b7f5eb54453737f371eda4ca897300b89abd9c2e opw-3031308 Forward-Port-Of: odoo/odoo#104089
Current behavior: When setting up a sales team in the PoS setting and trying to invoice an order, a traceback is raised. Steps to reproduce: - Go in PoS settings and set a sales team - Open a PoS session - Select a customer and add some products to the order - Go to the payment page, select a payment method and click on "Invoice" - A traceback is raised opw-3038413 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1
Original PR description
Current behavior: When setting up a sales team in the PoS setting and trying to invoice an order, a traceback is raised. Steps to reproduce: - Go in PoS settings and set a sales team - Open a PoS session - Select a customer and add some products to the order - Go to the payment page, select a payment method and click on "Invoice" - A traceback is raised opw-3038413 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104324
In `_compute_analytic_distribution` in project_purchase, we're dealing with recordset and so, should iterate on it. Also, the distribution expects an id, not the record of the analytic account. In sale, the `account` should be `account_id` as it is an id. 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-O
Original PR description
In `_compute_analytic_distribution` in project_purchase, we're dealing with recordset and so, should iterate on it. Also, the distribution expects an id, not the record of the analytic account. In sale, the `account` should be `account_id` as it is an id. 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#104227
Since the iOS 16.1 update, the WKWebView used in the iOS mobile app crashes when trying to instanciate a `SharedWorker`... even if this feature was newly added in iOS 16.0. Safari iOS doesn't seem to be impacted. This commit works around this issue by disabling the usage of the `SharedWorker` in the iOS mobile app, using instead the existing fallback to a regular `Worker`. Steps to reproduce: - On a device running iOS 16.1 - Open Odoo in the iOS mobile app => Once connected the app fr
Original PR description
Since the iOS 16.1 update, the WKWebView used in the iOS mobile app crashes when trying to instanciate a `SharedWorker`... even if this feature was newly added in iOS 16.0. Safari iOS doesn't seem to be impacted. This commit works around this issue by disabling the usage of the `SharedWorker` in the iOS mobile app, using instead the existing fallback to a regular `Worker`. Steps to reproduce: - On a device running iOS 16.1 - Open Odoo in the iOS mobile app => Once connected the app freezes with a gray screen Forward-Port-Of: odoo/odoo#104295
"div" as a child of "tr" is not really allowed. Because of this, custom widgets in a list_renderer are not properly styled resulting to issue where a widget doesn't take the full height of the parent "tr" element. This was missed during initial wowl porting so in this commit, we are putting the widget inside a "td" element. **Illustrations:** Before: <img width="959" alt="Screenshot 2022-10-28 at 11 48 26" src="https://user-images.githubusercontent.com/3245568/198559559-a7e4a8f8-
Original PR description
"div" as a child of "tr" is not really allowed. Because of this, custom widgets in a list_renderer are not properly styled resulting to issue where a widget doesn't take the full height of the parent "tr" element. This was missed during initial wowl porting so in this commit, we are putting the widget inside a "td" element. **Illustrations:** Before: <img width="959" alt="Screenshot 2022-10-28 at 11 48 26" src="https://user-images.githubusercontent.com/3245568/198559559-a7e4a8f8-0b5c-493a-97f9-17db54d8b042.png"> After: <img width="957" alt="Screenshot 2022-10-28 at 11 51 10" src="https://user-images.githubusercontent.com/3245568/198559638-84639595-b8f3-4b9d-a597-f7d5a316b3c7.png"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104314
Since commit, odoo/odoo@f2b71d51aa409eae435f31d433dac4290c2b80ab the text ellipsis is working again with long breadcrumb. But in form view when there is a long breadcrumb, the 'form status indicator' (save, discard) is not visible anymore. In this commit, we move the 'form status indicator' outside the breadcrumb, so it can't be hidden anymore. Note: we also changed the `align-items` to `flex-start` to keep all buttons aligned on the top ('form status indicator', action menu, pager, create
Original PR description
Since commit, odoo/odoo@f2b71d51aa409eae435f31d433dac4290c2b80ab the text ellipsis is working again with long breadcrumb. But in form view when there is a long breadcrumb, the 'form status indicator'…
Since commit, odoo/odoo@f2b71d51aa409eae435f31d433dac4290c2b80ab the text ellipsis is working again with long breadcrumb. But in form view when there is a long breadcrumb, the 'form status indicator' (save, discard) is not visible anymore.
In this commit, we move the 'form status indicator' outside the breadcrumb, so it can't be hidden anymore.
Note: we also changed the `align-items` to `flex-start` to keep all buttons aligned on the top ('form status indicator', action menu, pager, create button, send message, ...).
Steps to reproduce:
* Go to Sales
* Select a Quotation
* Click on the customer (to go to customer form view)
* Change its name to have a long breadcrumb
* Go back to the home menu
* Go to Sales
* Select the same Quotation as before
* Click on the customer (to go to customer form view)
* Change some data in the customer form => BUG 'form status indicator' isn't visible
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#104438When `make_json_response` was added in 034d01b2f36609297fd5af3bceb28ee7066ccc77 and `_response` was updated to use it, the `status` extracted from the error object was forgotten. Pass that status into `make_json_response` so the final response has the expected status code. Forward-Port-Of: odoo/odoo#104144
Original PR description
When `make_json_response` was added in 034d01b2f36609297fd5af3bceb28ee7066ccc77 and `_response` was updated to use it, the `status` extracted from the error object was forgotten. Pass that status into `make_json_response` so the final response has the expected status code. Forward-Port-Of: odoo/odoo#104144
Steps to reproduce: Go to a product form view that has a BoM. Issue: The price is displayed collapsed with the units and currency text. Solution: We need to remove the class "o_row" in order to be displayed in 2 columns as it is in other versions. opw-3041120 Forward-Port-Of: odoo/odoo#104339
Original PR description
Steps to reproduce: Go to a product form view that has a BoM. Issue: The price is displayed collapsed with the units and currency text. Solution: We need to remove the class "o_row" in order to be displayed in 2 columns as it is in other versions. opw-3041120 Forward-Port-Of: odoo/odoo#104339
Using a `frozenset` leads to non deterministic issues. Because when nothing is set in the context key `allowed_company_ids`, `self.env.companies` will fallback on `self['res.company'].browse(user_company_ids)` Since the browsing is done on a non ordered set, the recordset doesn't follow the `_order` set on the model, by definition. This has the effect of not being deterministic when iterating on `self.env.companies`. For instance https://runbot.odoo.com/runbot/build/20539598 Forward
Original PR description
Using a `frozenset` leads to non deterministic issues. Because when nothing is set in the context key `allowed_company_ids`, `self.env.companies` will fallback on `self['res.company'].browse(user_company_ids)` Since the browsing is done on a non ordered set, the recordset doesn't follow the `_order` set on the model, by definition. This has the effect of not being deterministic when iterating on `self.env.companies`. For instance https://runbot.odoo.com/runbot/build/20539598 Forward-Port-Of: odoo/odoo#104284
Before this commit, opening the Page Manager in debug mode would throw an error, stating that the website.RecordFilter has a t-foreach with duplicated keys. As per the [owl documentation]: "Owl requires the presence of a t-key directive, to be able to properly reconcile renderings." and "A key should be a unique number or string." This commit fixes the keys to be the website id instead of the website object. [owl documentation]: https://github.com/odoo/owl/blob/master/doc/reference
Original PR description
Before this commit, opening the Page Manager in debug mode would throw an error, stating that the website.RecordFilter has a t-foreach with duplicated keys. As per the [owl documentation]: "Owl requires the presence of a t-key directive, to be able to properly reconcile renderings." and "A key should be a unique number or string." This commit fixes the keys to be the website id instead of the website object. [owl documentation]: https://github.com/odoo/owl/blob/master/doc/reference/templates.md#loops --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#104425
The res.config.settings form view is handled with a custom widget expecting a very specific structure. a `<t>` node in the middle of `<div class="settings">` and `<div class="app_settings_block">` screws things up, and the app block will no longer be shown as expected in the web interface. This issue has been introduced with odoo/odoo#103799 The current revision reverts the change so it becomes as before, the `<t>` blocks with only `groups="..."` are removed from the architecture,
Original PR description
The res.config.settings form view is handled with a custom widget expecting a very specific structure. a `<t>` node in the middle of `<div class="settings">` and `<div class="app_settings_block">`…
The res.config.settings form view is handled with a custom widget expecting a very specific structure. a `<t>` node in the middle of `<div class="settings">` and `<div class="app_settings_block">` screws things up, and the app block will no longer be shown as expected in the web interface. This issue has been introduced with odoo/odoo#103799 The current revision reverts the change so it becomes as before, the `<t>` blocks with only `groups="..."` are removed from the architecture, even if they have not been added by the postprocessing itself. An alternative fix is done, directly in the `web_studio` module of odoo/enterprise, to overcome the issue odoo/odoo#103799 was solving. Both issues are covered with unit tests: - the issue odoo/odoo#103799 was solving is covered with the unit test added in the related odoo/enterprise#33075 - the issue solved by the current revision is covered with units tests added in this revision directly. Forward-Port-Of: odoo/odoo#104462
Before this commit, if a translation dialog was open, and the view where the button is unmounted, the dialog stays open. Now, the dialog closes, when the view is unmounted. Forward-Port-Of: odoo/odoo#104489
Original PR description
Before this commit, if a translation dialog was open, and the view where the button is unmounted, the dialog stays open. Now, the dialog closes, when the view is unmounted. Forward-Port-Of: odoo/odoo#104489
Before this commit, in the list view, clicking on the "export all" button created an xslx file that did not reproduce the order of the columns in the view. Why is this? The order used was based on the data fetched by a rpc("/web/export/get_fields". Solution: Do not do a rpc("/web/export/get_fields") and use the order of the columns in archInfo. How to reproduce: - Go to a list view - Click on the "export all" button Before this commit: The order of the columns in the created f
Original PR description
Before this commit, in the list view, clicking on the "export all" button created an xslx file that did not reproduce the order of the columns in the view.
Why is this?
The order used was based on the data fetched by a
rpc("/web/export/get_fields".
Solution:
Do not do a rpc("/web/export/get_fields") and use the order of the columns in archInfo.
How to reproduce:
- Go to a list view
- Click on the "export all" button
Before this commit:
The order of the columns in the created file may be different from the order in the list view.
After this commit:
The order of the columns in the created file is the same as in the list view.
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#104454`Payment acquirer` model was renamed `Payment Provider` in f7b8f07. Forward-Port-Of: odoo/odoo#104473
Original PR description
`Payment acquirer` model was renamed `Payment Provider` in f7b8f07. Forward-Port-Of: odoo/odoo#104473
Steps to reproduce: - set time effeciency of a workcenter to less than 100 - on a product page with a BoM using that workcenter - for the cost click on compute price from BoM Bug: workcenter effeciency is not taken into consideration Fix: included time_effeciency in computing the expected duration opw-3033672 Forward-Port-Of: odoo/odoo#104509 Forward-Port-Of: odoo/odoo#103705
Original PR description
Steps to reproduce: - set time effeciency of a workcenter to less than 100 - on a product page with a BoM using that workcenter - for the cost click on compute price from BoM Bug: workcenter effeciency is not taken into consideration Fix: included time_effeciency in computing the expected duration opw-3033672 Forward-Port-Of: odoo/odoo#104509 Forward-Port-Of: odoo/odoo#103705
A document folder can have different access rights than its subfoldes, like different groups or companies. Which can result in access errors when a folder is displaying its full path and reading the parent folder name. How to reproduce: ```- Create a multi company environment in a db v13 or higher - Go to Documents > configuration > workspaces - Enable 2 companies in the company selector - Create a folder "parent" in company 1 - Create a folder "child" with "parent" as parent workspace
Original PR description
A document folder can have different access rights than its subfoldes, like different groups or companies. Which can result in access errors when a folder is displaying its full path and reading the parent folder name. How to reproduce: ```- Create a multi company environment in a db v13 or higher - Go to Documents > configuration > workspaces - Enable 2 companies in the company selector - Create a folder "parent" in company 1 - Create a folder "child" with "parent" as parent workspace, and no company - Remove company 1 from the active companies - expectation: folder "parent" will not appear, folder "child" will appear - actual behavior: access error ``` Solution: read the parent folder name with `sudo` The same issue was fixed in 12.0 and saas~12.3 in https://github.com/odoo/enterprise/pull/11480 opw-3039597 Forward-Port-Of: odoo/enterprise#33171
Before this commit, the selection field modify_action cannot be translated. After this commit, the selection field modify_action is translated by the code translation mechanism Forward-Port-Of: odoo/enterprise#33344
Original PR description
Before this commit, the selection field modify_action cannot be translated. After this commit, the selection field modify_action is translated by the code translation mechanism Forward-Port-Of: odoo/enterprise#33344
taskid: 3000852 Forward-Port-Of: odoo/enterprise#32261
Original PR description
taskid: 3000852 Forward-Port-Of: odoo/enterprise#32261
The res.config.settings form view is handled with a custom widget expecting a very specific structure. a `<t>` node in the middle of `<div class="settings">` and `<div class="app_settings_block">` screws things up, and the app block will no longer be shown as expected in the web interface. This issue has been introduced with odoo/odoo#103799 The current revision reverts the change so it becomes as before, the `<t>` blocks with only `groups="..."` are removed from the architecture,
Original PR description
The res.config.settings form view is handled with a custom widget expecting a very specific structure. a `<t>` node in the middle of `<div class="settings">` and `<div class="app_settings_block">`…
The res.config.settings form view is handled with a custom widget expecting a very specific structure. a `<t>` node in the middle of `<div class="settings">` and `<div class="app_settings_block">` screws things up, and the app block will no longer be shown as expected in the web interface. This issue has been introduced with odoo/odoo#103799 The current revision reverts the change so it becomes as before, the `<t>` blocks with only `groups="..."` are removed from the architecture, even if they have not been added by the postprocessing itself. An alternative fix is done, directly in the `web_studio` module of odoo/enterprise, to overcome the issue odoo/odoo#103799 was solving. Both issues are covered with unit tests: - the issue odoo/odoo#103799 was solving is covered with the unit test added in the related odoo/enterprise#33075 - the issue solved by the current revision is covered with units tests added in this revision directly. Forward-Port-Of: odoo/enterprise#33379
The source for the attachment viewer could sometimes not work as you might not always have direct access to an attachment but have to go through the document instead. This commit ensures we use the document instead of the attachment to get the data to have a proper right access check. Forward-Port-Of: odoo/enterprise#32713
Original PR description
The source for the attachment viewer could sometimes not work as you might not always have direct access to an attachment but have to go through the document instead. This commit ensures we use the document instead of the attachment to get the data to have a proper right access check. Forward-Port-Of: odoo/enterprise#32713
The `currency_id` in `_compute_analytic_distribution` should be the one of the record, not of the whole recordset. Forward-Port-Of: odoo/enterprise#33280
Original PR description
The `currency_id` in `_compute_analytic_distribution` should be the one of the record, not of the whole recordset. Forward-Port-Of: odoo/enterprise#33280
The kanban view arch was using some owl directives which are not compatible with studio making it crash. Forward-Port-Of: odoo/enterprise#33110
Original PR description
The kanban view arch was using some owl directives which are not compatible with studio making it crash. Forward-Port-Of: odoo/enterprise#33110
Added standard Balance Sheet and Profit & Loss reports for SYSCOHADA Also added menu item in the module and minor change in the manifest task-id: 2350061 Forward-Port-Of: odoo/enterprise#33008 Forward-Port-Of: odoo/enterprise#26609
Original PR description
Added standard Balance Sheet and Profit & Loss reports for SYSCOHADA Also added menu item in the module and minor change in the manifest task-id: 2350061 Forward-Port-Of: odoo/enterprise#33008 Forward-Port-Of: odoo/enterprise#26609
Since https://github.com/odoo/enterprise/pull/31641, adding a dashboard view in studio is impossible. This commit removes dashboard from studio too to avoid errors if users try to enable it opw-3031492 Forward-Port-Of: odoo/enterprise#33335
Original PR description
Since https://github.com/odoo/enterprise/pull/31641, adding a dashboard view in studio is impossible. This commit removes dashboard from studio too to avoid errors if users try to enable it opw-3031492 Forward-Port-Of: odoo/enterprise#33335
# Current behaviour Editing names of form tabs in studio doesn't apply the changes to the correct tab. Sometimes you can't even add fields to a form sheet, or it adds to the incorrect ones. Sometimes you get stackstraces from xpath that couldn't be found. # Expected behaviour Adding/Editing elements in studio shouldn't produce any errors, or change other elements in proximity. # Steps to reproduce - Install Inventory and Studio - Disable Variants in Settings - Select a Product and go
Original PR description
# Current behaviour Editing names of form tabs in studio doesn't apply the changes to the correct tab. Sometimes you can't even add fields to a form sheet, or it adds to the incorrect ones. Sometimes…
# Current behaviour Editing names of form tabs in studio doesn't apply the changes to the correct tab. Sometimes you can't even add fields to a form sheet, or it adds to the incorrect ones. Sometimes you get stackstraces from xpath that couldn't be found. # Expected behaviour Adding/Editing elements in studio shouldn't produce any errors, or change other elements in proximity. # Steps to reproduce - Install Inventory and Studio - Disable Variants in Settings - Select a Product and go in Studio - Add a new Tab, try editing it's name - Observe that not the New Tab name changed, but the one of it's left. # Reason for the problem There is incoherency between the view that Studio is getting from the server (nodes to which the user doesn't have access are not present in the view), and the view that the server is applying Studio's changes. (there is no permission checking on the view used to apply the patches onto). This leads to WOWL generating incorrect xpaths of elements, because it is basing itself on the view sent from the server (with some nodes missing), and then the server is trying to apply the changes with that xpath on a view that is not the same. # Fix In the context of studio, instead of removing the nodes we don't have access to, we set them invisible. This is more inline with behaviour in saas-15.3 and before. # Affected versions - 16.0 - master # Related Community PR odoo/odoo#103744 --- opw-3018490 Forward-Port-Of: odoo/enterprise#33088
Before this commit: - When cell value is changed then we click directly to 'loop' icon to open more details, the new value is not displayed. After this commit: - the bug is fixed. Task-3005162 Forward-Port-Of: odoo/enterprise#33204 Forward-Port-Of: odoo/enterprise#32211
Original PR description
Before this commit: - When cell value is changed then we click directly to 'loop' icon to open more details, the new value is not displayed. After this commit: - the bug is fixed. Task-3005162 Forward-Port-Of: odoo/enterprise#33204 Forward-Port-Of: odoo/enterprise#32211
This commit purpose is make the behavior of all planning biew coherent. The 'planned shifts' button form the project update redirect to a planning view where the shifts with no planned date are visible in the list view. It is expected not to, as it is for all the other planning views. this commit : - change the domain of the action so that the shifts with no planned date are not picked task 2992614 Forward-Port-Of: odoo/enterprise#33225
Original PR description
This commit purpose is make the behavior of all planning biew coherent. The 'planned shifts' button form the project update redirect to a planning view where the shifts with no planned date are visible in the list view. It is expected not to, as it is for all the other planning views. this commit : - change the domain of the action so that the shifts with no planned date are not picked task 2992614 Forward-Port-Of: odoo/enterprise#33225