Wednesday, December 4, 2024
19 changes · saas-17.2
Miscellaneous changes
### Description When opening a report with a lot of data to display, getting some values can be very costly. In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`. To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls. ### Benchmark (made in 17.0) | N° of assets | Before | After | |------
Original PR description
### Description When opening a report with a lot of data to display, getting some values can be very costly. In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`. To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls. ### Benchmark (made in 17.0) | N° of assets | Before | After | |--------------|---------|--------| | 500 | 2 s | 1.55 s | | 7k | 20 s | 19 s | | 17k | 50 s | 41 s | ### Reference opw-4287192 Forward-Port-Of: odoo/enterprise#74085
When having Accounting installed with a company without chart template, we can not create a partner as bot `property_account_payable_id` and `property_account_receivable_id` are required. With ff54822738925d5b5b952520bbfbd4a76c876809 we add a non stored computed field to handle the `required` attribute on partner view. We use this field to make the `Accounting Entries` group invisble when it is not needed. opw-4323694 Forward-Port-Of: odoo/enterprise#75084 Forward-Port-Of: odoo/enterprise#749
Original PR description
When having Accounting installed with a company without chart template, we can not create a partner as bot `property_account_payable_id` and `property_account_receivable_id` are required. With ff54822738925d5b5b952520bbfbd4a76c876809 we add a non stored computed field to handle the `required` attribute on partner view. We use this field to make the `Accounting Entries` group invisble when it is not needed. opw-4323694 Forward-Port-Of: odoo/enterprise#75084 Forward-Port-Of: odoo/enterprise#74994
Forward-Port-Of: odoo/enterprise#74033
Original PR description
Forward-Port-Of: odoo/enterprise#74033
There is currently a problem of synchronization when using multiple tracking displays per pos config. Steps to reproduce: ------------------- * Configure 2 Preparation displays, 1 for the category food, the other for drinks. Link them both to the restaurant * Open the two preparation displays and their preparation status * In the restaurant, place an order for 1 food and 1 drink product * On one of the preparation display mark the food as ready > Observation: Both status screen will sh
Original PR description
There is currently a problem of synchronization when using multiple tracking displays per pos config. Steps to reproduce: ------------------- * Configure 2 Preparation displays, 1 for the category…
There is currently a problem of synchronization when using multiple tracking displays per pos config.
Steps to reproduce:
-------------------
* Configure 2 Preparation displays, 1 for the category food, the other for
drinks. Link them both to the restaurant
* Open the two preparation displays and their preparation status
* In the restaurant, place an order for 1 food and 1 drink product
* On one of the preparation display mark the food as ready
> Observation: Both status screen will show 'ready'
* Again on the preparation display mark the food as completed
> Observation: The order disappears from both screen.
Refreshing both status screen will not show the same state
Why the fix:
------------
The status screen should be seen as an ORDER status screen.
When placing an order 1 in the restaurant, the status screen should only show it as ready when all the pos preparation display orders linked to that order are ready.
This idea behind this fix is to get the status of the order as they are in the related preparation display and to modify it with regards of other status screen that are linked to the same pos config.
Let's discuss this part:
```python
for display in other_displays:
other_display_orders = display._get_pos_orders()
for order in other_display_orders['notDone']:
if order in current_display_orders['done']:
current_display_orders['done'].remove(order)
current_display_orders['notDone'].append(order)
```
`other_display_orders` represent the preparation display orders from other preparation displays.
`current_display_orders` represents the preparation display orders related to the preparation display we just used.
Here we basically ensure that we don't show a preparation order on the status screen as done if there is another preparation order linked to the same order which is not ready.
Scenario:
* `current_display_orders = {'done': ['101', '102'], 'notDone': ['103']} `
* `other_display_orders = {'done': ['101'], 'notDone': ['102', '103']}`
* result -> `current_display_orders = {'done': ['101'], 'notDone': ['103', '102']} `
The fix does not stop here as we also need to consider 2 scenarios:
* 1, we mark a preparation display order as complete in one preparation display.
* 2, we have preparation display orders that are not on the preparation display
but still linked to the same pos config as the status screen opened
In both scenarios, we will have some tracking numbers in `orders` which will not be found in `current_display_orders`.
```python
for order in other_display_orders['done'] + other_display_orders['notDone']:
if (
order not in current_display_orders['done'] + current_display_orders['notDone']
and self.env["pos_preparation_display.order"].search(
[('pos_order_id.tracking_number', 'ilike', order)]
).pos_config_id.id in self.pos_config_ids.ids
):
stage = 'done' if order in orders['done'] else 'notDone'
current_display_orders[stage].append(order)
```
This part of the fix will look at all the orders that are not present in `current_display_orders` and if the preparation order belong to a pos order made in the pos config of the current preparation display status then it will be added in the respective stage.
Scenario:
* `current_display_orders = {'done': ['101', '102'], 'notDone': ['103']} `
* `other_display_orders = {'done': ['101'], 'notDone': ['102', '103', '104']}`
* result -> `current_display_orders = {'done': ['101'], 'notDone': ['103', '102', '104']} `
We also apply this logic when loading the status screen for the first time/or refreshing it. We want to see the status of all orders from the set of pos configs.
opw-[4265987](https://www.odoo.com/web#id=4265987&view_type=form&model=project.task)
Forward-Port-Of: odoo/enterprise#74450**Steps to reproduce:** - Install Accounting - Create a Branch company without COA - Switch to the Branch company - Go to "Accounting / Accounting / Management / Assets" - Create an asset - Try to select an account for "Fixed Asset Account", "Depreciation Account" or "Expense Account" **Issue:** The list is empty. The accounts from the parent company should be proposed. opw-4368887 Forward-Port-Of: odoo/enterprise#75034
Original PR description
**Steps to reproduce:** - Install Accounting - Create a Branch company without COA - Switch to the Branch company - Go to "Accounting / Accounting / Management / Assets" - Create an asset - Try to select an account for "Fixed Asset Account", "Depreciation Account" or "Expense Account" **Issue:** The list is empty. The accounts from the parent company should be proposed. opw-4368887 Forward-Port-Of: odoo/enterprise#75034
Steps to reproduce ================== - Click on an invoice - Register a payment where the amount exceeds the invoice amount - Switch to another invoice with the same customer - Switch the active notebook to "Journal Items" - Click on "Outstanding credits" => You are redirected to the homepage Cause of the issue ================== Before 16.0, it used to be possible to click on a link where the target is inside another notebook. In that case, the notebook was switched before s
Original PR description
Steps to reproduce ================== - Click on an invoice - Register a payment where the amount exceeds the invoice amount - Switch to another invoice with the same customer - Switch the active notebook to "Journal Items" - Click on "Outstanding credits" => You are redirected to the homepage Cause of the issue ================== Before 16.0, it used to be possible to click on a link where the target is inside another notebook. In that case, the notebook was switched before scrolling to the anchor. With owl, it is no longer possible to query where the target is as the DOM inside other notebooks is not yet rendered before switching to them. Solution ======== If the anchor is visible, the link will work as intended, otherwise, the redirection to the homepage will be prevented opw-4344125 Forward-Port-Of: odoo/odoo#188479
Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure status back to the user, even for sucessful subsequent operations. This is particularly problematic, for example in the special case of BlackBox BE, where some points of sales have multiple checkouts using the same POS session and the same IoT Box + BlackBox. If at any point, a cashier sent an erroneo
Original PR description
Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure…
Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure status back to the user, even for sucessful subsequent operations. This is particularly problematic, for example in the special case of BlackBox BE, where some points of sales have multiple checkouts using the same POS session and the same IoT Box + BlackBox. If at any point, a cashier sent an erroneous message to the IoT Box or to the Blackbox, all checkouts would become blocked, with the only alternative being to reload the handlers or restart the IoT Box. Furthermore, the subsequent actions appearing as refused may have executed successfully. Which means there would be a mismatch between the data stored in Odoo (multiple failed transactions) and the data sent to the SPF (one failed transaction, then many successful ones). After this commit, the driver status is reset after being sent once. That way, when a new action is sent from the client to the IoT box, it's the status of the execution of this action and not the previous one that gets sent back to the client. opw-4313538 opw-4182434 opw-4293988 Forward-Port-Of: odoo/odoo#189062 Forward-Port-Of: odoo/odoo#186735
Use the Safari browser (MacOS or iOS): - Open a record (e.g. a SO); - Go to an external website (e.g. [www.google.com](http://www.google.com/)); - Return to the record using the browser's back button; Before this commit, the editable fields were not rendered correctly (in the SO example, the delivery address, the invoicing address were empty). This is because Safari used the `bfcache` to restore the page, but Odoo wasn't designed to be compatible with this cache. Now, when the `bfcac
Original PR description
Use the Safari browser (MacOS or iOS): - Open a record (e.g. a SO); - Go to an external website (e.g. [www.google.com](http://www.google.com/)); - Return to the record using the browser's back button; Before this commit, the editable fields were not rendered correctly (in the SO example, the delivery address, the invoicing address were empty). This is because Safari used the `bfcache` to restore the page, but Odoo wasn't designed to be compatible with this cache. Now, when the `bfcache` is used to restore a page, we reload the current page, to be sure that all the elements have been rendered correctly. Note that, a similar issue has been solved similarly in [1]. [1]: https://github.com/odoo/odoo/commit/fd0c2a18ac469239fe5d9c837f2fee8aa33f846b task-4281443 Forward-Port-Of: odoo/odoo#187854
Steps to reproduce: - Open the Notes App. - Type some content in the document. - On a new line, insert a table. - Resize the table so there is blank space on its right side. - Select some content and the entire table, ensuring the mouse pointer ends up in the blank space on the right side of the table. - Press `Ctrl + C` - A traceback error occurs. Description of the issue/feature this PR addresses: When selecting content with mouse and ending pointer in empty space to right of a
Original PR description
Steps to reproduce: - Open the Notes App. - Type some content in the document. - On a new line, insert a table. - Resize the table so there is blank space on its right side. - Select some content and the entire table, ensuring the mouse pointer ends up in the blank space on the right side of the table. - Press `Ctrl + C` - A traceback error occurs. Description of the issue/feature this PR addresses: When selecting content with mouse and ending pointer in empty space to right of a table, pressing Ctrl+C triggers `_onClipboardCopy`. It tries to clone the closest element of endContainer as a table, but if `closestElement` is not a table, it causes a traceback. Desired behavior after PR is merged: The traceback no longer occurs when copying a selection near a table. task-4357182 Forward-Port-Of: odoo/odoo#188758
Problem: When a BoM has a different UoM than the product, it will calculate the number of cycles needed for the work order using the product’s UoM. However, during the cycle time calculation, it uses the BoM’s UoM to calculate the number of cycles used in the previous work orders. It then uses this cycle number calculation to calculate the duration of each cycle. This can cause the expected duration for a work order to be calculated incorrectly. Purpose: Changing the cycle time’s calculation
Original PR description
Problem: When a BoM has a different UoM than the product, it will calculate the number of cycles needed for the work order using the product’s UoM. However, during the cycle time calculation, it uses…
Problem: When a BoM has a different UoM than the product, it will calculate the number of cycles needed for the work order using the product’s UoM. However, during the cycle time calculation, it uses the BoM’s UoM to calculate the number of cycles used in the previous work orders. It then uses this cycle number calculation to calculate the duration of each cycle. This can cause the expected duration for a work order to be calculated incorrectly. Purpose: Changing the cycle time’s calculation to use the product’s UoM will make it consistent with the number of cycles calculation on the work order. Steps to Reproduce on Runbot: 1. Create a new storable product. 2. Create a BoM for this product, but set the UoM to Dozens. 3. Navigate to the Operations tab and add an operation. 4. Set the Duration Computation to Compute based on tracked time. 5. Create a manufacturing order and confirm it. 6. Navigate to the Work Orders tab, set the Real Duration to 20:00, and mark it as done. 7. Create a new manufacturing order. 8. Navigate to the Work Orders tab and observe the Expected Duration is 240:00. opw-4239248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189445 Forward-Port-Of: odoo/odoo#187649
This change improves the invoice report by making the partner type label dynamic. It ensures that the label adapts correctly, enhancing flexibility and accuracy. **Description of the issue/feature this PR addresses:** The partner type label in the invoice report was previously static, which caused inconsistencies in cases where the label needed to reflect different partner types dynamically. **Current behavior before PR:** The partner type label in the invoice report is hardcoded, which
Original PR description
This change improves the invoice report by making the partner type label dynamic. It ensures that the label adapts correctly, enhancing flexibility and accuracy. **Description of the issue/feature this PR addresses:** The partner type label in the invoice report was previously static, which caused inconsistencies in cases where the label needed to reflect different partner types dynamically. **Current behavior before PR:** The partner type label in the invoice report is hardcoded, which does not adapt to specific partner configurations or custom scenarios. **Desired behavior after PR is merged:** The partner type label in the invoice report is dynamically computed based on the partner's type, ensuring it reflects the appropriate value for each invoice context. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189318 Forward-Port-Of: odoo/odoo#188696
Release notes: https://github.com/odoo/owl/releases/tag/v2.5.2 Forward-Port-Of: odoo/odoo#189410
Original PR description
Release notes: https://github.com/odoo/owl/releases/tag/v2.5.2 Forward-Port-Of: odoo/odoo#189410
When we have products on delivery on a sale order: - we update delivered qties - create invoice - we diminish delivered qties - create invoice -> should be a refund We want this last refund to be linked with the first invoice. As there is only one, there is no doubt that the two should be linked. However, we only do this for the localizations where the link is absolutely required, which is KE (enterprise) and ES Ticketbai for now. We also make sure in Ticketbai that the field is
Original PR description
When we have products on delivery on a sale order: - we update delivered qties - create invoice - we diminish delivered qties - create invoice -> should be a refund We want this last refund to be linked with the first invoice. As there is only one, there is no doubt that the two should be linked. However, we only do this for the localizations where the link is absolutely required, which is KE (enterprise) and ES Ticketbai for now. We also make sure in Ticketbai that the field is sufficiently editable. 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#187634
Steps: - have an industry module with a monetary field and don't specify its currency_field - use that field in a view of the module - Try installing the module via the source (not a module import) -> Validation error, the field is not present on the model This happens because we verify if the registry is loaded or not, but when installing from the source, we instantiate a new registry. Since we don't specify a currency_field, the _instantiate_attrs method would return nothing and the m
Original PR description
Steps: - have an industry module with a monetary field and don't specify its currency_field - use that field in a view of the module - Try installing the module via the source (not a module import) -> Validation error, the field is not present on the model This happens because we verify if the registry is loaded or not, but when installing from the source, we instantiate a new registry. Since we don't specify a currency_field, the _instantiate_attrs method would return nothing and the monetray field would not be registered on the model. The issue didn't appear when importing the module because the registry is loaded at that time, so we don't enter the condition. Forward-Port-Of: odoo/odoo#189443
Currently when multiple discounts are applied with loyalty rewards, the proportion applied to each line is not computed and lead to incoherant values for the next discount applied. Steps to reproduce: ------------------- * Create a promotion program rewarding 20% on the order for a minimum of 5 products * Create a promotion program rewarding 20% on a product category C1 for a minimum of 1 product * Create 2 products of 1$, one of them with the catgory C1 * Open shop session * Add 5 prod
Original PR description
Currently when multiple discounts are applied with loyalty rewards, the proportion applied to each line is not computed and lead to incoherant values for the next discount applied. Steps to…
Currently when multiple discounts are applied with loyalty rewards, the proportion applied to each line is not computed and lead to incoherant values for the next discount applied.
Steps to reproduce:
-------------------
* Create a promotion program rewarding 20% on the order for a minimum of 5 products
* Create a promotion program rewarding 20% on a product category C1 for a minimum of 1 product
* Create 2 products of 1$, one of them with the catgory C1
* Open shop session
* Add 5 products (not C1)
* Add 1 product (with C1)
> Observation: -1.2$ in discount for the 6 products and +0.08$ for the
products in category C1
Why the fix:
------------
After this fix https://github.com/odoo/odoo/commit/85047eca7c0f28e3b174ba166c0d7a1d9965b6b8 all discounts were taken into account when added to `linesToDiscount`.
Since it was now counted we had remove this part to not count the discount twice:
```python
if (lineReward.discount_mode === 'percent') {
const discount = lineReward.discount / 100;
for (const line of discountedLines) {
if (line.reward_id) {
continue;
}
if (lineReward.discount_applicability === 'cheapest') {
remainingAmountPerLine[line.cid] *= (1 - (discount / line.get_quantity()))
} else {
remainingAmountPerLine[line.cid] *= (1 - discount);
}
}
}
```
However when they were added to `linesToDiscount` the whole discount was taken into account, and not just the portion that applies on the order line.
We revert part of the previous fix but we modify the added part to only apply on rewards that have fixed amounts.
opw-4284817
Forward-Port-Of: odoo/odoo#188691
Forward-Port-Of: odoo/odoo#186775In odoo#130825, we prevented the import of records that are given an XMLid that belongs to an Odoo module, because such records would be unlinked when the module is updated. However, if the XMLid has noupdate set to True, then the record will not get unlinked anyway when the module is updated, so we should not block it from being creataed. This is useful because there are cases where during an import, `_load_records` is called again by the business code. For example, in 17.0+, when impo
Original PR description
In odoo#130825, we prevented the import of records that are given an XMLid that belongs to an Odoo module, because such records would be unlinked when the module is updated. However, if the XMLid has noupdate set to True, then the record will not get unlinked anyway when the module is updated, so we should not block it from being creataed. This is useful because there are cases where during an import, `_load_records` is called again by the business code. For example, in 17.0+, when importing a chart of accounts on a new company, the import of the opening balances causes a new 'Unaffected Earnings' account to be created via `_load_records`, with `noupdate=True`.[^1] [^1]: https://github.com/odoo/odoo/blob/a73e45ff9459ffdc0128327fac47962c6fe27af7/addons/account/models/company.py#L473 task-none runbot-108001 Forward-Port-Of: odoo/odoo#185030
When using ship later on a settle order, the qty_delivered on the original order would not take into account if the pos order has been delivered or not. Steps to reproduce: ------------------- * Install pos_sale module * Enable ship later * Create an order with any product * Open the PoS and settle the order * Validate the order and use ship later option > Observation: If you go on the sale order the qty_delivered will be 1 but the order has not been delivered yet. Why the fix: --
Original PR description
When using ship later on a settle order, the qty_delivered on the original order would not take into account if the pos order has been delivered or not. Steps to reproduce: ------------------- * Install pos_sale module * Enable ship later * Create an order with any product * Open the PoS and settle the order * Validate the order and use ship later option > Observation: If you go on the sale order the qty_delivered will be 1 but the order has not been delivered yet. Why the fix: ------------ We make sure that if the pos order is linked to a picking, the picking should be completely done to count the qty as delivered. opw-4199142 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189027 Forward-Port-Of: odoo/odoo#185456
Description of the issue/feature this PR addresses: - When working on this https://github.com/odoo/odoo/pull/186238 , few typos were discovered when populating data in demo database. - This pr fixes them - currently, the sample_ratio argument were not used in some methods [like this](https://github.com/odoo/odoo/blob/17.0/addons/mrp/populate/mrp.py#L363) instead values are hard coded. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa
Original PR description
Description of the issue/feature this PR addresses: - When working on this https://github.com/odoo/odoo/pull/186238 , few typos were discovered when populating data in demo database. - This pr fixes them - currently, the sample_ratio argument were not used in some methods [like this](https://github.com/odoo/odoo/blob/17.0/addons/mrp/populate/mrp.py#L363) instead values are hard coded. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187682
When having Accounting installed with a company without chart template, we can not create a partner as bot `property_account_payable_id` and `property_account_receivable_id` are required. With this commit we add a non stored computed field to handle the `required` attribute on the partner view. Note: a computed field with an `api.depends_context('company')` could no be used, because it wasn't not triggered at partner creation. It's a known ORM limitation. opw-4323694 Forward-Port-Of
Original PR description
When having Accounting installed with a company without chart template,
we can not create a partner as bot `property_account_payable_id` and
`property_account_receivable_id` are required.
With this commit we add a non stored computed field to handle the
`required` attribute on the partner view.
Note: a computed field with an `api.depends_context('company')` could no be used, because it wasn't not triggered at partner creation. It's a known ORM limitation.
opw-4323694
Forward-Port-Of: odoo/odoo#189487
Forward-Port-Of: odoo/odoo#189341