Tuesday, April 30, 2024
32 changes · saas-17.2
Enhancements to existing features
The mail module now provides a reusable set of test models needed by related modules such as live chat and website live chat. This reduces duplicated setup work and helps keep tests consistent when the mail module changes.
Original PR description
The mail module uses models from web, bus, and mail for its hoot test suite. Every module depending on mail would need to define those models to work properly. This is not robust as any change in the mail part would introduce inconsistencies in other modules. In order to solve this issue, the mail module now exports its required set of models so that other modules can reuse it.
Resolved issues and error corrections
This fixes an internal automated test for the website shop so it consistently archives the intended product variant. It helps keep validation runs stable and prevents false failures during release checks.
Original PR description
The test was recently updated to try solving some non deterministic issue but on fw-port wasn't correctly adapted to test changes (in 17.2). It was still relying on sequences to know which combination to archive when no sequence was set on the attributes, therefore the expected variant was not archived (and the tour was failing). runbot issue 61125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Issue: A traceback error is raised when a sales order is saved with products with varying company ids. Was trying to lookup a list of ids rather than a singular id which triggered the traceback. Purpose of this PR: To check accessible company branches on a individual company rather than a recordset of companies. Steps to Reproduce on Runbot: 1) Create branch of main company. 2) Create products one with company id of the branch and the other of company id in the main company. 3) Creat
Original PR description
Issue: A traceback error is raised when a sales order is saved with products with varying company ids. Was trying to lookup a list of ids rather than a singular id which triggered the traceback. Purpose of this PR: To check accessible company branches on a individual company rather than a recordset of companies. Steps to Reproduce on Runbot: 1) Create branch of main company. 2) Create products one with company id of the branch and the other of company id in the main company. 3) Create sale order, order lines with each of the products. 4) On save, a traceback error is raised. Notes: opw-3810770 Forward-Port-Of: odoo/odoo#162547
This change makes an automated test wait properly for the command palette search results before checking them. It reduces random test failures in the web module, helping keep release validation stable without changing user-facing behavior.
Original PR description
The searh input of the command palette is debounced, so we have to wait some more before doing assertions on the results given by the command palette. Before this commit, one test crashed in a undeterministic manner. After this commit, that test passes everytime. runbot-error-57966 runbot-error-58752 runbot-error-61760 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
On a customer invoice, the sentence "Please use the following communication for your payment : +++000/0000/10205+++" was changed to "Please use the following communication for your payment : +++000/0000/10205+++ on this account : BE81 3101 2528 8724" Customer invoices only had payment reference. Bank account (iban) was also needed on the invoice. task-3794432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163912
Original PR description
On a customer invoice, the sentence "Please use the following communication for your payment : +++000/0000/10205+++" was changed to "Please use the following communication for your payment : +++000/0000/10205+++ on this account : BE81 3101 2528 8724" Customer invoices only had payment reference. Bank account (iban) was also needed on the invoice. task-3794432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163912 Forward-Port-Of: odoo/odoo#157503
Description of the issue/feature this PR addresses: In the mobile view, the header has extra padding, for this reason it is not perfectly aligned with the content of the page. Current behavior before PR: The header is not aligned with the content | Desktop | Mobile | |--------|--------| |  |  | Desired
Original PR description
Description of the issue/feature this PR addresses: In the mobile view, the header has extra padding, for this reason it is not perfectly aligned with the content of the page. Current behavior before PR: The header is not aligned with the content | Desktop | Mobile | |--------|--------| |  |  | Desired behavior after PR is merged: The header is aligned with the content like desktop view https://github.com/odoo/odoo/assets/35231827/32fbe3f1-3ba8-443f-856d-26b03a0cbe13 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163705
fixes for following runbot errors: - 62449 - 62452 Forward-Port-Of: odoo/odoo#163795
Original PR description
fixes for following runbot errors: - 62449 - 62452 Forward-Port-Of: odoo/odoo#163795
Starting with Odoo 16.1, the ECMAScript version supported by Odoo has been bumped to ES2022, but support for all ES2022 features has only been achieved with Node.js 16.11*, making it the minimum required version to run Odoo. This commit updates the package.json to make this requirement explicit, preventing from using the tooling with an outdated version of Node.js, which would otherwise result in an unclear syntax error. *: From all the features added in ES2022, support for static initiali
Original PR description
Starting with Odoo 16.1, the ECMAScript version supported by Odoo has been bumped to ES2022, but support for all ES2022 features has only been achieved with Node.js 16.11*, making it the minimum required version to run Odoo. This commit updates the package.json to make this requirement explicit, preventing from using the tooling with an outdated version of Node.js, which would otherwise result in an unclear syntax error. *: From all the features added in ES2022, support for static initialization blocks is the latest to have been added, in Node.js 16.11, according to MDN's compatibility data. Forward-Port-Of: odoo/odoo#163787
Add a new tax, Exento, to the master data of the module l10n_mx, change the fiscal position 'Foreign Customer' and add a new tax group for Exento. Add the Exento tax recognition for the XML reader for vendor bills. task id : 3774996 Forward-Port-Of: odoo/odoo#163662 Forward-Port-Of: odoo/odoo#160624
Original PR description
Add a new tax, Exento, to the master data of the module l10n_mx, change the fiscal position 'Foreign Customer' and add a new tax group for Exento. Add the Exento tax recognition for the XML reader for vendor bills. task id : 3774996 Forward-Port-Of: odoo/odoo#163662 Forward-Port-Of: odoo/odoo#160624
Make the mininum version of Python a variable so that it can be easily retrieved and used by the code. For example, it could be used to detect when a monkey patch should be removed. Forward-Port-Of: odoo/odoo#163605 Forward-Port-Of: odoo/odoo#156774
Original PR description
Make the mininum version of Python a variable so that it can be easily retrieved and used by the code. For example, it could be used to detect when a monkey patch should be removed. Forward-Port-Of: odoo/odoo#163605 Forward-Port-Of: odoo/odoo#156774
*: im_livechat, im_livechat_mail_bot Since odoo/odoo#110188 `canned_response_ids` is not being passed to `mail_message_post` and since odoo/odoo#127382 canned response is enabled in only non-channel threads so odooBot onboarding crashes on the canned response step. This commit allows using `canned responses` in `chat with odooBot` and makes sure that we send them with the message post data. Related to odoo/odoo#157997 Forward-Port-Of: odoo/odoo#163607 Forward-Port-Of: odoo/odoo#162234
Original PR description
*: im_livechat, im_livechat_mail_bot Since odoo/odoo#110188 `canned_response_ids` is not being passed to `mail_message_post` and since odoo/odoo#127382 canned response is enabled in only non-channel threads so odooBot onboarding crashes on the canned response step. This commit allows using `canned responses` in `chat with odooBot` and makes sure that we send them with the message post data. Related to odoo/odoo#157997 Forward-Port-Of: odoo/odoo#163607 Forward-Port-Of: odoo/odoo#162234
Delivery and loyalty discount lines were already disregarded when computing the invoice status if they were the only lines to invoice, but new logic of discount lines, introduced in 17 with bf95b1f2ade01a79263461987e62d3b5b1b09483, didn't consider this situation. This commit harmonizes the existing logic of `loyalty` & `delivery`, directly in `sale`, making sure this is correctly handled at once for the three cases. opw-3853012 --- I confirm I have signed the CLA and read the PR guid
Original PR description
Delivery and loyalty discount lines were already disregarded when computing the invoice status if they were the only lines to invoice, but new logic of discount lines, introduced in 17 with bf95b1f2ade01a79263461987e62d3b5b1b09483, didn't consider this situation. This commit harmonizes the existing logic of `loyalty` & `delivery`, directly in `sale`, making sure this is correctly handled at once for the three cases. opw-3853012 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161563
Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user. Steps to reproduce: ------------------- * Go to the **Time Off** app * Select **Configuration** > **Time Off Type** * Create a new time off type * Approval: By Employee's Approver and Time Off Oficcer * Requires allocation: Yes * Employee Requests: Extra Days Requests Allowed * Approval: Approved by Time Off Officer * Notified Time off offi
Original PR description
Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user. Steps to reproduce: ------------------- * Go to the **Time…
Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user. Steps to reproduce: ------------------- * Go to the **Time Off** app * Select **Configuration** > **Time Off Type** * Create a new time off type * Approval: By Employee's Approver and Time Off Oficcer * Requires allocation: Yes * Employee Requests: Extra Days Requests Allowed * Approval: Approved by Time Off Officer * Notified Time off officer: Mitchell Admin * Select **Management** > **Allocations** * Create a new allocation * Employees: Mitchell Admin * Time off time: The one created previously * Validate the allocation * Select **Management** > **Time Off** * create a new time off * Employees: Any Employee A & Employee B * Time off type: > Observation: The new time off time is present in the name search while both employees don't have any allocation for it. Why the fix: ------------ The name search searches for time off type with ``` ['|', ['requires_allocation', '=', 'no'], '&', ['has_valid_allocation', '=', True], '&', ['max_leaves', '>', '0'], '|', ['allows_negative', '=', True], '&', ['virtual_remaining_leaves', '>', 0], ['allows_negative', '=', False]] ``` By configuration, the time off has `requires_allocation = yes` therefore it shouldn't appear here and it does not -> ok `has_valid_allocation` has a search method `_search_valid` https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L109-L138 `max_leaves` has a search method `_search_max_leaves` https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L165-L192 Both use the function `_get_contextual_employee` to make their search. https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_employee.py#L386-L388 When there are more than one employee selected on the hr leave form, the context contains `employee_id: False`. Thus here we are making the search using the current user, which is Mitchell Admin. The search shouldn't be made using the current user in this case since he doesn't correspond to any of the employees we added of the form. opw-3816442 Forward-Port-Of: odoo/odoo#163635 Forward-Port-Of: odoo/odoo#161713
### Current Issue: When we have an accrual plan where the accrued time is allocated at the start of the accrual period and we set the allocation start time in the past, the plan will be processed but `already_accrued` will not be saved. ### Example: - We have an accrual plan that allocates 1 day per month at the start of the accrual period. Milestone reached 0 days after allocation start. - We set the start date of the allocation to 2024-01-01, the current date is 2024-03-15. The number
Original PR description
### Current Issue: When we have an accrual plan where the accrued time is allocated at the start of the accrual period and we set the allocation start time in the past, the plan will be processed but `already_accrued` will not be saved. ### Example: - We have an accrual plan that allocates 1 day per month at the start of the accrual period. Milestone reached 0 days after allocation start. - We set the start date of the allocation to 2024-01-01, the current date is 2024-03-15. The number of days are calculated to 3.00 (jan, feb, mar). - We save the record, `already_accrued` is not saved (defaults to false) - When the scheduled action runs (2024-04-01), it will allocate 2 days instead of 1 ### Solution: This commit fixes this behavior by adding the `already_accrued` field to the form view so that it is saved when the record is created. opw-3851320 Forward-Port-Of: odoo/odoo#161508
Steps to reproduce: 1) Create a quotation and confirm it 2) Invoice a first down payment (fixed amount) and validate it 3) Invoice the rest of the SO amount and validate it 4) Create a credit note for the last invoice created (at step 3)) 5) From the SO, re-invoice the rest of the SO amount Issue: the amount of the downpayment is added to the total, not subtracted opw-3817440 Forward-Port-Of: odoo/odoo#161350
Original PR description
Steps to reproduce: 1) Create a quotation and confirm it 2) Invoice a first down payment (fixed amount) and validate it 3) Invoice the rest of the SO amount and validate it 4) Create a credit note for the last invoice created (at step 3)) 5) From the SO, re-invoice the rest of the SO amount Issue: the amount of the downpayment is added to the total, not subtracted opw-3817440 Forward-Port-Of: odoo/odoo#161350
**Description of the issue/feature this PR addresses:** This PR address the issue of redirecting to courses page with /invite_error when trying to update the optimize seo. **Current behavior before PR:** Previously, when editing Optimize SEO and clicking "Save," it redirected to /invite_error in Courses instead of remaining on the same URL after saving, which was caused due to not receiving seoName. **Desired behavior after PR is merged:** Now after saving, we stay on the same course U
Original PR description
**Description of the issue/feature this PR addresses:** This PR address the issue of redirecting to courses page with /invite_error when trying to update the optimize seo. **Current behavior before PR:** Previously, when editing Optimize SEO and clicking "Save," it redirected to /invite_error in Courses instead of remaining on the same URL after saving, which was caused due to not receiving seoName. **Desired behavior after PR is merged:** Now after saving, we stay on the same course URL without being redirected to /invite_error. This fix includes checking if the seoContext doesn't have a seoName , in which case we redirect to seoNameDefault to prevent redirection to /invite_error on the Courses page. **Task**-3688285 Forward-Port-Of: odoo/odoo#161029
Before this commit, alarms were always being set up when there was no 'next_date' specified, creating an undeterministic behavior since inside the 'get_next_alarm_date' function we check if the 'call_at' attribute from the trigger happens before 'now'. If this condition is false, i.e. if there is already an alarm set up for the future, we were returning a falsy value for the next alarm date and setting up the alarm anyway (using the current date inside '_setup_alarms', since the context was None
Original PR description
Before this commit, alarms were always being set up when there was no 'next_date' specified, creating an undeterministic behavior since inside the 'get_next_alarm_date' function we check if the 'call_at' attribute from the trigger happens before 'now'. If this condition is false, i.e. if there is already an alarm set up for the future, we were returning a falsy value for the next alarm date and setting up the alarm anyway (using the current date inside '_setup_alarms', since the context was None), thus generating a new alarm with the wrong call date. After this commit, we make an extra check for recurrences in the 'get_next_alarm_date' function in order to get the correct next date for the next alarm from the next recurrent event. Additionally, if there is no next date to be called in the in the future, we skip the 'send_reminder' function which was wrongly creating another alarm using 'now' as time. Issue-from: odoo/odoo#147914 Forward-Port-Of: odoo/odoo#161941
- Adds missing section D and E to the tax report. - Change line 43 to editable instead of aggregation. task-3672445 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161658 Forward-Port-Of: odoo/odoo#155223
Original PR description
- Adds missing section D and E to the tax report. - Change line 43 to editable instead of aggregation. task-3672445 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161658 Forward-Port-Of: odoo/odoo#155223
Before this commit, the drag and drop functionality of the MoveNodePlugin was not working all the time. The movable element would not move. The bug started with the introduction of the new drag and drop util (useNativeDraggable). The util has a parameter tolerance that does not start the drag and drop until the mouse has moved a certain distance. If the mouse entered another hook element before the start of the drag was triggered, the node that the user clicked would be removed before the drag
Original PR description
Before this commit, the drag and drop functionality of the MoveNodePlugin was not working all the time. The movable element would not move. The bug started with the introduction of the new drag and drop util (useNativeDraggable). The util has a parameter tolerance that does not start the drag and drop until the mouse has moved a certain distance. If the mouse entered another hook element before the start of the drag was triggered, the node that the user clicked would be removed before the drag started, therefore it would never start. This commit fixes the issue by setting the tolerance to 0, so the drag and drop starts immediately. task-3802746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157584
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to reproduce the issue: ============================= - Go to to-do - add a table on top the editable - Hover on the top left cell - The row and col ui boxes doesn't show correctl Origin of the issue: ==================== Since we forced the mentioned commit that `overflow-x` should be hid
Original PR description
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to…
Commit that introduced the issue: https://github.com/odoo/odoo/commit/c98c58301da82ad896e296b9bbbdf6bbb0bc2a8e Issue: ====== The row and column table ui elements doesn't show correctly. Steps to reproduce the issue: ============================= - Go to to-do - add a table on top the editable - Hover on the top left cell - The row and col ui boxes doesn't show correctl Origin of the issue: ==================== Since we forced the mentioned commit that `overflow-x` should be hidden, then the ui elements which overflows the visible area of the html field will be hdden too that's why only a small part of them appear. Solution: ========= To conserve the same ui and not add extra padding , we add padding to the `note-editable` to make it possible to display the ui elements fully (needs 16px) and decrease the padding of the padding of the formView sheet. Before: ======  After: =====  task-3861784 Forward-Port-Of: odoo/odoo#162029
**Current behaviour before commit:** In website when cropper is open, pressing ESC key hides side panel. **Desired behaviour after commit:** Now, pressing ESC works same as discard button. It closes the cropper and prevents hiding side panel. task-3787411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158543
Original PR description
**Current behaviour before commit:** In website when cropper is open, pressing ESC key hides side panel. **Desired behaviour after commit:** Now, pressing ESC works same as discard button. It closes the cropper and prevents hiding side panel. task-3787411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158543
Load taxes in an end script when all modules are loaded. Move script to end. ``` Traceback (most recent call last): File "/home/odoo/src/odoo/saas-17.1/odoo/service/server.py", line 1286, in preload_registries registry = Registry.new(dbname, update_module=update_module) File "<decorator-gen-14>", line 2, in new File "/home/odoo/src/odoo/saas-17.1/odoo/tools/func.py", line 87, in locked return func(inst, *args, **kwargs) File "/home/odoo/src/odoo/saas-17.1/odoo/module
Original PR description
Load taxes in an end script when all modules are loaded. Move script to end. ``` Traceback (most recent call last): File "/home/odoo/src/odoo/saas-17.1/odoo/service/server.py", line 1286, in…
Load taxes in an end script when all modules are loaded.
Move script to end.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-17.1/odoo/service/server.py", line
1286, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-14>", line 2, in new
File "/home/odoo/src/odoo/saas-17.1/odoo/tools/func.py", line 87, in
locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/registry.py", line
119, in new
odoo.modules.load_modules(registry, force_demo, status,
update_module)
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/loading.py", line
476, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/loading.py", line
364, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/loading.py", line
232, in load_module_graph
migrations.migrate_module(package, 'post')
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/migration.py", line
240, in migrate_module
migrate(self.cr, installed_version)
File
"/home/odoo/src/odoo/saas-17.1/addons/l10n_lu/migrations/2.2/post-migrate_update_taxes.py",
line 7, in migrate
env['account.chart.template'].try_loading('lu', company)
File
"/home/odoo/src/odoo/saas-17.1/addons/account/models/chart_template.py",
line 144, in try_loading
return self._load(template_code, company, install_demo)
File
"/home/odoo/src/odoo/saas-17.1/addons/account/models/chart_template.py",
line 195, in _load
self._post_load_data(template_code, company, template_data)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/chart_template.py",
line 31, in _post_load_data
company._get_and_update_tax_closing_moves(fields.Date.today(),
include_domestic=True)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/res_company.py",
line 162, in _get_and_update_tax_closing_moves
report, tax_closing_options =
tax_closing_move._get_report_options_from_tax_closing_entry()
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_move.py",
line 209, in _get_report_options_from_tax_closing_entry
report_options =
tax_report.with_context(allowed_company_ids=company_ids).get_options(previous_options=options)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1631, in get_options
return
self.env['account.report'].browse(options['report_id']).get_options(variant_options)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1636, in get_options
initializer(options, previous_options=previous_options)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1470, in _init_options_section_buttons
options['buttons'] =
sections_source.get_options(previous_options={**options,
'no_report_reroute': True})['buttons']
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1636, in get_options
initializer(options, previous_options=previous_options)
File
"/home/odoo/src/enterprise/saas-17.1/account_reports/models/account_report.py",
line 1585, in _init_options_custom
self.env[custom_handler_model]._custom_options_initializer(self,
options, previous_options)
File "/home/odoo/src/odoo/saas-17.1/odoo/api.py", line 534, in
__getitem__
return self.registry[model_name](self, (), ())
File "/home/odoo/src/odoo/saas-17.1/odoo/modules/registry.py", line
224, in __getitem__
return self.models[model_name]
KeyError: 'l10n_lu.tax.report.handler'
```
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#163114[IMP] l10n_mx : Update master data with new Exento tax and fix the XML reader issues Add a new tax, Exento, to the master data of the module l10n_mx, change the fiscal position 'Foreign Customer' and add a new tax group for Exento. Add the Exento tax recognition for the XML reader for vendor bills. task id: 3774996 Forward-Port-Of: odoo/enterprise#61613 Forward-Port-Of: odoo/enterprise#60107
Original PR description
[IMP] l10n_mx : Update master data with new Exento tax and fix the XML reader issues Add a new tax, Exento, to the master data of the module l10n_mx, change the fiscal position 'Foreign Customer' and add a new tax group for Exento. Add the Exento tax recognition for the XML reader for vendor bills. task id: 3774996 Forward-Port-Of: odoo/enterprise#61613 Forward-Port-Of: odoo/enterprise#60107
Before this commit: when editing a sign template and opening the sign item popover, it remained open when clicking away even when leaving the sign app. This commit addresses this issue by refining the `closeOnClickAway` to close the popover only if the click is not within an active modal, ensuring that the popover stays open when the role modal is displayed. Task: 3861496 _______________________________________________________________ Bug was introduced in this PR: https://github.com/
Original PR description
Before this commit: when editing a sign template and opening the sign item popover, it remained open when clicking away even when leaving the sign app. This commit addresses this issue by refining the `closeOnClickAway` to close the popover only if the click is not within an active modal, ensuring that the popover stays open when the role modal is displayed. Task: 3861496 _______________________________________________________________ Bug was introduced in this PR: https://github.com/odoo/enterprise/pull/49900 in attempt to keep the popover open when updating the sign item role. Forward-Port-Of: odoo/enterprise#60613
Before this commit: =========== - The balance column text on the partner screen had a low shade, diminishing its visibility. After this commit: =========== - The balance column text in the partner screen has a high shade, improving its visibility. task-3877793 Forward-Port-Of: odoo/enterprise#61127
Original PR description
Before this commit: =========== - The balance column text on the partner screen had a low shade, diminishing its visibility. After this commit: =========== - The balance column text in the partner screen has a high shade, improving its visibility. task-3877793 Forward-Port-Of: odoo/enterprise#61127
Summary ----- When you try to display the spanish tax report, model 347, if you have too much partners with few small transactions (the sum is lower than 3005.06€), an error is raised. Steps to reproduce ----- 1. Install the l10n_es module 2. Create 30,000 invoices with an amount of 1€, and each having a distinct partner linked 3. Open the model 347: Accounting > Reporting > Tax Report, and select the report called "Tax Report (Mod 347)(ES)" and a date range large enough 4. Observe the
Original PR description
Summary ----- When you try to display the spanish tax report, model 347, if you have too much partners with few small transactions (the sum is lower than 3005.06€), an error is raised. Steps to reproduce ----- 1. Install the l10n_es module 2. Create 30,000 invoices with an amount of 1€, and each having a distinct partner linked 3. Open the model 347: Accounting > Reporting > Tax Report, and select the report called "Tax Report (Mod 347)(ES)" and a date range large enough 4. Observe the very long UserError Cause ----- Too much partners must be excluded and the list of this partners are added to a domain which becomes very long and an error is raised when we use the function ast.literal_eval on it. Fix ----- The list of the excluded partners are passed in the "forced_domain" options. Like that, the ast.literal_eval function is not applied on it and the error is not raised. opw-3770944 Forward-Port-Of: odoo/enterprise#61452
- Adds missing section D and E to the tax report. - Change line 43 to editable instead of aggregation. Forward-Port-Of: odoo/enterprise#61557 Forward-Port-Of: odoo/enterprise#57367
Original PR description
- Adds missing section D and E to the tax report. - Change line 43 to editable instead of aggregation. Forward-Port-Of: odoo/enterprise#61557 Forward-Port-Of: odoo/enterprise#57367
Withholding tax lines should not appear in the Libro de IVA export, where only base lines and Tax Lines of IVA (=VAT) taxes should be reported. task-3875272 Forward-Port-Of: odoo/enterprise#61206
Original PR description
Withholding tax lines should not appear in the Libro de IVA export, where only base lines and Tax Lines of IVA (=VAT) taxes should be reported. task-3875272 Forward-Port-Of: odoo/enterprise#61206
_compute_l10n_br_is_service_transaction() was added as part of account.external.tax.mixin. It's supposed to be implemented for both account.move and sale.order. The sale.order override is part of l10n_br_edi_sale_services, which is only installed if EDI is installed. This causes issues with the "l10n single modules" runbot tests. When l10n_br_test_avatax_sale is tested it installs l10n_br_avatax and sale. l10n_br_avatax_services is auto-installed because of l10n_br_avatax. Because there's no
Original PR description
_compute_l10n_br_is_service_transaction() was added as part of account.external.tax.mixin. It's supposed to be implemented for both account.move and sale.order. The sale.order override is part of l10n_br_edi_sale_services, which is only installed if EDI is installed. This causes issues with the "l10n single modules" runbot tests. When l10n_br_test_avatax_sale is tested it installs l10n_br_avatax and sale. l10n_br_avatax_services is auto-installed because of l10n_br_avatax. Because there's no sale.order override various tests will fail with NotImplementedError() [1]. Ideally there should have been a l10n_br_avatax_sale_services module that contained just this one override. In absence of that, we make the function set False to stop breaking the tests. Users who just want tax computation on services will need to install the EDI part manually. [1] https://runbot.odoo.com/runbot/build/61615058 Forward-Port-Of: odoo/enterprise#61277
Missing condition that is hiding the "Reset to Draft" button on all journal entries. Forward-Port-Of: odoo/enterprise#61677
Original PR description
Missing condition that is hiding the "Reset to Draft" button on all journal entries. Forward-Port-Of: odoo/enterprise#61677
Some databases have a default column value `undefined` on l10n_mx_edi_cfdi_sat_state. When assigning `undefined` to `l10n_mx_edi_cfdi_sat_state`, the orm raises an error because it's no longer a valid value for this selection field. To not block people, let's set the field to None by default. Forward-Port-Of: odoo/enterprise#61686
Original PR description
Some databases have a default column value `undefined` on l10n_mx_edi_cfdi_sat_state. When assigning `undefined` to `l10n_mx_edi_cfdi_sat_state`, the orm raises an error because it's no longer a valid value for this selection field. To not block people, let's set the field to None by default. Forward-Port-Of: odoo/enterprise#61686
Reproduce Create some `expense`, approve some of them Expected: On journal dashboard, The `Expense Journal` need to display Number of Expense to process Actual: `number_expenses_to_pay` does not display on The `Expense Journal` because we haven't override the needed method yet Also this PR aim to improve the `open_expenses_action` to display correctly the number of expense on the journal dashboard Video to reproduce on runbot 25/09/2023 https://github.com/odoo/odoo/assets/5678
Original PR description
Reproduce Create some `expense`, approve some of them Expected: On journal dashboard, The `Expense Journal` need to display Number of Expense to process Actual: `number_expenses_to_pay` does not display on The `Expense Journal` because we haven't override the needed method yet Also this PR aim to improve the `open_expenses_action` to display correctly the number of expense on the journal dashboard Video to reproduce on runbot 25/09/2023 https://github.com/odoo/odoo/assets/56789189/6d4a4c14-1551-40af-84ae-9ce9a7e4a666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#139971 Forward-Port-Of: odoo/odoo#136232