Tuesday, October 4, 2022
77 changes · master
Enhancements to existing features
The mail message composer was reorganized to move some behind-the-scenes logic into shared models. This should make the composer easier to maintain and evolve without changing how users write messages today.
Original PR description
+ Create ComposerTextInputView model + Replace uses of useRef with useRefToModel + Replace use of useUpdate with useUpdateToModel + Remove dead code (ComposerTextInput._isEmpty) Task-3001200.
The Belgian payroll commission import field has been updated to use Odoo’s newer interface technology. This keeps the feature aligned with the current platform and helps maintain a smoother, more reliable user experience without changing the business workflow.
Original PR description
This commit migrates the `binary_commission` field to owl.
Resolved issues and error corrections
Fixed an issue that could cause an error when shoppers clicked a product in the website sales catalog with renting enabled. This helps keep the online shopping experience smooth and prevents interruptions during product browsing.
Original PR description
task_id: 3000852
Miscellaneous changes
Automatically translate "avoir" into "note de crédit" Forward-Port-Of: odoo/odoo#101968 Forward-Port-Of: odoo/odoo#101856
Original PR description
Automatically translate "avoir" into "note de crédit" Forward-Port-Of: odoo/odoo#101968 Forward-Port-Of: odoo/odoo#101856
The online shop’s category filter option now appears in the expected place when rental date search is enabled. This makes the storefront setup clearer for website managers and avoids confusion when configuring category behavior.
Original PR description
When you add the categories on the left you can tell if the categories are collapsible or not. But the field appears below "datepicker" that we added with rental search Taskid: 3004243
The automated product configurator test was adjusted to match the current interface, where the edit button no longer appears. This prevents unnecessary test failures and helps keep quality checks reliable without changing customer-facing behavior.
Original PR description
With the `always edit` changes, the edit button was removed. Thus, these steps were failing and became useless anyway.
This fix prevents an error from appearing when customers click products in the rental website catalog. It helps keep the shopping experience smooth and avoids disruption during product browsing.
Original PR description
see https://github.com/odoo/odoo/pull/101719
The rental product page settings now show the datepicker option in the correct position when category filters are enabled. This makes the website editor clearer and avoids confusion when configuring rental search and category display options.
Original PR description
see: https://github.com/odoo/odoo/pull/101900
If you create stress days, the default work calendar is set to be the company's default calendar, therefore exclude by default every employee with a different work calendar. Since the field is by default hidden, it is misleading, so by default no calendar should be set. Also removes unused imports task-2999197 Forward-Port-Of: odoo/odoo#101540
Original PR description
If you create stress days, the default work calendar is set to be the company's default calendar, therefore exclude by default every employee with a different work calendar. Since the field is by default hidden, it is misleading, so by default no calendar should be set. Also removes unused imports task-2999197 Forward-Port-Of: odoo/odoo#101540
Update dashboard as version of 3/10/2022 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#101872
Original PR description
Update dashboard as version of 3/10/2022 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#101872
**Description of the issue/feature this PR addresses:** Before this commit, if we remove the uploaded supporting documents in the time off, those are not removed. Current behavior before PR: Currently if we remove the uploaded supporting documents in the time off, those are not removed. Desired behavior after PR is merged: after this commit merge, we can able to remove the uploaded document. **Fix issue** : [#86323](https://github.com/odoo/odoo/issues/86323)
Original PR description
**Description of the issue/feature this PR addresses:**
Before this commit, if we remove the uploaded supporting documents in the time off, those are not removed.
Current behavior before PR:
Currently if we remove the uploaded supporting documents in the time off, those are not removed.
Desired behavior after PR is merged:
after this commit merge, we can able to remove the uploaded document.
**Fix issue** : [#86323](https://github.com/odoo/odoo/issues/86323)
Impact Version:
15.0
16.0
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#101204Allow our users to modify mail template more easily; - make the list accessible from the settings - give them a link to update relevant views to update header/footer - make the list and form of templates more readable task-2944770 Forward-Port-Of: odoo/odoo#101399
Original PR description
Allow our users to modify mail template more easily; - make the list accessible from the settings - give them a link to update relevant views to update header/footer - make the list and form of templates more readable task-2944770 Forward-Port-Of: odoo/odoo#101399
Manual forward port of https://github.com/odoo/odoo/pull/74064. Task: opw-2965529 Forward-Port-Of: odoo/odoo#101740
Original PR description
Manual forward port of https://github.com/odoo/odoo/pull/74064. Task: opw-2965529 Forward-Port-Of: odoo/odoo#101740
Add a new method `_get_move_applicability` allowing to trigger the EDI on any journal entry, using the custom functions you want. enterprise-https://github.com/odoo/enterprise/pull/30869 Forward-Port-Of: odoo/odoo#99227
Original PR description
Add a new method `_get_move_applicability` allowing to trigger the EDI on any journal entry, using the custom functions you want. enterprise-https://github.com/odoo/enterprise/pull/30869 Forward-Port-Of: odoo/odoo#99227
This test is failling during nightly mainly when executed arround 23 The most likely reason for that is because of the freezetime rounding the day and creating an error between 23 and 00. The freezetime only wraps the create but the compute will be triggered only after that. Adding all assertions inside the freezetime may be enough to fix this issue. Forward-Port-Of: odoo/odoo#101960
Original PR description
This test is failling during nightly mainly when executed arround 23 The most likely reason for that is because of the freezetime rounding the day and creating an error between 23 and 00. The freezetime only wraps the create but the compute will be triggered only after that. Adding all assertions inside the freezetime may be enough to fix this issue. Forward-Port-Of: odoo/odoo#101960
auth="none" pages don't have self.env.user filled in, this throws a traceback if you try to get the current cart. This causes an issue when we try to fetch the cart quantity on the login page. Forward-Port-Of: odoo/odoo#101938 Forward-Port-Of: odoo/odoo#101907
Original PR description
auth="none" pages don't have self.env.user filled in, this throws a traceback if you try to get the current cart. This causes an issue when we try to fetch the cart quantity on the login page. Forward-Port-Of: odoo/odoo#101938 Forward-Port-Of: odoo/odoo#101907
…ice is correctly used When a boolean ir.config.parameter is set to False, self.env['ir.config_parameter'].sudo().get_param('parzm_key') will return 'False'. As the string is not falsy, the parameter value match as true. This commit fix the behavior for the sale.automatic_invoice to keep coherence with the subscription module taskid: 2988410 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101555 Forward-Port-Of: odo
Original PR description
…ice is
correctly used
When a boolean ir.config.parameter is set to False, self.env['ir.config_parameter'].sudo().get_param('parzm_key') will return 'False'. As the string is not falsy, the parameter value match as true. This commit fix the behavior for the sale.automatic_invoice to keep coherence with the subscription module
taskid: 2988410
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#101555
Forward-Port-Of: odoo/odoo#100545This commit applies the proper spacing between FormView's buttons in a Dialog's footer. Steps to reproduce: - Open Notes - Enable debug mode - In Debug menu, open "Edit View: List" => dialog's buttons have no spacing Forward-Port-Of: odoo/odoo#101882
Original PR description
This commit applies the proper spacing between FormView's buttons in a Dialog's footer. Steps to reproduce: - Open Notes - Enable debug mode - In Debug menu, open "Edit View: List" => dialog's buttons have no spacing Forward-Port-Of: odoo/odoo#101882
Before this commit ================== before this commit, it will raise the error when submitting EDI because the tax report line does not exist and it will be removed from this PR #99401 After this commit ================= no error will be raised and it will get related tag_ids 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.odo
Original PR description
Before this commit ================== before this commit, it will raise the error when submitting EDI because the tax report line does not exist and it will be removed from this PR #99401 After this commit ================= no error will be raised and it will get related tag_ids 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#101866
Task-2998135 Forward-Port-Of: odoo/odoo#101762
Original PR description
Task-2998135 Forward-Port-Of: odoo/odoo#101762
This commit fixes the alignment of the message shown when validating transfer without quantities set. before:  after: <img width="736" alt="image" src="https://user-images.githubusercontent.com/15212149/193596553-4459d6bf-427c-4548-9b9c-f2ffb3ee6679.png"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101
Original PR description
This commit fixes the alignment of the message shown when validating transfer without quantities set. before:  after: <img width="736" alt="image" src="https://user-images.githubusercontent.com/15212149/193596553-4459d6bf-427c-4548-9b9c-f2ffb3ee6679.png"> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101944
Steps to reproduce: - Activate Dropship and multi routes - Create a SO and select the route Dropship - Confirm the SO - Confirm the purchase - Click on Customer Preview Issue: In the customer preview, if the customer click on the do, vendor's info will be displayed. opw-2961884 Forward-Port-Of: odoo/odoo#101578 Forward-Port-Of: odoo/odoo#100276
Original PR description
Steps to reproduce: - Activate Dropship and multi routes - Create a SO and select the route Dropship - Confirm the SO - Confirm the purchase - Click on Customer Preview Issue: In the customer preview, if the customer click on the do, vendor's info will be displayed. opw-2961884 Forward-Port-Of: odoo/odoo#101578 Forward-Port-Of: odoo/odoo#100276
Purpose: split words with whitespace, as it's usually done. Task-3004148 Forward-Port-Of: odoo/odoo#101889
Original PR description
Purpose: split words with whitespace, as it's usually done. Task-3004148 Forward-Port-Of: odoo/odoo#101889
The early payment cash discount functionality was merged in 16.0. This PR allows for the behavior to be as localization specific as possible. This concerns : - The tax computation (some countries leave it untouched after the discount, some countries discount it, and Belgium has a mixed behaviour) - The account in which the cash difference resulting of the cash discount should be put. task- 2983913 related to https://github.com/odoo/odoo/pull/99572 Forward-Port-Of: odoo/odoo#100654
Original PR description
The early payment cash discount functionality was merged in 16.0. This PR allows for the behavior to be as localization specific as possible. This concerns : - The tax computation (some countries leave it untouched after the discount, some countries discount it, and Belgium has a mixed behaviour) - The account in which the cash difference resulting of the cash discount should be put. task- 2983913 related to https://github.com/odoo/odoo/pull/99572 Forward-Port-Of: odoo/odoo#100654
Unpublish the job from the website when they are archived, and correct the condition to show Archive/Unarchive on the job kanban view. task-3001159 Forward-Port-Of: odoo/odoo#101992 Forward-Port-Of: odoo/odoo#101735
Original PR description
Unpublish the job from the website when they are archived, and correct the condition to show Archive/Unarchive on the job kanban view. task-3001159 Forward-Port-Of: odoo/odoo#101992 Forward-Port-Of: odoo/odoo#101735
This repeats the fix from #80049, which already solved the same problem. That `compute_sudo` was dropped by #81510 afterwards, but only in the `sale` module. Forward-Port-Of: odoo/odoo#99823
Original PR description
This repeats the fix from #80049, which already solved the same problem. That `compute_sudo` was dropped by #81510 afterwards, but only in the `sale` module. Forward-Port-Of: odoo/odoo#99823
## Description of the issue/feature this PR addresses: Change 'Invoice date' label on report according move_type I've discover this on odoo 14.0 as far I remember I've to open PR against lowest maintain version here agains 13.0 ! ## Current behavior before PR: While printing credit note the document date is labeled "Invoice date:` ## Desired behavior after PR is merged: While printing credit note the document should be labeled "Credit note date:` -- I confirm I have
Original PR description
## Description of the issue/feature this PR addresses: Change 'Invoice date' label on report according move_type I've discover this on odoo 14.0 as far I remember I've to open PR against lowest maintain version here agains 13.0 ! ## Current behavior before PR: While printing credit note the document date is labeled "Invoice date:` ## Desired behavior after PR is merged: While printing credit note the document should be labeled "Credit note date:` -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101993 Forward-Port-Of: odoo/odoo#100851
Steps to reproduce: - in any app log a note using full composer - add styles to the text (underline strike through italic) Bug: styles except bold are removed Fix: added missing styles to the whitlelist opw-2956374 Forward-Port-Of: odoo/odoo#100326
Original PR description
Steps to reproduce: - in any app log a note using full composer - add styles to the text (underline strike through italic) Bug: styles except bold are removed Fix: added missing styles to the whitlelist opw-2956374 Forward-Port-Of: odoo/odoo#100326
**Bug**: Users are able to modify their eCommerce cart after it has been paid when they fail to return to Odoo through the payment provider's return route. This prevents the cart from being confirmed. **Steps to reproduce**: 1. Install the payment provider Mollie and set it to test mode. 2. Go to the /shop page, add a product to the cart, and select Mollie for the payment. 3. On Mollie's hosted payment page, use the card number 4111111111111111 with the expiry date 03/30 and the secret cod
Original PR description
**Bug**: Users are able to modify their eCommerce cart after it has been paid when they fail to return to Odoo through the payment provider's return route. This prevents the cart from being…
**Bug**: Users are able to modify their eCommerce cart after it has been paid when they fail to return to Odoo through the payment provider's return route. This prevents the cart from being confirmed. **Steps to reproduce**: 1. Install the payment provider Mollie and set it to test mode. 2. Go to the /shop page, add a product to the cart, and select Mollie for the payment. 3. On Mollie's hosted payment page, use the card number 4111111111111111 with the expiry date 03/30 and the secret code 123. Select 'paid' as the payment outcome. 4. Confirm the payment but take care not to be redirected to the /payment/status route. For examples, close the tab before or comment out https://github.com/odoo/odoo/blob/15.0/addons/payment_mollie/controllers/main.py#L38. 5. Go back to /shop/cart and modify the cart. 6. Wait up to 20 minutes for the "payment: post-process transactions" cron to try to confirm the cart. 7. Check the cart's chatter: the confirmation failed because the cart's and transaction's amounts mismatch. **Explanation**: The post-processing of the transaction is responsible for confirming the cart, but it failed to be triggered because the user did not visit the /payment/status page. The post-processing cron takes care of pending post-processings after 10 to 20 minutes, which is long enough for the user to modify their cart. **Fix**: Force creating a new cart as soon as the current one is paid and is being requested by the website. task-2995504 Forward-Port-Of: odoo/odoo#101956 Forward-Port-Of: odoo/odoo#101169
TaskId-2991207 Forward-Port-Of: odoo/odoo#102028
Original PR description
TaskId-2991207 Forward-Port-Of: odoo/odoo#102028
Work hours in a planning do not respect the timezone Steps to reproduce: 1. Set your computer timezone to 'America/New_York' 2. Install Manufacturing 3. Go to Settings > Manufacturing > Operations and enable Work Orders 4. Go to Settings > Technical > Resource > Working Times and open 'Standard 40 hours/week' (San Francisco) 5. Edit the timezone to 'America/New_York' 6. Go to Manufacturing > Planning > Planning by Workcenter and trigger the day view 7. The work hours are not correct as
Original PR description
Work hours in a planning do not respect the timezone Steps to reproduce: 1. Set your computer timezone to 'America/New_York' 2. Install Manufacturing 3. Go to Settings > Manufacturing > Operations and enable Work Orders 4. Go to Settings > Technical > Resource > Working Times and open 'Standard 40 hours/week' (San Francisco) 5. Edit the timezone to 'America/New_York' 6. Go to Manufacturing > Planning > Planning by Workcenter and trigger the day view 7. The work hours are not correct as they do not respect the timezone Solution: Add the timezone of the resource's calendar when computing unavailabilities opw-2903591 Forward-Port-Of: odoo/odoo#101983 Forward-Port-Of: odoo/odoo#100538
This pr follow the framework refactoring and translate the widgets of stock module to wowl. CountedQuantityWidgetField needs to add an upper listener on input since the function onChange and onInput of `useInputField` are not overidable. Json fields had their template in the json send from the server. With wowl, the template needs to be declare before the setup. So a new wiget is create for each template and those widgets extends the a common component that put the json content in the
Original PR description
This pr follow the framework refactoring and translate the widgets of stock module to wowl. CountedQuantityWidgetField needs to add an upper listener on input since the function onChange and onInput of `useInputField` are not overidable. Json fields had their template in the json send from the server. With wowl, the template needs to be declare before the setup. So a new wiget is create for each template and those widgets extends the a common component that put the json content in the props. 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#99019
The event listeners were added to the upload object instead of the xhr object making them being called before they were supposed to. Forward-Port-Of: odoo/odoo#101969
Original PR description
The event listeners were added to the upload object instead of the xhr object making them being called before they were supposed to. Forward-Port-Of: odoo/odoo#101969
This commit increases quantity field's width to about 4 characters task-2996494 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#101274
Original PR description
This commit increases quantity field's width to about 4 characters task-2996494 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#101274
### Steps to reproduce * setup Alipay in test mode (note that Alipay's test mode only support one currency: the USD) * create an invoice. Make sure the invoice's total has decimal places * generate a payment link for that invoice * go to the generated link * select Alipay as the payment method and click pay. You should be met with an INVALID_PARAMETER message. ### Cause Alipay's doc states that the parameter 'total_fee' can only have two decimal places. Currently, this requirement is
Original PR description
### Steps to reproduce * setup Alipay in test mode (note that Alipay's test mode only support one currency: the USD) * create an invoice. Make sure the invoice's total has decimal places * generate a payment link for that invoice * go to the generated link * select Alipay as the payment method and click pay. You should be met with an INVALID_PARAMETER message. ### Cause Alipay's doc states that the parameter 'total_fee' can only have two decimal places. Currently, this requirement is not always respected opw-2996278 Forward-Port-Of: odoo/odoo#101917 Forward-Port-Of: odoo/odoo#101798
Users with both "HR Officer" and "Contract Administrator" access should be able to archive employees even without Payroll access. Forward-Port-Of: odoo/odoo#102055
Original PR description
Users with both "HR Officer" and "Contract Administrator" access should be able to archive employees even without Payroll access. Forward-Port-Of: odoo/odoo#102055
It seems that there is a rather frequent warning that can be added to mail received by outlook 365 and that has the form: ``` <table border="0" cellspacing="0" cellpadding="0" align="left" width="100%" style="width:100.0%"> ...Caution: This is an external email and has a suspicious subject or content... </table> ``` The combination of `align="left" width="100%"` means that a div after this alert will probably have a width of 0 (because the previous content is floating to the left, a
Original PR description
It seems that there is a rather frequent warning that can be added to mail received by outlook 365 and that has the form: ``` <table border="0" cellspacing="0" cellpadding="0" align="left"…
It seems that there is a rather frequent warning that can be added to mail received by outlook 365 and that has the form: ``` <table border="0" cellspacing="0" cellpadding="0" align="left" width="100%" style="width:100.0%"> ...Caution: This is an external email and has a suspicious subject or content... </table> ``` The combination of `align="left" width="100%"` means that a div after this alert will probably have a width of 0 (because the previous content is floating to the left, and taking 100% of width so there is 0 pixel of width remaining). This is not an issue in general, but in Odoo this conflicts with a code that adds scrollbar if a message content overflows (but here since width is 0 pixel the content is just hidden). With this commit, if we detect the code that is used in all our received report (width=100% and float=left), we ignore the float to prevent this issue from happening. An alternative is to avoid Outlook 365 adding this structure in a message (see [1]), but this is only possible if we can change the configuration where this structure is added (eg. we can't if it is a customer that is forwarding a mail already broken). [1]: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/set-up-anti-phishing-policies?view=o365-worldwide#first-contact-safety-tip opw-2887342 opw-2946587 Forward-Port-Of: odoo/odoo#101295
[FIX] base: no back-end view caching in --dev xml mode In `--dev xml` mode, you would like the views to be loaded from their definition in the XML file directly. The view caching introduced in https://github.com/odoo/odoo/pull/99417 prevents that feature, as once the view has been loaded a first time, the views are returned directly from the cache, therefore not taking into account changes directly done in the XML file views. Setting a conditional decorator, disabling the caching
Original PR description
[FIX] base: no back-end view caching in --dev xml mode In `--dev xml` mode, you would like the views to be loaded from their definition in the XML file directly. The view caching introduced in…
[FIX] base: no back-end view caching in --dev xml mode In `--dev xml` mode, you would like the views to be loaded from their definition in the XML file directly. The view caching introduced in https://github.com/odoo/odoo/pull/99417 prevents that feature, as once the view has been loaded a first time, the views are returned directly from the cache, therefore not taking into account changes directly done in the XML file views. Setting a conditional decorator, disabling the caching when in `--dev xml` mode, solves this issue. Solves https://github.com/odoo/odoo/pull/99417#issuecomment-1241977197 [IMP] base: move view related methods out of odoo/models.py By definition, views are useless without the web client. The web client is in the module `web`. Therefore, in a perfect world, the `get_views` model method and any related method should be within the `web` module, as without it they are useless. Let's imagine you would like to use fully in command-line, without web client, all those view related methods are useless. Maybe excepted for reports, as you might still like to be able to print reports while using odoo fully in command line. Views related method therefore shouldn't be in `odoo/models.py`. Also, when you think about it, `get_views` related methods do not make sense without the model `ir.ui.view`, which is loaded after the `get_views` related methods, which also doesn't make sense. However, moving these methods fully in the `web` module is an harder work. For instance, there are base models, such as res.partner, already overriding `get_view` in the `base` module, and therefore relying on these view related methods. As a first step, we move view related methods direcly in the `odoo/addons/base/models/ir_ui_view.py` file, where the `ir.ui.view` model is loaded. This is not only a design / cleaning change, but a required change to be able to use content of `odoo.tools.config`, which is loaded after `odoo/models.py`. For instance, if you want to configure a conditional decorator based on the config `odoo.tools.config['dev_mode']`, it is not possible to do so in `odoo/models.py` because the config is parsed/loaded after `odoo/models.py`. The config is loaded here: https://github.com/odoo/odoo/blob/31de2b0a7a0921cab3c6c54045d15da46c8e6d8a/odoo/cli/server.py#L127 While, within the same file, `odoo/models.py` gets loaded through the `import odoo` https://github.com/odoo/odoo/blob/31de2b0a7a0921cab3c6c54045d15da46c8e6d8a/odoo/cli/server.py#L26 And we would like to put such a decorator based on `odoo.tools.config['dev_mode']` on `_get_view_cache`, to not cache the back-end views when `--dev xml` is passed in the server arguments. Forward-Port-Of: odoo/odoo#101200
Since the split of components with their templates in dedicated file in https://github.com/odoo/o-spreadsheet/commit/10e1a0ca, the templates were eager-loaded. However, this had an impact on the size of the `assets_qweb` bundle. This commit introduces the lazy-loading of the `spreadsheet.o_spreadsheet` bundle since it is now achievable. A followup of https://github.com/odoo/enterprise/pull/30609 task 2896049 Description of the issue/feature this PR addresses: Current behavior befo
Original PR description
Since the split of components with their templates in dedicated file in https://github.com/odoo/o-spreadsheet/commit/10e1a0ca, the templates were eager-loaded. However, this had an impact on the size of the `assets_qweb` bundle. This commit introduces the lazy-loading of the `spreadsheet.o_spreadsheet` bundle since it is now achievable. A followup of https://github.com/odoo/enterprise/pull/30609 task 2896049 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#101477
The feature was not appreciated. Revert of https://github.com/odoo/odoo/pull/98703. Forward-Port-Of: odoo/odoo#101153
Original PR description
The feature was not appreciated. Revert of https://github.com/odoo/odoo/pull/98703. Forward-Port-Of: odoo/odoo#101153
This commit temporarily reverts commit 10087e2ccfbc30191c743eac84270360d10c6351 which makes the main flow tour fail non deterministically (around 1/2). A proper fix will come tomorrow. We revert to unlock the mergebot. 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#102126
Original PR description
This commit temporarily reverts commit 10087e2ccfbc30191c743eac84270360d10c6351 which makes the main flow tour fail non deterministically (around 1/2). A proper fix will come tomorrow. We revert to unlock the mergebot. 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#102126
Toggling an optional field in list view do not unselect row anymore. It feels better for the user experience and remove the problem of having a failed validation on toggle. Forward-Port-Of: odoo/odoo#100828
Original PR description
Toggling an optional field in list view do not unselect row anymore. It feels better for the user experience and remove the problem of having a failed validation on toggle. Forward-Port-Of: odoo/odoo#100828
Adds `width: 100%` on the `.o_field_widget` so the input it can take the all width in the "Quick Create" form. Also, this commit fixes the CSS selector for the `margin` rule as in the "Quick Create" form view there is no `.o_group` anymore on `.o_inner_group`. Steps to reproduce: * Go to project * Select a project * Click on the `Create` button => BUG --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101913
Original PR description
Adds `width: 100%` on the `.o_field_widget` so the input it can take the all width in the "Quick Create" form. Also, this commit fixes the CSS selector for the `margin` rule as in the "Quick Create" form view there is no `.o_group` anymore on `.o_inner_group`. Steps to reproduce: * Go to project * Select a project * Click on the `Create` button => BUG --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101913
The goal of this commit is to fix the behaviour of clicking on a field with the "many2one" widget in a list view. Expected behaviour when clicking on a field with the "many2one" widget: - Editable list view: switch row to edit - Multi_edit list view with selected record: switch row to edit - Other case: open the many2one record in a form view Before this commit, clicking on a field with the "many2one" widget always opens the record in a form view. After this commit, the expected beha
Original PR description
The goal of this commit is to fix the behaviour of clicking on a field with the "many2one" widget in a list view. Expected behaviour when clicking on a field with the "many2one" widget: - Editable list view: switch row to edit - Multi_edit list view with selected record: switch row to edit - Other case: open the many2one record in a form view Before this commit, clicking on a field with the "many2one" widget always opens the record in a form view. After this commit, the expected behaviour when clicking on a field with the "many2one" widget is respected. 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#101737
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#101876
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#101876
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#101932
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#101932
Forward-Port-Of: odoo/odoo#102022
Original PR description
Forward-Port-Of: odoo/odoo#102022
Before this commit, creating a new record with the "many2many" widget did not allow to use a context containing a default value for the parentID (id of the Record containing the many2many). This value is ignored. How to reproduce? - Go to a form view with a field using the "many2many" widget with context = {"default_parentID" = ...} - Click on "Add a new line" - Click on "Create" (The form view should display the parentID field) Before this commit: The parentID field is empty. A
Original PR description
Before this commit, creating a new record with the "many2many" widget did not allow to use a context containing a default value for the parentID (id of the Record containing the many2many). This value is ignored.
How to reproduce?
- Go to a form view with a field using the "many2many" widget with context = {"default_parentID" = ...}
- Click on "Add a new line"
- Click on "Create" (The form view should display the parentID field)
Before this commit:
The parentID field is empty.
After this commit:
The parentID field contains the record corresponding
to "default_parentID".
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#102023Before this revision, the active sheet was not correctly set to the first sheet. Task-id 3002541 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#101851
Original PR description
Before this revision, the active sheet was not correctly set to the first sheet. Task-id 3002541 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#101851
Before this commit, clicking on view buttons with attribute `close="1"` in FormViewDialog didn't close the dialog once the button action was performed. This commit fixes that issue, and ensures we do not reload the record if we're about to close the dialog. 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:
Original PR description
Before this commit, clicking on view buttons with attribute `close="1"` in FormViewDialog didn't close the dialog once the button action was performed. This commit fixes that issue, and ensures we do not reload the record if we're about to close the dialog. 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#101864
Before that commit, it was not possible to select some part only of a input/textarea input in an editable list view. Forward-Port-Of: odoo/odoo#102131
Original PR description
Before that commit, it was not possible to select some part only of a input/textarea input in an editable list view. Forward-Port-Of: odoo/odoo#102131
task-3006024 Forward-Port-Of: odoo/odoo#102024
Original PR description
task-3006024 Forward-Port-Of: odoo/odoo#102024
Fix display conditions, clean duplicate code. Follow up of https://github.com/odoo/odoo/pull/100570 And follow up of https://github.com/odoo/odoo/pull/98101/ (for the SCSS part) task-3003947 https://github.com/odoo/enterprise/pull/32269 Forward-Port-Of: odoo/odoo#102092
Original PR description
Fix display conditions, clean duplicate code. Follow up of https://github.com/odoo/odoo/pull/100570 And follow up of https://github.com/odoo/odoo/pull/98101/ (for the SCSS part) task-3003947 https://github.com/odoo/enterprise/pull/32269 Forward-Port-Of: odoo/odoo#102092
In community. task-3003947 https://github.com/odoo/odoo/pull/102092 Forward-Port-Of: odoo/enterprise#32269
Original PR description
In community. task-3003947 https://github.com/odoo/odoo/pull/102092 Forward-Port-Of: odoo/enterprise#32269
Forward-Port-Of: odoo/enterprise#32188
Original PR description
Forward-Port-Of: odoo/enterprise#32188
The new formView is now editable with studio. How it basically works: - each node of interest in the arch is assigned an xpath relative to the arch at compile time. - most of the studio logic relies on that studioXpath (clicking, drag/drop) - each component uses that xpath to identify itself, be draggable if applicable, and be modified if applicable. - every node of the arch is present in the compiled template, though they won't necessarily end up in the DOM (they have a t-if that ref
Original PR description
The new formView is now editable with studio. How it basically works: - each node of interest in the arch is assigned an xpath relative to the arch at compile time. - most of the studio logic relies…
The new formView is now editable with studio. How it basically works: - each node of interest in the arch is assigned an xpath relative to the arch at compile time. - most of the studio logic relies on that studioXpath (clicking, drag/drop) - each component uses that xpath to identify itself, be draggable if applicable, and be modified if applicable. - every node of the arch is present in the compiled template, though they won't necessarily end up in the DOM (they have a t-if that reflect their invisible modifier state). - the config in the env of the formEditor holds methods and variables that allow for interacting with the viewEditorManager and for editing the view. What has changed: - hopefully minimal functional changes, except the persistence of the current active node in edition specifically, if the current node is not findable anymore (e.g. because it has become invisible), the sidebar is reset to the initial state, and so is the editor itself: they won't try to guess which element should be in edition next. - technically a lot of things: the editor must satisfy the view.js interface drag and drop is handled natively via a in-house feature, though support for JQueryUI is still present for legacy compatibility reasons. - The compiler passes metadata and it is the responsibility of each form component to handle those. - The new form grid layout is supported, though draggable field (the ones with automatic labels) are handled differently the label is now the one unit that handles click, display of the style and the drag/drop. The two elements (label and field) are now outlined separately, though at the same time, letting two outlines appear. This may be resolve when the "subgrid" feature of CSS is supported across browsers. Co-authored-by: Bruno Boi <boi@odoo.com> Co-authored-by: Samuel Degueldre <sad@odoo.com> Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com> Co-authored-by: Julien Mougenot <jum@odoo.com> Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com> Forward-Port-Of: odoo/enterprise#32186
Steps to reproduce: - Don't save between the steps only at the end - Create a product - Check sell on ebay and put fixed price - Configure some variants - Save Current behavior: The first variant in the ebay tab list has an ebay quantity of zero Expected behavior: The quantity should be one (classical default value) Explanation: Ebay_quantity is a related field between the product template and the product variant. The product template is created after the product variants so whe
Original PR description
Steps to reproduce: - Don't save between the steps only at the end - Create a product - Check sell on ebay and put fixed price - Configure some variants - Save Current behavior: The first variant in the ebay tab list has an ebay quantity of zero Expected behavior: The quantity should be one (classical default value) Explanation: Ebay_quantity is a related field between the product template and the product variant. The product template is created after the product variants so when the product template is created with a default value for ebay_quantity of zero it also sets the value of the related product variant. opw-2974596 Forward-Port-Of: odoo/enterprise#31577
In short, the mandate form buttons display is completely broken, and this fix will the issue. Forward-Port-Of: odoo/enterprise#32103
Original PR description
In short, the mandate form buttons display is completely broken, and this fix will the issue. Forward-Port-Of: odoo/enterprise#32103
As the wowl2 refactor was done pretty early in the wowl2 conversions some stuff could be written better in the code base. This also makes use of the generic file upload service instead of using a custom one. Forward-Port-Of: odoo/enterprise#32207
Original PR description
As the wowl2 refactor was done pretty early in the wowl2 conversions some stuff could be written better in the code base. This also makes use of the generic file upload service instead of using a custom one. Forward-Port-Of: odoo/enterprise#32207
Because the unavailabilities are now given according to the calendar timezone, the tests failed as the calendar was in timezone 'America/New_York' and the timezone used in the test was 'UTC' Solution: Put the calendar in timezone 'UTC' opw-2903591 Forward-Port-Of: odoo/enterprise#32210 Forward-Port-Of: odoo/enterprise#31913
Original PR description
Because the unavailabilities are now given according to the calendar timezone, the tests failed as the calendar was in timezone 'America/New_York' and the timezone used in the test was 'UTC' Solution: Put the calendar in timezone 'UTC' opw-2903591 Forward-Port-Of: odoo/enterprise#32210 Forward-Port-Of: odoo/enterprise#31913
The field is now readonly=False in the definition and readonly=True in the views. TaskId-2991207 Forward-Port-Of: odoo/enterprise#32231
Original PR description
The field is now readonly=False in the definition and readonly=True in the views. TaskId-2991207 Forward-Port-Of: odoo/enterprise#32231
After deployment to production, several aspects of the iap service were modified to better integrate within the iap ecosystem, including its endpoint. This commit makes sure that users need not define a system parameter for the integration to work - the parameter is used e.g. to switch to sandbox, etc. Forward-Port-Of: odoo/enterprise#32226
Original PR description
After deployment to production, several aspects of the iap service were modified to better integrate within the iap ecosystem, including its endpoint. This commit makes sure that users need not define a system parameter for the integration to work - the parameter is used e.g. to switch to sandbox, etc. Forward-Port-Of: odoo/enterprise#32226
Before this commit, the affected test may crash sometimes when the transitions of bootstrap's collapsing resolve after the timeouts set in the test. After this commit, there is no undeterministic behavior as we wait for bootstrap events, plus a complete AnimationFrame before asserting stuff. Forward-Port-Of: odoo/enterprise#32224
Original PR description
Before this commit, the affected test may crash sometimes when the transitions of bootstrap's collapsing resolve after the timeouts set in the test. After this commit, there is no undeterministic behavior as we wait for bootstrap events, plus a complete AnimationFrame before asserting stuff. Forward-Port-Of: odoo/enterprise#32224
With this commit, we are able to see the message generated by the cron "Data Merge: Find Duplicate Records", even if the user preference for notification is set to Handle in Odoo. Previous behavior: - Your user -> Preferences -> Notifications -> Handle in Odoo - Contact, create two duplicates (I created two contacts named test with the email test@test.fun) - Data cleaning -> Configuration -> Deduplication -> Contact -> Notify Users, set to your user and to 1 day - Scheduled Actions -> Dat
Original PR description
With this commit, we are able to see the message generated by the cron "Data Merge: Find Duplicate Records", even if the user preference for notification is set to Handle in Odoo. Previous behavior: - Your user -> Preferences -> Notifications -> Handle in Odoo - Contact, create two duplicates (I created two contacts named test with the email test@test.fun) - Data cleaning -> Configuration -> Deduplication -> Contact -> Notify Users, set to your user and to 1 day - Scheduled Actions -> Data Merge: Find Duplicate Records -> Run Manually - Your notification bar now has 1 more notification, which you can't access other than by entering the Discuss app and seeing your inbox This behavior was ver confusing for customers. Behavior now: You can see this notification as well as the message associated in the discuss bar. OPW-2903716 OPW-2992342 OPW-2634116 Forward-Port-Of: odoo/enterprise#32170 Forward-Port-Of: odoo/enterprise#32105
The labels were taking a single cell, which means they wouldn't be on a separate line anymore and the whole groups were shifted and no longer correctly placed (label on one line, field on the other) Forward-Port-Of: odoo/enterprise#32098
Original PR description
The labels were taking a single cell, which means they wouldn't be on a separate line anymore and the whole groups were shifted and no longer correctly placed (label on one line, field on the other) Forward-Port-Of: odoo/enterprise#32098
Have the primary action on the left, and the secondary action de-emphasized. Forward-Port-Of: odoo/enterprise#32149
Original PR description
Have the primary action on the left, and the secondary action de-emphasized. Forward-Port-Of: odoo/enterprise#32149
Previous to this PR: If the user wanted to issue sales tickets (boletas) for l10n-cl, there was the need to install the module manually. This was because in previous versions was mandatory to send the daily sales report for the beginning of the use month. After this PR: As the daily sales report cron has been disabled in this version there is no reason to have this module uninstalled whenever the electronic invoicing feature is installed. This is a backport for #30711 Forward-Port-Of:
Original PR description
Previous to this PR: If the user wanted to issue sales tickets (boletas) for l10n-cl, there was the need to install the module manually. This was because in previous versions was mandatory to send the daily sales report for the beginning of the use month. After this PR: As the daily sales report cron has been disabled in this version there is no reason to have this module uninstalled whenever the electronic invoicing feature is installed. This is a backport for #30711 Forward-Port-Of: odoo/enterprise#32143 Forward-Port-Of: odoo/enterprise#31538
taskid: 2988410 Forward-Port-Of: odoo/enterprise#31994 Forward-Port-Of: odoo/enterprise#31488
Original PR description
taskid: 2988410 Forward-Port-Of: odoo/enterprise#31994 Forward-Port-Of: odoo/enterprise#31488
…e 'liquidity' line on the bank reconciliation widget Forward-Port-Of: odoo/enterprise#31900
Original PR description
…e 'liquidity' line on the bank reconciliation widget Forward-Port-Of: odoo/enterprise#31900
Due to the recent JSONB fields update, the tax names retrieved in the VAT closing entry displayed as stringified JSON fields, e.g. `{'en_US': '20% Import', 'nl_BE': '20% Import'}`. Solution is to use `->>lang_code` in the SQL query to parse the JSON field and retrieve the right translation. Forward-Port-Of: odoo/enterprise#31928
Original PR description
Due to the recent JSONB fields update, the tax names retrieved in the VAT closing entry displayed as stringified JSON fields, e.g. `{'en_US': '20% Import', 'nl_BE': '20% Import'}`.
Solution is to use `->>lang_code` in the SQL query to parse the JSON field and retrieve the right translation.
Forward-Port-Of: odoo/enterprise#31928The widget is not in owl yet, so we can't have the new analytic widget. We reput the analytic account field and create a distribution from it. Forward-Port-Of: odoo/enterprise#31946
Original PR description
The widget is not in owl yet, so we can't have the new analytic widget. We reput the analytic account field and create a distribution from it. Forward-Port-Of: odoo/enterprise#31946
Add a new method `_get_move_applicability` allowing to trigger the EDI on any journal entry, using the custom funtion you want. community-https://github.com/odoo/odoo/pull/99227 Forward-Port-Of: odoo/enterprise#30869
Original PR description
Add a new method `_get_move_applicability` allowing to trigger the EDI on any journal entry, using the custom funtion you want. community-https://github.com/odoo/odoo/pull/99227 Forward-Port-Of: odoo/enterprise#30869
When there are exactly 6 Reconciliation models and the 6th one is selected, the `more` dropdown is displayed without any item in it. Forward-Port-Of: odoo/enterprise#32153
Original PR description
When there are exactly 6 Reconciliation models and the 6th one is selected, the `more` dropdown is displayed without any item in it. Forward-Port-Of: odoo/enterprise#32153
…lidation Most of the time, the 'action_post' method of account.move is used for the bank transactions instead of the method defined on account.bank.statement.line. Forward-Port-Of: odoo/enterprise#32076
Original PR description
…lidation Most of the time, the 'action_post' method of account.move is used for the bank transactions instead of the method defined on account.bank.statement.line. Forward-Port-Of: odoo/enterprise#32076
Allow our users to modify mail template more easily; - make the list accessible from the settings - give them a link to update relevant views to update header/footer - make the list and form of templates more readable task-2944770 Forward-Port-Of: odoo/enterprise#31916
Original PR description
Allow our users to modify mail template more easily; - make the list accessible from the settings - give them a link to update relevant views to update header/footer - make the list and form of templates more readable task-2944770 Forward-Port-Of: odoo/enterprise#31916
Update dashboard as version of 3/10/2022 Forward-Port-Of: odoo/enterprise#32159
Original PR description
Update dashboard as version of 3/10/2022 Forward-Port-Of: odoo/enterprise#32159
Automatically translate "avoir" into "note de crédit" Enterprise part of odoo/odoo#101856 Forward-Port-Of: odoo/enterprise#32203 Forward-Port-Of: odoo/enterprise#32146
Original PR description
Automatically translate "avoir" into "note de crédit" Enterprise part of odoo/odoo#101856 Forward-Port-Of: odoo/enterprise#32203 Forward-Port-Of: odoo/enterprise#32146