Monday, May 9, 2022
35 changes · master
Enhancements to existing features
Deleting draft accounting entries is now faster on large databases. This reduces delays for finance teams working with high volumes of accounting data and makes cleanup tasks run more smoothly.
Original PR description
Solving performance issue raised in the following PR for master: - https://github.com/odoo/odoo/pull/83472 - https://github.com/odoo/odoo/pull/83469 Current behavior before PR: On bigger DB, unlinking a draft account_move takes ages. Desired behavior after PR is merged: On bigger DB, unlinking a draft account_move goes smoothly.
Cancelling a sales order now consistently asks users to confirm the action and gives them the option to send an email notification. This helps prevent accidental order cancellations and improves communication with customers when an order is cancelled.
Original PR description
Before this commit, when cancelling a SO, the wizard opened only when there were draft invoices or delivered pickings in the order. In order to complete the notification flow of the SO and avoid unexpected cancellation of orders, the user must now confirm cancellation and gets to possibility to send an email notification. task-2660895 See also: - https://github.com/odoo/enterprise/pull/26866
This update streamlines how messaging-related screens pass information internally, reducing reliance on temporary identifiers. It helps make chat, leave, live chat, snail mail, and website live chat components more consistent and easier to maintain without changing day-to-day workflows.
Original PR description
*: hr_holidays, im_livechat, snailmail, website_livechat Task-2847927
This update refines how approval, messaging, and signature screens share record information internally. It helps these screens behave more consistently and reduces the risk of display or interaction issues without changing the user workflow.
Original PR description
*: approvals, sign Task-2847927
Users can now choose which key columns appear in the Documents list view, including name, tags, partner, owner, type, and creation date. This makes the list easier to use on smaller phone screens by letting each user hide fields they do not need.
Original PR description
There isn't enough place on a default phone screen to display the 6 default fields of the documents list view*. Unfortunately, since none of those fields are marked as optional, a user cannot customize the view and decide to toggle those fields. This commit adds the optional attribute on several fields to allow some customization. * concerned fields - name - tag_ids - partner_id - owner_id - type - create_date Task-id 2846754
Subscription templates now have a defined order, making it easier for users to find and select the right template when creating a new subscription. This improves usability for teams managing many templates.
Original PR description
create lot of template create a new subscription, try to select an template --> it is not easy because template have no order. @tde-banana-odoo @arj-odoo
Resolved issues and error corrections
Project task analysis now calculates average ratings correctly by matching ratings to the right task and averaging them instead of adding them together. This gives managers more reliable task satisfaction reporting and adds test/demo coverage to prevent the issue from returning.
Original PR description
Before this commit: - Join between task and rating is made on parent_res_id - Displayed value is the sum of tasks average_rating - No Unit test to detect this anomalie - Each task is rated one time so average_rating and last_rating are the same After this commit: - Join is made on res_id which is the task_id - Displayed value is the avg of tasks average_rating - Unit test added to cover mesaures calculation - New demo record added to let average_rating be different from last_rating 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
In a MTO case, when a salesman decreases the ordered quantity, it can lead to an access error To reproduce the issue: (Use demo data) 1. In Users, edit Marc Demo: - Invoicing: None - Purchase: None 2. Create a product P: - Type: Storable - Add a vendor V - Routes: - MTO - Buy 3. Log in as Marc Demo 4. Create a sale order SO with 2 x P 5. Confirm SO 6. Edit SO: - Set the qty of P to 1 - ignore the warning 7. Save the SO Error: Th
Original PR description
In a MTO case, when a salesman decreases the ordered quantity, it can lead to an access error To reproduce the issue: (Use demo data) 1. In Users, edit Marc Demo: - Invoicing: None - Purchase: None…
This fixes a dashboard issue where adding a new action could erase the dashboard's existing layout or previously added actions. Users can now add multiple actions to a dashboard without losing the current board state.
Original PR description
Before this commit, the code of the `add_to_dashboard` method did not go through the get_view override of the board model. Because of that, it did not get the arch of the current board, which means that each add_to_dashboard call was actually a complete reset: it was not possible to add an action without removing the current board state. For reference, this was caused recently by a change in commit b03c227e885efa. The fix is basically a localized revert of that commit. 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
Time off requests now show whole-day totals consistently, even when an employee or manager uses a different time zone than the company context. This prevents misleading fractional leave balances such as 2.69 days for a 3-day absence.
Original PR description
When the user is set in another timezone than the context timezone, the first or last work interval retrieved to calculate the number of days between two dates is starting later or ending earlier depending on the user timezone. The number of days displayed between two dates is therefore not an integer. e.g. A time off taken between 08/06/2021 and 10/06/2021 (timezone in the context is Europe/Brussels) will give: - Number of days: 3 days if the user is in Europe/Brussels - Number of days: 2.69 if the user is in Asia/Calcutta (first work interval starting later) - Number of days: 2.5 if the user is in US/Pacific (last work interval ending earlier) task-2646655 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Automated Amazon sales and subscription cancellation flows now bypass the manual cancellation wizard. This prevents background processes from being interrupted by a user-facing prompt and helps cancellations complete reliably.
Original PR description
`action_cancel` opens the cancellation wizard, but we don't want to open it in an automated flow. So we need to use `_action_cancel` instead. task-2660895 See also: - https://github.com/odoo/odoo/pull/81569
In a MTO case, when a salesman decreases the ordered quantity, it can
lead to an access error
To reproduce the issue:
(Use demo data)
1. In Users, edit Marc Demo:
- Invoicing: None
- Purchase: None
2. Create a product P:
- Type: Storable
- Add a vendor V
- Routes:
- MTO
- Buy
3. Log in as Marc Demo
4. Create a sale order SO with 2 x P
5. Confirm SO
6. Edit SO:
- Set the qty of P to 1
- ignore the warning
7. Save the SO
Error: There is an access error ("create" on "Activity" (mail.activity))
Because the user decreases the quantity, we want to log this decreasing
on the related documents:
https://github.com/odoo/odoo/blob/ee9ea35ad218be87564de484470f1c4e9c433977/addons/sale_stock/models/sale_order.py#L91-L94
In the above case, it leads to a write operation on the generated
purchase order. However, Marc Demo hasn't any right to perform such an
operation.
We should bypass the rights checking in such situation.
Note: in `/sale_stock:SaleOrder.write`: we need to specify what kind of
precision we are using.
OPW-2745317
Forward-Port-Of: odoo/odoo#90732
Forward-Port-Of: odoo/odoo#89392Steps : Go to a Project's settings. In your 'Following' preferences, uncheck 'Task Rating'. Create a new Task in this Project and see your preferences. Issue : Task Rating is checked. Cause : The default value of project's task rating notification is True. The value of its task's is supposed to be inheritted from there. Yet, this inherittance only happen when default is False. Fix : Set default to False. opw-282497 Description of the issue/feature this PR addresses: Cur
Original PR description
Steps : Go to a Project's settings. In your 'Following' preferences, uncheck 'Task Rating'. Create a new Task in this Project and see your preferences. Issue : Task Rating is checked. Cause : The default value of project's task rating notification is True. The value of its task's is supposed to be inheritted from there. Yet, this inherittance only happen when default is False. Fix : Set default to False. opw-282497 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#90727 Forward-Port-Of: odoo/odoo#89929
Description of the issue/feature this PR addresses: round ppn on tax_line if .5, is round down Current behavior before PR: qty = 1 price = 13750 ppn actual is 1512.5 but round down become 1512 Desired behavior after PR is merged: round up become 1513 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#89793
Original PR description
Description of the issue/feature this PR addresses: round ppn on tax_line if .5, is round down Current behavior before PR: qty = 1 price = 13750 ppn actual is 1512.5 but round down become 1512 Desired behavior after PR is merged: round up become 1513 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#89793
Schedule date was hide in the view for a back to basic task in order to simplify the view. But it was at the time, the optional parameter did not exist, we could readd it under the hide option opw-2842963 Forward-Port-Of: odoo/odoo#90717
Original PR description
Schedule date was hide in the view for a back to basic task in order to simplify the view. But it was at the time, the optional parameter did not exist, we could readd it under the hide option opw-2842963 Forward-Port-Of: odoo/odoo#90717
This commit aims to fix an issue when downloading attachments and using 'name' as the field for the file's name. When 'name' contains a dot, the file is considered to already have a file extension, and thus the right extension is not added to the name. After this commit, using 'name' as a filename field will also consider the name to be a 'default' for any other model than `ir.attachment`. TaskId-2826061 Forward-Port-Of: odoo/odoo#90614
Original PR description
This commit aims to fix an issue when downloading attachments and using 'name' as the field for the file's name. When 'name' contains a dot, the file is considered to already have a file extension, and thus the right extension is not added to the name. After this commit, using 'name' as a filename field will also consider the name to be a 'default' for any other model than `ir.attachment`. TaskId-2826061 Forward-Port-Of: odoo/odoo#90614
Before this commit: calling `odoo-bin cloc -P <path_to_a_module>` when the manifest of a module includes an empty string in the demo, demo_xml or cloc_exclude entries, would result in a crash because an empty string is not an acceptable pattern for Path.glob opw-2829886 Forward-Port-Of: odoo/odoo#89703
Original PR description
Before this commit: calling `odoo-bin cloc -P <path_to_a_module>` when the manifest of a module includes an empty string in the demo, demo_xml or cloc_exclude entries, would result in a crash because an empty string is not an acceptable pattern for Path.glob opw-2829886 Forward-Port-Of: odoo/odoo#89703
Have the taxes: - [Ftax] any% included in price - [TAX1] 15% not included price - [TAX2] 15% included in price Apply [Ftax] and [TAX1] to a product having product price [PRI] Have a fiscal position mapping [TAX1] to [TAX2] Make a SO with the fiscal position, add in a line the product The unit price will not be [PRI] but will increment. This occur because the function doing the mapping will make the computation assuming [TAX1] is included in price opw-2797237 Description of the i
Original PR description
Have the taxes: - [Ftax] any% included in price - [TAX1] 15% not included price - [TAX2] 15% included in price Apply [Ftax] and [TAX1] to a product having product price [PRI] Have a fiscal position mapping [TAX1] to [TAX2] Make a SO with the fiscal position, add in a line the product The unit price will not be [PRI] but will increment. This occur because the function doing the mapping will make the computation assuming [TAX1] is included in price opw-2797237 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#90559 Forward-Port-Of: odoo/odoo#90140
Before this commit: if a Microsoft event didn't have body property, it couldn't get synced with Odoo and raised an error. The solution is first to check if it contains the body and then gets its content value. opw-2765443 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88288
Original PR description
Before this commit: if a Microsoft event didn't have body property, it couldn't get synced with Odoo and raised an error. The solution is first to check if it contains the body and then gets its content value. opw-2765443 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88288
Do not require user to type all digits of the document number Instead, fill the dash-separated numbers with zeroes, as needed Also, remove the condition on `l10n_ec_foreign` which is not an actual field of `l10n_ec` Description of the issue/feature this PR addresses: Filling a lot of zeroes in a field is not user-friendly The formatting of a document number should not depend on a nonexistent field. Current behavior before PR: Users have to type the exact characters of the document num
Original PR description
Do not require user to type all digits of the document number Instead, fill the dash-separated numbers with zeroes, as needed Also, remove the condition on `l10n_ec_foreign` which is not an actual field of `l10n_ec` Description of the issue/feature this PR addresses: Filling a lot of zeroes in a field is not user-friendly The formatting of a document number should not depend on a nonexistent field. Current behavior before PR: Users have to type the exact characters of the document number for it to be validated Desired behavior after PR is merged: Users no longer have to type leading zeroes -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#89924
A user should be able to scrap some products thanks to an internal transfer. To reproduce the issue: 1. In Settings, enable "Multi-Step Routes" 2. Create a storable product P and update its quantity (> 1) 3. Create a planned and internal transfer T: - From: WH/Stock - To: Virtual Locations/YourCompany: Scrap - With: 1 x P 4. Mark T as done Error: T is still in draft The `_compute_state` of a picking should not ignore the scrapped moves. However, if we include them,
Original PR description
A user should be able to scrap some products thanks to an internal
transfer.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Create a storable product P and update its quantity (> 1)
3. Create a planned and internal transfer T:
- From: WH/Stock
- To: Virtual Locations/YourCompany: Scrap
- With: 1 x P
4. Mark T as done
Error: T is still in draft
The `_compute_state` of a picking should not ignore the scrapped moves.
However, if we include them, we need to think about this use case: a
picking with a cancelled normal move and a done scrapped move -> its
state should be cancelled (see use case and test from [1])
[1] 429b589618e8dc2b0c0ccdec3f6eed88f1c73fc8
OPW-2841190
Forward-Port-Of: odoo/odoo#90801
Forward-Port-Of: odoo/odoo#90615- before this commit: always return an error when submitting answers - after theis commit: return the awarded_points according to the answers -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#87177
Original PR description
- before this commit: always return an error when submitting answers - after theis commit: return the awarded_points according to the answers -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#87177
Before these commits, the qunit test on systray activity in calendar module could fail non-deterministically. https://runbot.odoo.com/runbot/build/15116338 This was caused by 2 issues: - `_systray_get_calendar_event_domain` was not properly considering the whole day for the start date time - the test was relying on current datetime of execution, which was prone to failure at midnight These commits should fix the non-deterministic crash in this test. Forward-Port-Of: odoo/odoo#90856
Original PR description
Before these commits, the qunit test on systray activity in calendar module could fail non-deterministically. https://runbot.odoo.com/runbot/build/15116338 This was caused by 2 issues: - `_systray_get_calendar_event_domain` was not properly considering the whole day for the start date time - the test was relying on current datetime of execution, which was prone to failure at midnight These commits should fix the non-deterministic crash in this test. Forward-Port-Of: odoo/odoo#90856
Since odoo/odoo#85759 we are allowed to use other hashing algorithm with OGONE's payment acquierer. The V15 fw-port of this PR missed to unlock the max key size. The goal of this PR is to fix the issue where 32+ length key were not accepted in V15 and later. opw-2766648 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#89093
Original PR description
Since odoo/odoo#85759 we are allowed to use other hashing algorithm with OGONE's payment acquierer. The V15 fw-port of this PR missed to unlock the max key size. The goal of this PR is to fix the issue where 32+ length key were not accepted in V15 and later. opw-2766648 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#89093
The goal is for regular user (e.g. salesmen) to be able to create their email templates themselves, as long as they do not contain any dynamic code. Interrogations: - The condition to apply this strategy is currently doing it for models having the unrestricted rendering set to True. I wonder if we couldn't apply this for all models inheriting from `mail.render.mixin`, simply. - Is this `_unrestricted_rendering` still useful if we do so ? If not, maybe we could remove/refactor this in mast
Original PR description
The goal is for regular user (e.g. salesmen) to be able to create their email templates themselves, as long as they do not contain any dynamic code. Interrogations: - The condition to apply this…
The goal is for regular user (e.g. salesmen) to be able to create their email templates themselves, as long as they do not contain any dynamic code. Interrogations: - The condition to apply this strategy is currently doing it for models having the unrestricted rendering set to True. I wonder if we couldn't apply this for all models inheriting from `mail.render.mixin`, simply. - Is this `_unrestricted_rendering` still useful if we do so ? If not, maybe we could remove/refactor this in master. - With this, shouldn't we remove the mail editor group from the inherited groups of the employee group ? - Is it correct to loop on all fields of the model to check if they are dynamic ? Shouldn't we loop over a restricted set of fields of the model (e.g. `body_html`, `email_to`, ...) that could be given in a global list or in a method that could be overridden by modules ? Or simply force to set a `render_engine` on the attribute of the field to tell this is a field which can be templated/rendered. Forward-Port-Of: odoo/odoo#90822 Forward-Port-Of: odoo/odoo#88903
* project, hr, web In project, -fixed green and red icons are not visible in kanban example wizrad -fixed border issue on project kanban cards when zooming In hr, - fixed job title on my profile is not aligned correctly In web, - fixed display issue with kanban examples wizard - fixed color_picker widget alignment issue task-2720976 closes: https://github.com/odoo/odoo/pull/83727 closes: https://github.com/odoo/enterprise/pull/23875 Forward-Port-Of: odoo/odoo#90853 Forward-P
Original PR description
* project, hr, web In project, -fixed green and red icons are not visible in kanban example wizrad -fixed border issue on project kanban cards when zooming In hr, - fixed job title on my profile is not aligned correctly In web, - fixed display issue with kanban examples wizard - fixed color_picker widget alignment issue task-2720976 closes: https://github.com/odoo/odoo/pull/83727 closes: https://github.com/odoo/enterprise/pull/23875 Forward-Port-Of: odoo/odoo#90853 Forward-Port-Of: odoo/odoo#83727
With this commit, we make sure that all lines are fully reconciled when reversing a move. Steps to reproduce: - Create a Journal Entry, with eg a line with 300$ debit/credit and two others lines to make the journal entry fully balanced - Then reverse the move -> Only one line is marked as fully reconciled, the other one is marked as partially reconciled. This is because each line was passed in the reconcile method with all the counterpart lines, even those which didn't belong to i
Original PR description
With this commit, we make sure that all lines are fully reconciled when reversing a move. Steps to reproduce: - Create a Journal Entry, with eg a line with 300$ debit/credit and two others lines to…
With this commit, we make sure that all lines are fully reconciled when reversing a move. Steps to reproduce: - Create a Journal Entry, with eg a line with 300$ debit/credit and two others lines to make the journal entry fully balanced - Then reverse the move -> Only one line is marked as fully reconciled, the other one is marked as partially reconciled. This is because each line was passed in the reconcile method with all the counterpart lines, even those which didn't belong to it. Therefore, all the firsts lines was marked as partially reconciled until the last one, which passed with the only counterpart line left. With this commit, we group the amls and their counterpart lines by account and currency in a dict, then reconcile them by looping in the dict. opw-2810392 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#90888 Forward-Port-Of: odoo/odoo#89254
The /terms page may be disabled/enabled in the company settings, however the page would always be present in the sitemap whether it is enabled or not. This commit adds a method that checks for this settings before adding it to the sitemap. TaskId-2820292 Forward-Port-Of: odoo/odoo#90765
Original PR description
The /terms page may be disabled/enabled in the company settings, however the page would always be present in the sitemap whether it is enabled or not. This commit adds a method that checks for this settings before adding it to the sitemap. TaskId-2820292 Forward-Port-Of: odoo/odoo#90765
In case we try to delete an allocation, we should add a check if there are already taken leaves, otherwise it could lead to an incoherent situation with validated leaves without allocation while their associated time off type is requiring allocation. Description of the issue/feature this PR addresses: opw-2766580 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-
Original PR description
In case we try to delete an allocation, we should add a check if there are already taken leaves, otherwise it could lead to an incoherent situation with validated leaves without allocation while their associated time off type is requiring allocation. Description of the issue/feature this PR addresses: opw-2766580 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#90850
With this commit, we set the asset's deprecation moves to auto_post = True after modifying the asset. Steps to reproduce: - Create an asset for several months in the future, and confirm it - Modify the asset -> deprecation moves are not set to be auto post anymore Use the _post method on moves newly created after the asset modification. A fix was already deployed with this commit 33998d754761f8fa31033414898e11bb86264190 but led to other issues, so we moved the call to _post() on
Original PR description
With this commit, we set the asset's deprecation moves to auto_post = True after modifying the asset. Steps to reproduce: - Create an asset for several months in the future, and confirm it - Modify the asset -> deprecation moves are not set to be auto post anymore Use the _post method on moves newly created after the asset modification. A fix was already deployed with this commit 33998d754761f8fa31033414898e11bb86264190 but led to other issues, so we moved the call to _post() on the asset_modify wizard. opw-2823359 opw-2833078 Forward-Port-Of: odoo/enterprise#26972
* planning, industry_fsm_report, web_grid In planning, -fixed 'I take it' will be aligned with other buttons In industry_fsm_report, - fixed alignment issue with worksheet template field In web_grid, -fixed gap issue in all timesheet grid view task-2720976 closes: https://github.com/odoo/odoo/pull/83727 closes: https://github.com/odoo/enterprise/pull/23875 Forward-Port-Of: odoo/enterprise#27094 Forward-Port-Of: odoo/enterprise#23875
Original PR description
* planning, industry_fsm_report, web_grid In planning, -fixed 'I take it' will be aligned with other buttons In industry_fsm_report, - fixed alignment issue with worksheet template field In web_grid, -fixed gap issue in all timesheet grid view task-2720976 closes: https://github.com/odoo/odoo/pull/83727 closes: https://github.com/odoo/enterprise/pull/23875 Forward-Port-Of: odoo/enterprise#27094 Forward-Port-Of: odoo/enterprise#23875
Steps to reproduce: - Install data_merge & contacts modules - Create a company B (assume default/current company is A) - Switch to company A - Go to Contact module, create a new contact TEST (as individual)): Set name as "Test" and company as "A", then save - Switch to company B - Go to Data Cleaning -> Configuration -> Deduplication - Select 'Contact' and click on 'Deduplicate' Issue: Contact TEST is displayed. Cause: Ir.rule missing regarding multi
Original PR description
Steps to reproduce:
- Install data_merge & contacts modules
- Create a company B (assume default/current company is A)
- Switch to company A
- Go to Contact module, create a new contact TEST (as individual)):
Set name as "Test" and company as "A", then save
- Switch to company B
- Go to Data Cleaning -> Configuration -> Deduplication
- Select 'Contact' and click on 'Deduplicate'
Issue:
Contact TEST is displayed.
Cause:
Ir.rule missing regarding multi-company for data_merge.record model.
Solution:
Add multi-company ir.rule for data_merge.record model.
PR part 1 : https://github.com/odoo/enterprise/pull/26686
opw-2825324
Forward-Port-Of: odoo/enterprise#27001Steps: - Open a model (for example sale.order) - Open studio - Click on a button (exemple: Create button or save button) - Add an approval rules on it - save and close studio - Try to use the button without approval Bug: The message `The following approvals are missing` is showing up but it contains ugly html tags. Fix: Use markup to apply markdown tags. opw-2780867 Forward-Port-Of: odoo/enterprise#27058
Original PR description
Steps:
- Open a model (for example sale.order)
- Open studio
- Click on a button (exemple: Create button or save button)
- Add an approval rules on it
- save and close studio
- Try to use the button without approval
Bug:
The message `The following approvals are missing` is showing up but
it contains ugly html tags.
Fix:
Use markup to apply markdown tags.
opw-2780867
Forward-Port-Of: odoo/enterprise#27058Steps: - Open last runbot in 15.0 - Go to Products variants - Open Studio - Click on `Translations` - Traceback occurs Reason: There are many related fields in product.product and without this fix, the translation domain length is 360k, so JS raises a maximum call stack Traceback Fix: Avoid domain duplication opw-2777469 Forward-Port-Of: odoo/enterprise#26989
Original PR description
Steps:
- Open last runbot in 15.0
- Go to Products variants
- Open Studio
- Click on `Translations`
- Traceback occurs
Reason:
There are many related fields in product.product and without this
fix, the translation domain length is 360k, so JS raises a maximum
call stack Traceback
Fix: Avoid domain duplication
opw-2777469
Forward-Port-Of: odoo/enterprise#26989Steps to reproduce - Go to Documents - Open the list view - Upload 81+ documents - With for example `touch {1..100}.txt` + drag and drop - Check the checkbox in the header - Click on 'Select All' -> Only 80 documents are displayed in the DocumentsInspector Solution Before rendering the documents inspector, fetch any missing records opw-2778821 Forward-Port-Of: odoo/enterprise#26107
Original PR description
Steps to reproduce
- Go to Documents
- Open the list view
- Upload 81+ documents
- With for example `touch {1..100}.txt` + drag and drop
- Check the checkbox in the header
- Click on 'Select All'
-> Only 80 documents are displayed in the DocumentsInspector
Solution
Before rendering the documents inspector, fetch any missing
records
opw-2778821
Forward-Port-Of: odoo/enterprise#26107Before this only accounting users had access to the button. But sales users need the ability to do it on their quotations as well. task-2824272 Forward-Port-Of: odoo/enterprise#26853
Original PR description
Before this only accounting users had access to the button. But sales users need the ability to do it on their quotations as well. task-2824272 Forward-Port-Of: odoo/enterprise#26853