Monday, June 17, 2024
25 changes · saas-17.1
Resolved issues and error corrections
Long skill labels in the avatar popover are now clipped correctly instead of spilling outside the card. This keeps profile popovers readable and visually tidy for users when longer skill names are shown.
Original PR description
This PR fixes an issue introduced in Commit[1] about the avatar card popover overflowing in certain scenarios. Since saas-17.1, we allow users to add skills within the avatar card popover. Allowing the card to display such long labels introduced an issue about long labels overflowing outside the popover, due to a missing `overflow-hidden-class`. To prevent such a behaviour, we add an `overflow-hidden` class to the popover. task-3924641 Commit[1] : dba8528 Backport of : https://github.com/odoo/odoo/pull/165172
Miscellaneous changes
xlrd 2.0 removed xlsx support, and that's the version on Noble. So xlsx (the modern excel format) can't be imported on Noble. Aside from the error message being confusing (it says to install xlsx >= 1.0, which is already there) this would be fine, just no support for xlsx, except the only *export* formats are xlsx and csv, and xlsx is the default, and csv is kinda shit too. In fact when using the "Export All" quick action, the only thing you can get is xlsx. So losing xlsx support turns ou
Original PR description
xlrd 2.0 removed xlsx support, and that's the version on Noble. So xlsx (the modern excel format) can't be imported on Noble. Aside from the error message being confusing (it says to install xlsx >= 1.0, which is already there) this would be fine, just no support for xlsx, except the only *export* formats are xlsx and csv, and xlsx is the default, and csv is kinda shit too. In fact when using the "Export All" quick action, the only thing you can get is xlsx. So losing xlsx support turns out to be a concern. This can be resolved, kinda, by adding support for openpyxl. The API is pretty simple and similar to xlsx though not super well documented (especially when trying to do type dispatching). This here version seems to work with the (fairly limited) XLSX test case of base_import. Forward-Port-Of: odoo/odoo#169245
### Steps to reproduce: 1. Create a BOM with 2 operations: op 1 and 2 2. Create and confirm an MO for 10 units using that BOM. 3. Put the quantity to 10 then start and done op 1 4. Put the quantity to 2 then start and done op 2 5. Produce and create a backorder 6. Put the quantity to 4 then start and done op 2 7. Produce and create a backorder #### > instead of 4 units remaining in op 2 we have 4 units remaining in op 1 ### Cause of the issue: The operations of a productions (`mr
Original PR description
### Steps to reproduce: 1. Create a BOM with 2 operations: op 1 and 2 2. Create and confirm an MO for 10 units using that BOM. 3. Put the quantity to 10 then start and done op 1 4. Put the quantity…
### Steps to reproduce: 1. Create a BOM with 2 operations: op 1 and 2 2. Create and confirm an MO for 10 units using that BOM. 3. Put the quantity to 10 then start and done op 1 4. Put the quantity to 2 then start and done op 2 5. Produce and create a backorder 6. Put the quantity to 4 then start and done op 2 7. Produce and create a backorder #### > instead of 4 units remaining in op 2 we have 4 units remaining in op 1 ### Cause of the issue: The operations of a productions (`mrp.workorder`'s) are ordered by `leave_id`, `date_start` and then `id`: https://github.com/odoo/odoo/blob/26239b2d0bdbc2f06d50f7739d61c490248b65bb/addons/mrp/models/mrp_workorder.py#L14-L17 Since, in the first backorder, the workorder corresponding to op 1 is cancelled it has an empty `leave_id` and `date_start`. On the other hand, once the partial operation of op 2 has been completed its associated `date_start` is not empty anymore and the order of both operations is therefore swaped. However, when a backorder is created, the quantity of the workorders is set by relying on the order of operations (which is not the same with and without `leave_id`, `date_start`): https://github.com/odoo/odoo/blob/d826c3782d737fc1724887692b71b27999bf846d/addons/mrp/models/mrp_production.py#L1973-L1983 So that the data is set on the wrong line. opw-3880963 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166820
Steps to reproduce: - create a new db `--without-demo=True -i l10n_ar` - Load demo data Issue: Everything goes wild Cause: When we instantiate a database without demo data with l10n_ar, the res_partner(1) has the l10n_latam_identification_type_id field set to 'CUIT'. When loading demo data, a VAT number is assigned to res.partner(1)(*), which triggers a constraint error: https://github.com/odoo/odoo/blob/69e31db6ac90874ed6329599fca8f09709efd119/addons/l10n_ar/models/res_partner.py#L6
Original PR description
Steps to reproduce: - create a new db `--without-demo=True -i l10n_ar` - Load demo data Issue: Everything goes wild Cause: When we instantiate a database without demo data with l10n_ar, the…
Steps to reproduce: - create a new db `--without-demo=True -i l10n_ar` - Load demo data Issue: Everything goes wild Cause: When we instantiate a database without demo data with l10n_ar, the res_partner(1) has the l10n_latam_identification_type_id field set to 'CUIT'. When loading demo data, a VAT number is assigned to res.partner(1)(*), which triggers a constraint error: https://github.com/odoo/odoo/blob/69e31db6ac90874ed6329599fca8f09709efd119/addons/l10n_ar/models/res_partner.py#L60-L61 Since res.partner(1) has the CUIT identification type, its VAT will be checked for correctness here: https://github.com/odoo/odoo/blob/69e31db6ac90874ed6329599fca8f09709efd119/addons/l10n_ar/models/res_partner.py#L106 The dummy VAT added with this PR causes the constraint error: https://github.com/odoo/odoo/commit/a171597d1904de992bcf0e0f606b4c6a4b70b725 (*)By default (even without demo data) there is a "MyCompany" partner: https://github.com/odoo/odoo/blob/7e58f5c5ee772f2a6b4dff7ad3279dc9242ea2b3/odoo/addons/base/data/res_partner_data.xml#L4-L13 Solution: For 'main_partner' we don't set any vat number. Since some irregularities might happen, if the vat is necesarry for it, adding it to the specific module might be a better choice commit:https://github.com/odoo/odoo/commit/a171597d1904de992bcf0e0f606b4c6a4b70b725 opw-3907520 Forward-Port-Of: odoo/odoo#168976 Forward-Port-Of: odoo/odoo#167062
Description of the issue/feature this PR addresses: In the journal entry you can group by partner/date/journal/company, but in vendor bill or customer invoice you cannot. @qdp-odoo @oco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168339 Forward-Port-Of: odoo/odoo#161369
Original PR description
Description of the issue/feature this PR addresses: In the journal entry you can group by partner/date/journal/company, but in vendor bill or customer invoice you cannot. @qdp-odoo @oco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168339 Forward-Port-Of: odoo/odoo#161369
Current behaviour: --- When scheduled_date is not set, we get a traceback Steps to reproduce: --- 1. Create Product FNS storable 2. Create Product CMP storable 3. Create quant for 10 units of CMP 4. Set CMP tracking to 'Lot' and 'Use expiration date' to True 5. Create MO for 1 unit of FNS using 1 unit of CMP 6. Try to Confirm: Traceback Cause of the issue: --- Caused by: https://github.com/odoo/odoo/commit/f1d4a727a84672d974151f681e43768abd3ac7cc opw-3981689 --- I confirm
Original PR description
Current behaviour: --- When scheduled_date is not set, we get a traceback Steps to reproduce: --- 1. Create Product FNS storable 2. Create Product CMP storable 3. Create quant for 10 units of CMP 4. Set CMP tracking to 'Lot' and 'Use expiration date' to True 5. Create MO for 1 unit of FNS using 1 unit of CMP 6. Try to Confirm: Traceback Cause of the issue: --- Caused by: https://github.com/odoo/odoo/commit/f1d4a727a84672d974151f681e43768abd3ac7cc opw-3981689 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169052
## Issue: - The stock valuation for discounted purchase orders is incorrectly based on the original unit price instead of the price. ## Steps To Reproduce: - Create a storable product with AVCO costing method. - In its purchase tab set control policy "On ordered quantities". - Create RFQ for a product 10 qty with 10 unit price and add a 10% discount. - Create a vendor bill and confirm it. - Receive the product. - See the valuation, it will show 100 instead of 90. ## Solution: - I f
Original PR description
## Issue: - The stock valuation for discounted purchase orders is incorrectly based on the original unit price instead of the price. ## Steps To Reproduce: - Create a storable product with AVCO costing method. - In its purchase tab set control policy "On ordered quantities". - Create RFQ for a product 10 qty with 10 unit price and add a 10% discount. - Create a vendor bill and confirm it. - Receive the product. - See the valuation, it will show 100 instead of 90. ## Solution: - I fixed the issue by updating the `_get_price_unit` method to consider discounts when calculating the invoiced value. opw-3895448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168619
Before this fix, when grouping by a date filter that only had "false" value, the global filter matching was causing a traceback trying to split a non existant month/year value. This commit fixes this behavior by checking for "false" in date filter and setting the matching filter to "undefied" OPW: 3776544 OPW: 3952358 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169453
Original PR description
Before this fix, when grouping by a date filter that only had "false" value, the global filter matching was causing a traceback trying to split a non existant month/year value. This commit fixes this behavior by checking for "false" in date filter and setting the matching filter to "undefied" OPW: 3776544 OPW: 3952358 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169453
In this commit, we changed the way the addresses were displayed in accounting. https://github.com/odoo/odoo/commit/28fdcaabda9dc61b352e58e692bc5adf15a08a1e We now want the same behavior with the sale orders. task-3951205 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166877
Original PR description
In this commit, we changed the way the addresses were displayed in accounting. https://github.com/odoo/odoo/commit/28fdcaabda9dc61b352e58e692bc5adf15a08a1e We now want the same behavior with the sale orders. task-3951205 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166877
Display IoTBox connected devices on its display. Task: 3960101 Forward-Port-Of: odoo/odoo#168833
Original PR description
Display IoTBox connected devices on its display. Task: 3960101 Forward-Port-Of: odoo/odoo#168833
Back Porting commit - https://github.com/odoo/odoo/pull/147812/commits/5bd0d647094d00f93d73a4498e571e84a6317446 and https://github.com/odoo/odoo/pull/147812/commits/5c755e4148399d80717d0047c55a7833f7bdfdde Commit merged in PR - https://github.com/odoo/odoo/pull/147812 (in saas-17.3) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169224
Original PR description
Back Porting commit - https://github.com/odoo/odoo/pull/147812/commits/5bd0d647094d00f93d73a4498e571e84a6317446 and https://github.com/odoo/odoo/pull/147812/commits/5c755e4148399d80717d0047c55a7833f7bdfdde Commit merged in PR - https://github.com/odoo/odoo/pull/147812 (in saas-17.3) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169224
`to_recheck_leaves` stores every leave that is not yet taken into account by the "allocation_leaves_consumed" dictionary. now for some leave type, it's allocation contain False value as key of this `allocation_leaves_consumed` dictionary. because when leave_type with requires_allocation Is not yes then we pass leave type data with False as allocation. see: https://github.com/odoo/odoo/blob/7363d568df6e82119eed1cec55b3ae67a3816a1a/addons/hr_holidays/models/hr_employee.py#L565 and this wi
Original PR description
`to_recheck_leaves` stores every leave that is not yet taken into account by the "allocation_leaves_consumed" dictionary. now for some leave type, it's allocation contain False value as key of this…
`to_recheck_leaves` stores every leave that is not yet taken into account by the "allocation_leaves_consumed" dictionary. now for some leave type, it's allocation contain
False value as key of this `allocation_leaves_consumed` dictionary.
because when leave_type with requires_allocation
Is not yes then we pass leave type data with False as allocation.
see:
https://github.com/odoo/odoo/blob/7363d568df6e82119eed1cec55b3ae67a3816a1a/addons/hr_holidays/models/hr_employee.py#L565
and this will create issue when we try to calculate `latest_accrual_bonus` value by iterating consumed_content which call `_get_future_leaves_on` function but as we got allocation as False will get error :
```
File "/home/odoo/src/odoo/17.0/addons/hr_holidays/models/hr_employee.py", line 105, in _compute_allocation_remaining_display
leaves_taken = self._get_consumed_leaves(allocations.holiday_status_id)[0]
File "/home/odoo/src/odoo/17.0/addons/hr_holidays/models/hr_employee.py", line 582, in _get_consumed_leaves
latest_accrual_bonus += allocation._get_future_leaves_on(date_to_simulate)
AttributeError: 'bool' object has no attribute '_get_future_leaves_on'
```
Generated during upgrade.
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#169208Steps to reproduce: ------------------- - in settings, activate "Recurring Tasks" - create a recurring task with a dateline to today and a recurrence every "1 Days Until tomorrow" - save - change the state to "Done" - on the new created task, change the state to "Done" Issue: ------ Steps can be repeated indefinitely, creating an infinite number of recurring tasks with a specific end date for the recurrence. Cause: ------ There is no check with the `repeat_until` field when creat
Original PR description
Steps to reproduce: ------------------- - in settings, activate "Recurring Tasks" - create a recurring task with a dateline to today and a recurrence every "1 Days Until tomorrow" - save - change the state to "Done" - on the new created task, change the state to "Done" Issue: ------ Steps can be repeated indefinitely, creating an infinite number of recurring tasks with a specific end date for the recurrence. Cause: ------ There is no check with the `repeat_until` field when creating a recurring task. opw-3941688 Forward-Port-Of: odoo/odoo#168003
When triggering the onchange method of the reconciliation widget, the `_get_invoice_matching_amls_candidates` method is executed. If there are both numerical and exact tokens, it produces a query with 6 subqueries (a general query with 6 UNION ALL). This can become quite slow on database with lots of amls. Because for each of these 6 "subqueries" the FROM, JOIN and WHERE clauses are the same, we can extract all of them in a single CTE. Thanks to that the CTE is executed only once and each UNI
Original PR description
When triggering the onchange method of the reconciliation widget, the `_get_invoice_matching_amls_candidates` method is executed. If there are both numerical and exact tokens, it produces a query…
When triggering the onchange method of the reconciliation widget, the `_get_invoice_matching_amls_candidates` method is executed. If there are both numerical and exact tokens, it produces a query with 6 subqueries (a general query with 6 UNION ALL). This can become quite slow on database with lots of amls. Because for each of these 6 "subqueries" the FROM, JOIN and WHERE clauses are the same, we can extract all of them in a single CTE. Thanks to that the CTE is executed only once and each UNION ALL simply scans the CTE to get the correct columns + performs an additional filtering. This reduces the average execution of the query by a factor of 3-4 on hot-cache. Since the onchange is triggered each time we do something in the reconciliation widget, on average the cache is expected to be hot so the average speedup boils down to the hot-cache scenario. #### speedup Customer 17.0 database with 7M account_move_lines and 8000 accounts, the query execution, given a st_line and with both numerical and exact tokens: 7.5s -> 2.3s ##### dalibo [Standard](https://explain.dalibo.com/plan/0a6fe16h503614e0) vs [CTE](https://explain.dalibo.com/plan/495a777ef95d2980) There is also a speedup achievable with a partial multicolumn index but that's more of a case by case index. opw-3938995 Forward-Port-Of: odoo/enterprise#64433
Task-3924439 Forward-Port-Of: odoo/enterprise#64310
Original PR description
Task-3924439 Forward-Port-Of: odoo/enterprise#64310
opw-3935664 Forward-Port-Of: odoo/enterprise#63998
Original PR description
opw-3935664 Forward-Port-Of: odoo/enterprise#63998
Steps to reproduce: - Install `documents_project` - Go to one of the task and add a document - Close it Issues: In the project update the number of documents is shown however it is wrong, as it compute it by retrieving all the tasks without taking into account the state of the tasks. When clicking on the documents button you don't see documents linked to task that are closed, the desired behaviour is to see all of them and not take into account the state of the tasks. The behaviour
Original PR description
Steps to reproduce: - Install `documents_project` - Go to one of the task and add a document - Close it Issues: In the project update the number of documents is shown however it is wrong, as it compute it by retrieving all the tasks without taking into account the state of the tasks. When clicking on the documents button you don't see documents linked to task that are closed, the desired behaviour is to see all of them and not take into account the state of the tasks. The behaviour was due to the way the domain is set on the `task_ids` in the project model. https://github.com/odoo/odoo/blob/174cb193592f12c7f4167eb34642665778deb208/addons/project/models/project.py#L332-L333 Because of this when we retrieved the documents we didn't have all the tasks. https://github.com/odoo/enterprise/blob/0e98a5fdf5e4f32eeae769552284297b9233088c/documents_project/models/project_project.py#L204 opw-3921156 Forward-Port-Of: odoo/enterprise#64603
Create an asset Reverse an entry in the past => In depreciation schedule, if we take the current period, initial amount in Depreciation does not correspond to the cumulative depreciation in the Depreciation Board of the asset. The reversed entry are not taken into account, which was normal before, but now we take reversal entry into account so these should be too. opw-3890144 Forward-Port-Of: odoo/enterprise#64564 Forward-Port-Of: odoo/enterprise#63821
Original PR description
Create an asset Reverse an entry in the past => In depreciation schedule, if we take the current period, initial amount in Depreciation does not correspond to the cumulative depreciation in the Depreciation Board of the asset. The reversed entry are not taken into account, which was normal before, but now we take reversal entry into account so these should be too. opw-3890144 Forward-Port-Of: odoo/enterprise#64564 Forward-Port-Of: odoo/enterprise#63821
…efined Steps to reproduce: - Have a company A - Have a company B - Have a Product A defined only for Company A - Activate intercompany and automatic invoice/bills in both Company A and Company B - In Company A, create an invoice with Product A and Company B as the customer - Confirm Issue: An access error is raised Cause: Because of the new access rules introduced by branches, `account.move.line` have `_check_company_auto = True` https://github.com/odoo/odoo/blob/14db39961c445
Original PR description
…efined Steps to reproduce: - Have a company A - Have a company B - Have a Product A defined only for Company A - Activate intercompany and automatic invoice/bills in both Company A and Company B - In Company A, create an invoice with Product A and Company B as the customer - Confirm Issue: An access error is raised Cause: Because of the new access rules introduced by branches, `account.move.line` have `_check_company_auto = True` https://github.com/odoo/odoo/blob/14db39961c445a8243c2cc7af44132320a655594/addons/account/models/account_move_line.py#L23 Triggering the check at https://github.com/odoo/odoo/blob/e30853b9fbde28cd4b1dc9948e12fe2be0b03abc/odoo/models.py#L4324-L4325 Creating inconsistencies at https://github.com/odoo/odoo/blob/e30853b9fbde28cd4b1dc9948e12fe2be0b03abc/odoo/models.py#L3745-L3750 Solution: Set the product on the bill only it has no company_id set on it opw-3875354 Forward-Port-Of: odoo/enterprise#63086
Adds a new module for the PoS adaptation for Ecuador. task-3763326 Forward-Port-Of: odoo/enterprise#63087
Original PR description
Adds a new module for the PoS adaptation for Ecuador. task-3763326 Forward-Port-Of: odoo/enterprise#63087
Issue: It is possible to select the option "hide 0 lines" in the partner ledger. For one, it does not make sense as if a partner appears, it means that there are transactions. Even if the balance is set to 0, we should display the transactions. And then, the option simply does not work in partner ledger. Solution: Put as a default value "never" so it does not show up. opw-3981939 Forward-Port-Of: odoo/enterprise#64602
Original PR description
Issue: It is possible to select the option "hide 0 lines" in the partner ledger. For one, it does not make sense as if a partner appears, it means that there are transactions. Even if the balance is set to 0, we should display the transactions. And then, the option simply does not work in partner ledger. Solution: Put as a default value "never" so it does not show up. opw-3981939 Forward-Port-Of: odoo/enterprise#64602
A new field of type 'sale.subscription.pricing' was added to the 'product.template' model. This breaks product creation form for users who don't have sales permissions (e.g. stock managers). This commit fixes the issue by adding `groups` to the field. Forward-Port-Of: odoo/enterprise#60912
Original PR description
A new field of type 'sale.subscription.pricing' was added to the 'product.template' model. This breaks product creation form for users who don't have sales permissions (e.g. stock managers). This commit fixes the issue by adding `groups` to the field. Forward-Port-Of: odoo/enterprise#60912
A string domain is being used without being evaluated, leading to a traceback ### Steps to reproduce * Turn on debug mode * Go to the “Journal Entries” window action via Settings > Technical > Actions > Window Actions * Give any domain to the “Domain Value” field of the window action * Go to Tax Report via Accounting > Reporting > Statement Reports > Tax Report * Click the “Closing Entry” button * Click the “Post” button to post the closing entry you will run into the following tr
Original PR description
A string domain is being used without being evaluated, leading to a traceback ### Steps to reproduce * Turn on debug mode * Go to the “Journal Entries” window action via Settings > Technical > Actions > Window Actions * Give any domain to the “Domain Value” field of the window action * Go to Tax Report via Accounting > Reporting > Statement Reports > Tax Report * Click the “Closing Entry” button * Click the “Post” button to post the closing entry you will run into the following traceback: `IndexError: string index out of range` ### Fix The `account.action_move_journal_line` (Journal Entries window action) record was being reused for consistency. However, domains added to that record should not be propagated in this context. So in this case, the solution is to remove the domain from the returned action. opw-3903500 Forward-Port-Of: odoo/enterprise#64597
If the network is really slow, when you order a drink at the frontdesk. The visitor_id will not be set correctly, and you will have a traceback. Steps to reproduce: ------------------- * Install frontdesk * Enable "host selection" on the frontdesk station * Choose open kiosk * With the developper tool make the network slow, and use a mobile view * Click on check in, then try to order a drink > Observation: You get a traceback Why the fix: ------------ The `createVisitor` functi
Original PR description
If the network is really slow, when you order a drink at the frontdesk. The visitor_id will not be set correctly, and you will have a traceback. Steps to reproduce: ------------------- * Install frontdesk * Enable "host selection" on the frontdesk station * Choose open kiosk * With the developper tool make the network slow, and use a mobile view * Click on check in, then try to order a drink > Observation: You get a traceback Why the fix: ------------ The `createVisitor` function was not awaited during the setup of the page. But it is required to order the drink. opw-3889245 Forward-Port-Of: odoo/enterprise#62899
Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month. Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it. Task-3885769 Forward-Port-Of: odoo/enterprise#63488
Original PR description
Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month. Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it. Task-3885769 Forward-Port-Of: odoo/enterprise#63488