Friday, May 17, 2024
38 changes · saas-17.2
Resolved issues and error corrections
Helpdesk reports now use the correct label logic when showing default filters. This prevents error messages that could interrupt users while viewing ticket graph reports.
Original PR description
Issue: - Previously, the `_getDefaultFilterLabel()` method overridden, but mistakenly called the `_getEmptyGroupLabel()` method from the superclass, causing traceback errors. Fix: - This commit fixes the issue by calling the correct superclass method, `_getDefaultFilterLabel()`. Effect of the commit:https://github.com/odoo/enterprise/commit/8382bf4dc94139bd9eb44eb0907bb1b991a0e3b2#
Miscellaneous changes
Description of the issue this commit addresses: The Customers and Vendors dropdown start to bloat and the Amounts to Settle view can be reached via the dashboard or the Aged Payable/Aged Receivable reports. Therefore, we can remove them to lower the amount of buttons. Desired behavior after this commit is merged: The menuitems in the Customers and the Vendors dropdown to reach the Amounts to Settle view have been removed. no task linked, feedback --- I confirm I have signed th
Original PR description
Description of the issue this commit addresses: The Customers and Vendors dropdown start to bloat and the Amounts to Settle view can be reached via the dashboard or the Aged Payable/Aged Receivable reports. Therefore, we can remove them to lower the amount of buttons. Desired behavior after this commit is merged: The menuitems in the Customers and the Vendors dropdown to reach the Amounts to Settle view have been removed. no task linked, feedback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165806
First commit: Doesn't look like an issue since it is a fallback in case `action.last_run` is not set Second commit: to verify Forward-Port-Of: odoo/odoo#165873 Forward-Port-Of: odoo/odoo#165735
Original PR description
First commit: Doesn't look like an issue since it is a fallback in case `action.last_run` is not set Second commit: to verify Forward-Port-Of: odoo/odoo#165873 Forward-Port-Of: odoo/odoo#165735
With the conversion of inline templates in [1], a typo was introduced that changed "screen" to "string". This commit fixes that typo and updates the .pot file. Also, the `escape` function used was changed to the correct one. [1] 5700cc65b614b0db0f73b6704fe2fad44b62d2d3 Forward-Port-Of: odoo/odoo#165854 Forward-Port-Of: odoo/odoo#164893
Original PR description
With the conversion of inline templates in [1], a typo was introduced that changed "screen" to "string". This commit fixes that typo and updates the .pot file. Also, the `escape` function used was changed to the correct one. [1] 5700cc65b614b0db0f73b6704fe2fad44b62d2d3 Forward-Port-Of: odoo/odoo#165854 Forward-Port-Of: odoo/odoo#164893
If the footer is too long in a boxed layout, it's not properly wrapped. This css rule was introduced in saas-15 in 4c8a806a23f7d0da8f43c0bb5ebf7307776bf000 to fix an issue where the phone/vat fields of the footers could be wrongly displayed. (in those older versions, you had harcoded company fields in the footer, like phone and vat) Now footer is a simple text, so this css line is not relevant anymore. steps to reproduce: - go to settings, click on "configure document layout" - sel
Original PR description
If the footer is too long in a boxed layout, it's not properly wrapped. This css rule was introduced in saas-15 in 4c8a806a23f7d0da8f43c0bb5ebf7307776bf000 to fix an issue where the phone/vat fields of the footers could be wrongly displayed. (in those older versions, you had harcoded company fields in the footer, like phone and vat) Now footer is a simple text, so this css line is not relevant anymore. steps to reproduce: - go to settings, click on "configure document layout" - select boxed - add a really long one-line footer - check the preview (or download the pdf preview) before this commit:  after this commit:  opw-3871778 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162921
In this PR: - Improved user interface for better tracking and cancellation of E-WayBills. - Introduced a wizard feature to simplify the insertion of cancel E-waybill details. Task ID: 3659636. Co-authored-by: Co-authored-by: K Theja (kthe@odoo.com) Forward-Port-Of: odoo/odoo#165846 Forward-Port-Of: odoo/odoo#156452
Original PR description
In this PR: - Improved user interface for better tracking and cancellation of E-WayBills. - Introduced a wizard feature to simplify the insertion of cancel E-waybill details. Task ID: 3659636. Co-authored-by: Co-authored-by: K Theja (kthe@odoo.com) Forward-Port-Of: odoo/odoo#165846 Forward-Port-Of: odoo/odoo#156452
Steps to reproduce: - Install attendance and website - Toggle "Employee PIN Identification" in Settings - Open "Attendances" - Kiosk Mode - Identify Manually and click on an employee Issues: The button for the pin code are too big, this is due to the CSS change in website module for the 'btn-lg' class. https://github.com/odoo/odoo/blob/71227dbc4848c7c27c61e477a78b35e0c0167b8e/addons/website/static/src/scss/website.scss#L576-L594 As a solution I added the styling to the `o_hr_atte
Original PR description
Steps to reproduce: - Install attendance and website - Toggle "Employee PIN Identification" in Settings - Open "Attendances" - Kiosk Mode - Identify Manually and click on an employee Issues: The button for the pin code are too big, this is due to the CSS change in website module for the 'btn-lg' class. https://github.com/odoo/odoo/blob/71227dbc4848c7c27c61e477a78b35e0c0167b8e/addons/website/static/src/scss/website.scss#L576-L594 As a solution I added the styling to the `o_hr_attendance_PINbox_button` class, such that we keep the original styling. https://github.com/odoo/odoo/blob/71227dbc4848c7c27c61e477a78b35e0c0167b8e/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L3462-L3466 opw-3864816 Forward-Port-Of: odoo/odoo#164530
1. Avoid crashing if move.name is not set In the tests - `:TestAccountMoveInInvoiceOnchanges.test_fiduciary_mode_date_suggestion` - `:TestSequenceMixin.test_sequence_empty_editable_with_quick_edit_mode` the compute method `_compute_l10n_hu_edi_attachment_filename` was called before the invoice name was set. Because of this, calling move.name.replace('/', '_') was raising an AttributeError. 2. Allow user to not put credentials when they are using demo mode. 3. sent (waiting for res
Original PR description
1. Avoid crashing if move.name is not set
In the tests
- `:TestAccountMoveInInvoiceOnchanges.test_fiduciary_mode_date_suggestion`
- `:TestSequenceMixin.test_sequence_empty_editable_with_quick_edit_mode`
the compute method `_compute_l10n_hu_edi_attachment_filename` was called before the invoice name was set.
Because of this, calling move.name.replace('/', '_') was raising an AttributeError.
2. Allow user to not put credentials when they are using demo mode.
3. sent (waiting for response) and confirmed_warning states should not raise a UserError and should not block an e-mail from being sent to the customer.
4. always send modification invoices using 'MODIFY' (never 'STORNO') since 'STORNO' prevents further modifications from being issued to the invoice, but in Odoo we can't predict whether the user will want to issue further corrections to an invoice in the future.
Fixes runbot errors 64755 and 64756.
Forward-Port-Of: odoo/odoo#165195## Description Since b2eaf32ba92e537c7eefba6489533613be1b8c91, channels that have no message aren't created anymore, so the assertion that if we have a livechat existing it has at least 1 message holds true. Therefor the leaf `('has_message', '=', True)` in many of the livechat related domains is not necessary. In a large database with millions of records on `mail_message`, loading the index on `res_id+model_id` from disk, even for an `Index Only Scan` can be really slow. ## Benchmark Examp
Original PR description
## Description Since b2eaf32ba92e537c7eefba6489533613be1b8c91, channels that have no message aren't created anymore, so the assertion that if we have a livechat existing it has at least 1 message…
## Description
Since b2eaf32ba92e537c7eefba6489533613be1b8c91, channels that have no message aren't created anymore, so the assertion that if we have a livechat existing it has at least 1 message holds true. Therefor the leaf `('has_message', '=', True)` in many of the livechat related domains is not necessary. In a large database with millions of records on `mail_message`, loading the index on `res_id+model_id` from disk, even for an `Index Only Scan` can be really slow.
## Benchmark
Example for runtime on a staging database, with over 256M mail_messages, 600k discuss_channels, warm cache. Cold cache is around 10x slower in both cases. The bottleneck for loading the default Livechat view: `_compute_nbr_channel`
| | Before | After |
|---------|----------|----------|
| Timings | 1.88 sec | 0.25 sec |
## Reference
opw-3896457
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#165609
Forward-Port-Of: odoo/odoo#164752When the base event is archived, it continues being the base event of the recurrence, and when trying to change the recurrence of all the events of the recurrence, an error is thrown or some inconsistencies occur. To test the problem, you can follow these steps: 1. Create a recurrence of events from a non included day on the recurrence (example: recurrence on tuesday and friday and the start of the recurrence on monday). The first event will be archived automatically. 2. Open other event
Original PR description
When the base event is archived, it continues being the base event of the recurrence, and when trying to change the recurrence of all the events of the recurrence, an error is thrown or some…
When the base event is archived, it continues being the base event of the recurrence, and when trying to change the recurrence of all the events of the recurrence, an error is thrown or some inconsistencies occur. To test the problem, you can follow these steps: 1. Create a recurrence of events from a non included day on the recurrence (example: recurrence on tuesday and friday and the start of the recurrence on monday). The first event will be archived automatically. 2. Open other event of the recurrence. 3. Modify the recurrence for all events (example: change the weekdays, set just tuesday instead of tuesday and friday) An error will be thrown. See next gif:  By making these changes, the base event will be updated, as indicated in the `_select_new_base_event` method, so these inconsistencies will not occur when making the changes. See next gif:  cc @Tecnativa TT46742 ping @pedrobaeza @chienandalu --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165659 Forward-Port-Of: odoo/odoo#149349
TPAR is not commonly used and makes it difficult to search for taxes in Many2one fields. This commits sets them to inactive by default. Task# 3782518 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#165321
Original PR description
TPAR is not commonly used and makes it difficult to search for taxes in Many2one fields. This commits sets them to inactive by default. Task# 3782518 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#165321
l10n_bd: Add bangaldesh localization pack Accounts Journals Taxes Default tax in settings Tax Groups Fiscal Positions: Not required Tax report Tax grids Reason: Include a new localization pack in odoo Task-3693258 Task-3842115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160421
Original PR description
l10n_bd: Add bangaldesh localization pack Accounts Journals Taxes Default tax in settings Tax Groups Fiscal Positions: Not required Tax report Tax grids Reason: Include a new localization pack in odoo Task-3693258 Task-3842115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160421
Forward-Port-Of: odoo/odoo#165727
Original PR description
Forward-Port-Of: odoo/odoo#165727
I found in the CRM view crm_team_views.xml on line 82 an extra closing curly brace in the value of the context. Each opening tag/brace must have only one closing tag/brace. In our case it was a curly brace which must be removed to avoid syntax errors. This PR is made after a similar one for 17.0 branch which has the same issue and I was advised by @reth-odoo to make the PR for the first branch containing the bug. The previous PR URL for 17.0: [https://github.com/odoo/odoo/pull/164
Original PR description
I found in the CRM view crm_team_views.xml on line 82 an extra closing curly brace in the value of the context. Each opening tag/brace must have only one closing tag/brace. In our case it was a curly brace which must be removed to avoid syntax errors. This PR is made after a similar one for 17.0 branch which has the same issue and I was advised by @reth-odoo to make the PR for the first branch containing the bug. The previous PR URL for 17.0: [https://github.com/odoo/odoo/pull/164461](https://github.com/odoo/odoo/pull/164461) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165717
Issue: ====== Availablity message and product doesn't exist shows at the same time. Steps to reproduce the issue: ============================= - Create a storable product with 2 attributes each having 2 values - Set show available qty below 5 units - Remove one of the created variants - Set qty for all the other variants to 3 (anything less than 5 and > 0) - Go to website page of the product and switch between variants - You can see that when we go to the deleted variant it shows bo
Original PR description
Issue: ====== Availablity message and product doesn't exist shows at the same time. Steps to reproduce the issue: ============================= - Create a storable product with 2 attributes each having 2 values - Set show available qty below 5 units - Remove one of the created variants - Set qty for all the other variants to 3 (anything less than 5 and > 0) - Go to website page of the product and switch between variants - You can see that when we go to the deleted variant it shows both messaged. "Deoesn't exist" message for the current variant and stock message from the old variant that we switched from Origin of the issue: ==================== When the product doesn't exist we don't update the availability message neither we hide it. Solution: ========= We can use the same trick to show/hide the not available message but in the opposite logic to show/hide the availability message. opw-3875941 Forward-Port-Of: odoo/odoo#163979
Before this commit: l10nEGDrivers errors can be ambiguous as we only receive the error string. After this commit: The full traceback alongside an error message is logged in the IoT opw-3915843 Forward-Port-Of: odoo/odoo#165726
Original PR description
Before this commit: l10nEGDrivers errors can be ambiguous as we only receive the error string. After this commit: The full traceback alongside an error message is logged in the IoT opw-3915843 Forward-Port-Of: odoo/odoo#165726
Purpose ======= Fix the traceback appearing when clicking on the print button for a survey participation. Specifications ============== When preparing the print page statistics, the number of correct/skipped/partial/incorrect answers are computed based on the user input lines. The issue is that when the user input lines are retrieved, the comments are also taken into account. So when the user input lines for a simple choice question are accessed, a traceback appears as we got 2 input lin
Original PR description
Purpose ======= Fix the traceback appearing when clicking on the print button for a survey participation. Specifications ============== When preparing the print page statistics, the number of correct/skipped/partial/incorrect answers are computed based on the user input lines. The issue is that when the user input lines are retrieved, the comments are also taken into account. So when the user input lines for a simple choice question are accessed, a traceback appears as we got 2 input lines (the simple choice answer and the comment) where we expected only 1. Fixing the issue by removing from the considered user input lines the ones related to comments if they're not considered as being an answer. (the comment_count_as_answer field on the question is False). related PR: odoo/odoo#120629 Task-3893199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163346
Users can create menu items whose URL contain special characters (e.g. spaces, apostrophes, etc.). This is a legitimate use, as menus can for instance redirect towards uploaded files whose name may include such characters. However, when the URL doesn't exist, we land on a 404 page. If we then create the page through the "Create Page" button, special characters are slugified for the new page. At that point, we need to update the menu's URL accordingly. Steps to reproduce: 1. Create a Menu "T
Original PR description
Users can create menu items whose URL contain special characters (e.g. spaces, apostrophes, etc.). This is a legitimate use, as menus can for instance redirect towards uploaded files whose name may include such characters. However, when the URL doesn't exist, we land on a 404 page. If we then create the page through the "Create Page" button, special characters are slugified for the new page. At that point, we need to update the menu's URL accordingly. Steps to reproduce: 1. Create a Menu "Test A" 2. Add a URL with a space "/test a" 3. Save it 4. Go to the website, and click on the menu "Test A" (it opens the URL "/test%20a", which lands on a 404 page) 6. Click on "Create Page" (the created page uses the URL "/test-a") 7. Save it 8. Click again on the menu "Test A" => You land on the same 404 as before, on "/test%20a". opw-3896659 Forward-Port-Of: odoo/odoo#165602 Forward-Port-Of: odoo/odoo#165408
Steps to reproduce: - Install `website_hr_recruitment` - For one of the job listing add a job location without specifying a city - For another job listing add a job location with a city - Go to `/jobs` url Issues: Since one of the record doesn't have a city specified `record[city]` is False. This resulted in a traceback in the `sorted` call as we were comparing string to boolean. opw-3911415 Forward-Port-Of: odoo/odoo#165094
Original PR description
Steps to reproduce: - Install `website_hr_recruitment` - For one of the job listing add a job location without specifying a city - For another job listing add a job location with a city - Go to `/jobs` url Issues: Since one of the record doesn't have a city specified `record[city]` is False. This resulted in a traceback in the `sorted` call as we were comparing string to boolean. opw-3911415 Forward-Port-Of: odoo/odoo#165094
Steps to reproduce: - Create 3 warehouses A, B and C - Open the form of warehouse C - Select warehouse A as resupply warehouse and save. - Select warehouse B as resupply warehouse as well and save. Issue: The active resupply routes don't match the one selected in the warehouse form. Following #140644, the default behavior of the `many2many_checkboxes` widget changed. Instead of returning a SET command with all the currently linked models, it now returns a list of LINK/UNLINK commands
Original PR description
Steps to reproduce: - Create 3 warehouses A, B and C - Open the form of warehouse C - Select warehouse A as resupply warehouse and save. - Select warehouse B as resupply warehouse as well and save. Issue: The active resupply routes don't match the one selected in the warehouse form. Following #140644, the default behavior of the `many2many_checkboxes` widget changed. Instead of returning a SET command with all the currently linked models, it now returns a list of LINK/UNLINK commands containing the changes. The warehouse `write()` was still processing them as a SET command, leading to inconsistencies between the active routes and the form. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165126
Before this commit: =========================== The "Flexible Pricelist" setting is hidden during Kiosk configuration. After this commit: =========================== The "Flexible Pricelist" setting is visible during Kiosk configuration. task-3693379 Forward-Port-Of: odoo/odoo#159876
Original PR description
Before this commit: =========================== The "Flexible Pricelist" setting is hidden during Kiosk configuration. After this commit: =========================== The "Flexible Pricelist" setting is visible during Kiosk configuration. task-3693379 Forward-Port-Of: odoo/odoo#159876
Current behavior: --- Colombian phone numbers starting with 324 are invalid. Steps to reproduce: --- parsed = phonenumbers.parse('324 1234567', 'CO') is_valid = phonenumbers.is_valid_number(parsed) is_valid == False Cause of the issue: --- Old versions of phonenumbers (external library) are not up to date with the latest colombian phone system changes Fix: --- Monkey patched the library Similar as: https://github.com/odoo/odoo/commit/b7878038e0aca885aa174ccd74be9ffd4b393a89
Original PR description
Current behavior:
---
Colombian phone numbers starting with 324 are invalid.
Steps to reproduce:
---
parsed = phonenumbers.parse('324 1234567', 'CO')
is_valid = phonenumbers.is_valid_number(parsed)
is_valid == False
Cause of the issue:
---
Old versions of phonenumbers (external library) are not
up to date with the latest colombian phone system changes
Fix:
---
Monkey patched the library
Similar as: https://github.com/odoo/odoo/commit/b7878038e0aca885aa174ccd74be9ffd4b393a89
opw-3870579
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#164848
Forward-Port-Of: odoo/odoo#164608This commit sets TDS (Tax Deducted at Source) and TCS (Tax Collected at Source) taxes to be active by default. task-3745995 Forward-Port-Of: odoo/odoo#165584
Original PR description
This commit sets TDS (Tax Deducted at Source) and TCS (Tax Collected at Source) taxes to be active by default. task-3745995 Forward-Port-Of: odoo/odoo#165584
Have a numeric field with a given value (e.g. 25.00). Edit it in a way the value is actually the same (e.g. 25). Click out. Before this commit, the value wasn't formatted as it should be, i.e. 25 was still displayed in the input, whereas it should display 25.00. This commit fixes the issue. Similar as https://github.com/odoo/odoo/pull/164953 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I h
Original PR description
Have a numeric field with a given value (e.g. 25.00). Edit it in a way the value is actually the same (e.g. 25). Click out. Before this commit, the value wasn't formatted as it should be, i.e. 25 was still displayed in the input, whereas it should display 25.00. This commit fixes the issue. Similar as https://github.com/odoo/odoo/pull/164953 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#165245
Previously, if an error occurred in a third-party script loaded from a different origin (eg: google analytics or scripts injected into the in-app browsers of Meta apps such as Facebook or Instagram), we would show an error dialog mentioning a "CORS" error with no details. There are three problems with this: first, this is not actually a CORS error. It is normal error, but in Chrome and Safari, the details of the error are unavailable inside of code from scripts hosted on a different origin, t
Original PR description
Previously, if an error occurred in a third-party script loaded from a different origin (eg: google analytics or scripts injected into the in-app browsers of Meta apps such as Facebook or Instagram),…
Previously, if an error occurred in a third-party script loaded from a different origin (eg: google analytics or scripts injected into the in-app browsers of Meta apps such as Facebook or Instagram), we would show an error dialog mentioning a "CORS" error with no details. There are three problems with this: first, this is not actually a CORS error. It is normal error, but in Chrome and Safari, the details of the error are unavailable inside of code from scripts hosted on a different origin, this unavailability is caused by CORS but the error is *not* a CORS error. The second problem is that we're showing these error dialogs to website visitors, who are both likely to be confused or frustrated by the error and very unlikely to report it. Lastly, because the error occurred in a third party script, it's likely code that is not even controlled by the Odoo instance in any way, which means that it oftentimes cannot be fixed in Odoo. In Firefox, the first point doesn't hold true, as Firefox does not hide the error details, but we still do not want to display an error dialog because of the two other points. This commit fixes this by simply not displaying these errors to visitors outside of debug mode. Actual visitors will not be in debug mode, but it could be useful to still show the error for people developing integrations with third-party libraries and scripts. The error dialog will still not contain much information in non-Firefox browsers, but we encourage the developer to look at the browser console for extra details. We still display these errors for logged-in users in all cases as users are much more likely to report such issues. Ideally, we may not want to show these errors to portal users either, but this information is not currently available in JS. opw-3857323 Forward-Port-Of: odoo/odoo#164695 Forward-Port-Of: odoo/odoo#163710
url_unquote was not used before 17.0 and not available in the noble monkeypatch, adding it for 17.0 -> master See https://runbot.odoo.com/runbot/build/62587153 Forward-Port-Of: odoo/odoo#165716
Original PR description
url_unquote was not used before 17.0 and not available in the noble monkeypatch, adding it for 17.0 -> master See https://runbot.odoo.com/runbot/build/62587153 Forward-Port-Of: odoo/odoo#165716
Before this commit: We restrict the user to delete GST Return Period record once the transaction has been initiated with the government server to maintain the consistency After this commit: In some special case i.e. for demo/bad record we might want to delete the GST Return Period with help of `force_delete` context it can be easily done in the special cases task-3930638 Forward-Port-Of: odoo/enterprise#62562
Original PR description
Before this commit: We restrict the user to delete GST Return Period record once the transaction has been initiated with the government server to maintain the consistency After this commit: In some special case i.e. for demo/bad record we might want to delete the GST Return Period with help of `force_delete` context it can be easily done in the special cases task-3930638 Forward-Port-Of: odoo/enterprise#62562
How to reproduce: - Enable "Storage Locations"; - Create a receipt with WH/Stock/Shelf 2 as the Destination Location; - Add a product with a barcode in this receipt and mark it as todo; - Open the created receipt in the Barcode app; - Scan the product; - Scan WH/Stock/Shelf 1 barcode. -> Current behavior: the product will be moved in Shelf 1, which is not a sublocation of Shelf 2 (the receipt's destination.) -> Expected behavior: a product cannot be moved in a destination who is not
Original PR description
How to reproduce: - Enable "Storage Locations"; - Create a receipt with WH/Stock/Shelf 2 as the Destination Location; - Add a product with a barcode in this receipt and mark it as todo; - Open the created receipt in the Barcode app; - Scan the product; - Scan WH/Stock/Shelf 1 barcode. -> Current behavior: the product will be moved in Shelf 1, which is not a sublocation of Shelf 2 (the receipt's destination.) -> Expected behavior: a product cannot be moved in a destination who is not (a part of) the picking's destination. [OPW-3895328](https://www.odoo.com/web#id=3895328&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#62357 Forward-Port-Of: odoo/enterprise#61560
The tests were failing because the TPAR report was working correctly beause all TPAR taxes were inactive. They need to be set active before using. Task# 3782518 Forward-Port-Of: odoo/enterprise#62697
Original PR description
The tests were failing because the TPAR report was working correctly beause all TPAR taxes were inactive. They need to be set active before using. Task# 3782518 Forward-Port-Of: odoo/enterprise#62697
## Analysis Since this commit https://github.com/odoo/enterprise/commit/16ba33cd77413948308dd09326021a14f52f51f6, a domain is used to filter which preparation displays should be refreshed when an order arrives. The current domain only filters the preparation displays that are linked to one or more PoS (`pos_config_ids`). If no specific PoS are linked to the preparation display, the domain will filter out the preparation display and the user will have to **manually refresh** the preparation di
Original PR description
## Analysis Since this commit https://github.com/odoo/enterprise/commit/16ba33cd77413948308dd09326021a14f52f51f6, a domain is used to filter which preparation displays should be refreshed when an order arrives. The current domain only filters the preparation displays that are linked to one or more PoS (`pos_config_ids`). If no specific PoS are linked to the preparation display, the domain will filter out the preparation display and the user will have to **manually refresh** the preparation display to see a new order. ## Solution The domain should also check if a preparation display is linked to all PoS. ## References opw-3756416 Forward-Port-Of: odoo/enterprise#62430
When typing in the softphone's search bar, the search result doesn't appear immediately; the user has to press Enter to make it happen. This is because the input field uses the t-model directive with the trim modifier. The trim modifier silently switches the directive to lazy mode, meaning that the content of the field is updated whenever the onchange event is fired instead of oninput. This commit removes the trim modifier to fix the problem. opw-3890028 Forward-Port-Of: odoo/enterprise#6
Original PR description
When typing in the softphone's search bar, the search result doesn't appear immediately; the user has to press Enter to make it happen. This is because the input field uses the t-model directive with the trim modifier. The trim modifier silently switches the directive to lazy mode, meaning that the content of the field is updated whenever the onchange event is fired instead of oninput. This commit removes the trim modifier to fix the problem. opw-3890028 Forward-Port-Of: odoo/enterprise#62204 Forward-Port-Of: odoo/enterprise#62125
The SellerSupplierParty data was initially included for transport reason '13', but recent validations show it is only necessary for transport reasons '02' and '07', which we do not support. Removed these fields to prevent data redundancy and potential errors. Before: - Included SellerSupplierParty data for transport reason '13'. After: - Removed SellerSupplierParty data from DespatchAdvice template. This change ensures compliance with the latest validation rules and reduces unnecessar
Original PR description
The SellerSupplierParty data was initially included for transport reason '13', but recent validations show it is only necessary for transport reasons '02' and '07', which we do not support. Removed these fields to prevent data redundancy and potential errors. Before: - Included SellerSupplierParty data for transport reason '13'. After: - Removed SellerSupplierParty data from DespatchAdvice template. This change ensures compliance with the latest validation rules and reduces unnecessary XML data. Legal Reference:  https://cpe.sunat.gob.pe/sites/default/files/inline-files/ValidacionesGREv20221020_publicacion.xlsx Latam Task: https://latam-localizations.odoo.com/web#id=1203&menu_id=142&cids=1&action=188&model=project.task&view_type=form Forward-Port-Of: odoo/enterprise#62651
### Steps to reproduce the issue: 1. Go to _Planning > My Planning_ and switch to the Weekly Calendar view 2. Plan a new Event from 5.30 AM to 7 PM in the Calendar 3. When the creation Form opens, the Date does not reflect the slot you were creating - Also happens in Gantt view: 1. Make sure the company's schedule starts or ends between two hours (e.g.: 8.15 am) 2. Click on the '+' button of the corresponding cell in the Daily Gantt view 3. The Date will be cut to the start or e
Original PR description
### Steps to reproduce the issue: 1. Go to _Planning > My Planning_ and switch to the Weekly Calendar view 2. Plan a new Event from 5.30 AM to 7 PM in the Calendar 3. When the creation Form opens,…
### Steps to reproduce the issue: 1. Go to _Planning > My Planning_ and switch to the Weekly Calendar view 2. Plan a new Event from 5.30 AM to 7 PM in the Calendar 3. When the creation Form opens, the Date does not reflect the slot you were creating - Also happens in Gantt view: 1. Make sure the company's schedule starts or ends between two hours (e.g.: 8.15 am) 2. Click on the '+' button of the corresponding cell in the Daily Gantt view 3. The Date will be cut to the start or end of the schedule. ### Explanation: Before opening `planning.planning_view_form`, the client calls for `onchange` which will then call for `default_get` that will align `start_datetime` and `end_datetime` with the work hours of `res.company.resource_calendar_id` in every situation where no resource is specified. https://github.com/odoo/enterprise/blob/ff4e39a09399f46790c0ad45bc9f9af4e4cd44d1/planning/models/planning.py#L625-L635 ### Suggested fix: `start_datetime` and `end_datetime` should not change only in Weekly and Daily Calendar views and in Daily Gantt View. The key should not remain in the Context of the Action to avoid unintended behaviours, adding it in the Context of the Event instead. opw-3829635 Forward-Port-Of: odoo/enterprise#62601 Forward-Port-Of: odoo/enterprise#61152
Before this commit: - Select an image (WEBP format) along with other images. - The preview in the inspector is distorted. Reason: - When introducing the support for WEBP images in the following PR -- https://github.com/odoo/odoo/pull/85494, the upload of documents was not taken into account. - The current image processing ensures that the supported image formats are resized at the backend before being sent to the frontend. Fix: - The exact values of the `max-width` and `max-height` dr
Original PR description
Before this commit: - Select an image (WEBP format) along with other images. - The preview in the inspector is distorted. Reason: - When introducing the support for WEBP images in the following PR -- https://github.com/odoo/odoo/pull/85494, the upload of documents was not taken into account. - The current image processing ensures that the supported image formats are resized at the backend before being sent to the frontend. Fix: - The exact values of the `max-width` and `max-height` draw their inspiration from the following image resizing values in the `documents_inspector.xml` ref- https://github.com/odoo/enterprise/blob/saas-16.4/documents/static/src/views/inspector/documents_inspector.xml#L39 After this commit: - The WEBP image, along with the other image formats can now be previewed without breaking any alignment in the Inspector. Task-3749547 Forward-Port-Of: odoo/enterprise#62565 Forward-Port-Of: odoo/enterprise#59339
Before this commit, users were able to see one2many, many2many, and binary fields in the sortby dropdown menu in the map and list views of the studio. Steps to reproduce: - Project > Tasks > All Tasks. - Click on toggle studio and navigate to View tab in the sidebar. - In the sortby dropdown menu, all fields, including x2many and binary, were visible. Observed behavior: Users were able to select one2many, many2many, and binary fields for sorting via the studio sidebar in the map and
Original PR description
Before this commit, users were able to see one2many, many2many, and binary fields in the sortby dropdown menu in the map and list views of the studio. Steps to reproduce: - Project > Tasks > All Tasks. - Click on toggle studio and navigate to View tab in the sidebar. - In the sortby dropdown menu, all fields, including x2many and binary, were visible. Observed behavior: Users were able to select one2many, many2many, and binary fields for sorting via the studio sidebar in the map and list views. Expected behavior: One should not be able to sort by one2many, many2many, and binary fields in the map and list views via the studio. After this commit, users will not be able to see one2many, many2many, and binary fields in the sortby dropdown menu in the map and list views of the studio. Task-3790886 Forward-Port-Of: odoo/enterprise#62527 Forward-Port-Of: odoo/enterprise#59733
When taking a new car, the write on the controller did not update the employer cost properly in case the applicant or employee took extra holidays, to fix this we write the _get_benefit_values_wishlist_car_total_depreciated_cost with it's intended use Forward-Port-Of: odoo/enterprise#62538
Original PR description
When taking a new car, the write on the controller did not update the employer cost properly in case the applicant or employee took extra holidays, to fix this we write the _get_benefit_values_wishlist_car_total_depreciated_cost with it's intended use Forward-Port-Of: odoo/enterprise#62538
Steps to Reproduce: 1. Select a doc. 2. Replace it with another doc. 3. You can see the history of the inspector. 4. From the history tab, double-click on the restore button. 5. Delete the previewed doc from the history list. 6. Throws a Traceback. Issue: triggers asynchronous operation on "_onHistoryItemRestore", when clicked, rapid consecutive clicks could result in multiple asynchronous operations being initiated simultaneously, leading to race conditions or unexpected behavior.
Original PR description
Steps to Reproduce: 1. Select a doc. 2. Replace it with another doc. 3. You can see the history of the inspector. 4. From the history tab, double-click on the restore button. 5. Delete the previewed doc from the history list. 6. Throws a Traceback. Issue: triggers asynchronous operation on "_onHistoryItemRestore", when clicked, rapid consecutive clicks could result in multiple asynchronous operations being initiated simultaneously, leading to race conditions or unexpected behavior. Fix: No traceback will occur, registered only once on a button. Task:3843157 Forward-Port-Of: odoo/enterprise#62560 Forward-Port-Of: odoo/enterprise#60227
Before this commit, an error occurred when opening a product with an attribute set to 'Instantly Variants Creation Mode' and an option attribute. The issue was due to the 'Instantly' attributes not being loaded into the PoS, resulting in a missing attribute_id. opw-3850050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165196
Original PR description
Before this commit, an error occurred when opening a product with an attribute set to 'Instantly Variants Creation Mode' and an option attribute. The issue was due to the 'Instantly' attributes not being loaded into the PoS, resulting in a missing attribute_id. opw-3850050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165196