Tuesday, November 21, 2023
67 changes · master
Enhancements to existing features
Calendar invitation emails now avoid showing the automated OdooBot name as the meeting contact. This makes invitation messages look more natural and less confusing for recipients.
Original PR description
When the partner name of the meeting is 'OdooBot', change the sentence to prevent displaying 'OdooBot' in the mail. Task-3544915 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves how manufacturing scrap forms keep related values up to date. It reduces the chance of inconsistent information when users edit scrap records, making the process more reliable without changing the overall workflow.
Original PR description
Task: 2709744 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The customer rating search view has been reorganized to make common filters and grouping options easier to find. Labels and ordering were adjusted so teams using ratings, especially in project-related views, can review feedback more clearly.
Original PR description
Improvements are as follows: - reordered the groups as follows: assigned to, helpdesk team, rating, customer, date inside search view > group by of customer rating. - inside search view switch the position of helpdesk team and customer. - added an attribute invisble to make sure that it only display on project task-3475466
Creating a to-do from the activity menu now uses the dedicated to-do activity type instead of a redundant reminder type. This reduces confusion for users and protects the default to-do activity type from being deleted or archived accidentally.
Original PR description
Before this commit, if we add todo from activity menu then it create a activity with reminder type which is redundant with todo. Remove reminder type activity from activity type and make to do activity type as default when creating a todo from activity menu. task-3196864
Mexico and Chile localization screens now show certain banking and partner fields only for companies in the relevant fiscal country. This reduces clutter and helps users in other countries avoid seeing fields that do not apply to their business.
Original PR description
This PR will hide some fields to other companies by adding fiscal country codes to some model used in the mexican and chilean localization. task: 3551098 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fields related to Mexican and Chilean electronic invoicing are now limited to companies with the matching fiscal country. This keeps screens cleaner for companies in other countries and reduces confusion from irrelevant localization options.
Original PR description
This PR will hide some fields to other companies by adding fiscal country codes to some model used in the mexican and chilian localization. task: 3551098
The Helpdesk customer rating search view has been reorganized to make common filters and grouping options easier to find. Users will see clearer ordering for grouping by assignee, team, rating, customer, and submission date, with the date label renamed to “Submitted on.”
Original PR description
Improvements are as follows: - reordered the groups as follows: assigned to, helpdesk team, rating, customer, date inside search view > group by of customer rating. - renamed Date into Submitted on. - inside search view switch the position of helpdesk team and customer. task-3475466
The Knowledge command palette now remembers whether a user is allowed to create new articles instead of checking repeatedly while they type. This reduces unnecessary server calls and should make search suggestions feel faster without changing normal permissions behavior.
Original PR description
When the user enters specific terms in the command palette, and there is no article matching those terms, the system will display a helper that allows the user to quickly create a new article with…
When the user enters specific terms in the command palette, and there is no article matching those terms, the system will display a helper that allows the user to quickly create a new article with the provided name. The helper will only be shown if the user has the permission to create a new article in the database. To verify this permission, the system will perform an RPC call to the server each time the helper needs to be displayed. In practice, it's highly unlikely for the user to lose the 'create' privilege between two searches. Therefore, one can cache the result of the RPC call that checks if the user is allowed to create a new article. Caching this result should reduce the number of RPC calls triggered when the user types something in the search bar. To implement the caching mechanism, we will simply use the `memoize` utility function to cache the promise checking the user's 'create' privilege. The system will perform the RPC call on the first invocation, cache the promise, and reuse it for subsequent calls, thereby improving speed. If the user loses the 'create' privilege between two searches, the system will display an access error if the user clicks on the helper. While this occurrence should be infrequent, it's not a major issue, as similar errors can also occur with the existing code. task-3603346
Resolved issues and error corrections
This change adjusts internal tests around the bus messaging connection behavior. It helps ensure real-time communication features remain reliable, with no direct change expected for everyday users.
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
Features or functions removed from Odoo
This update removes older context fields that were previously deprecated and no longer intended for use. It simplifies the underlying evaluation behavior in base and web components, reducing legacy dependencies while keeping supported context values available.
Original PR description
PR [1] deprecated keys `active_id`, `active_ids` and `active_model` from the evalContext. As stated in the PR message, the idea was to completely remove those keys for v18. This is what this commit does.
As of now, the evalContext contains
- a few static keys:
- `context`
- `uid`
- `allowed_company_ids`
- `current_company_id`
- python builtins:
- `today`
- `now`
- `bool`
- ... (complete list available in py_builtin.js)
- [if we are in a record] a key for each field in the view
- [if we are inside an x2many] a `parent` key pointing to the parent record.
[1] https://github.com/odoo/odoo/pull/136665/
Task 3543406
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-prDocumentation and clarification updates
A contributor agreement document for an individual was removed from the repository. This is an administrative/legal documentation cleanup and does not affect Odoo features or day-to-day product behavior.
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
Miscellaneous changes
Main Changes: Precise (copy) in the name of a duplicate of a delivery carrier Before: When we duplicate a delivery carrier, the name of the copy is exactly the same as the name of the source After: When we duplicate a delivery carrier, we append ' (copy)' at the end of the name for the copy Forward-Port-Of: odoo/odoo#140540
Original PR description
Main Changes:
Precise (copy) in the name of a duplicate of a delivery carrier
Before:
When we duplicate a delivery carrier, the name of the copy is
exactly the same as the name of the source
After:
When we duplicate a delivery carrier, we append ' (copy)' at the end
of the name for the copy
Forward-Port-Of: odoo/odoo#140540This update removes an unnecessary console message from the spreadsheet pivot interface. It keeps the browser console cleaner for users and support teams without changing spreadsheet functionality.
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
This fixes demo data so expenses and their related expense sheets are assigned to the same employee. It helps sample project expense flows work consistently during demonstrations, testing, or evaluations.
Original PR description
Fix broken demo data where expenses and expense sheets aren't using the same employee Related commit: 202ed9256a5d9b108208ac56a9ef15ba8d97e47c 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
This pull request adds a contributor license agreement signature for rpinset. It is an administrative legal update that confirms contribution permissions and does not change product functionality.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Before commit [1], anchors would not have a duplicate name as checks where in place to prevent it from happening. However, after [1], those checks were no longer valid. They would check in the global variable document, which was no longer the editable document. This commit fixes that by using the ownerDocument of the target, which should always return the correct document. [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b Forward-Port-Of: odoo/odoo#141936 F
Original PR description
Before commit [1], anchors would not have a duplicate name as checks where in place to prevent it from happening. However, after [1], those checks were no longer valid. They would check in the global variable document, which was no longer the editable document. This commit fixes that by using the ownerDocument of the target, which should always return the correct document. [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b Forward-Port-Of: odoo/odoo#141936 Forward-Port-Of: odoo/odoo#139897
Issue: ====== When choosing product with attributes that have attributes which have variant creation mode never it will not take into account the extra price. Steps to reproduce the issue: ============================= - Install pos , restaurant - Create a product which have `Size` attribute and add some values in it, 'S' and 'M' for example , then add extra prices in each one of them. Enable available in POS setting in Sales page of the product. - Got to point of sala , click on 3 d
Original PR description
Issue: ====== When choosing product with attributes that have attributes which have variant creation mode never it will not take into account the extra price. Steps to reproduce the issue:…
Issue: ====== When choosing product with attributes that have attributes which have variant creation mode never it will not take into account the extra price. Steps to reproduce the issue: ============================= - Install pos , restaurant - Create a product which have `Size` attribute and add some values in it, 'S' and 'M' for example , then add extra prices in each one of them. Enable available in POS setting in Sales page of the product. - Got to point of sala , click on 3 dots in restaurant and open mobile menu. - Added the created product to cart and click review. - The price shown is the original price of the product and not taking into account the extra price of the attribute. Origin of the issue: ==================== This was not supported before Solution: ========= Using the selected_attributes value in the line we can calculate the extra_price of those attributes and add it to the price_unit so we can get taxed_amount and untaxed_amount correctly. opw-3511374 Forward-Port-Of: odoo/odoo#142485 Forward-Port-Of: odoo/odoo#142173
If the option "Lock Posted Entries with Hash" is enabled on the inventory journal, it will be impossible to post a bill with a price difference (a `UserError` error will be raised) When there is a price difference, we create a SVL and validate its accounting entires: https://github.com/odoo/odoo/blob/724d88e3863b9e96069bc4a53bfd9081c30eb2b1/addons/purchase_stock/models/account_invoice.py#L167-L168 We will create and post a new AM and the SVL will be then linked to it. Then, we post the
Original PR description
If the option "Lock Posted Entries with Hash" is enabled on the inventory journal, it will be impossible to post a bill with a price difference (a `UserError` error will be raised) When there is a…
If the option "Lock Posted Entries with Hash" is enabled on the inventory journal, it will be impossible to post a bill with a price difference (a `UserError` error will be raised) When there is a price difference, we create a SVL and validate its accounting entires: https://github.com/odoo/odoo/blob/724d88e3863b9e96069bc4a53bfd9081c30eb2b1/addons/purchase_stock/models/account_invoice.py#L167-L168 We will create and post a new AM and the SVL will be then linked to it. Then, we post the bill. Thanks to that, the bill has now a correct name, and we use it in the SVL description and in the label of the AML linked the SVL: https://github.com/odoo/odoo/blob/8b37cd2960f748fa502c6c216f9db41ae93827ed/addons/purchase_stock/models/account_invoice.py#L178 But here is the issue: the AML is posted and since the journal is locked, we can't change its label: https://github.com/odoo/odoo/blob/39b44dbfef0d533722ce2c96d375ada113d32b00/addons/account/models/account_move_line.py#L1455-L1461 We need the name of the bill before posting the SVL, so we have to post the bill first. And here is a new issue: when posting the bill, it leads to the override in `/stock_account` where we try to reconcile the anglo saxon AMLS: https://github.com/odoo/odoo/blob/8444f5aae8b83c113e1cd2864ec11e92d836780a/addons/stock_account/models/account_move.py#L54 But it's too soon as we haven't yet validated the SVL's accounting entries. So we need to prevent this reconciliation, validate the SVL entries, and only then reconcile all AMLs. Note: This will actually fix another use case. In some cases, when validating a p_diff SVL, it does not generate any new AM: https://github.com/odoo/odoo/blob/8b37cd2960f748fa502c6c216f9db41ae93827ed/addons/purchase_stock/models/account_invoice.py#L167-L168 https://github.com/odoo/odoo/blob/eb022e388b62856020d95e063ec0dfd4b786c4a9/addons/stock_account/models/stock_valuation_layer.py#L53 https://github.com/odoo/odoo/blob/3e2421982c229af44aa0f46dfd91bcff3fd729a0/addons/stock_account/models/stock_move.py#L557-L560 In such case, the SVL is still linked to the bill. As a result, we wrote the bill name on all lines of that bill, which was incorrect. See `test_pdiff_and_aml_labels` for more details OPW-3446950 OPW-3550013 Forward-Port-Of: odoo/odoo#142620 Forward-Port-Of: odoo/odoo#139200
Steps to reproduce: - Install Accounting and l10n_ch - Switch to a Swiss company - Go to Settings and make sure that DIN5008 is selected as Document Layout - Go to Accounting settings and activate "QR Codes" option - Create an invoice for an Swiss contact - Print the invoice => The DIN5008 header is appearing on the QR code page. No header should appear on the QR code page with DIN5008. opw-3529963 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com
Original PR description
Steps to reproduce: - Install Accounting and l10n_ch - Switch to a Swiss company - Go to Settings and make sure that DIN5008 is selected as Document Layout - Go to Accounting settings and activate "QR Codes" option - Create an invoice for an Swiss contact - Print the invoice => The DIN5008 header is appearing on the QR code page. No header should appear on the QR code page with DIN5008. opw-3529963 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142704 Forward-Port-Of: odoo/odoo#142310
Steps to reproduce: - Install eLearning - Create or go to an existing course. - Add Content - Fill the name and use Save & Close - Click again in the same content we have just created. - Click on website preview. Issue: Saving a record from a form view that is part of an x2many field would only reload the fields present in the list view. This led to incomplete data being loaded into the model. Solution: - Pass the `viewType` option to `_fetchRecord` to ensure that the recor
Original PR description
Steps to reproduce: - Install eLearning - Create or go to an existing course. - Add Content - Fill the name and use Save & Close - Click again in the same content we have just created. - Click on website preview. Issue: Saving a record from a form view that is part of an x2many field would only reload the fields present in the list view. This led to incomplete data being loaded into the model. Solution: - Pass the `viewType` option to `_fetchRecord` to ensure that the record is reloaded in the context of the form view, thereby including all fields. - Add `viewType` to the `saveOptions` in the `basic_relational_model.js` to ensure the correct view context is used during the save operation. This ensures that all fields are reloaded into the model, providing a complete view of the data. opw-3330010 Forward-Port-Of: odoo/odoo#139346 Forward-Port-Of: odoo/odoo#136068
This PR also includes `[IMP] web: soften the UI active element takeover` This is needed in order to make possible `[FIX] web: fix popover in dialog with useAutofocus` Forward-Port-Of: odoo/odoo#140885
Original PR description
This PR also includes `[IMP] web: soften the UI active element takeover` This is needed in order to make possible `[FIX] web: fix popover in dialog with useAutofocus` Forward-Port-Of: odoo/odoo#140885
Following the Bookkeeping Act Request we needed to add a tag on each account of the standard CoA. In this PR, we created a tag for each account and updated the coa accordingly. task: 3593628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141976
Original PR description
Following the Bookkeeping Act Request we needed to add a tag on each account of the standard CoA. In this PR, we created a tag for each account and updated the coa accordingly. task: 3593628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141976
Steps to reproduce: ------------------- - create several product categories on the ecommerce; - do not add products to these categories - go on a category; - go on an other category; Issue: ------ The message is the same for both categories: ``` No product defined in category "First Category". ``` Cause: ------ When we go to the first category, the template is cached according to the existing `t-cache` key containing the products. In this case, we have no products. When we g
Original PR description
Steps to reproduce: ------------------- - create several product categories on the ecommerce; - do not add products to these categories - go on a category; - go on an other category; Issue: ------ The message is the same for both categories: ``` No product defined in category "First Category". ``` Cause: ------ When we go to the first category, the template is cached according to the existing `t-cache` key containing the products. In this case, we have no products. When we go to the second category, which has no products, the current `t-cache` key doesn't detect changes and therefore uses the cached template from the first category. Solution: --------- Remove the category name because adding `category` to existing `t-cache` key to detect a difference between categories that may have the same t-cache key would add complexity to the key and have a cost in terms of performance. opw-3572953 Forward-Port-Of: odoo/odoo#140632
Customer should do it in two steps if that's really what they want to do. This custom log was mainly intended to follow quantity changes on confirmed orders, but it's plain wrong if the product is changed at the same time. opw-3432715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142524 Forward-Port-Of: odoo/odoo#142357
Original PR description
Customer should do it in two steps if that's really what they want to do. This custom log was mainly intended to follow quantity changes on confirmed orders, but it's plain wrong if the product is changed at the same time. opw-3432715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142524 Forward-Port-Of: odoo/odoo#142357
If user tried to apply promotion that was targeting specific product on a product that was 0 price, it would cause an error. Now discount is no longer applied on free products. opw-3562218 Forward-Port-Of: odoo/odoo#142383 Forward-Port-Of: odoo/odoo#142282
Original PR description
If user tried to apply promotion that was targeting specific product on a product that was 0 price, it would cause an error. Now discount is no longer applied on free products. opw-3562218 Forward-Port-Of: odoo/odoo#142383 Forward-Port-Of: odoo/odoo#142282
When a product has been unbuilt and also (mistakenly) scrapped, it's impossible to reuse the serial number in production again, even if the product is unscrapped. This fixes the sanity check in a similar way to the _check_sn_uniqueness function, not just checking for removed stock move lines, but also unremoved stock move lines. A test case is also added to check this scenario. This is a similar fix to a previous commit we did (4f07b260807053586ac6c01cf92ac3d5e37b1041) where we bumped int
Original PR description
When a product has been unbuilt and also (mistakenly) scrapped, it's impossible to reuse the serial number in production again, even if the product is unscrapped. This fixes the sanity check in a similar way to the _check_sn_uniqueness function, not just checking for removed stock move lines, but also unremoved stock move lines. A test case is also added to check this scenario. This is a similar fix to a previous commit we did (4f07b260807053586ac6c01cf92ac3d5e37b1041) where we bumped into a problem with the duplicate serial sanity check. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142574 Forward-Port-Of: odoo/odoo#139643
Link zws should not be applied on links that contain blocks so as to avoid unfortunate side effects of zws on the dimensions of the link. task-3596919 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142651
Original PR description
Link zws should not be applied on links that contain blocks so as to avoid unfortunate side effects of zws on the dimensions of the link. task-3596919 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142651
### Steps to reproduce - Install the Events module - Go to the General Settings and add French translation and make sure to check the **website 1** option - Go to the Events module and select an event - Click on Go To Website smart button on the right top corner - On the event page, Change the language and notice the start and end date format ### Investigation - The bug is more present in version `16.0` and above. This version has just small issue with formatting since the day and the r
Original PR description
### Steps to reproduce - Install the Events module - Go to the General Settings and add French translation and make sure to check the **website 1** option - Go to the Events module and select an event - Click on Go To Website smart button on the right top corner - On the event page, Change the language and notice the start and end date format ### Investigation - The bug is more present in version `16.0` and above. This version has just small issue with formatting since the day and the rest of the date were separate block. - By Using the option `format: 'full'` the date can be formatted correctly depending on the language used ### Resources - [https://babel.pocoo.org/en/latest/api/dates.html](https://babel.pocoo.org/en/latest/api/dates.html) opw-3569167 Forward-Port-Of: odoo/odoo#142425 Forward-Port-Of: odoo/odoo#141121
Steps: - Open Field Service - Go to gantt view - Create new task - Leave the title and customer field empty - Save the form dialog Issue: - The customer required notification show in the gantt view instead of form view dialog. Cause: - When we save the form 'saveRecord' method triggered and this doesn't return anything. Fix: - Add the return statement in 'saveRecord' method. task-3502839 Forward-Port-Of: odoo/odoo#142698 Forward-Port-Of: odoo/odoo#139147
Original PR description
Steps: - Open Field Service - Go to gantt view - Create new task - Leave the title and customer field empty - Save the form dialog Issue: - The customer required notification show in the gantt view instead of form view dialog. Cause: - When we save the form 'saveRecord' method triggered and this doesn't return anything. Fix: - Add the return statement in 'saveRecord' method. task-3502839 Forward-Port-Of: odoo/odoo#142698 Forward-Port-Of: odoo/odoo#139147
This commit adapts some steps to correctly select the elements as before because some selectors no longer work due to changes done in Framework JS code (web module). Forward-Port-Of: odoo/odoo#142746 Forward-Port-Of: odoo/odoo#142654
Original PR description
This commit adapts some steps to correctly select the elements as before because some selectors no longer work due to changes done in Framework JS code (web module). Forward-Port-Of: odoo/odoo#142746 Forward-Port-Of: odoo/odoo#142654
To reproduce: 1. on your windows computer, add a system environment variable with: - Key: ODOO_RC - Value: (path to any file except the `$INSTDIR\server\odoo.log`) 2. Install Odoo Windows version Notice that the log are stored into the `$INSTDIR\server\odoo.log` file 3. Restart Odoo's service => Odoo's log file does not log anything anymore Cause: As odoo will use in priority the environment variable as the config file path. This will save the config change into that file in
Original PR description
To reproduce: 1. on your windows computer, add a system environment variable with: - Key: ODOO_RC - Value: (path to any file except the `$INSTDIR\server\odoo.log`) 2. Install Odoo Windows version…
To reproduce: 1. on your windows computer, add a system environment variable with: - Key: ODOO_RC - Value: (path to any file except the `$INSTDIR\server\odoo.log`) 2. Install Odoo Windows version Notice that the log are stored into the `$INSTDIR\server\odoo.log` file 3. Restart Odoo's service => Odoo's log file does not log anything anymore Cause: As odoo will use in priority the environment variable as the config file path. This will save the config change into that file instead of the intended one at `$INSTDIR\server\odoo.conf`. Due to this, the config file remain the default one created by the previous commands but the log_file information get save to the wrong config file. On restart of the service, as the parameter is not present, it does not log in the intended way After this commit: Logs are logged into the log file as intended Was discovered accidentally while reviewing an IoT PR: https://github.com/odoo/odoo/pull/137547 Forward-Port-Of: odoo/odoo#141979 Forward-Port-Of: odoo/odoo#138644
Description of the issue/feature this PR addresses: In project.task timesheet notebook mobile view and project update kanban view, the alignment between employee name and avatar is not proper. Name is display slightly down than to avatar. Current behavior before PR: Alignment is not proper between name and avatar. Desired behavior after PR is merged: Alignment is proper between name and avatar. Fix: add d-flex class in outer div of name and avatar so that both name and avatar shou
Original PR description
Description of the issue/feature this PR addresses: In project.task timesheet notebook mobile view and project update kanban view, the alignment between employee name and avatar is not proper. Name is display slightly down than to avatar. Current behavior before PR: Alignment is not proper between name and avatar. Desired behavior after PR is merged: Alignment is proper between name and avatar. Fix: add d-flex class in outer div of name and avatar so that both name and avatar should display in same horizontal alignment. task-3277977 Forward-Port-Of: odoo/odoo#142779 Forward-Port-Of: odoo/odoo#120868
**Version:** - 17.0 ### Steps to produce: (for small devices) - install the sales app - activate discounts in the sale setting - create a sale order and add the product - click on the discount button and check the pop-up ### Issue: The radio button's text is not arranged in a single line. ### Cause: The full text cannot be displayed in one line due to the lack of space. ### Solution: Providing sufficient space for displaying the entire text of the radio button in a single l
Original PR description
**Version:** - 17.0 ### Steps to produce: (for small devices) - install the sales app - activate discounts in the sale setting - create a sale order and add the product - click on the discount button and check the pop-up ### Issue: The radio button's text is not arranged in a single line. ### Cause: The full text cannot be displayed in one line due to the lack of space. ### Solution: Providing sufficient space for displaying the entire text of the radio button in a single line. task-3568058 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#140612
The test 'buttons with attr "special" in dialog close the dialog' sometimes fail on runbot because it can't click on 'Create and edit...' inside the many2one dropdown. Before this commit, the test edited the many2one as follows: 1) edit input to write a new value (with editInput) 2) click on the input to open the dropdown 3) click on 'Create and edit...' in the input But calling editInput opens the dropdown (even though the opening is a bit debounced, which is why it only failed sometim
Original PR description
The test 'buttons with attr "special" in dialog close the dialog' sometimes fail on runbot because it can't click on 'Create and edit...' inside the many2one dropdown. Before this commit, the test…
The test 'buttons with attr "special" in dialog close the dialog' sometimes fail on runbot because it can't click on 'Create and edit...' inside the many2one dropdown. Before this commit, the test edited the many2one as follows: 1) edit input to write a new value (with editInput) 2) click on the input to open the dropdown 3) click on 'Create and edit...' in the input But calling editInput opens the dropdown (even though the opening is a bit debounced, which is why it only failed sometimes). So it might happens, in rare cases, that the dropdown is already opened when we click in the input (step 2), which closes it and makes step 3 fail. This commit changes the test to do something similar as what we do in many2one_tests.js: we patch setTimeout to execute the callback directly, and thus remove the opening delay. We call editInput which triggers the opening of the dropdown, and we click inside the dropdown. Runbot issue 24739 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#142787 Forward-Port-Of: odoo/odoo#142743
Issue : - When you check-in/out on a day of time off, all the time is logged as extra hours. - When you do the same on a public holiday, it's not. _leave_intervals_batch is used to get all leave for an employee but the domain for the search only find leaves related to given ressources. Public Holiday Leaves are not related to any specific ressources and thus where never found. task-id: 3465686 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Issue : - When you check-in/out on a day of time off, all the time is logged as extra hours. - When you do the same on a public holiday, it's not. _leave_intervals_batch is used to get all leave for an employee but the domain for the search only find leaves related to given ressources. Public Holiday Leaves are not related to any specific ressources and thus where never found. task-id: 3465686 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141495 Forward-Port-Of: odoo/odoo#141235
Completely rewrite the 3 scroll hooks into a unified version that doesn't have conflicting and overriding conditions. - re-apply scroll (bottom in particular) when images are loaded - restore auto-scrolling to newly posted message - don't do any scroll save/restore before the thread is loaded - don't snapshot before the thread is loaded - don't snapshot after patch - fix condition for detecting when to restore snapshot - don't apply scroll multiple times for highlight Follow up of h
Original PR description
Completely rewrite the 3 scroll hooks into a unified version that doesn't have conflicting and overriding conditions. - re-apply scroll (bottom in particular) when images are loaded - restore auto-scrolling to newly posted message - don't do any scroll save/restore before the thread is loaded - don't snapshot before the thread is loaded - don't snapshot after patch - fix condition for detecting when to restore snapshot - don't apply scroll multiple times for highlight Follow up of https://github.com/odoo/odoo/pull/141999/ Only breaking after https://github.com/odoo/odoo/pull/136539 Also follow-up fix of https://github.com/odoo/odoo/pull/127889/ runbot-39172 https://github.com/odoo/enterprise/pull/50931 Forward-Port-Of: odoo/odoo#142308
po_uom_id and uom_id should be from similar uom_group. It was not the case by default using `'default_detailed_type': 'service'`. This fix the issue 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#139298
Original PR description
po_uom_id and uom_id should be from similar uom_group. It was not the case by default using `'default_detailed_type': 'service'`. This fix the issue 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#139298
Before this commit, some tests of the SwitchCompanyMenu sometimes failed: - "companies can be logged in even if some toggled within delay" - "can toggle multiple companies at once" They failed because the debounce delay between the first click to toggle a company and the moment the company service is notified to actually select the companies was sometimes too short for the 2 or 3 clicks on the menu to toggle companies to occur, as those clicks are separated by nextTick(), i.e. a mix o
Original PR description
Before this commit, some tests of the SwitchCompanyMenu sometimes failed: - "companies can be logged in even if some toggled within delay" - "can toggle multiple companies at once" They failed…
Before this commit, some tests of the SwitchCompanyMenu sometimes failed: - "companies can be logged in even if some toggled within delay" - "can toggle multiple companies at once" They failed because the debounce delay between the first click to toggle a company and the moment the company service is notified to actually select the companies was sometimes too short for the 2 or 3 clicks on the menu to toggle companies to occur, as those clicks are separated by nextTick(), i.e. a mix of calls to setTimeout and requestAnimationFrame. In tests, we patch the debounce delay to 0 by default, and before this commit we set a delay of 50 in the two faulty tests. This commit fixes the issue by keeping the real delay in those tests (1s), as they aim at testing the fact that the user has the time to do multiple clicks before committing the company changes and reloading. Fixes runbot error 29962 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#142607 Forward-Port-Of: odoo/odoo#142544
Before this commit, the "add reaction" button was available even when the thread is not persisted. This is wrong since those messages are only temporary thus not known by the server: a crash would occur when trying to add a reaction to such messages. This commit disables reactions for temporary messages. Steps to reproduce the issue: - Go to the `/contactus` page - Open a chat with the welcome bot - Try to add a reaction to its first message - An error modal appears task-3603577 Fo
Original PR description
Before this commit, the "add reaction" button was available even when the thread is not persisted. This is wrong since those messages are only temporary thus not known by the server: a crash would occur when trying to add a reaction to such messages. This commit disables reactions for temporary messages. Steps to reproduce the issue: - Go to the `/contactus` page - Open a chat with the welcome bot - Try to add a reaction to its first message - An error modal appears task-3603577 Forward-Port-Of: odoo/odoo#142718
Manual fw port of https://github.com/odoo/odoo/pull/130914 When trying to delete a bank statement, if there is no move with the same id, we get an error "Record doesn't exist or has been deleted". The reason is we call the account_move.check_move_sequence_chain() method wih the id of the statement. We avoid using account_move_service if the model is not account_move as it make no sense to call an account_move method from a bank statement record. Root cause: https://github.com/odoo/enterprise/
Original PR description
Manual fw port of https://github.com/odoo/odoo/pull/130914 When trying to delete a bank statement, if there is no move with the same id, we get an error "Record doesn't exist or has been deleted". The reason is we call the account_move.check_move_sequence_chain() method wih the id of the statement. We avoid using account_move_service if the model is not account_move as it make no sense to call an account_move method from a bank statement record. Root cause: https://github.com/odoo/enterprise/blob/fd6586e8b098f018a54c715c53a2c12fe192bf7c/account_bank_statement_import/views/account_bank_statement_import_view.xml#L28 opw-3425826 Forward-Port-Of: odoo/odoo#142818
Since the refactoring to owl, the stats in the left zone were not shown anymore and the hover was missing. This was because the method that fixes the xpath to match line by line the qweb, was done on a getter and not on the data itself. Now we replace in the prop value, from this way, in every place we use the getter, we have fixed the data with the xpath. /t/div -> /t[1]/div[1] Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior aft
Original PR description
Since the refactoring to owl, the stats in the left zone were not shown anymore and the hover was missing. This was because the method that fixes the xpath to match line by line the qweb, was done on a getter and not on the data itself. Now we replace in the prop value, from this way, in every place we use the getter, we have fixed the data with the xpath. /t/div -> /t[1]/div[1] 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#142515 Forward-Port-Of: odoo/odoo#142463
## Description Since 54857ec409d2cd2a565ad73b069a8641046aedac , the results of the expensive recursive CTE on `res.partner` were never used. So the query doesn't do anything at all, besides slowing down the whole process for minutes on databases with a large volume of `res.partner` entries. ## Fix Removing the dead code ## Reference task-3601394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142578
Original PR description
## Description Since 54857ec409d2cd2a565ad73b069a8641046aedac , the results of the expensive recursive CTE on `res.partner` were never used. So the query doesn't do anything at all, besides slowing down the whole process for minutes on databases with a large volume of `res.partner` entries. ## Fix Removing the dead code ## Reference task-3601394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142578
…Invoicing only Steps to reproduce: 1. Create a database in demo mode with only Invoicing installed 2. Create a new company 3. Set any accounting localization package in Settings 4. Traceback because User doesn't have access rights on account.bank.statement task-id: 3584244 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/
Original PR description
…Invoicing only Steps to reproduce: 1. Create a database in demo mode with only Invoicing installed 2. Create a new company 3. Set any accounting localization package in Settings 4. Traceback because User doesn't have access rights on account.bank.statement task-id: 3584244 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#141196
To Reproduce ============ - enable a currency and make it for example = 0.01$ - create pricelist for that currency - make sale order with that pricelist (let's say 1000 = 10$) - on dashboards the Revenue will be 1 000$ Problem ======== on spreadsheet we use the field `amount_untaxed` from `sale.order`, which contains the amount in the currency of the sale order and not the company. Solution ======== as `sale.oder` module doesn't have any field containing the converted amount, we w
Original PR description
To Reproduce ============ - enable a currency and make it for example = 0.01$ - create pricelist for that currency - make sale order with that pricelist (let's say 1000 = 10$) - on dashboards the Revenue will be 1 000$ Problem ======== on spreadsheet we use the field `amount_untaxed` from `sale.order`, which contains the amount in the currency of the sale order and not the company. Solution ======== as `sale.oder` module doesn't have any field containing the converted amount, we will use the field `price_subtotal` from `sale.report` opw-3527802 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142762 Forward-Port-Of: odoo/odoo#142489
# Issue: The hr_referral application can not be installed with demo data. # Analyze: The db is being auto locked. And transaction is not rollback due to the xml failure. # Fix: Add corresponding line into hr_demo.xml instead of hr_referral_demo.xml # Note: It does not fix the root cause, but until the root cause is well defined and fix, it is the best workaround. # Related ticket: opw-3547638 # Affected version: 16.0 and above Forward-Port-Of: odoo/odoo#142589 Forward-Port-
Original PR description
# Issue: The hr_referral application can not be installed with demo data. # Analyze: The db is being auto locked. And transaction is not rollback due to the xml failure. # Fix: Add corresponding line into hr_demo.xml instead of hr_referral_demo.xml # Note: It does not fix the root cause, but until the root cause is well defined and fix, it is the best workaround. # Related ticket: opw-3547638 # Affected version: 16.0 and above Forward-Port-Of: odoo/odoo#142589 Forward-Port-Of: odoo/odoo#142302
Before this commit, the account mapping from fiscal position was not taken into account for payable/receivable accounts. Steps: - Create a fiscal position - In accounts mapping, set the default receivable account X as source account and an other one Y as destination account. - Create an invoice and set the fiscal position newly created. - Add an invoice line and select a product. - Go to journal items tab -> The receivable line as X account instead of Y account. opw-3600605 Forward-Port-Of:
Original PR description
Before this commit, the account mapping from fiscal position was not taken into account for payable/receivable accounts. Steps: - Create a fiscal position - In accounts mapping, set the default receivable account X as source account and an other one Y as destination account. - Create an invoice and set the fiscal position newly created. - Add an invoice line and select a product. - Go to journal items tab -> The receivable line as X account instead of Y account. opw-3600605 Forward-Port-Of: odoo/odoo#142801 Forward-Port-Of: odoo/odoo#142733
### Steps to reproduce: 1. Create a new product with a cost of 10 (std, manual) 2. Create an inventory adjustment to set the quantity to -3 3. Change the product's category to real-time Now the valuation for this product is -30€, but the accounting part has 30€, creating a difference of 60€. ### Before this commit: Changing the valuation to real-time while having a negative quantity/value gives a positive value in accounting. ### After this commit: Changing the valuation to real-ti
Original PR description
### Steps to reproduce: 1. Create a new product with a cost of 10 (std, manual) 2. Create an inventory adjustment to set the quantity to -3 3. Change the product's category to real-time Now the valuation for this product is -30€, but the accounting part has 30€, creating a difference of 60€. ### Before this commit: Changing the valuation to real-time while having a negative quantity/value gives a positive value in accounting. ### After this commit: Changing the valuation to real-time while having a negative quantity/value gives a negative value in accounting. opw-3390692 Forward-Port-Of: odoo/odoo#130674
Steps to reproduce: - New DB - Switch to russian - Install stock app Bug: throw back is raised when setting up the data caused by a duplicate operation type (Sequence Packing/Picking) Fix: apply the correct translation note: manual PR created since there's no russian translation on transifex after 16.0 opw-3589539 Forward-Port-Of: odoo/odoo#142715
Original PR description
Steps to reproduce: - New DB - Switch to russian - Install stock app Bug: throw back is raised when setting up the data caused by a duplicate operation type (Sequence Packing/Picking) Fix: apply the correct translation note: manual PR created since there's no russian translation on transifex after 16.0 opw-3589539 Forward-Port-Of: odoo/odoo#142715
# Issue: The hr_referral application can't be installed with demo data. # Analyze: The db is locked. And transaction is not rollback due to the xml failure. # Fix: The name is a required field in hr.job and it is not recommended to use '.' in ids. # Related ticket: opw-3547638 # Affected version: 16.0 and above Forward-Port-Of: odoo/enterprise#50944 Forward-Port-Of: odoo/enterprise#48705
Original PR description
# Issue: The hr_referral application can't be installed with demo data. # Analyze: The db is locked. And transaction is not rollback due to the xml failure. # Fix: The name is a required field in hr.job and it is not recommended to use '.' in ids. # Related ticket: opw-3547638 # Affected version: 16.0 and above Forward-Port-Of: odoo/enterprise#50944 Forward-Port-Of: odoo/enterprise#48705
Bad copy-paste caused the action to be named the same, which caused the Run action to not be available anymore. Forward-Port-Of: odoo/enterprise#51023
Original PR description
Bad copy-paste caused the action to be named the same, which caused the Run action to not be available anymore. Forward-Port-Of: odoo/enterprise#51023
Fixes in community PR. https://github.com/odoo/odoo/pull/142308 Forward-Port-Of: odoo/enterprise#50931
Original PR description
Fixes in community PR. https://github.com/odoo/odoo/pull/142308 Forward-Port-Of: odoo/enterprise#50931
Accounting > Configuration > Follow-up Levels Open any followup level configuration, access the template configuration Under 'Email configuration' tab fill reply-to field Send a followup email using this followup level Issue: reply-to field is not filled This occurs because the system never use the field from the template. Accounting > Follow-up Reports Select a partner in need of action Click "Follow up", the send mail wizard will open Add as recepient the current user Send Is
Original PR description
Accounting > Configuration > Follow-up Levels Open any followup level configuration, access the template configuration Under 'Email configuration' tab fill reply-to field Send a followup email using this followup level Issue: reply-to field is not filled This occurs because the system never use the field from the template. Accounting > Follow-up Reports Select a partner in need of action Click "Follow up", the send mail wizard will open Add as recepient the current user Send Issue: User will not receive the email This occurs because without the context key 'mail_notify_author' the mail subsystem will avoid sending the email to the author opw-3575447 Forward-Port-Of: odoo/enterprise#50902 Forward-Port-Of: odoo/enterprise#50621
Issue: ====== When you add comparaison in consolidation it will not show the period in the display name so we are not able to distinguish between them. Steps to reproduce the issue: ============================= - Install consolidation - Install demo data for consolidation - Go to consolidation app and click on consolidated balance in the first test chart - Click on comparison and select test chart - You will see 2 columns that you can't distinguish between them. Solution: =======
Original PR description
Issue: ====== When you add comparaison in consolidation it will not show the period in the display name so we are not able to distinguish between them. Steps to reproduce the issue: ============================= - Install consolidation - Install demo data for consolidation - Go to consolidation app and click on consolidated balance in the first test chart - Click on comparison and select test chart - You will see 2 columns that you can't distinguish between them. Solution: ========== - Added `display_dates` in the display in the comparaison field and in the headers fields. Before: ======  After: ====  opw-3514517 Forward-Port-Of: odoo/enterprise#51092 Forward-Port-Of: odoo/enterprise#48667
**Steps:** - Open Timesheet - You can see the row of timer with Start Button - Choose Grid View and apply a Group By filter - Now go to the List View **Issue:** - When ListView is selected, the row with the timer consisting of the Start Button is not displayed. **Cause:** - In the list view because of the closed rows, the display timer doesn't get the data due to which the timer is not visible. **Fix:** - Added a different condition to showTimer instead of depending on display_ti
Original PR description
**Steps:** - Open Timesheet - You can see the row of timer with Start Button - Choose Grid View and apply a Group By filter - Now go to the List View **Issue:** - When ListView is selected, the row with the timer consisting of the Start Button is not displayed. **Cause:** - In the list view because of the closed rows, the display timer doesn't get the data due to which the timer is not visible. **Fix:** - Added a different condition to showTimer instead of depending on display_timer field value in view which only gives the desire result when there is no group-by or group-by has at-least one section opened. **Task**-3387850 Forward-Port-Of: odoo/enterprise#51097 Forward-Port-Of: odoo/enterprise#50884
Fix the whatsapp template form to be able to enter bigger titles. Prevent displaying the account name in the breadcrumbs if there is none. Task-3555944 Forward-Port-Of: odoo/enterprise#51033 Forward-Port-Of: odoo/enterprise#49594
Original PR description
Fix the whatsapp template form to be able to enter bigger titles. Prevent displaying the account name in the breadcrumbs if there is none. Task-3555944 Forward-Port-Of: odoo/enterprise#51033 Forward-Port-Of: odoo/enterprise#49594
This PR aims to standardize the design of alerts inside planning by adding some spacing between alerts and the next element and by removing custom padding. Prior to this commit, the alert would be directly stick to the form sheet, due to the lack of `margin-bottom`. This was causing consistency issues with other alerts from other modules that would have a bottom spacing to prevent them to stick to the following element. There was also a padding property used to add some whitespace wi
Original PR description
This PR aims to standardize the design of alerts inside planning by adding some spacing between alerts and the next element and by removing custom padding. Prior to this commit, the alert would be directly stick to the form sheet, due to the lack of `margin-bottom`. This was causing consistency issues with other alerts from other modules that would have a bottom spacing to prevent them to stick to the following element. There was also a padding property used to add some whitespace within the alert, while our alert class already include a CSS variables that handles the padding of the element. To fix this visual issue, we simply reset the styling applied to these alert to standard, by removing margin and padding overrides. Forward-Port-Of: odoo/enterprise#49998
Before this PR in help center search results webpage a space is missing between the different tags. In this PR we have fixed the spacing issue by adding bootstrap class task-3463622 Forward-Port-Of: odoo/enterprise#51056 Forward-Port-Of: odoo/enterprise#46139
Original PR description
Before this PR in help center search results webpage a space is missing between the different tags. In this PR we have fixed the spacing issue by adding bootstrap class task-3463622 Forward-Port-Of: odoo/enterprise#51056 Forward-Port-Of: odoo/enterprise#46139
There is a business check on attachment unlink that needs to access approval state. This is why the attachment needs to be unlinked before the approval itself. steps to reproduce: - create a draft approval and attach a document - delete the approval. before this commit: odoo.exceptions.MissingError: Record does not exist or has been deleted. (Record: approval.request(8,), User: 2) after this commit: approval is deleted opw-3558437 Forward-Port-Of: odoo/enterprise#51095 Forward-P
Original PR description
There is a business check on attachment unlink that needs to access approval state. This is why the attachment needs to be unlinked before the approval itself. steps to reproduce: - create a draft approval and attach a document - delete the approval. before this commit: odoo.exceptions.MissingError: Record does not exist or has been deleted. (Record: approval.request(8,), User: 2) after this commit: approval is deleted opw-3558437 Forward-Port-Of: odoo/enterprise#51095 Forward-Port-Of: odoo/enterprise#49681
On some variants of the reports, marking the reports as inactive wouldn't disable the automatic redirection towards this report when selected from the menu. Example to reproduce : - Open BE Company CoA - Make the belgian VAT Return report inactive (debug mode --> configuration --> accounting reports) - Open the Tax report ==> The belgian vat report was opened while the generic one should be opened, since we deactivated the belgian one. Added a check when compiling the available variant
Original PR description
On some variants of the reports, marking the reports as inactive wouldn't disable the automatic redirection towards this report when selected from the menu. Example to reproduce : - Open BE Company CoA - Make the belgian VAT Return report inactive (debug mode --> configuration --> accounting reports) - Open the Tax report ==> The belgian vat report was opened while the generic one should be opened, since we deactivated the belgian one. Added a check when compiling the available variants before redirection. task-3577540 Forward-Port-Of: odoo/enterprise#51036
Commit [1] adapted a few WebClientEnterprise tests to reflect with a community change [2] which makes a click a on menu perform two updates of the webclient: one with a blank screen, and another one with the requested view. Tests were adapted to check that after a tick, no view was displayed yet, and that after another tick, the view was finally there. This is incorrect and sometimes fails. Indeed, it might happen that the kanban view is already there after the first tick, because more than o
Original PR description
Commit [1] adapted a few WebClientEnterprise tests to reflect with a community change [2] which makes a click a on menu perform two updates of the webclient: one with a blank screen, and another one with the requested view. Tests were adapted to check that after a tick, no view was displayed yet, and that after another tick, the view was finally there. This is incorrect and sometimes fails. Indeed, it might happen that the kanban view is already there after the first tick, because more than one animation frame can occur during a nextTick. This commit fixes those test by simply removing the first assertion (blank screen), which isn't the concern of those tests anyway. [1] 430b9dc15031bce98e3be55b23438ee09494dada [2] https://github.com/odoo/odoo/pull/124068 Task 3603040 Forward-Port-Of: odoo/enterprise#51050
[FIX] account_reports: use correct cog button target on composite reports In debug mode, a little cog button is displayed next to the report filters. Clicking it open the form view of the report. The problem is the report used as the target of this action was options['report_id'], not options['sections_source_id']. Because of that, when clicking this button on a composite report, only the form view of the currently displayed section was open, while we actually should have opened the form o
Original PR description
[FIX] account_reports: use correct cog button target on composite reports In debug mode, a little cog button is displayed next to the report filters. Clicking it open the form view of the report. The…
[FIX] account_reports: use correct cog button target on composite reports In debug mode, a little cog button is displayed next to the report filters. Clicking it open the form view of the report. The problem is the report used as the target of this action was options['report_id'], not options['sections_source_id']. Because of that, when clicking this button on a composite report, only the form view of the currently displayed section was open, while we actually should have opened the form of the whole composite report. -------------------------- [IMP] account_reports: allow opening the sections' form view from the composite report owning them For usability. ------------------------- [FIX] account_reports: don't depend on show_debug_column options to display the cog button The cog button allows opening the form view of the report to reconfigure it. It is only supposed to be displayed in debug mode. For that, the show_debug_column option key was used. Yet, this was wrong, as this option key is not always true in debug mode: for example, if a comparison is being done, it will be False. We now display the cog directly from debug mode info, without depending on options. Forward-Port-Of: odoo/enterprise#50927
Before this commit we use `column.name` as label of our columns for report lines in the report form view. It caused that the label was in lower case. The aim of this commit is using the `label` instead of the `name` to have the column `label` well formatted. Before:  After:  no task id Forwa
Original PR description
Before this commit we use `column.name` as label of our columns for report lines in the report form view. It caused that the label was in lower case. The aim of this commit is using the `label` instead of the `name` to have the column `label` well formatted. Before:  After:  no task id Forward-Port-Of: odoo/enterprise#51057
The `export_report` variable is not longer needed since `dispatch_report_action()` is already handling it through the `on_sections_source` parameter. Forward-Port-Of: odoo/enterprise#50926
Original PR description
The `export_report` variable is not longer needed since `dispatch_report_action()` is already handling it through the `on_sections_source` parameter. Forward-Port-Of: odoo/enterprise#50926
When loading up the GanttView from Field of Service and switching to "Year", the number of tasks to load can be quite big. If these tasks' description contains images, it's very likely that a MemoryError will be raised. To avoid that, turn off field prefetching in `_compute_leave_warning` and `_gantt_progress_bar_user_ids` and then use `read` to prefetch all needed fields at once. Because `read` (as oppose to `fetch` in saas-16.2 up) does not check the cache, the query count in `test_perfo
Original PR description
When loading up the GanttView from Field of Service and switching to "Year", the number of tasks to load can be quite big. If these tasks' description contains images, it's very likely that a…
When loading up the GanttView from Field of Service and switching to "Year", the number of tasks to load can be quite big. If these tasks' description contains images, it's very likely that a MemoryError will be raised. To avoid that, turn off field prefetching in `_compute_leave_warning` and `_gantt_progress_bar_user_ids` and then use `read` to prefetch all needed fields at once. Because `read` (as oppose to `fetch` in saas-16.2 up) does not check the cache, the query count in `test_performance` has to be increased from 9 to 10, even though creating new tasks inside this test puts their fields' value in cache. Browsing for self.ids prevents AccessErrors with NewIds that don't have values in database yet. But they do in cache so the following calls to `__get__` will simply return the values from the field cache. So no additionnal queries from turning off prefetching in that case. Ideally, the calls to `read` should be replaced by calls to `fetch` from 16.2 up. #### Benchmark In a customer database with 2600 project.task for the current year, loading up the GanttView goes from 2Gb (MemoryError raised) to 500Mb (no MemoryError raised).   Forward-Port-Of: odoo/enterprise#51034 Forward-Port-Of: odoo/enterprise#48912
Steps to reproduce: Set up German localization for PoS, make a PoS that is bar / restaurant, make an order and proceed to pay. Error pop up: `Unknown Error, Please Contact Odoo Support` When synchronizing, get traceback: ``` TypeError: (value || 0).toFixed is not a function ``` The issue is that before saas-16.3, unit price was converted to string and was processed to have correct formating on the Python side. In saas-16.3, this string was passed into `formatCurrency` method which d
Original PR description
Steps to reproduce: Set up German localization for PoS, make a PoS that is bar / restaurant, make an order and proceed to pay. Error pop up: `Unknown Error, Please Contact Odoo Support` When synchronizing, get traceback: ``` TypeError: (value || 0).toFixed is not a function ``` The issue is that before saas-16.3, unit price was converted to string and was processed to have correct formating on the Python side. In saas-16.3, this string was passed into `formatCurrency` method which did a similar functionality. However `formatCurrency` expects a number and not a string which causes the issue. To fix this, it is better to do all the string processing in JavaScript code. opw-3499791 Forward-Port-Of: odoo/enterprise#48659
In Shop Floor, when you change the details of a raw material or a byproduct, the new quantity is not fully reflected on the move when you click to mark it as 'picked'. Moreover, clicking a second time make the move quantity falls to 0. Forward-Port-Of: odoo/enterprise#50793
Original PR description
In Shop Floor, when you change the details of a raw material or a byproduct, the new quantity is not fully reflected on the move when you click to mark it as 'picked'. Moreover, clicking a second time make the move quantity falls to 0. Forward-Port-Of: odoo/enterprise#50793
The label of the first move line of the journal report has been broken, and is now showing the debit. This fix will revert that mistake so that it shows the name as expected. Forward-Port-Of: odoo/enterprise#51006 Forward-Port-Of: odoo/enterprise#50882
Original PR description
The label of the first move line of the journal report has been broken, and is now showing the debit. This fix will revert that mistake so that it shows the name as expected. Forward-Port-Of: odoo/enterprise#51006 Forward-Port-Of: odoo/enterprise#50882