Friday, May 17, 2024
30 changes · saas-17.1
Resolved issues and error corrections
This fix removes outdated country restrictions from several localization-related module manifests that were missed in an earlier cleanup. It helps keep module availability rules consistent across Odoo, reducing configuration confusion for country-specific features.
Original PR description
This commits cleans up countries from manifest which were missed out by the following commit- https://github.com/odoo/odoo/commit/ac809d3c31cc29a31790aeef53f7a2a7bde4b9c8 task-3935204 Ent PR-https://github.com/odoo/enterprise/pull/62723 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The accounting dashboard now correctly recognizes when a purchase or sales journal already has entries. This prevents users from repeatedly seeing the first-time bill import wizard after they have already uploaded documents, reducing confusion in day-to-day accounting workflows.
Original PR description
To reproduce: - Connect as administrator - Create a new purchase journal "Vendor Bills Test" - Go to the accounting dashboard - Click on 'Upload' button on the "Vendor Bills Test" journal record => The 'Import your first bill' wizard open - Import a bill - Go back to the accounting dashboard - Click again on 'Upload' button on the "Vendor Bills Test" journal record => The 'Import your first bill' still open even if the journal has already some entries. After odoo/odoo@4074c675ee the `entries_count` are not returned anymore as part of kanban data for sale/purchase journals, so the view always show the button to open the 'Import your first bill' wizard. This commit re-add the `entries_count` in returned data (we arbitrarily use of count of 1 if there is some entries has its only used to determine what button is display on the kanban record) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale now correctly handles products that use instant variant attributes with selectable options. This prevents an error when staff open affected products, improving reliability during sales operations.
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
This fixes missed country settings in several localization-related module definitions. It helps ensure these country-specific features are correctly classified and available only where relevant, reducing configuration confusion.
Original PR description
This commits cleans up countries from manifest which were missed out by the following commit- https://github.com/odoo/enterprise/commit/148810637bf9e7a9cc53338f665ec612221a1ba2 task-3935204 Community PR- https://github.com/odoo/odoo/pull/165936
Miscellaneous changes
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
## 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
Forward-Port-Of: odoo/odoo#165727
Original PR description
Forward-Port-Of: odoo/odoo#165727
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#165195Users 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
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
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#164608l10n_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
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
Steps ----- 1. Install accounting and mrp_workorder_hr, activate analytic accounting in settings. 2. Select a work center and check "Requires Log In" 3. Create a manufacturing order and add a work order using the work center from the previous step. On the miscellaneous tab, add an analytic account. 4. Confirm the MO. 5. On the Work Orders tab, change the Real Duration to 60:00 6. Analytic account smart button > the gross margin is correctly set. 7. Either change the real duration to 0:
Original PR description
Steps ----- 1. Install accounting and mrp_workorder_hr, activate analytic accounting in settings. 2. Select a work center and check "Requires Log In" 3. Create a manufacturing order and add a work…
Steps ----- 1. Install accounting and mrp_workorder_hr, activate analytic accounting in settings. 2. Select a work center and check "Requires Log In" 3. Create a manufacturing order and add a work order using the work center from the previous step. On the miscellaneous tab, add an analytic account. 4. Confirm the MO. 5. On the Work Orders tab, change the Real Duration to 60:00 6. Analytic account smart button > the gross margin is correctly set. 7. Either change the real duration to 0:00 or open the work order and delete a line from the Time Tracking tab. Note: decreasing the Real Duration on the Manufacturing Order page will not lead to an issue as long as no time record is deleted on the work order (typically, when decreasing the time by a small amount). Issue ----- The gross margin still takes into account the employee's cost for the deleted time. Note that the workcenter's cost is removed from the gross margin as expected. Either by _create_or_update_analytic_entry in case the time of the work order is modified, or unlink if the work order is deleted. https://github.com/odoo/odoo/blob/16.0/addons/mrp_account/models/mrp_workorder.py Fix ----- When deleting a time record, modify the analytic account accordingly. We create an analytic entry with a previous_duration equal to the double of the time that is deleted. https://github.com/odoo/enterprise/blob/a992a3ae345478a148e536103c1585a4caa86113/mrp_workorder_hr_account/models/mrp_workorder.py#L16 That way, we create an analytic entry with a duration equal to the negative of the deleted time. This will add a positive amount to the analytic account. https://github.com/odoo/enterprise/blob/a992a3ae345478a148e536103c1585a4caa86113/mrp_workorder_hr_account/models/mrp_workorder.py#L21-L22 This makes the analytic account's gross margin consistent with the time worked. **opw-3759144** Forward-Port-Of: odoo/enterprise#61402 Forward-Port-Of: odoo/enterprise#58760
Backport of odoo/enterprise#59212 [OPW-3797344](https://www.odoo.com/web#id=3797344&cids=1&menu_id=4720&action=333&active_id=966&model=project.task&view_type=form) Original commit message: ======================== When the user quits a unfinished picking, the reservation on the move lines are lost. To avoid that, uncompleted moves will be split in such case. For example: - Assume we have a move of 0/15; - The user picks 4 qty (4/15) then exit the picking: => Before this commit, we
Original PR description
Backport of odoo/enterprise#59212 [OPW-3797344](https://www.odoo.com/web#id=3797344&cids=1&menu_id=4720&action=333&active_id=966&model=project.task&view_type=form) Original commit message:…
Backport of odoo/enterprise#59212 [OPW-3797344](https://www.odoo.com/web#id=3797344&cids=1&menu_id=4720&action=333&active_id=966&model=project.task&view_type=form) Original commit message: ======================== When the user quits a unfinished picking, the reservation on the move lines are lost. To avoid that, uncompleted moves will be split in such case. For example: - Assume we have a move of 0/15; - The user picks 4 qty (4/15) then exit the picking: => Before this commit, we're left with only one `stock.move.line` with 4 qty and already picked (not knowing what its reservation was since this information is on the `stock.move` and not on the `stock.move.line`.) => After this commit, the line's move will be split and we'll be left with two `stock.move` and thus `stock.move.line`: - One with 4 qty, already picked (4/4); - One with 11 qty, waiting to be picked (0/11); So, the user will always know what the remaining qty they still have to pick. Same is true for manufacturing orders since they use `stock.move` and `stock.move.line` too. task-3821067 Forward-Port-Of: odoo/enterprise#60452
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
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
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
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