Thursday, May 22, 2025
61 changes · saas-18.2
Resolved issues and error corrections
This fix prevents accounting test failures when localization demo data depends on other demo data that is not installed. The tests now only check localization demo data when the base accounting demo data was successfully loaded, improving reliability without changing business workflows.
Original PR description
l10n's contain demo data to be loaded, these are triggered from a function call inside the demo data file. account also has additional tests to verify the demo data loading, and reloading of demo data when the chart of accounts changes. but since the l10n demo data often relies on demo data from dependency modules, issue could arise when the dependent demo data is not available eg. `without-demo=True`. To circumvent this, these tests conditionally test the l10n demo data iff the account module has successfully installed demo data. Issue report on https://github.com/odoo/odoo/pull/197588#issuecomment-2667929919
This fixes an internal automated test that could fail unpredictably during nightly checks because it depended on the current time. By freezing time in the test, the team gets more stable quality checks and fewer false alarms during release validation.
Original PR description
Alays use a freeze_time when adding time-based tests. Runbot-223332
Users can now start configuring a server action without first selecting a model without triggering an error screen. The system checks that the required model information exists before using it, making setup smoother and preventing an avoidable crash.
Original PR description
Currently, an error produced on creating a new server action if the user selects a field in the **Action Details** without specifying a model. **Steps to Reproduce:** 1) Navigate to `Settings>Technical>Actions>Server Action`. 2) Click on `New Server Action`. 3) Select the field in Action Details without selecting the Model. 4) Observe the Error. **Error:** KeyError: False **Root Cause:** - The error occurs because the system attempts to access `self.model_id.model` at [1] without verifying it exists or not, which leads to a `KeyError`. [1]-https://github.com/odoo/odoo/blob/4fa26954bbb5f6a9c9679b7d44ec2261057da29e/odoo/addons/base/models/ir_actions.py#L820 **Solution:** - This commit prevents errors by adding checks to ensure model_id and model_id.model are present before accessing them. Sentry-6591474450
This fix prevents an error when processing Hong Kong payroll records for married employees who do not have a spouse name entered. It improves reliability by allowing optional spouse information to remain blank without interrupting payroll-related workflows.
Original PR description
When the status is married and no spouse name is provided, it raises a traceback. So we check that there is a spouse name before trying to upercase it, because the field is not required.
Miscellaneous changes
This reverts commit d413a9895742594d064084cd6dafbf1f2ec97221. This fix was decided after https://github.com/odoo/enterprise/pull/74127 that was trying to prevent invoicing users to see accounting features, when it seemed to be unwanted to have the two property accounts fields required while having no CoA installed. The issue is, now when having Accounting installed, we can create a user without having CoA as these two fields are not required anymore, but we end up with a error message when cre
Original PR description
This reverts commit d413a9895742594d064084cd6dafbf1f2ec97221. This fix was decided after https://github.com/odoo/enterprise/pull/74127 that was trying to prevent invoicing users to see accounting…
This reverts commit d413a9895742594d064084cd6dafbf1f2ec97221.
This fix was decided after https://github.com/odoo/enterprise/pull/74127
that was trying to prevent invoicing users to see accounting features,
when it seemed to be unwanted to have the two property accounts fields
required while having no CoA installed.
The issue is, now when having Accounting installed, we can create a user
without having CoA as these two fields are not required anymore, but
we end up with a error message when creating an invoice ('no CoA
installed') although we could be have added accounts manually instead
of installing a CoAi (which is not possible for invoicing user).
In this situation, we should be able to create a contact, and having these
fields required will force the user to create them.
Finally, it is ok to revert the full chain, as the original issue is
fixed by this commit https://github.com/odoo/enterprise/commit/68f6c1f9fd3ff6762c98e1a405ade035129efce0
Forward-Port-Of: odoo/odoo#210859
Forward-Port-Of: odoo/odoo#209832Issue ===== In the test `test_stock_landed_costs_lots`, there is this `assertRecordValues`: ```python self.assertRecordValues(lc.stock_valuation_layer_ids.sorted('product_id'), [ {'lot_id': lot_product_b[0].id, 'product_id': product2.id, 'stock_valuation_layer_id': og_p2_layers[0].id, 'quantity': 0, 'value': 1.5}, {'lot_id': lot_product_b[1].id, 'product_id': product2.id, 'stock_valuation_layer_id': og_p2_layers[1].id, 'quantity': 0, 'value': 1.5}, {'lot_id': lot_product_a[0
Original PR description
Issue ===== In the test `test_stock_landed_costs_lots`, there is this `assertRecordValues`: ```python self.assertRecordValues(lc.stock_valuation_layer_ids.sorted('product_id'), [ {'lot_id':…
Issue
=====
In the test `test_stock_landed_costs_lots`, there is this `assertRecordValues`:
```python
self.assertRecordValues(lc.stock_valuation_layer_ids.sorted('product_id'), [
{'lot_id': lot_product_b[0].id, 'product_id': product2.id, 'stock_valuation_layer_id': og_p2_layers[0].id, 'quantity': 0, 'value': 1.5},
{'lot_id': lot_product_b[1].id, 'product_id': product2.id, 'stock_valuation_layer_id': og_p2_layers[1].id, 'quantity': 0, 'value': 1.5},
{'lot_id': lot_product_a[0].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[0].id, 'quantity': 0, 'value': 1},
{'lot_id': lot_product_a[1].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[1].id, 'quantity': 0, 'value': 1},
{'lot_id': lot_product_a[2].id, 'product_id': self.product1.id, 'stock_valuation_layer_id': og_p1_layers[2].id, 'quantity': 0, 'value': 1},
])
```
This issue is sometime the records order is not the expected one.
Cause of the issue
==================
By doing `recordset.sorted('product_id')`, it will sort the records by compare their `product_id` records, using the python built-in `sorted`. The built-in `sorted` function simply check if record A is lower than record B, using the < operation. But in Odoo, comparing two recordsets is equal than comparing their ids as a `set`:
```python
def __lt__(self, other):
try:
if self._name == other._name:
return set(self._ids) < set(other._ids)
except AttributeError:
pass
return NotImplemented
```
In python, the comparaison between two sets compares is a set is a subset of the other one, which means than:
```python
{1} < {2} # is false
{1} < {2, 1} # is true
```
So, comparing SVLs by their product won't sort them by their product's id. If we want to do that, we have to explicitly do it by passing a function as the `sorted` `key` argument.
For more information, see:
-https://docs.python.org/3/library/functions.html#sorted -https://docs.python.org/3/reference/expressions.html#comparisons
runbot-build-error: 99086
Forward-Port-Of: odoo/odoo#210514When posting the vendor bill before validating the receipt, and the currency rate changed between the bill and receipt: - An Exchange diff account move would be created, and the Stock Input Account would not be balanced This is because the balance of the receipt would perfectly match the balance of the vendor bill, but not the Amount in currency. So, when we try to reconcile the 2 lines, because they are in the same currency, we are reconciling the Amount in Currency. Hence, the exchange rat
Original PR description
When posting the vendor bill before validating the receipt, and the currency rate changed between the bill and receipt: - An Exchange diff account move would be created, and the Stock Input Account…
When posting the vendor bill before validating the receipt, and the currency rate changed between the bill and receipt:
- An Exchange diff account move would be created, and the Stock Input Account would not be balanced
This is because the balance of the receipt would perfectly match the balance of the vendor bill, but not the Amount in currency. So, when we try to reconcile the 2 lines, because they are in the same currency, we are reconciling the Amount in Currency. Hence, the exchange rate journal entry is created, and a discrepancy in the Stock Input Account balance is introduced.
When the bill is posted before the receipt is validated, we want the receipt to have the value of the bill, and there is no reason to have only the balance or the amount in currency from the bill, so we can take both of them.
https://github.com/user-attachments/assets/c6dc5e72-8f5b-4c0f-99fa-c5e98a9574ff
## How to reproduce:
- Install stock_account,purchase
- Create product P:
* Valued in AVCO automated.
* Control Policy to 'On ordered quantities'
- Add currency rates for the EUR currency:
* 2.0 on the 2025-01-01
* 2.1 today
- Create and Confirm a new purchase for 1 unit of P and a price of 100 Euros
- Create the Bill:
* Set the bill's accounting date & bill date to the 2025-01-01
* Confirm the bill
=> Amount in Currency: 100 Euros - Balance: $50 USD - Rate used: 2.0
- Go back to the PO and receive the product.
=> Amount in Currency: 105 Euros - Balance: $50 USD - Rate used: 2.1
- Check the created Journal Entries:
=> Currency exchange rate difference: $2.38
=> (105 - 100) / 2.1
OPW-4631348
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#210538
Forward-Port-Of: odoo/odoo#209118Versions -------- - saas-17.4+ Steps ----- 1. Go to Website / Settings; 2. scroll to Shop - Checkout Process; 3. assign portal user as salesperson for online orders. Issue ----- Portal user shouldn't be allowed as a salesperson. Cause ----- The `salesperson_id` field of `res.config.settings` is set to be related to `website_id.salesperson_id`. The `salesperson_id` field for `website` does have a domain configured, but because the domain is a string, it does not get re-used for
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Go to Website / Settings; 2. scroll to Shop - Checkout Process; 3. assign portal user as salesperson for online orders. Issue ----- Portal user shouldn't be allowed as a salesperson. Cause ----- The `salesperson_id` field of `res.config.settings` is set to be related to `website_id.salesperson_id`. The `salesperson_id` field for `website` does have a domain configured, but because the domain is a string, it does not get re-used for related fields[^1]. [^1]: https://github.com/odoo/odoo/blob/87381d316/odoo/fields.py#L3009-L3021 Issue was introduced by commit 2f8c20d7d2385, which moved the domain from the `res.config.settings` field to the `website` field it relates to. Solution -------- Provide the domain as a list. opw-4801697 Forward-Port-Of: odoo/odoo#210612
Versions -------- - 17.0+ Steps ----- 1. Have a company partner with a credit limit; 2. add an employee partner to the company; 3. create a sales order for the employee; 4. have the total amount exceed the credit limit; 5. confirm order; 6. create a copy. Issue ----- The credit warning isn't updated with the new order's amount. Cause ----- The `credit` field gets computed on the `commercial_partner_id` while `credit_to_invoice` gets computed on the current partner. Solut
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a company partner with a credit limit; 2. add an employee partner to the company; 3. create a sales order for the employee; 4. have the total amount exceed the credit limit; 5. confirm order; 6. create a copy. Issue ----- The credit warning isn't updated with the new order's amount. Cause ----- The `credit` field gets computed on the `commercial_partner_id` while `credit_to_invoice` gets computed on the current partner. Solution -------- Compute the `credit_to_invoice` on the `commercial_partner_id`. Also, search sales orders on `partner_invoice_id` instead of `partner_id` to compute `credit_to_invoice`. opw-4654476 Forward-Port-Of: odoo/odoo#210698 Forward-Port-Of: odoo/odoo#210177
Currently because of the changes in ca35adf7412b132e37c22d09 both the test `test_increase_available_quantity_3` and `test_decrease_available_quantity_3` are always skipped, even with demo data. That's because `self.stock_location` points to a new location created in `setUpClass`. So no demo data quant can have this location_id as it cannot be referenced from a demo data file. However, "stock.stock_location_stock" is actually created in a data file, `stock_data.xml`. So we can revert back to u
Original PR description
Currently because of the changes in ca35adf7412b132e37c22d09 both the test `test_increase_available_quantity_3` and `test_decrease_available_quantity_3` are always skipped, even with demo data. That's because `self.stock_location` points to a new location created in `setUpClass`. So no demo data quant can have this location_id as it cannot be referenced from a demo data file. However, "stock.stock_location_stock" is actually created in a data file, `stock_data.xml`. So we can revert back to using `env.ref` instead of creating a new location. With that both tests are properly executed when demo data are installed while they are skipped without demo data. We're also creating the quants in case they are not found in the database so we ensure the test is always run. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204682
Description of the issue/feature this PR addresses: The "Quantities Available" field (shown in the product form vie smart button and the prognosis) can sometimes over-estimate the amounts actually available due to rounding. For example in the following case: Product-A is made via Kit-BoM from 2 Units of Product-B. There are 3 units of Product-B in stock. The precision of the "Unit" UoM, used for Product-A, is set to 1 (only integer amounts). The actual amount of units available is 1.5, this is
Original PR description
Description of the issue/feature this PR addresses: The "Quantities Available" field (shown in the product form vie smart button and the prognosis) can sometimes over-estimate the amounts actually…
Description of the issue/feature this PR addresses: The "Quantities Available" field (shown in the product form vie smart button and the prognosis) can sometimes over-estimate the amounts actually available due to rounding. For example in the following case: Product-A is made via Kit-BoM from 2 Units of Product-B. There are 3 units of Product-B in stock. The precision of the "Unit" UoM, used for Product-A, is set to 1 (only integer amounts). The actual amount of units available is 1.5, this is rounded as Half-Up to 2 Units. This is misleading, since only one unit of Product-A could be shipped. Current behavior before PR: For Kit-BoM Products, the quantities in _compute_quantities_dict() are all rounded with HALF-UP, potentially rounding up and claiming a higher availability than actually supported. Desired behavior after PR is merged: _compute_quantities_dict() rounds down to ensure it doesn't over-promise. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209317 Forward-Port-Of: odoo/odoo#208374
Before this commit, if a many2one field was loaded with its data, it would not get connected. For example, in the Chilean localization, the account_move is loaded when capturing an order, but it would not get linked, causing an error. opw-4479284 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197084 Forward-Port-Of: odoo/odoo#193616
Original PR description
Before this commit, if a many2one field was loaded with its data, it would not get connected. For example, in the Chilean localization, the account_move is loaded when capturing an order, but it would not get linked, causing an error. opw-4479284 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197084 Forward-Port-Of: odoo/odoo#193616
Before this commit, when an orderline was removed and the order failed to sync on the first attempt, the deletion command was already discarded. As a result, the order could be synced later with the previously deleted order line still present. Additionally, if a record is removed from another device but the change has not yet been synced, attempting to remove or modify that record can result in a "missing record" error. This commit resolves the issue by checking for the record's existence bef
Original PR description
Before this commit, when an orderline was removed and the order failed to sync on the first attempt, the deletion command was already discarded. As a result, the order could be synced later with the previously deleted order line still present. Additionally, if a record is removed from another device but the change has not yet been synced, attempting to remove or modify that record can result in a "missing record" error. This commit resolves the issue by checking for the record's existence before performing any write operations. opw-4707596 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206698
When manually changing the `discount_date` field to null in an invoice related to a customer with an Early price discount payment term, the customer will face a type error on the website when accessing their invoices. **Steps to reproduce:** * Install the accountant module * Create a new invoice for the current user as a customer (e.g., Mitchel Admin). * Set `2/7 Net 30` in payment terms and add any product. * Go to Journal Items and make Discount Date visible if not already visible. *
Original PR description
When manually changing the `discount_date` field to null in an invoice related to a customer with an Early price discount payment term, the customer will face a type error on the website when…
When manually changing the `discount_date` field to null in an invoice related to a customer with an Early price discount payment term, the customer will face a type error on the website when accessing their invoices. **Steps to reproduce:** * Install the accountant module * Create a new invoice for the current user as a customer (e.g., Mitchel Admin). * Set `2/7 Net 30` in payment terms and add any product. * Go to Journal Items and make Discount Date visible if not already visible. * Under the account field `121000 Account Receivable` remove the discount date and confirm the invoice. * Open portal View (/my) and click on Your Invoices >>> Error occurs. `TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.date'` **Solution:** We use if else blocks to check if `discount_date` exists for the `days_left calculation`; if it exists, do the calculation as usual if `discount_date` is in future. Otherwise, set `days_left` to zero and continue the function as usual. Sentry-6395559503 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205306
### Steps to reproduce: 1. Create a portal user. 2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view 3. Now, add the portal user as a follower on a task. 4. Change the state of a task to execute an automation rule. 5. Email will be received by a portal user but it will not be visible on the messaging history on the portal. ### Cause: This is happening because when running an automation rule that
Original PR description
### Steps to reproduce: 1. Create a portal user. 2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view 3. Now,…
### Steps to reproduce: 1. Create a portal user. 2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view 3. Now, add the portal user as a follower on a task. 4. Change the state of a task to execute an automation rule. 5. Email will be received by a portal user but it will not be visible on the messaging history on the portal. ### Cause: This is happening because when running an automation rule that will send an email we set the 'mail.message' state as System notification by default which leads that this mail will be sent normally to every follower of the record but will be only shown in the chat history for internal users not portal as we are just showing 'comment', 'incoming_email' and 'outgoing_email' messages. ### Fix: Checking if the server action that is being run is sending an email we will set the state of the 'mail.message' as 'auto_comment' -introduced in https://github.com/odoo/odoo/pull/94018/commits/d1dd307555ac78841384d1158de5a0a7787370db - and add 'auto_comment' to the domain of the field website_message_id which is for the messages shown to the portal user in his view P.S. LNA confirmed that we need to show it to the portal user. opw-4459754 Forward-Port-Of: odoo/odoo#210807 Forward-Port-Of: odoo/odoo#194401
runbot-error-181592 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#210535
Original PR description
runbot-error-181592 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#210535
PR #210777 Fix the issue for master (18.4) Currently the write access right is given to the inventory user. However some customer want to revoke this access in order to avoid user messing with their location configuration. But it's not possible since it will also raise an access error when validation an inventory adjustement. opw-4782515 Forward-Port-Of: odoo/odoo#210784
Original PR description
PR #210777 Fix the issue for master (18.4) Currently the write access right is given to the inventory user. However some customer want to revoke this access in order to avoid user messing with their location configuration. But it's not possible since it will also raise an access error when validation an inventory adjustement. opw-4782515 Forward-Port-Of: odoo/odoo#210784
Related to https://github.com/odoo/enterprise/pull/85952 Forward-Port-Of: odoo/odoo#210767
Original PR description
Related to https://github.com/odoo/enterprise/pull/85952 Forward-Port-Of: odoo/odoo#210767
In the kanban template there is a `row` container that is not wrapped into a `container` DIV, so it has negative margin and produce an overflow (horizontal scroll). This commit adds the `g-0` class on the `row` container. Steps to reproduce: * On Odoo on small screen * Go to the app "eLearning" * Try to scroll horizontally => BUG --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210825
Original PR description
In the kanban template there is a `row` container that is not wrapped into a `container` DIV, so it has negative margin and produce an overflow (horizontal scroll). This commit adds the `g-0` class on the `row` container. Steps to reproduce: * On Odoo on small screen * Go to the app "eLearning" * Try to scroll horizontally => BUG --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210825
*Behavior before this PR* When sending an Invoice to MyInvois, tracebacks could be raised if the `party_identification_vals` dictionary held values other than `id_attrs`. This was the case for the Customer Reference (`ref`), added in PR #206655 *Behavior after this PR* Invoices can be properly submitted to MyInvois, even with Customer References. opw-4807559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210768
Original PR description
*Behavior before this PR* When sending an Invoice to MyInvois, tracebacks could be raised if the `party_identification_vals` dictionary held values other than `id_attrs`. This was the case for the Customer Reference (`ref`), added in PR #206655 *Behavior after this PR* Invoices can be properly submitted to MyInvois, even with Customer References. opw-4807559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210768
This **PR** introduces manual input for lines 01, 04, 10, and 25 in the mod.111 report. The previous automatic calculation based on tax tags was unreliable and could produce inaccurate values, so manual entry ensures the data correctly reflects actual figures. **task**-4797773 Forward-Port-Of: odoo/odoo#210279
Original PR description
This **PR** introduces manual input for lines 01, 04, 10, and 25 in the mod.111 report. The previous automatic calculation based on tax tags was unreliable and could produce inaccurate values, so manual entry ensures the data correctly reflects actual figures. **task**-4797773 Forward-Port-Of: odoo/odoo#210279
- Fixes the error coming from using discounts in invoices: the node `AllowanceChargeReasonCode` was added while not accepted by the Turkish implementation, and the amounts might not respect the asked format in some cases. - Fixes the error coming from invoices using a different currency than the company one (TRY). Although the documentation says the node `PricingExchangeRate` is only needed "If the prices of goods or services on the invoice are shown in a currency other than the 'Docum
Original PR description
- Fixes the error coming from using discounts in invoices: the node `AllowanceChargeReasonCode` was added while not accepted by the Turkish implementation, and the amounts might not respect the asked format in some cases. - Fixes the error coming from invoices using a different currency than the company one (TRY). Although the documentation says the node `PricingExchangeRate` is only needed "If the prices of goods or services on the invoice are shown in a currency other than the 'Document Currency", and our file did indeed use only one currency at a time (either all TRY or all USD amounts, e.g.), the server was still refusing our file. - Limits the decimal precision to 2 for most amoutns, as requested by the nilvera format. - Use uppercase on invoice names when putting them in the xml. task-4356940 Forward-Port-Of: odoo/odoo#210622 Forward-Port-Of: odoo/odoo#205749
The rename in the chat window as well as in discuss is not working for livechat, this commit is fixing the issue. The name should now be visible by all operators but not to visitors task-4431259 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#209635 Forward-Port-Of: odoo/odoo#202306
Original PR description
The rename in the chat window as well as in discuss is not working for livechat, this commit is fixing the issue. The name should now be visible by all operators but not to visitors task-4431259 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#209635 Forward-Port-Of: odoo/odoo#202306
Steps to Reproduce : - Drag and drop text snippet / or select some text. - Apply the back-ground color to the text. - Click on the Animate button. - You will notice that the background got removed/misplaced. The issue was caused because the animated text is wrapped in an element with "display: inline-block". To fix the bug, we moved the element with the background color inside the wrapper of the animated text, instead of keeping it outside. This fix works as long as the animated text
Original PR description
Steps to Reproduce : - Drag and drop text snippet / or select some text. - Apply the back-ground color to the text. - Click on the Animate button. - You will notice that the background got removed/misplaced. The issue was caused because the animated text is wrapped in an element with "display: inline-block". To fix the bug, we moved the element with the background color inside the wrapper of the animated text, instead of keeping it outside. This fix works as long as the animated text is exactly the same as the one with the background color. If only a portion of the text with a background color is animated, the fix doesn’t work. That case was too complex to handle, and in any case, the most common user scenarios are now fixed. task-4690318 Forward-Port-Of: odoo/odoo#210953 Forward-Port-Of: odoo/odoo#206240
Description of the issue/feature this PR addresses: allow portal attendees to be synced by google calendar Current behavior before PR: There was an `AccessError` happening when: - One portal user was invited to more than one event. - At least one of them was going to be notified in the future. - Google cancelled the first of those. <details> ``` 2024-12-11 10:19:02,144 31 INFO odoo odoo.addons.base.models.ir_cron: Manually starting job `Google Calendar: sincronización`. 2024-12-1
Original PR description
Description of the issue/feature this PR addresses: allow portal attendees to be synced by google calendar Current behavior before PR: There was an `AccessError` happening when: - One portal user was…
Description of the issue/feature this PR addresses:
allow portal attendees to be synced by google calendar
Current behavior before PR:
There was an `AccessError` happening when:
- One portal user was invited to more than one event.
- At least one of them was going to be notified in the future.
- Google cancelled the first of those.
<details>
```
2024-12-11 10:19:02,144 31 INFO odoo odoo.addons.base.models.ir_cron: Manually starting job `Google Calendar: sincronización`.
2024-12-11 10:19:02,151 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(29,)
2024-12-11 10:19:02,539 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(15,)
2024-12-11 10:19:03,029 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(50,)
2024-12-11 10:19:03,414 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(40,)
2024-12-11 10:19:03,823 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(52,)
2024-12-11 10:19:04,219 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(10,)
2024-12-11 10:19:04,580 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(28,)
2024-12-11 10:19:04,936 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(2,)
2024-12-11 10:19:05,501 31 INFO odoo odoo.models.unlink: User #2 deleted mail.message records with IDs: [1055490, 1055487, 1055480, 1055478, 1055403]
2024-12-11 10:19:05,518 31 INFO odoo odoo.models.unlink: User #2 deleted calendar.event records with IDs: [2920874, 2920875, 2920880]
2024-12-11 10:19:05,520 31 INFO odoo odoo.models.unlink: User #2 deleted mail.followers records with IDs: [6232226, 6232227, 6232228, 6232229, 6232230, 6232231, 6232232, 6232233, 6232234, 6232235, 6232236, 6232237, 6232238, 6232239, 6232240, 6232241, 6232242, 6232243, 6232270, 6232271, 6232272, 6232283]
2024-12-11 10:19:05,544 31 INFO odoo odoo.addons.base.models.ir_model: Access Denied by ACLs for operation: read, uid: 65, model: calendar.alarm
2024-12-11 10:19:05,545 31 INFO odoo odoo.addons.base.models.ir_model: Access Denied by ACLs for operation: read, uid: 65, model: calendar.alarm
2024-12-11 10:19:05,545 31 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(2,)] Calendar Synchro - Exception : No puede ingresar a los registros 'Event Alarm' (calendar.alarm)
Se permite esta operación para los grupos siguientes:
- User types/Internal User
Póngase en contacto con su administrador para solicitar acceso si es necesario. !
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 997, in get
cache_value = field_cache[record._ids[0]]
KeyError: 8
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1161, in __get__
value = env.cache.get(record, self)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 1004, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.alarm(8,).alarm_type'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1187, in __get__
recs._fetch_field(self)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3210, in _fetch_field
self._read(fnames)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3220, in _read
self.check_access_rights('read')
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3480, in check_access_rights
return self.env['ir.model.access'].check(self._name, operation, raise_exception)
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_model.py", line 1924, in check
raise AccessError(msg)
odoo.exceptions.AccessError: No puede ingresar a los registros 'Event Alarm' (calendar.alarm)
Se permite esta operación para los grupos siguientes:
- User types/Internal User
Póngase en contacto con su administrador para solicitar acceso si es necesario.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 100, in _sync_all_google_calendar
user.with_user(user).sudo()._sync_google_calendar(google)
File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 79, in _sync_google_calendar
synced_events = self.env['calendar.event'].with_context(write_dates=events_write_dates)._sync_google2odoo(events - recurrences, default_reminders=default_reminders)
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 185, in _sync_google2odoo
cancelled_odoo._cancel()
File "/opt/odoo/auto/addons/google_calendar/models/calendar.py", line 326, in _cancel
super(Meeting, my_cancelled_records)._cancel()
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 152, in _cancel
self.unlink()
File "/opt/odoo/auto/addons/calendar/models/calendar_event.py", line 721, in unlink
self.env['calendar.alarm_manager']._notify_next_alarm(partner_ids)
File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 242, in _notify_next_alarm
notif = self.with_user(user).with_context(allowed_company_ids=user.company_ids.ids).get_next_notif()
File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 210, in get_next_notif
last_found = self.do_check_alarm_for_one_date(in_date_format, meeting, max_delta, time_limit, 'notification', after=partner.calendar_last_notif_ack)
File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 130, in do_check_alarm_for_one_date
if alarm.alarm_type != alarm_type:
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1189, in __get__
record._fetch_field(self)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3210, in _fetch_field
self._read(fnames)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3220, in _read
self.check_access_rights('read')
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3480, in check_access_rights
return self.env['ir.model.access'].check(self._name, operation, raise_exception)
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_model.py", line 1924, in check
raise AccessError(msg)
odoo.exceptions.AccessError: No puede ingresar a los registros 'Event Alarm' (calendar.alarm)
Se permite esta operación para los grupos siguientes:
- User types/Internal User
Póngase en contacto con su administrador para solicitar acceso si es necesario.
2024-12-11 10:19:05,547 31 INFO odoo odoo.addons.base.models.ir_cron: Job `Google Calendar: sincronización` done.
```
</details>
Desired behavior after PR is merged:
Google Sync works.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
@moduon MT-8345
cc @arj-odoo
Forward-Port-Of: odoo/odoo#199074
Forward-Port-Of: odoo/odoo#190356Before this PR, the name_search function would perform a search on products by injecting a list of ids in the domain instead of using a subquery. In cases where this list of ids is way too big, the search query becomes extremely slow. This PR uses a subquery instead in the domain to avoid this problem. Benchmarks: |Num. product_ids| Before PR | After PR | |---------------------|---------------|--------------| |28801| 65 s| <1 s| opw-4743566 --- I confirm I have signed the CLA
Original PR description
Before this PR, the name_search function would perform a search on products by injecting a list of ids in the domain instead of using a subquery. In cases where this list of ids is way too big, the search query becomes extremely slow. This PR uses a subquery instead in the domain to avoid this problem. Benchmarks: |Num. product_ids| Before PR | After PR | |---------------------|---------------|--------------| |28801| 65 s| <1 s| opw-4743566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210463 Forward-Port-Of: odoo/odoo#207953
This commit fixes the `disconnect during vacuum should ask for reload` test that was non-deterministic as it was triggering websocket reconnection too early, resulting in the wrong event being sent. fixes runbot-223185 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#210991
Original PR description
This commit fixes the `disconnect during vacuum should ask for reload` test that was non-deterministic as it was triggering websocket reconnection too early, resulting in the wrong event being sent. fixes runbot-223185 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#210991
This is a continuation of [this fix](https://github.com/odoo/odoo/commit/291518a7e7708690d183b9d1ca53c84d0c56ad90) following a feedback on its working state. --- Description of the issue this commit addresses: On purchase orders, it was decided that sections and notes would still be editable after the order has been confirmed so it would seem logic to be able to delete them too but at the moment, doing so raises an error. --- Desired behavior after this commit is merged: It is
Original PR description
This is a continuation of [this fix](https://github.com/odoo/odoo/commit/291518a7e7708690d183b9d1ca53c84d0c56ad90) following a feedback on its working state. --- Description of the issue this commit addresses: On purchase orders, it was decided that sections and notes would still be editable after the order has been confirmed so it would seem logic to be able to delete them too but at the moment, doing so raises an error. --- Desired behavior after this commit is merged: It is possible to delete a section or note line on a confirmed purchase order. --- opw-4744367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210760
Before this commit: - 'In Progress' payment states were shown with a green tag, which could misleadingly suggest that the payment process was complete. - 'Paid' payment states were shown with a grey tag, implying that some action might still be pending. After this commit: - 'In Progress' tags are now orange, signaling that further actions (such as batching or reconciliation) are still required. - 'Paid' tags are now green, indicating that the process is fully complete and no further user
Original PR description
Before this commit: - 'In Progress' payment states were shown with a green tag, which could misleadingly suggest that the payment process was complete. - 'Paid' payment states were shown with a grey tag, implying that some action might still be pending. After this commit: - 'In Progress' tags are now orange, signaling that further actions (such as batching or reconciliation) are still required. - 'Paid' tags are now green, indicating that the process is fully complete and no further user action is needed. Task Id: 4797098 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210071
Adding CLA Forward-Port-Of: odoo/odoo#210640 Forward-Port-Of: odoo/odoo#161944
Original PR description
Adding CLA Forward-Port-Of: odoo/odoo#210640 Forward-Port-Of: odoo/odoo#161944
**Issue:** When sharing a project, the project manager was accidentally removed from the project's followers **Steps to reproduce:** - create a new project. - in the project settings, click “Share Project”. - add a collaborator and share. The project manager disappears from the follower list, leaving only the new collaborator. opw-4764035 Forward-Port-Of: odoo/odoo#208753
Original PR description
**Issue:** When sharing a project, the project manager was accidentally removed from the project's followers **Steps to reproduce:** - create a new project. - in the project settings, click “Share Project”. - add a collaborator and share. The project manager disappears from the follower list, leaving only the new collaborator. opw-4764035 Forward-Port-Of: odoo/odoo#208753
When generating the self-invoice XML, the system incorrectly uses the invoice_date field, which reflects the supplier’s invoice date. However, for self-invoices in Italy, the date field (i.e., the accounting date) should be used instead. According to Italian regulations, self-invoices must be issued within 15 days of the transaction, and the invoice date must fall within the month the invoice is received. Using the supplier’s invoice date (e.g., April 2025) when the invoice is actually receiv
Original PR description
When generating the self-invoice XML, the system incorrectly uses the invoice_date field, which reflects the supplier’s invoice date. However, for self-invoices in Italy, the date field (i.e., the accounting date) should be used instead. According to Italian regulations, self-invoices must be issued within 15 days of the transaction, and the invoice date must fall within the month the invoice is received. Using the supplier’s invoice date (e.g., April 2025) when the invoice is actually received in May 2025 results in non-compliance. References Official: https://www.agenziaentrate.gov.it/portale/documents/20143/451259/Guida_compilazione-FE-Esterometro-V_1.9_2024-03-05.pdf/67fe4c2d-1174-e8de-f1ee-cea77b7f5203 , page 14 Extra: https://www.fiscoetasse.com/approfondimenti/16247-reverse-charge-interno-e-reverse-charge-esterno.html , entry 5  Forward-Port-Of: odoo/odoo#210342
**Current behaviour before PR:** Steps to reproduce: - Select a text, open color selector. - Switch to custom tab. - Apply any custom color. - Switch to any other tab without closing color selector. - Switch back to the custom color tab. - Selected default color in colorpicker is old one rather than applied one. **Desired behaviour after PR is merged:** Applied custom color should be selected by default when switching back to custom tab. task-4737027 --- I confirm I hav
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Select a text, open color selector. - Switch to custom tab. - Apply any custom color. - Switch to any other tab without closing color selector. - Switch back to the custom color tab. - Selected default color in colorpicker is old one rather than applied one. **Desired behaviour after PR is merged:** Applied custom color should be selected by default when switching back to custom tab. task-4737027 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210673 Forward-Port-Of: odoo/odoo#208963
Forward-Port-Of: odoo/odoo#210625
Original PR description
Forward-Port-Of: odoo/odoo#210625
Description of the issue/feature this PR addresses: The audit trail error is displayed eventhough the audit_trail is disabled for the company. Current behavior before PR: Attachments cannot be deleted with deactivated audit trail feature. Desired behavior after PR is merged: Only prevent deleting audit trail attachments, when audit trail setting is active. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr https://github.com/odoo/odoo/pull/207024 Forwa
Original PR description
Description of the issue/feature this PR addresses: The audit trail error is displayed eventhough the audit_trail is disabled for the company. Current behavior before PR: Attachments cannot be deleted with deactivated audit trail feature. Desired behavior after PR is merged: Only prevent deleting audit trail attachments, when audit trail setting is active. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr https://github.com/odoo/odoo/pull/207024 Forward-Port-Of: odoo/odoo#209024
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the
Original PR description
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display…
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the context preparation the preparation_display doesn't process the order. Fix: Make the call to syncAllOrders from preparation_display await. Move the call for sendOrderInPreparationUpdateLastChange after addPendingOrder since addPendingOrder adds the order again to the pending orders that causes the syncAllOrders from the floor_plan to make the sync_from_ui call again. Task-4812830 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#211099
When you settle a sale order that has a payment term, it was always ignored in the PoS. But it should only be ignored when the payment term has an early discount. Steps to reproduce: ------------------- * Create a sale order with a payment term that has no early discount * Go to the PoS and settle the sale order * Invoice and validate the order > Observation: In the backend, the sale order has the payment term applied on the invoice Why the fix: ------------ Some modules needs
Original PR description
When you settle a sale order that has a payment term, it was always ignored in the PoS. But it should only be ignored when the payment term has an early discount. Steps to reproduce: ------------------- * Create a sale order with a payment term that has no early discount * Go to the PoS and settle the sale order * Invoice and validate the order > Observation: In the backend, the sale order has the payment term applied on the invoice Why the fix: ------------ Some modules needs the invoice to have payment terms set (l10n_mx for example). But the PoS invoice was always ignoring it. We should only ignore it if the payment terms has an early discount. opw-4670234 Forward-Port-Of: odoo/odoo#210683 Forward-Port-Of: odoo/odoo#207231
Before this commit, mapping over `suggestedPartners['res.partner']` without checking caused runtime errors when the RPC returned no data. removed the mapping step and adding data to store as returned by server task-[4737958](https://www.odoo.com/odoo/project/1519/tasks/4737958) Forward-Port-Of: odoo/odoo#207743
Original PR description
Before this commit, mapping over `suggestedPartners['res.partner']` without checking caused runtime errors when the RPC returned no data. removed the mapping step and adding data to store as returned by server task-[4737958](https://www.odoo.com/odoo/project/1519/tasks/4737958) Forward-Port-Of: odoo/odoo#207743
Summary ----- When you generate an entry via the deferred revenue report, if the original journal item has an analytic distribution at x%, then the lines of the deferred entries have an analytic distribution at -x%. Steps to reproduce ----- 1. In Accounting > Settings, enable the analytic accounting and set the "Generate Revenue Entries" as "Manually & Grouped". 2. Create an invoice with an analytic distribution, a start date and an end date. 3. Generate an entry with the deferred reven
Original PR description
Summary ----- When you generate an entry via the deferred revenue report, if the original journal item has an analytic distribution at x%, then the lines of the deferred entries have an analytic distribution at -x%. Steps to reproduce ----- 1. In Accounting > Settings, enable the analytic accounting and set the "Generate Revenue Entries" as "Manually & Grouped". 2. Create an invoice with an analytic distribution, a start date and an end date. 3. Generate an entry with the deferred revenue report by selecting a period including the created invoice. 4. Observe the negative analytic distribution in the generated entries. opw-4502556 Forward-Port-Of: odoo/enterprise#85039 Forward-Port-Of: odoo/enterprise#82594
Currently you are able to select the button to settle customer account/ deposit money even though the config does not have access to a paylater payment method. This will never settle the customer account. Steps to reproduce: ------------------- * Remove the customer account payment method from the config * Open the pos session * Find a customer that has an amount due * Select "Settle due accounts" * Process > Observation: The customer account is never settled. Why the fix: --------
Original PR description
Currently you are able to select the button to settle customer account/ deposit money even though the config does not have access to a paylater payment method. This will never settle the customer account. Steps to reproduce: ------------------- * Remove the customer account payment method from the config * Open the pos session * Find a customer that has an amount due * Select "Settle due accounts" * Process > Observation: The customer account is never settled. Why the fix: ------------ If there is no payment method of type "pay_later" we should not show the button whose purpose is to use such payment method. opw-4488571 Forward-Port-Of: odoo/enterprise#85925 Forward-Port-Of: odoo/enterprise#83995
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the
Original PR description
Steps to reproduce: - Open a pos config configured with a belgian blackbox - Make an order that should be displayed on the preparation_display - The order doesn't appear on the preparation_display Cause: Since the call of syncAllOrders is not awaited in the preparation_display, the calls to the orm needed for the blackbox are executed and make the call of syncAllOrders from the submitOrder -> floorPlan -> .... -> unsetTable go first. since the second call to syncAllOrders doesn't have the context preparation the preparation_display doesn't process the order. Fix: Make the call to syncAllOrders from preparation_display await. Move the call for sendOrderInPreparationUpdateLastChange after addPendingOrder since addPendingOrder adds the order again to the pending orders that causes the syncAllOrders from the floor_plan to make the sync_from_ui call again. Task-4812830 Forward-Port-Of: odoo/enterprise#86119
This commit adds translations for Luxembourg Annual VAT Declaration in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 Forward-Port-Of: odoo/enterprise#86043 Forward-Port-Of: odoo/enterprise#85898
Original PR description
This commit adds translations for Luxembourg Annual VAT Declaration in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 Forward-Port-Of: odoo/enterprise#86043 Forward-Port-Of: odoo/enterprise#85898
Currently, entering only spaces in the Full Name field when signing in auto mode enables the sign button, allowing users to proceed without a valid name. Steps to reproduce: 1. Sign > Create a request 2. Attempt to sign in auto mode with only spaces in the Full Name field 3. Observe that the sign button becomes enabled Cause: The system does not checks for whitespace-only name Solution: Add a validation to disable the sign button if the trimmed name is empty in auto mode. opw-462
Original PR description
Currently, entering only spaces in the Full Name field when signing in auto mode enables the sign button, allowing users to proceed without a valid name. Steps to reproduce: 1. Sign > Create a request 2. Attempt to sign in auto mode with only spaces in the Full Name field 3. Observe that the sign button becomes enabled Cause: The system does not checks for whitespace-only name Solution: Add a validation to disable the sign button if the trimmed name is empty in auto mode. opw-4628577 Forward-Port-Of: odoo/enterprise#85996 Forward-Port-Of: odoo/enterprise#84613
This commit fixes an issue with the Facebook app and the management of pages. For Facebook to identify the user as able to manage a page, we need to provide another permission to the scope. The permission `business_management` is needed for the API to understand that the user is able to manage its pages. Thus we are adding it to the scope but as an optional permission. Some users may not have this permission set up for their own applications, thus we are adding the system parameter `social.
Original PR description
This commit fixes an issue with the Facebook app and the management of pages. For Facebook to identify the user as able to manage a page, we need to provide another permission to the scope. The permission `business_management` is needed for the API to understand that the user is able to manage its pages. Thus we are adding it to the scope but as an optional permission. Some users may not have this permission set up for their own applications, thus we are adding the system parameter `social.facebook_no_business_management`. This parameter blocks the addition of the permission to the scope if set to any value, if not set it adds the permission to the scope. task-4719790 Forward-Port-Of: odoo/enterprise#84032
…line are postpaid Forward-Port-Of: odoo/enterprise#85644 Forward-Port-Of: odoo/enterprise#73731
Original PR description
…line are postpaid Forward-Port-Of: odoo/enterprise#85644 Forward-Port-Of: odoo/enterprise#73731
Description ----------- Installing the `helpdesk_timesheet` module on databases with millions of `account.analytic.lines` would reach the default memory limit of 2 GiB due to excessive ORM caching. The main memory consumption came from `_check_no_link_task_and_ticket` and `_compute_helpdesk_ticket_id` methods loading large amounts of records into the ORM cache. This commit adds manual column initialization and optimizes constraints to reduce ORM cache memory usage. Reference ------
Original PR description
Description ----------- Installing the `helpdesk_timesheet` module on databases with millions of `account.analytic.lines` would reach the default memory limit of 2 GiB due to excessive ORM caching. The main memory consumption came from `_check_no_link_task_and_ticket` and `_compute_helpdesk_ticket_id` methods loading large amounts of records into the ORM cache. This commit adds manual column initialization and optimizes constraints to reduce ORM cache memory usage. Reference --------- opw-4743742 Forward-Port-Of: odoo/enterprise#86099 Forward-Port-Of: odoo/enterprise#85974
Steps to reproduce: - Install Stock and Field Service apps. - Create a product that tracks inventory by lot. - Add some on-hand quantity with a created lot. - In Field Service, create a task with `under_warranty` checked. - Add the created product to the task. Issue: - A sale order is generated with order lines at the product's price. - The price should be 0 since the customer should not be charged. Fix: - Ensure the sale order line price is set to 0 when `under_warranty` is checke
Original PR description
Steps to reproduce: - Install Stock and Field Service apps. - Create a product that tracks inventory by lot. - Add some on-hand quantity with a created lot. - In Field Service, create a task with `under_warranty` checked. - Add the created product to the task. Issue: - A sale order is generated with order lines at the product's price. - The price should be 0 since the customer should not be charged. Fix: - Ensure the sale order line price is set to 0 when `under_warranty` is checked in the _generate_lot() which is called on adding product tracked by lot. opw-4648542 opw-4646960 Forward-Port-Of: odoo/enterprise#85867 Forward-Port-Of: odoo/enterprise#82341
compute imp & assert deduplicate Forward-Port-Of: odoo/enterprise#84867 Forward-Port-Of: odoo/enterprise#84842
Original PR description
compute imp & assert deduplicate Forward-Port-Of: odoo/enterprise#84867 Forward-Port-Of: odoo/enterprise#84842
There is a missing ``s`` in the translation in ``pt_BR`` language. Traceback: ``` ValueError: incomplete format File "/home/odoo/src/odoo/odoo/tools/translate.py", line 422, in get_translation return translation % args ``` This issue was introduced in this commit:https://github.com/odoo/enterprise/commit/12c9eee514868f627c581e367e566458520ae122 https://github.com/odoo/enterprise/blob/9d51f5171b3c2478599dde1ce991c90fa6fed32b/l10n_br_avatax/i18n/pt_BR.po#L1156 Here, the ``s`` i
Original PR description
There is a missing ``s`` in the translation in ``pt_BR`` language.
Traceback:
```
ValueError: incomplete format
File "/home/odoo/src/odoo/odoo/tools/translate.py", line 422, in get_translation
return translation % args
```
This issue was introduced in this commit:https://github.com/odoo/enterprise/commit/12c9eee514868f627c581e367e566458520ae122
https://github.com/odoo/enterprise/blob/9d51f5171b3c2478599dde1ce991c90fa6fed32b/l10n_br_avatax/i18n/pt_BR.po#L1156 Here, the ``s`` is missing at the end of ``%(errors)``
It should be ``%(errors)s``.
sentry-6616622354
Forward-Port-Of: odoo/enterprise#85983Version: - saas-17.4 Steps to reproduce: - Create a sign request activity from sales or any other app. - Try to send document from activity from kanban view. Issue: - The sign request is created, but it is not linked to the related record. Cause: - The res_model and res_id were being read from the 'props' but it is available inside 'props.activity'. Solution: - Corrected the code to read res_model and res_id from 'props.activity'. task-4788037 Forward-Port-Of: odoo/enterpri
Original PR description
Version: - saas-17.4 Steps to reproduce: - Create a sign request activity from sales or any other app. - Try to send document from activity from kanban view. Issue: - The sign request is created, but it is not linked to the related record. Cause: - The res_model and res_id were being read from the 'props' but it is available inside 'props.activity'. Solution: - Corrected the code to read res_model and res_id from 'props.activity'. task-4788037 Forward-Port-Of: odoo/enterprise#86026 Forward-Port-Of: odoo/enterprise#85285
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos20.xsd) - Remove existing attachment - Change the attachment on the document to the relatively long XML file **Issue:** After saving the change, the attachment_uuid (Fiscal Folio) is left blank. **Cause:** Normally, the uuid should be extracted from the uploaded a
Original PR description
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format…
**Steps to reproduce:** With mexican localisation installed: - Open form view for the model 'l10n_mx_edi.document' - Prepare a payment document in the Payment-20 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos20.xsd) - Remove existing attachment - Change the attachment on the document to the relatively long XML file **Issue:** After saving the change, the attachment_uuid (Fiscal Folio) is left blank. **Cause:** Normally, the uuid should be extracted from the uploaded attachment, but the computation of the 'raw' field on the attachment returns the value "b'56.00 bytes'", leaving the attachment_uuid field empty because the XML is assumed to be in the wrong format. The issue doesn't exist for shorter XML files in the Payment-10 format (https://www.sat.gob.mx/sitio_internet/cfd/Pagos/Pagos10.xsd) **Solution:** Before computing the attachment_uuid from the attachment, we set the bin_size to False in the context. opw-4641487 Forward-Port-Of: odoo/enterprise#83538
If the subject serial number is not set in the certificate and the user clicks the ``Send now to SII`` button on the invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_cl_edi`` module and switch to CL company - Go to Invoicing > Configuration > Settings > SII Web Services: SII - Test - Create a new invoice > customer: CL company > add a line > Confirm > ``Send now to SII`` Traceback: ``` TypeError: 'bool' object is not subscriptable ``` https://git
Original PR description
If the subject serial number is not set in the certificate and the user clicks the ``Send now to SII`` button on the invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_cl_edi`` module and switch to CL company - Go to Invoicing > Configuration > Settings > SII Web Services: SII - Test - Create a new invoice > customer: CL company > add a line > Confirm > ``Send now to SII`` Traceback: ``` TypeError: 'bool' object is not subscriptable ``` https://github.com/odoo/enterprise/blob/7acf9b1f0cdd5c0968188ac6c2351ae9ab228689/l10n_cl_edi/models/account_move.py#L290 Here, If ``subject_serial_number`` of certificate is False. It will lead to the above traceback. ``subject_serial_number`` can be False because Some certificates do not provide this number. ref-https://github.com/odoo/enterprise/blob/7acf9b1f0cdd5c0968188ac6c2351ae9ab228689/l10n_cl_edi/models/certificate.py#L19-L20 sentry-6591311577 Forward-Port-Of: odoo/enterprise#84980
Otherwise, there's no other way for users to verify if the charged taxes are correct. task-4688950 Forward-Port-Of: odoo/enterprise#85100 Forward-Port-Of: odoo/enterprise#83464
Original PR description
Otherwise, there's no other way for users to verify if the charged taxes are correct. task-4688950 Forward-Port-Of: odoo/enterprise#85100 Forward-Port-Of: odoo/enterprise#83464
Before this patch, adding `l10n_mx_edi_cfdi_supplier_rfc` (or any other field filled by `_fill_from_cfdi_values`) to a tree/form view showed the field empty. Root cause ---------- `_fill_from_cfdi_values()` decoded the CFDI using `attachment.raw` with `bin_size=True` still in the context, so the ORM returned the placeholder `b'59.00 bytes'`. As a result, `_decode_cfdi_attachment()` got an empty payload and returned `{}`. Fix --- Reload the attachment without the `bin_size` flag 
Forward-Port-Of: odoo/enterprise#85333Related to https://github.com/odoo/odoo/pull/210767 Forward-Port-Of: odoo/enterprise#85952
Original PR description
Related to https://github.com/odoo/odoo/pull/210767 Forward-Port-Of: odoo/enterprise#85952
This commit fixes an issue where we had been using the UTC start and end times for a work entry when computing the correct duration for a payslip. Specifically, this is necessary when a work entry exceeds the interval of the payslip, which can happen when a work entry starts before the payslip interval or ends after the payslip interval. Previously, the UTC times were used. Consider an EST work entry that starts at 18:00 one night and ends at 01:00 the next morning. The UTC times would be 22:
Original PR description
This commit fixes an issue where we had been using the UTC start and end times for a work entry when computing the correct duration for a payslip. Specifically, this is necessary when a work entry…
This commit fixes an issue where we had been using the UTC start and end times for a work entry when computing the correct duration for a payslip. Specifically, this is necessary when a work entry exceeds the interval of the payslip, which can happen when a work entry starts before the payslip interval or ends after the payslip interval. Previously, the UTC times were used. Consider an EST work entry that starts at 18:00 one night and ends at 01:00 the next morning. The UTC times would be 22:00 and 05:00 respecively, up to a 1-hour difference for daylight savings time. Now suppose that the paysliip for this work entry only goes up to that following morning. Instead of using the local times of 18:00 and 01:00, the payslip would use the UTC times of 22:00 and 05:00, which would only count 2 of those hours instead of 6. This is resolved by converting the UTC times to local before using them to clamp the work entries to the payslip interval. opw-4790119 Forward-Port-Of: odoo/enterprise#85967 Forward-Port-Of: odoo/enterprise#85548
The redesign of the spreadsheet layout did not account for the small screen mode. Mor specifically, the breadcrumbs can be reduded to a "previous arrow" to spare some space to display the spreadsheet name. task-4774806 Forward-Port-Of: odoo/enterprise#84732
Original PR description
The redesign of the spreadsheet layout did not account for the small screen mode. Mor specifically, the breadcrumbs can be reduded to a "previous arrow" to spare some space to display the spreadsheet name. task-4774806 Forward-Port-Of: odoo/enterprise#84732
### Steps to reproduce: 1. Create a portal user. 2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view 3. Now, add the portal user as a follower on a task. 4. Change the state of a task to execute an automation rule. 5. Email will be received by a portal user but it will not be visible on the messaging history on the portal. ### Cause: This is happening because when running an automation rule that
Original PR description
### Steps to reproduce: 1. Create a portal user. 2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view 3. Now,…
### Steps to reproduce: 1. Create a portal user. 2. Create an automation rule to send an email as a message. Example: https://drive.google.com/file/d/1mIa4R7a2Z2fnkngOMD7zN2t9Z2XHhGY7/view 3. Now, add the portal user as a follower on a task. 4. Change the state of a task to execute an automation rule. 5. Email will be received by a portal user but it will not be visible on the messaging history on the portal. ### Cause: This is happening because when running an automation rule that will send an email we set the 'mail.message' state as System notification by default which leads that this mail will be sent normally to every follower of the record but will be only shown in the chat history for internal users not portal as we are just showing 'comment', 'incoming_email' and 'outgoing_email' messages. ### Fix: Checking if the server action that is being run is sending an email we will set the state of the 'mail.message' as 'auto_comment' and add 'auto_comment' to the domain of the field website_message_id which is for the messages shown to the portal user in his view opw-4459754 Forward-Port-Of: odoo/enterprise#85969 Forward-Port-Of: odoo/enterprise#82352
…vailability ### Steps to reproduce: - In the settings enable "Rental transfers" - Create a storable product that can be rented put 100 units in stock and add a `Security Time` of 24 hours. - Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it. - Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it. - Look at the forecast rentable quantity. ####
Original PR description
…vailability ### Steps to reproduce: - In the settings enable "Rental transfers" - Create a storable product that can be rented put 100 units in stock and add a `Security Time` of 24 hours. - Create…
…vailability ### Steps to reproduce: - In the settings enable "Rental transfers" - Create a storable product that can be rented put 100 units in stock and add a `Security Time` of 24 hours. - Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it. - Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it. - Look at the forecast rentable quantity. #### > It should be 90 but it is 100. ### Cause of the issue: The `preparation_time` (`Security Time`) field is used at the sale order line creation to modify the `reservation_begin` value: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L447-L453 In particular, the `preparation_time` of the product creates a difference between the `order_id.rental_start_date` and the `reservation_begin`. This is porblematic since the `rental_start_date` is used to generate the dates of the deliveries taken into account by the forecast: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L354-L362 but the quantity considered as rented does not and is purely based on the `reservation_begin` of the line: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/product_product.py#L113-L117 In particular, the qunaities are not yet accounted ithe stock forecast by the `virtual_available` value of the product: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L129-L132 But will incorrectly be found and read by the rental forecast: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/sale_stock_renting/models/sale_order_line.py#L133-L140 opw-4552760 Forward-Port-Of: odoo/enterprise#85949
**Steps to reproduce:** - Install `sale_commission_linked_achievement` module - Enable Commissions in settings - Go to Sales > Commissions > Commissions - Group By Sales Team - Error `psycopg2.errors.UndefinedFunction: operator does not exist: text = integer` is triggered **Issue:** When generating a raw query with a untyped `NULL` value (`NULL AS team_id`) in a `WITH` subquery, PostgreSQL infers the type as `text` (instead of default `unknown`) when the clause is done. This leads to a
Original PR description
**Steps to reproduce:** - Install `sale_commission_linked_achievement` module - Enable Commissions in settings - Go to Sales > Commissions > Commissions - Group By Sales Team - Error…
**Steps to reproduce:**
- Install `sale_commission_linked_achievement` module
- Enable Commissions in settings
- Go to Sales > Commissions > Commissions
- Group By Sales Team
- Error `psycopg2.errors.UndefinedFunction: operator does not exist: text = integer` is triggered
**Issue:**
When generating a raw query with a untyped `NULL` value (`NULL AS team_id`) in a `WITH` subquery, PostgreSQL infers the type as `text` (instead of default `unknown`) when the clause is done. This leads to a comparison error when joining results during the `group_by` operation.
`ON ("sale_commission_report"."team_id" = "sale_commission_report__team_id"."id")`
Explanation in PostgreSQL source code:
```
* If all the inputs were UNKNOWN type --- ie, unknown-type literals ---
* then resolve as type TEXT. This situation comes up with constructs
* like SELECT (CASE WHEN foo THEN 'bar' ELSE 'baz' END); SELECT 'foo'
* UNION SELECT 'bar'; It might seem desirable to leave the construct's
* output type as UNKNOWN, but that really doesn't work, because we'd
* probably end up needing a runtime coercion from UNKNOWN to something
* else, and we usually won't have it. We need to coerce the unknown
* literals while they are still literals, so a decision has to be made
* now.
```
This can be reproduced manually by doing :
```
WITH example AS (
SELECT NULL AS team_id
)
SELECT pg_typeof(team_id) FROM example;
pg_typeof
-----------
text
(1 row)
```
**Fix:**
Explicitly cast the `NULL` value to the proper type using `NULL::INTEGER` to ensure it is treated as an integer during the comparison.
The issue was introduced here : https://github.com/odoo/enterprise/commit/80beef2077c3b4fa7ee6e20dd2f9400a7d1d2273
And, as the `sale_commission_linked_achievement` will be removed, as well as the `Sales Team` grouping, it should disappear with this : https://github.com/odoo/enterprise/commit/b1e41f9b23aa62bfd6f9be1feb1059b3507f2ce5
opw-4765421
Forward-Port-Of: odoo/enterprise#85097Before this commit, when re-scheduling a call activity to a date of today or older, it raised the following error: ``` Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl') at ActivityListPopoverItem.template ``` This happens because in this specific case of change of call activity deadline date, the VOIP softphone code is fetching activity data of today faster than odoo views, thanks to relying on bus notification, whereas odoo views and chatter rely on mostly
Original PR description
Before this commit, when re-scheduling a call activity to a date of today or older, it raised the following error: ``` Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl')…
Before this commit, when re-scheduling a call activity to a date of today or older, it raised the following error: ``` Caused by: TypeError: Cannot read properties of undefined (reading 'avatarUrl') at ActivityListPopoverItem.template ``` This happens because in this specific case of change of call activity deadline date, the VOIP softphone code is fetching activity data of today faster than odoo views, thanks to relying on bus notification, whereas odoo views and chatter rely on mostly on returned RPCs. The code of VOIP returns activity data with a custom formatter, which omits `persona` that is important for the good templating of an activity in Chatter otherwise there's the crash above. A recent PR [1] attempted to fix this issue, but the syntax for Store was wrong: it used the syntax for an item in field list (e.g. in `_to_store_defaults`) instead of pure store data from a specific record. This bad use of Store.One() resulted in actually returning `False`. [1]: https://github.com/odoo/enterprise/pull/84970 opw-4586756 Forward-Port-Of: odoo/enterprise#85907