Wednesday, May 22, 2024
23 changes · saas-17.2
Enhancements to existing features
Point of Sale now plays a short beep when the camera barcode scanner successfully reads a barcode. This gives cashiers immediate confirmation that an item was scanned, helping reduce uncertainty and speed up checkout.
Original PR description
This commit adds an audio notification when the camera barcode scanner registers a barcode. Task: 3942503 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Shared project links now work for people opening them outside an existing session, such as in an incognito browser. This prevents an access error when the system counts project items, making project sharing more reliable.
Original PR description
Steps to reproduce: - Open the project kanban card. - Click "Share" and copy the link. - Open the link in an incognito window. Issue: - Access is not getting for search_count Solution: - Give the sudo access. task-3884334 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Create a [TEST] Product with: - Invoicing Policy: Prepaid/Fixed Price product - Create on Order: Project & Task - Unit of Measure: Days Create a Sales Order with [TEST] prod Add a timesheet line on the recorded hours Go in Timesheet > Reporting > By Project Add the measure Timesheet Revenues Issue: Revenues are much greater than the sale order line amount. This occurs because we don't keep into account the UoM in the computation opw-3864227 Forward-Port-Of: odoo/odoo#164181
Original PR description
Create a [TEST] Product with: - Invoicing Policy: Prepaid/Fixed Price product - Create on Order: Project & Task - Unit of Measure: Days Create a Sales Order with [TEST] prod Add a timesheet line on the recorded hours Go in Timesheet > Reporting > By Project Add the measure Timesheet Revenues Issue: Revenues are much greater than the sale order line amount. This occurs because we don't keep into account the UoM in the computation opw-3864227 Forward-Port-Of: odoo/odoo#164181
This update improves the reliability of automated testing tools and mock systems used around messaging, live chat, and web features. It helps developers catch issues more consistently and reduces the risk of hidden defects reaching users, with little direct impact on day-to-day business workflows.
Original PR description
[New PROOT16](https://github.com/odoo/odoo/pull/166311)
This fixes a template inheritance issue where moving elements could change how empty content was represented. It helps avoid unnecessary differences and potential display inconsistencies when applying Studio or template customizations.
Original PR description
When calling apply_inheritance_specs and moving a node (before after or inside), we merge the text content of the adjacents nodes. If the parent and target node both have no text, we should not set the text to an empty string. When a node has no text, it is serialized as follows: `<node/>` But if it has an empty string, it has the following representation: `<node></node>` In the linked PR, we now apply the studio inheritance manually, and since we use the resulting tree directly instead of parsing the result, the `remove_blank_text` option of the parser has no effect. This causes existing tests to show some difference. opw-3888345 opw-3924997
Currently there are 2 issues with the function used to compute `credit_to_invoice` on model 'res.partner' (`_compute_credit_to_invoice`): 1) On 17.0 a traceback has been reported. There were instances in which the `amount_to_invoice` was `None` and not `0` (to be looked at in a separate fix). In such a case the `None` value is passed to the `float` function and causes a traceback. 2) From a performance perspective it is unnecessary to aggregate all the `amount_to_invoice` values
Original PR description
Currently there are 2 issues with the function used to compute `credit_to_invoice` on model 'res.partner' (`_compute_credit_to_invoice`): 1) On 17.0 a traceback has been reported. There were…
Currently there are 2 issues with the function used to compute `credit_to_invoice` on model 'res.partner' (`_compute_credit_to_invoice`): 1) On 17.0 a traceback has been reported. There were instances in which the `amount_to_invoice` was `None` and not `0` (to be looked at in a separate fix). In such a case the `None` value is passed to the `float` function and causes a traceback. 2) From a performance perspective it is unnecessary to aggregate all the `amount_to_invoice` values into an array and then postprocess them in python. Effectively the only thing we do in the postprocess is sum all the values but ignore all non-postive values. Thus we can just ignore sales orders with `amount_to_invoice <= 0` and let the SQL / the database handle the summing. This way we avoid the overhead from passing around the array(s) (size proportional to the number of sales orders) and just pass around a single value. This commit introduces the changes mentioned in (2). These changes also solve (1): The additional condition in the domain leads to sales orders where `amount_to_invoice` is `None` being ignored. (SQL / the DB handles (1) for us now.) related PR introducing the changed lines of code: https://github.com/odoo/odoo/pull/162770 a comment about the issue in 17.0: https://github.com/odoo/odoo/commit/b5d02cc72543b36c7e5e620a3a579f15c88baed6#r141990142 Forward-Port-Of: odoo/odoo#166175 Forward-Port-Of: odoo/odoo#166087
Steps to reproduce the bug: - In Website edit mode. - Drag and drop a "Badge" snippet into the footer. - Bug: it is not possible to edit the text of the badge or change its icon. The problem occurs because the handles of the snippet overlay cover the entire surface of the snippet, and the pointer event is intercepted by these handles. Note that the fix does not need to be made before version 17 because, prior to that, the handles have a smaller height and therefore do not cause this b
Original PR description
Steps to reproduce the bug: - In Website edit mode. - Drag and drop a "Badge" snippet into the footer. - Bug: it is not possible to edit the text of the badge or change its icon. The problem occurs because the handles of the snippet overlay cover the entire surface of the snippet, and the pointer event is intercepted by these handles. Note that the fix does not need to be made before version 17 because, prior to that, the handles have a smaller height and therefore do not cause this bug. Their height was changed with this commit [1]. [1]: https://github.com/odoo/odoo/commit/70f723a9f78c406746f5409f6a89cbe93ad21580 task-3927962 Forward-Port-Of: odoo/odoo#165657
In the express checkout flow delivery methods with failed rate shipment stay still available as a choice for the users. With this commit only carriers with successful rate will be shown. opw-3861519 Forward-Port-Of: odoo/odoo#165260 Forward-Port-Of: odoo/odoo#161524
Original PR description
In the express checkout flow delivery methods with failed rate shipment stay still available as a choice for the users. With this commit only carriers with successful rate will be shown. opw-3861519 Forward-Port-Of: odoo/odoo#165260 Forward-Port-Of: odoo/odoo#161524
When there are a relatively high number of exclusions + a lot of combinations for a given product_template, `create_variant_ids` can become slow. The main bottlneck is the call to `_is_combination_possible_by_config`. More specifically, calling `attribute_lines.product_template_value_ids` and `self._get_own_attribute_exclusions` for each combination is pretty slow. To speed that up, this commit introduces a new method, `_filter_combinations_impossible_by_config`. This method accepts a sequen
Original PR description
When there are a relatively high number of exclusions + a lot of combinations for a given product_template, `create_variant_ids` can become slow. The main bottlneck is the call to…
When there are a relatively high number of exclusions + a lot of combinations for a given product_template, `create_variant_ids` can become slow. The main bottlneck is the call to `_is_combination_possible_by_config`. More specifically, calling `attribute_lines.product_template_value_ids` and `self._get_own_attribute_exclusions` for each combination is pretty slow. To speed that up, this commit introduces a new method, `_filter_combinations_impossible_by_config`. This method accepts a sequence of combinations and yield those that are valid w.r.t. the exclusions. Because values that only depends on self are computed once before looping through the combinations, this lead to a significant speedup. This method is a generator to avoid MemoryErrors, be able to raise a UserError after "creating" 1000 variants and be consistent with choices made in `_create_variant_ids`. https://github.com/odoo/odoo/blob/0042b9d3eece219d4e89fe9c6ecb9971a1f3bf12/addons/product/models/product_template.py#L710 #### speedup Customer saas-16.4 database with 378 templates, 3832 products, 44 product.attributes, 186 product.attribute.values, 79 product.template.attribute.lines, 484 product.template.attribute.values, 374 product.template.attribute.exclusions. No dynamic attributes. Timing to write on product.template, adding a new attribute value on a ProductTemplate Form increasing the number of combinations. | Combinations | Before PR | After PR | |:------------:|:----------------:|:--------:| | 4 | 219ms | 218ms | | 55 | 785ms | 440ms | | 216 | 1.36s | 592ms | | 1 944 | 28s | 809ms | | 33 048 | 5min30s | 3.78s | | 231 336 | +15min (timeout) | 12s | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164191 Forward-Port-Of: odoo/odoo#162239
If you try to retrieve the `amout_available_for_refund` of a recordset of `account.payment`, it raises a traceback because the search domain includes `self.id` where it should be on the record `payment`. Fixes #165537 Forward-Port-Of: odoo/odoo#165945
Original PR description
If you try to retrieve the `amout_available_for_refund` of a recordset of `account.payment`, it raises a traceback because the search domain includes `self.id` where it should be on the record `payment`. Fixes #165537 Forward-Port-Of: odoo/odoo#165945
Steps to repoduce: - Create an invoice - Add a discount - Post it - Send and print (to get the xml) - Upload the xml on https://face.gob.es/en/facturas/validar-visualizar-facturas Issue: You will get an error from the platform "Línea 111: Element 'DiscountRate': This element is not expected. Expected is ( DiscountReason )." Cause: The default is an empty string and will not be generated. Investigation indicates a delay in ticket arrivals (code from 2023). Presumably, the Spanish Go
Original PR description
Steps to repoduce: - Create an invoice - Add a discount - Post it - Send and print (to get the xml) - Upload the xml on https://face.gob.es/en/facturas/validar-visualizar-facturas Issue: You will get…
Steps to repoduce: - Create an invoice - Add a discount - Post it - Send and print (to get the xml) - Upload the xml on https://face.gob.es/en/facturas/validar-visualizar-facturas Issue: You will get an error from the platform "Línea 111: Element 'DiscountRate': This element is not expected. Expected is ( DiscountReason )." Cause: The default is an empty string and will not be generated. Investigation indicates a delay in ticket arrivals (code from 2023). Presumably, the Spanish Gobierno may have restricted its XML validation. Solution: Add a default value (the same for Charges just in case) We don't add a `t-if` since the value is always empty and the requirements of the Spanish governement only requires a string [0-2500 characters] `3.1.5.2.1.1. DiscountReason Reason why the discount or rebate is made. Y[1..1] TextMax2500Type string positions: 0-2500` sources: - https://www.facturae.gob.es/formato/Versiones%20anteriores/B)%20Versi%C3%B3n%203.0/Esquema_ingles_V3_0.pdf - https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx - https://www.facturae.gob.es/formato/Documents/EnglishFacturae3_0.pdf opw-3911313 Forward-Port-Of: odoo/odoo#165525 Forward-Port-Of: odoo/odoo#165258
The compute function _compute_sending_conditions needs date_from and date_to fields as its dependencies to compute whether or not to show the "Send" button on the ICP report SBR wizard. Without them, the field does not get properly recomptued, and the button isn't shown, unless the "Is Test" checkbox gets ticked by the user. Forward-Port-Of: odoo/enterprise#62876
Original PR description
The compute function _compute_sending_conditions needs date_from and date_to fields as its dependencies to compute whether or not to show the "Send" button on the ICP report SBR wizard. Without them, the field does not get properly recomptued, and the button isn't shown, unless the "Is Test" checkbox gets ticked by the user. Forward-Port-Of: odoo/enterprise#62876
…ec widget Steps to reproduce: - Create an invoice with a foreign currency of rate 1:3: 120 EUR = 40 USD - Create a statement line with a foreign currency of rate 1:2: 120 EUR = 60 USD - Reconcile them both using the bank reco widget: An exchange diff of 20 USD will be created. At this point, the invoice and the statement line are reconciled all together. The exchange difference is reconciled with the statement line (lowest rate). The point is both account.partial.reconcile are linke
Original PR description
…ec widget Steps to reproduce: - Create an invoice with a foreign currency of rate 1:3: 120 EUR = 40 USD - Create a statement line with a foreign currency of rate 1:2: 120 EUR = 60 USD - Reconcile…
…ec widget Steps to reproduce: - Create an invoice with a foreign currency of rate 1:3: 120 EUR = 40 USD - Create a statement line with a foreign currency of rate 1:2: 120 EUR = 60 USD - Reconcile them both using the bank reco widget: An exchange diff of 20 USD will be created. At this point, the invoice and the statement line are reconciled all together. The exchange difference is reconciled with the statement line (lowest rate). The point is both account.partial.reconcile are linked to the exchange diff. That's what will cause the problem describe below. When the invoice is reset to draft: 'button_draft' removes the reconciliation so the partial linking the invoice with the statement line is deleted. Since an exchange diff is attached to the account.partial.reconcile through the exchange_move_id field, we create a reversal for the exchange diff to neutralize its accounting items. During the creation of the reversal, we remove the reconciliation so the partial linking the exchange difference with the statement line is deleted. Since the exchange diff is wrongly attached to this partial too, again, the code tries to reverse the exchange difference. At the end, a double reversal of the exchange diff has been created. opw: 3869770 Forward-Port-Of: odoo/enterprise#62773 Forward-Port-Of: odoo/enterprise#62717
**Steps to reproduce:** - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE) - Activate another currency (e.g. USD) - In Accounting settings, run the "Automatic Currency Rates" feature ([MX] Bank of Mexico) - Add a different currency rate for USD for yesterday - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Currency: [USD] * Invoice Date: [yesterday] * Invoice Lines: - Product: [any product with UNS
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE) - Activate another currency (e.g. USD) - In Accounting settings, run the…
**Steps to reproduce:**
- Install Accounting and l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE)
- Activate another currency (e.g. USD)
- In Accounting settings, run the "Automatic Currency Rates" feature ([MX] Bank of Mexico)
- Add a different currency rate for USD for yesterday
- Create an invoice:
* Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
* Currency: [USD]
* Invoice Date: [yesterday]
* Invoice Lines:
- Product: [any product with UNSPSC Category set]
- Price: [any] - Taxes: [any]
- Confirm the invoice
- Generate CFDI via "Send & Print" button
- Request Cancel:
* Reason: 01- Invoice issued with errors (with related document)
- Create Replacement Invoice
**Issue:**
A UserError is raised while checking the balance of the replacement invoice because the total of debits and the total of credits are different.
**Cause:**
The lines for the replacement invoice are just copied, keeping the values of the original invoice lines for many fields (such as "balance", "discount_balance" and "tax_base_amount").
Product-type lines do not have "balance" set in the copied data. In this case, "balance" is computed by using the current currency rate when the replacement invoice is created, which is correct.
The other lines are populated with the copied "balances" that correspond to the previous currency rate, which is not correct.
This leads to a mix of balances linked to different currency rates.
These fields are in the invoice currency and should be computed with the current currency rate as the replacement invoice is created with the present day as invoice date.
**Solution:**
Remove non product-type lines from the copied data to force them to recompute with the current currency rate.
opw-3863010
opw-3902683
Forward-Port-Of: odoo/enterprise#62373This issue arises after having visited the "General Ledger" at least once. When clicking on the "General Ledger" part of the "The current balance in the General Ledger didn't match the balance of your last bank statement, leading to an unexplained difference of [...]" message in "Bank Reconciliation", options such as the currency unit weren't properly transferred. Steps to reproduce original issue: - Install `account_reports` - Go to: Accounting > Reporting > Audit Reports > General Le
Original PR description
This issue arises after having visited the "General Ledger" at least once. When clicking on the "General Ledger" part of the "The current balance in the General Ledger didn't match the balance of your last bank statement, leading to an unexplained difference of [...]" message in "Bank Reconciliation", options such as the currency unit weren't properly transferred. Steps to reproduce original issue: - Install `account_reports` - Go to: Accounting > Reporting > Audit Reports > General Ledger - Go back - Create, confirm & reconcile an invoice - Reset invoice to draft - In "Accounting", go to "Dashboard" - Click on the 3 vertical dots to the right of the "Bank" card - Click on "Reconciliation Report" - In "Options: Posted Entries Only", select "Include Draft Entries" - Click on "General Ledger" in the first yellow warning - Draft entries won't be included task-3928454 Forward-Port-Of: odoo/enterprise#62655
Task-id: 3631712 Forward-Port-Of: odoo/enterprise#62751 Forward-Port-Of: odoo/enterprise#52348
Original PR description
Task-id: 3631712 Forward-Port-Of: odoo/enterprise#62751 Forward-Port-Of: odoo/enterprise#52348
**Steps to reproduce:** 1) Open any view of any module. 2) Click on insert a link in the article from Favorites. 3) Now publish the article from the share panel. 4) Copy that link and open it from the public user. 5) Click on the embedded link. **Issue:** Nothing will happen on click of that embedded link. **Solution:** Redirect the public user to the login page and after logging in redirect the user to that view if they have access to that view. **Task**-3082042 Forward-Port-O
Original PR description
**Steps to reproduce:** 1) Open any view of any module. 2) Click on insert a link in the article from Favorites. 3) Now publish the article from the share panel. 4) Copy that link and open it from the public user. 5) Click on the embedded link. **Issue:** Nothing will happen on click of that embedded link. **Solution:** Redirect the public user to the login page and after logging in redirect the user to that view if they have access to that view. **Task**-3082042 Forward-Port-Of: odoo/enterprise#62674 Forward-Port-Of: odoo/enterprise#57346
When receiving a webhook to update for template quality it may crash with the following error: ``` ValueError: Wrong value for whatsapp.template.quality: 'unknown' ``` As indicated in the reference documentation [^1], whatsapp use the value `UNKOWN` whereas we're using `none` for `whatsapp.template` quality, so this commit convert it to the appropriate value. [^1]: https://developers.secure.facebook.com/docs/graph-api/reference/whats-app-business-account/message_templates/ Forward-Po
Original PR description
When receiving a webhook to update for template quality it may crash with the following error: ``` ValueError: Wrong value for whatsapp.template.quality: 'unknown' ``` As indicated in the reference documentation [^1], whatsapp use the value `UNKOWN` whereas we're using `none` for `whatsapp.template` quality, so this commit convert it to the appropriate value. [^1]: https://developers.secure.facebook.com/docs/graph-api/reference/whats-app-business-account/message_templates/ Forward-Port-Of: odoo/enterprise#62756
Steps to reproduce: - Configure Starshipit - Create a stock picking - Choose Starshipit as carrier - Validate the picking - Try multiple times to reproduce the error Current behaviour: - KeyError exception raised Expected behaviour: - Should not have any KeyError Explanation: Starshipit API sometimes will not return the total_shipping_price, therefore the carrier price become 0 and cannot proceed. To handle this case, we put the order detail fetching in background as wel
Original PR description
Steps to reproduce: - Configure Starshipit - Create a stock picking - Choose Starshipit as carrier - Validate the picking - Try multiple times to reproduce the error Current behaviour: - KeyError exception raised Expected behaviour: - Should not have any KeyError Explanation: Starshipit API sometimes will not return the total_shipping_price, therefore the carrier price become 0 and cannot proceed. To handle this case, we put the order detail fetching in background as welljust in case the API didn't return the total_shipping_price again. task-3887386 Forward-Port-Of: odoo/enterprise#61286
payment_method_code was in the view for the batch payment creation view. However, when you create batch payment the check printing module has a compute that was being triggered on all payments with the same payment method because the payment method's code was being written by the payment_method_code on this view. This would cause performance issues on some databases. Setting this to readonly causes the create to no longer use this payment_method_code value and subsquently no longer triggers t
Original PR description
payment_method_code was in the view for the batch payment creation view. However, when you create batch payment the check printing module has a compute that was being triggered on all payments with the same payment method because the payment method's code was being written by the payment_method_code on this view. This would cause performance issues on some databases. Setting this to readonly causes the create to no longer use this payment_method_code value and subsquently no longer triggers the recompute. opw-3848817 Forward-Port-Of: odoo/enterprise#62431 Forward-Port-Of: odoo/enterprise#61908
To reproduce: - Log-in Administrator - Go to Timesheet app - Switch to list view - Add 2 group by: * Date > Week * Date > Day - Switch to grid view After odoo/enterprise@28337b5ae971 that result in a crash (error dialog) saying that `day` is not valid aggregation methods. This commit ensure we remove all groupby on the column field (no only the first one). opw-3908383 Forward-Port-Of: odoo/enterprise#62381
Original PR description
To reproduce: - Log-in Administrator - Go to Timesheet app - Switch to list view - Add 2 group by: * Date > Week * Date > Day - Switch to grid view After odoo/enterprise@28337b5ae971 that result in a crash (error dialog) saying that `day` is not valid aggregation methods. This commit ensure we remove all groupby on the column field (no only the first one). opw-3908383 Forward-Port-Of: odoo/enterprise#62381
Versions -------- - 17.0+ Steps ----- 1. Go to timesheet grid view; 2. start a new timer for a project; 3. wait at least one minute; 4. leave view and come back; 5. press stop & start timer in quick succession; 6. if timer starts like normal, go back to step 1. Issue ----- Timer may display a negative value after first tick. Cause ----- 1. `onWillStart` begins; 2. it suspends for a RPC to get the server time; 3. render is canceled on resetting the timer; 4. `onWillDestro
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to timesheet grid view; 2. start a new timer for a project; 3. wait at least one minute; 4. leave view and come back; 5. press stop & start timer in quick succession; 6. if timer starts like normal, go back to step 1. Issue ----- Timer may display a negative value after first tick. Cause ----- 1. `onWillStart` begins; 2. it suspends for a RPC to get the server time; 3. render is canceled on resetting the timer; 4. `onWillDestroy` is called; 5. timer isn't canceled because it hasn't started yet; 6. `onWillStart` continues; 7. a timer is added for a destroyed component. Solution -------- Use Owl's `status` function to ensure the component hasn't been destroyed before adding a timer. opw-3815398 Forward-Port-Of: odoo/enterprise#62110
**Steps** - Install Field Service and Helpdesk - Create a ticket for a customer. Add a field service task. A link will be sent to the customer via mail (visible in chatter). ** 403 for the customer if not logged in when clicking the link ** **Issue** Access rights issue here https://github.com/odoo/enterprise/blob/4f44fcf5761ca5499ede148e2e49363e3c8f80bc/helpdesk_fsm/controllers/portal.py#L34 **Fix** Don't show the "Tasks" link if the user doesn't have access rights to them. opw-39
Original PR description
**Steps** - Install Field Service and Helpdesk - Create a ticket for a customer. Add a field service task. A link will be sent to the customer via mail (visible in chatter). ** 403 for the customer if not logged in when clicking the link ** **Issue** Access rights issue here https://github.com/odoo/enterprise/blob/4f44fcf5761ca5499ede148e2e49363e3c8f80bc/helpdesk_fsm/controllers/portal.py#L34 **Fix** Don't show the "Tasks" link if the user doesn't have access rights to them. opw-3911444 Forward-Port-Of: odoo/enterprise#62087