Friday, December 20, 2024
46 changes · 18.0
Enhancements to existing features
This update adds tests that clarify how accounting should handle changes to existing tax rates. It helps reduce the risk of errors when tax rates are updated, supporting more reliable compliance and reporting.
Original PR description
This commit aims at better defining how to handle tax rates being updated for some taxes, and test the procedure.
The vehicle model view now places the engine and salary information blocks in a more suitable order. This makes the Belgian payroll fleet screen easier to read and helps users find related vehicle details more naturally.
Original PR description
changing position of engine block and salary block in vehicle models view task-4351672
Resolved issues and error corrections
This fix prevents the Point of Sale from showing a confusing technical dialog when a Stripe Terminal payment setup is invalid. Users now see the real error message, while detailed information is logged for support teams to diagnose the issue faster.
Original PR description
Before this commit: 1. Install pos_stripe & pos_restaurant 2. Create a PoS payment method wish Stripe Terminal setup with dummy (wrong) value. ! Purposfully DON'T set up the Stripe account (so let it…
Before this commit:
1. Install pos_stripe & pos_restaurant
2. Create a PoS payment method wish Stripe Terminal setup with dummy (wrong) value. ! Purposfully DON'T set up the Stripe account (so let it as deactivate)
3. Add the payment method to the bar PoS
4. Open the bar PoS, make an order and try to pay by the stripe payment method
=> JS error
```js
undefined
undefined
OwlError: Invalid props for component 'AlertDialog': 'body' is not a string
Error: Invalid props for component 'AlertDialog': 'body' is not a string
at Object.validateProps (http://127.0.0.1:8069/web/assets/debug/point_of_sale.assets_prod.js:11392:19) (/web/static/lib/owl/owl.js:3160)
at DialogWrapper.template (eval at compile (http://127.0.0.1:8069/web/assets/debug/point_of_sale.assets_prod.js:13846:20), <anonymous>:10:13) (/web/static/lib/owl/owl.js:5614)
at Fiber._render (http://127.0.0.1:8069/web/assets/debug/point_of_sale.assets_prod.js:9961:38) (/web/static/lib/owl/owl.js:1729)
at Fiber.render (http://127.0.0.1:8069/web/assets/debug/point_of_sale.assets_prod.js:9953:18) (/web/static/lib/owl/owl.js:1721)
at ComponentNode.initiateRender (http://127.0.0.1:8069/web/assets/debug/point_of_sale.assets_prod.js:10633:23) (/web/static/lib/owl/owl.js:2401)
```
This error hide the real error as the error dialog expect to receive a string while it receive an Error object
After this commit:
The (real) error is logged to the console:
```js
payment_stripe.js:272 SyntaxError: "undefined" is not valid JSON
at JSON.parse (<anonymous>)
at Proxy.connectReader (payment_stripe.js:87:1)
at Proxy.checkReader (payment_stripe.js:79:1)
at Proxy.send_payment_request (payment_stripe.js:268:1)
at async Proxy.pay (pos_payment.js:74:1)
at async PaymentScreen.sendPaymentRequest (payment_screen.js:545:1)
```
and the error dialog shows with the string of the error, here: `SyntaxError: "undefined" is not valid JSON`
We will not have the traceback in the client message as I didn't find a way to do so except letting the error propagate. But this might have side effects so I didn't used this option.
opw-4375876Miscellaneous changes
**Current behavior before PR:** The `probability` field, defined as a float, had values in demo data assigned as strings. This caused errors during domain evaluation. **Desired behavior after PR is merged:** This update ensures the `probability` field in demo data uses values compatible with its float type. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191098
Original PR description
**Current behavior before PR:** The `probability` field, defined as a float, had values in demo data assigned as strings. This caused errors during domain evaluation. **Desired behavior after PR is merged:** This update ensures the `probability` field in demo data uses values compatible with its float type. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191098
This fix keeps Peppol demo-mode handling separate from Italian EDI requests. It prevents an error that could interrupt electronic invoicing flows when the two services use different request information.
Original PR description
The problem was that the decorator would be triggered if Peppol is in demo mode, but also for the requests made by the Italian EDI which does not have the same information which results in a traceback. opw-4421483 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
Product pages now show the correct tags when shoppers select different product variants. This helps customers see accurate product information and prevents variant-specific labels from being missed in the online shop.
Original PR description
Steps to reproduce:
------------------
- Set a product tag for a specific variant.
- Go to the shop.
- Select different variants of the product.
Issue:
-----
The tags of the variant is not shown. This is due to the JS file: odoo/addons/website_sale/static/src/js/sale_variant_mixin.js In this file we set the parent to:
var $parent = $(ev.target).closest('.js_product'); To update the product tags we do a find('.o_product_tags') However this falls outside of the div of the parent. This "find" then results with nothing. And nothing is updated.
Fix:
----
To fix this the call to website_sale.product_tags was inserted inside the right div so it can be found and thus updated.
opw-4357477
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an installation issue for modules that depend on Python packages with hyphens in their names, such as google-auth-oauthlib. These modules can now be installed correctly even when the optional packaging library is not available.
Original PR description
Some modules may have python packages with hyphen in the external_dependies (google-auth-oauthlib, ...) Those module cannot be installed anymore. Fixing the regex to allow hyphen in external dependencies when packaging is not installed.
The point of sale demo data now correctly applies the default category ordering on the product screen. This helps demo shops and restaurants show product categories in the intended order, making the POS interface clearer and more consistent.
Original PR description
In this commit: === - Ensured that the default sequence defined for POS categories is properly reflected on the product screen in the POS interface. task-4365434 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This reverts an earlier mistaken change in the Vietnam localization migration process. It helps keep the module upgrade path aligned with the intended behavior and reduces the risk of incorrect data handling during migrations.
Original PR description
Undo the change made in error in the following PR : https://github.com/odoo/odoo/pull/190559/
The overdue invoice filter now only shows invoices that are unpaid or partially paid. This prevents invoices already in the payment process from appearing as overdue, giving users a more accurate view of outstanding debts.
Original PR description
Steps to reproduce: ------------------ - Go to invoices - filters on "Overdue" - Filter includes "in_payment" Issue: ----- This is not intended, the overdue filter should only include the not paid and partial. Fix: --- Removed it. opw-4383117 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Steps to reproduce: - Install the l10n_cl module - Create an invoice - Some terms are not translated : - Incorrect: Net Amount - Correct: Total Neto - Incorrect: Exempt Amount - Correct: Total sin Impuestos - Incorrect: VAT - Correct: IVA - Incorrect: The VAT tax of this boleta is: - Correct: El IVA de esta boleta es: Issue: Some translation were missing making it incorect for the Chile localization. Fix: Updated the .pot and the .po accordingly to includ
Original PR description
Steps to reproduce: - Install the l10n_cl module - Create an invoice - Some terms are not translated : - Incorrect: Net Amount - Correct: Total Neto - Incorrect: Exempt Amount - Correct: Total sin Impuestos - Incorrect: VAT - Correct: IVA - Incorrect: The VAT tax of this boleta is: - Correct: El IVA de esta boleta es: Issue: Some translation were missing making it incorect for the Chile localization. Fix: Updated the .pot and the .po accordingly to include the terms so the translation is correct. opw-4329049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Reversed accounting documents are no longer treated as overdue in the customer portal. This prevents customers from seeing misleading payment warnings for amounts they should not pay.
Original PR description
We should never consider 'reversed' move as overdue, otherwise the user might get a warning when it connect to its portal and are encouraged to pay it whereas it should not be paid. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where some messaging menu entries could fail or show the wrong conversation name after a previous backport. The change ensures regular records and discussion channels use the correct name source, keeping messaging notifications reliable for users.
Original PR description
Follow-up of [1] PR above was a backport of some improvements made in master [2]. The original PR was using `thread.display_name`, from a recent other improvement in master that split `channel.name`…
Follow-up of [1] PR above was a backport of some improvements made in master [2]. The original PR was using `thread.display_name`, from a recent other improvement in master that split `channel.name` and `thread.display_name` for clarity on the actual python field being used in client-side code [3]. The backport version [1] changed `thread.display_name` to `thread.name`, because the web client has to receive thread name from server in formatted data as `name`. However, the commit forgot that the internal formatter of thread had to pass `display_name` in the named field, and under-the-hood it is turning it into the expected `name` [4]. This commit fixes the issue by passing `display_name` as expected for non-channels. Note that channel's `display_name` is not the same as `name`, and we must always `name` for them rather than `display_name`, hence the enforced `"name"` for discuss channels. [1]: https://github.com/odoo/odoo/pull/190486 [2]: https://github.com/odoo/odoo/pull/189805 [3]: https://github.com/odoo/odoo/pull/190243 [4]: https://github.com/odoo/odoo/blob/18.0/addons/mail/models/mail_thread.py#L4607 opw-4412441 opw-4415546
This fix updates internal automated checks so they first select the correct company folder before looking for test documents. It helps keep document spreadsheet workflows stable after pagination changes limited which folders appear by default.
Original PR description
Changes from the PR(ENT)https://github.com/odoo/enterprise/pull/73443 break some tours in documents_spreadsheet (create empty sheet, clone xlsx, create template and save multipage). They all fail to find the Test folder's Kanban record in the Kanban view. PR#73443 limits the number of records per page. Tours open 'Documents' on 'Home' and 'Test folder' belongs to 'COMPANY'. When there is a large number of records, 'Test folder' is not displayed in the Kanban view. So one adds a prior step to select COMPANY before checking for the Test folder's Kanban record. task-4394473 see https://github.com/odoo/enterprise/pull/73443 see runbot error 109604
Point of Sale orders are no longer incorrectly removed when the Urban Piper module is installed but not configured. This helps businesses keep order data available in the POS cache even if the integration is not actively set up.
Original PR description
When the pos_urban_piper module is installed but not configured in the PoS settings, the orders were being filtered out incorrectly. opw-4423378
Following 17fa8a4531df0cd7281962211797ba60df06f775, `force_open` was introduced as a parameter to the function, but the condition to set the folding state references `open` (python's default function to open a file), not `force_open` (the parameter), probably a typo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189294
Original PR description
Following 17fa8a4531df0cd7281962211797ba60df06f775, `force_open` was introduced as a parameter to the function, but the condition to set the folding state references `open` (python's default function to open a file), not `force_open` (the parameter), probably a typo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189294
Add the user_ids to the token for the signup and reset password of the user. This prevent to token to work if there was a change to the users of the partner, effectively requiring the generation of a new token. Forward-Port-Of: odoo/odoo#190365
Original PR description
Add the user_ids to the token for the signup and reset password of the user. This prevent to token to work if there was a change to the users of the partner, effectively requiring the generation of a new token. Forward-Port-Of: odoo/odoo#190365
When attaching an image in the account module, the `_check_and_decode_attachment` method led to the deletion of non-decodable attachments, causing subsequent access errors in `IrAttachment._post_add_create` since it was trying to use deleted record Reproduce --- - -i ,account - Create new draft invoice (without lines) -> Save - Attach some pdf with invoice - Try attaching some image to the chatter -> BUG: stuck on uploading opw-4144868 Forward-Port-Of: odoo/odoo#191040 Forward-Port-O
Original PR description
When attaching an image in the account module, the `_check_and_decode_attachment` method led to the deletion of non-decodable attachments, causing subsequent access errors in `IrAttachment._post_add_create` since it was trying to use deleted record Reproduce --- - -i ,account - Create new draft invoice (without lines) -> Save - Attach some pdf with invoice - Try attaching some image to the chatter -> BUG: stuck on uploading opw-4144868 Forward-Port-Of: odoo/odoo#191040 Forward-Port-Of: odoo/odoo#181638
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---17.0-esoriginlength-jco I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187332
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---17.0-esoriginlength-jco I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187332
Before this commit, if you opened the PoS, made it offline, validated an order, stayed on the receipt screen, then made the PoS online and refreshed the page, the paid order would become a draft order. This caused the loss of tracking for the paid receipt-printed order. This issue occurred because using readAll prevented the effect from triggering on data modification. opw-4371425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: od
Original PR description
Before this commit, if you opened the PoS, made it offline, validated an order, stayed on the receipt screen, then made the PoS online and refreshed the page, the paid order would become a draft order. This caused the loss of tracking for the paid receipt-printed order. This issue occurred because using readAll prevented the effect from triggering on data modification. opw-4371425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190821
When we pass create = false in the action context, a new record cannot be created in the kanban and list views. However, a new record could still be created in the activity view. In this commit, we have prevented that. task-3887972 Forward-Port-Of: odoo/odoo#190566 Forward-Port-Of: odoo/odoo#188378
Original PR description
When we pass create = false in the action context, a new record cannot be created in the kanban and list views. However, a new record could still be created in the activity view. In this commit, we have prevented that. task-3887972 Forward-Port-Of: odoo/odoo#190566 Forward-Port-Of: odoo/odoo#188378
Some were out-of-date, at least 1 had duplicated terms. Also, note that https://github.com/odoo/odoo/pull/183067 was merged after the last mass export, so many email templates terms changed due to this. Due to the change: - the self closing elements are now more correctly represented in the templates - invalid html nesting is auto-fixed (e.g. nested `<p>` tags and a `<div>` within a `<p>`are invalid html) In theory this shouldn't affect much since email templates are matched by `xml_id
Original PR description
Some were out-of-date, at least 1 had duplicated terms. Also, note that https://github.com/odoo/odoo/pull/183067 was merged after the last mass export, so many email templates terms changed due to this. Due to the change: - the self closing elements are now more correctly represented in the templates - invalid html nesting is auto-fixed (e.g. nested `<p>` tags and a `<div>` within a `<p>`are invalid html) In theory this shouldn't affect much since email templates are matched by `xml_id` and not by content of the email, but in practice ¯\_(ツ)_/¯ 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
We have a constraint enforcing the presence of a zip code on both the sender and the receiver of the invoice but we can't trace the origin of this constraint. It seems to not exists anymore in the doc or the schematrons. We therefore remove it as it cause unnecessary frictions when invoicing. task-no (feedback from our prod + tsb) Forward-Port-Of: odoo/odoo#191129
Original PR description
We have a constraint enforcing the presence of a zip code on both the sender and the receiver of the invoice but we can't trace the origin of this constraint. It seems to not exists anymore in the doc or the schematrons. We therefore remove it as it cause unnecessary frictions when invoicing. task-no (feedback from our prod + tsb) Forward-Port-Of: odoo/odoo#191129
Currently, when searching the through the customers loaded in pos you can search using the zip code but if the customer is not loaded you cannot search those in db using the zip code. Steps to reproduce: ------------------- * Create a customer and set his zip code. * Open pos shop * Search for customers * Enter the zip code, normally you shouldn't see the customer * Select "Search more" > Observation: No customer found Note: If you search with the customer name it will find it. W
Original PR description
Currently, when searching the through the customers loaded in pos you can search using the zip code but if the customer is not loaded you cannot search those in db using the zip code. Steps to reproduce: ------------------- * Create a customer and set his zip code. * Open pos shop * Search for customers * Enter the zip code, normally you shouldn't see the customer * Select "Search more" > Observation: No customer found Note: If you search with the customer name it will find it. Why the fix: ------------ Adding a few search values when loeading customers in the session. opw-4334412 Forward-Port-Of: odoo/odoo#191258 Forward-Port-Of: odoo/odoo#189164
### Steps to reproduce: - Install "l10n_ch" and switch to "CH company" - Create a new invoice with a Swiss partner and confirm - Click "Send & Print" and select "Send by Post", confirm - Go in Setting > technical > Email > Snailmail Letters and find your invoice - Download the PDF document - The QR code and several other information are missing ### Cause: The snailmail module is setting specific paper format (base.paperformat_euro) when generating the PDF. https://github.com/odoo/o
Original PR description
### Steps to reproduce: - Install "l10n_ch" and switch to "CH company" - Create a new invoice with a Swiss partner and confirm - Click "Send & Print" and select "Send by Post", confirm - Go in Setting > technical > Email > Snailmail Letters and find your invoice - Download the PDF document - The QR code and several other information are missing ### Cause: The snailmail module is setting specific paper format (base.paperformat_euro) when generating the PDF. https://github.com/odoo/odoo/blob/ce92dedea0fd3cdc73da6366c20b8052bb04f7e9/addons/snailmail/models/ir_actions_report.py#L17-L24 But the Swiss reports have their own formats to display the QR code correctly. So the generated PDF have its QR code on another page that is lost when merging the PDF for the header and the one with the QR code. ### Solution: Force the paper format for the two "IrActionReports" responsible for the page with the Qr-code. opw-4399150 Forward-Port-Of: odoo/odoo#190881
Add a check on Viva Wallet callback when paying. Verify if the pending payment line exist before processing the callback. Adapted from: https://github.com/odoo/odoo/pull/186580 opw-4242322 opw-4374450 Forward-Port-Of: odoo/odoo#191151 Forward-Port-Of: odoo/odoo#190735
Original PR description
Add a check on Viva Wallet callback when paying. Verify if the pending payment line exist before processing the callback. Adapted from: https://github.com/odoo/odoo/pull/186580 opw-4242322 opw-4374450 Forward-Port-Of: odoo/odoo#191151 Forward-Port-Of: odoo/odoo#190735
In 17.2 and prior, the product carousel did not auto slide. However, after upgrading to Bootstrap 3.5.5 in 17.4, this commit 7da319c81f0a0 changed the behavior of the carousel and made it auto slide after user interactions, using `data-bs-ride="true"` attribute. This issue is known, and fixes were provided for some carousels in 9eff9ae and 1db386b. Here we apply the same fix for the products carousel. opw-4391294 opw-4404683 Forward-Port-Of: odoo/odoo#190960
Original PR description
In 17.2 and prior, the product carousel did not auto slide. However, after upgrading to Bootstrap 3.5.5 in 17.4, this commit 7da319c81f0a0 changed the behavior of the carousel and made it auto slide after user interactions, using `data-bs-ride="true"` attribute. This issue is known, and fixes were provided for some carousels in 9eff9ae and 1db386b. Here we apply the same fix for the products carousel. opw-4391294 opw-4404683 Forward-Port-Of: odoo/odoo#190960
To allow compatibility between all db versions and new IoT Box images, we need to ensure that `path_file` method returns the path starting from `/home/pi` instead of the path of the service user (which is `/home/odoo` in newer images). Forward-Port-Of: odoo/odoo#191149 Forward-Port-Of: odoo/odoo#190963
Original PR description
To allow compatibility between all db versions and new IoT Box images, we need to ensure that `path_file` method returns the path starting from `/home/pi` instead of the path of the service user (which is `/home/odoo` in newer images). Forward-Port-Of: odoo/odoo#191149 Forward-Port-Of: odoo/odoo#190963
Steps to reproduce: - Insert a list in a spreadsheet (e.g. CRM Lead) - Create a global filter, set a value on it (filter on CRM Stages -> Select new) - Open the list side panel, update the domain (add Marc Demo as Salesperson) - Save => The domain does not take the global filter into account Task:4398467 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
Original PR description
Steps to reproduce: - Insert a list in a spreadsheet (e.g. CRM Lead) - Create a global filter, set a value on it (filter on CRM Stages -> Select new) - Open the list side panel, update the domain (add Marc Demo as Salesperson) - Save => The domain does not take the global filter into account Task:4398467 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#191124 Forward-Port-Of: odoo/odoo#190782
Let say we have two record with a reference field with char type. Record X with reference A Record Y with reference B If we open the record x form view directly from the list view the fetch will works as wanted (reference A) But if we use the pager to navigate to record Y, the reference field will not be correct, it will dispay the old one (reference A instead of B) This is because in the `ReferenceField` setup method we use an `useRecordObserver` to track record changes and update refer
Original PR description
Let say we have two record with a reference field with char type. Record X with reference A Record Y with reference B If we open the record x form view directly from the list view the fetch will works as wanted (reference A) But if we use the pager to navigate to record Y, the reference field will not be correct, it will dispay the old one (reference A instead of B) This is because in the `ReferenceField` setup method we use an `useRecordObserver` to track record changes and update reference data. But before this commit, we passed the wrong `props` to `_fetchReferenceCharData` `useRecordObserver` has a second argument, which is the new `props`, so we can use it instead of `this.props` still referring to the previous record This can be reproduced on `External Identifiers` view (accessible with debug) opw-4349296 Forward-Port-Of: odoo/odoo#191174 Forward-Port-Of: odoo/odoo#190970
Currently, a connection error shows when the ReadTimeout error occurs when calling the JSON-RPC endpoint in IAP. This commit will show users a timeout error when a "ReadTimeout" error is found in the JSON response in the RPC call. sentry-6059323528 Forward-Port-Of: odoo/odoo#190841
Original PR description
Currently, a connection error shows when the ReadTimeout error occurs when calling the JSON-RPC endpoint in IAP. This commit will show users a timeout error when a "ReadTimeout" error is found in the JSON response in the RPC call. sentry-6059323528 Forward-Port-Of: odoo/odoo#190841
[FIX] l10n_fr: add tax move lines in tax report In the l10n_fr tax report, the wrong `account_move_line` entries are used in the journal item list view of the tax report in section `TD-VAT Due`. As a result, the balance debit/credit displayed under the `TD-VAT Due` is not the same as the balance in the journal items list view. - Create a customer invoice with a price 1000 and a tax 20% Goods. - Create a vendor bill with a price 100 and a tax 20% Goods. - Open the tax report, under the TD -
Original PR description
[FIX] l10n_fr: add tax move lines in tax report In the l10n_fr tax report, the wrong `account_move_line` entries are used in the journal item list view of the tax report in section `TD-VAT Due`. As a…
[FIX] l10n_fr: add tax move lines in tax report In the l10n_fr tax report, the wrong `account_move_line` entries are used in the journal item list view of the tax report in section `TD-VAT Due`. As a result, the balance debit/credit displayed under the `TD-VAT Due` is not the same as the balance in the journal items list view. - Create a customer invoice with a price 1000 and a tax 20% Goods. - Create a vendor bill with a price 100 and a tax 20% Goods. - Open the tax report, under the TD - VAT Due, the balance is 180. - Click on the amount in TD - VAT Due, the debit is 20 but the credit is 1000 (should be 200). The formula for `TD-VAT Due` is defined as `box_16.balance - box_23.balance`. - `box_16` is the sum of box_xx.balance which are defined by `account_tag`. - The balances of these boxes were computed using the base `account_tag`, which calculates the correct amount but causes `_expand_aggregations` in `account_report_expression` to generate a list view based on base move lines instead of the corresponding tax lines. This can be seen the label field of the lines, which are not the tax label. `box_16` needs to be computed using `box_xx_taxe` instead of `box_xx_base` to ensure the correct tax lines are included. For box 08, 09, 9B, 10, 11, T1, T2, T3, T4, T5, T6, P1, P2, I1, I2, I3, I4, I5, I6 we replace balance to balance_from_tags (which uses box_xx_taxe) For box 13, 14, 15, T7, 5B we keep balance (which already uses box_xx_taxe) opw-4335396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188640
We encounter an error when trying to open any POS category from the ``Dashboard``, if the Administrator is assigned the role of ``User`` for ``Point of Sale``. Steps to reproduce: --- - Install ``point_of_sale`` module - Open POS - Now go to Users and Change the right from ``Admin`` -> ``User`` in ``Point of Sale`` - Now go to ``Dashboard`` and try to open any category Traceback: --- ``` ParseError: while parsing /home/odoo/src/odoo/saas-17.4/addons/product/data/product_demo.xml:5
Original PR description
We encounter an error when trying to open any POS category from the ``Dashboard``, if the Administrator is assigned the role of ``User`` for ``Point of Sale``. Steps to reproduce: --- - Install…
We encounter an error when trying to open any POS category from the ``Dashboard``, if the Administrator is assigned the role of ``User`` for ``Point of Sale``.
Steps to reproduce:
---
- Install ``point_of_sale`` module
- Open POS
- Now go to Users and Change the right from ``Admin`` -> ``User`` in ``Point of Sale``
- Now go to ``Dashboard`` and try to open any category
Traceback:
---
```
ParseError: while parsing /home/odoo/src/odoo/saas-17.4/addons/product/data/product_demo.xml:5, somewhere inside <record id="base.group_user" model="res.groups">
<field name="implied_ids" eval="[(4, ref('product.group_product_variant'))]"/>
</record>
```
This error occurs when the POS application is opened, as the onWillStart method is triggered. However, if the user's permissions are changed, the method does not update accordingly, leading to an error.
sentry-5710465833
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#189522Steps to reproduce: - Try to add a parent to the base plan "Projects" Issue: Unclear error message Cause: This is a master data and the constraint raised an unclear message "Invalid Operation This column contains module data and cannot be removed!" https://github.com/odoo/odoo/blob/1621f12e90b5903d1132875db7b0d94fa68bc642/odoo/addons/base/models/ir_model.py#L857-L859 Solution: We specify a more user-friendly message during the onchange opw-4327913 Forward-Port-Of: odoo/odoo
Original PR description
Steps to reproduce: - Try to add a parent to the base plan "Projects" Issue: Unclear error message Cause: This is a master data and the constraint raised an unclear message "Invalid Operation This column contains module data and cannot be removed!" https://github.com/odoo/odoo/blob/1621f12e90b5903d1132875db7b0d94fa68bc642/odoo/addons/base/models/ir_model.py#L857-L859 Solution: We specify a more user-friendly message during the onchange opw-4327913 Forward-Port-Of: odoo/odoo#188778
The PR https://github.com/odoo/odoo/pull/178407 changed `external_reference` syntax to use the order UUID instead of UID. The UUID is composed of hexadecimal values as opposed to the UID which is just digits. As such, as a side effect of this PR. Mercado pago webhook callback were are all rejected with a warning: `POST message received with no or malformed "external_reference" key: XXX_YYY_ZZZ` which prevent user to validate their Mercado Pago payments. opw-4349957 opw-4396287 opw-4385500
Original PR description
The PR https://github.com/odoo/odoo/pull/178407 changed `external_reference` syntax to use the order UUID instead of UID. The UUID is composed of hexadecimal values as opposed to the UID which is just digits. As such, as a side effect of this PR. Mercado pago webhook callback were are all rejected with a warning: `POST message received with no or malformed "external_reference" key: XXX_YYY_ZZZ` which prevent user to validate their Mercado Pago payments. opw-4349957 opw-4396287 opw-4385500 Forward-Port-Of: odoo/odoo#191043
Steps to reproduce: - In the rental module, set a product as storable and uncheck 'Out-of-Stock: Continue Selling.' - Create a discount program for product purchase with 'Get Free Product' reward. - Add enough rental products to an order on the website to trigger the discount. Issue: - Traceback error: TypeError: < not supported between instances of datetime.datetime and bool. Cause: - The reward_line has reservation_begin = False, which results in a dictionary containing a False v
Original PR description
Steps to reproduce: - In the rental module, set a product as storable and uncheck 'Out-of-Stock: Continue Selling.' - Create a discount program for product purchase with 'Get Free Product' reward. - Add enough rental products to an order on the website to trigger the discount. Issue: - Traceback error: TypeError: < not supported between instances of datetime.datetime and bool. Cause: - The reward_line has reservation_begin = False, which results in a dictionary containing a False value alongside other datetime objects. Fix: - Filter the lines to ensure the loop iterates only over rental lines. opw-4360396 Forward-Port-Of: odoo/enterprise#75950 Forward-Port-Of: odoo/enterprise#75894
On a previous commit: https://github.com/odoo/enterprise/commit/8e2957c238e28b8a952c0e354c46e39b1fdd03a6 We changed the condition on the VATNumber node on oss report, but actually it was a mistake and in some cases, this change broke some xml exports on other customer db. But, after more investigation, we decided to remove the fixedEstablishment node from the xml export, as we don't have any use cases where this node is required for now. no task Forward-Port-Of: odoo/enterprise#75964 Forw
Original PR description
On a previous commit: https://github.com/odoo/enterprise/commit/8e2957c238e28b8a952c0e354c46e39b1fdd03a6 We changed the condition on the VATNumber node on oss report, but actually it was a mistake and in some cases, this change broke some xml exports on other customer db. But, after more investigation, we decided to remove the fixedEstablishment node from the xml export, as we don't have any use cases where this node is required for now. no task Forward-Port-Of: odoo/enterprise#75964 Forward-Port-Of: odoo/enterprise#75705
There are new requirements for the ph check format: - No '*' allowed anymore - In amount in words: • no thousand comma separator • no 'And' between hundreds and tens https://www.metrobank.com.ph/articles/new-check-format-advisory This commit fixes also an issue with the cents format in the amount in words ('X/100' instead of 'X0/100') opw-4376550 Forward-Port-Of: odoo/enterprise#75647
Original PR description
There are new requirements for the ph check format:
- No '*' allowed anymore
- In amount in words:
• no thousand comma separator
• no 'And' between hundreds and tens
https://www.metrobank.com.ph/articles/new-check-format-advisory
This commit fixes also an issue with the cents format in the amount in
words ('X/100' instead of 'X0/100')
opw-4376550
Forward-Port-Of: odoo/enterprise#75647Due to a typo in the directory name the warnings.xml file got duplicated and one of them is now unnecesary. linked pr: #67187 Forward-Port-Of: odoo/enterprise#75833
Original PR description
Due to a typo in the directory name the warnings.xml file got duplicated and one of them is now unnecesary. linked pr: #67187 Forward-Port-Of: odoo/enterprise#75833
Steps to reproduce the issue: 1) Open the create new product page 2) From the "General Information" tab, set the "Product Type" to "Goods", and set a "Sales Price" 3) Check the "Subscriptions" 4) From the "Recurring Prices" tab, create 2 different pricing rules, for different variants (like one for size S, and one for size M) 5) From the "Sales" tab, set an "Optional Product" 6) On the website's product page, keep the default variant and click "Add to cart", the modal "Configure your p
Original PR description
Steps to reproduce the issue: 1) Open the create new product page 2) From the "General Information" tab, set the "Product Type" to "Goods", and set a "Sales Price" 3) Check the "Subscriptions" 4)…
Steps to reproduce the issue: 1) Open the create new product page 2) From the "General Information" tab, set the "Product Type" to "Goods", and set a "Sales Price" 3) Check the "Subscriptions" 4) From the "Recurring Prices" tab, create 2 different pricing rules, for different variants (like one for size S, and one for size M) 5) From the "Sales" tab, set an "Optional Product" 6) On the website's product page, keep the default variant and click "Add to cart", the modal "Configure your product" will open 7) Close the modal by clicking "X" or "Esc" 8) Choose another variant that results in a different price (from the prices configured in step 4) 9) Click "Add to cart" again -> Notice that the product's price is no longer the expected recurring price, but it's the "Sales Price" configured in step 2. Reason: When opening the modal, we query the `data-subscription-plan-id` attribute from the DOM using JQuery's `data` method. However, this latter is not meant to querying data attributes from DOM. Its usage is to actually store data associated with the JQuery objects it's associated with. It worked the first time when we opened the modal, as the first call for it will try to initialize the internal store, if empty, with the value of the appropriate `data-*` attribute from DOM, but any subsequent updates to the underlying `data-*` attribute won't be seen by a new call to this function. Fix: Use `attr` instead of `data`, as the former reads directly from the DOM, every time it's invoked. Refs: https://api.jquery.com/data/ https://api.jquery.com/data/#data-html5 https://api.jquery.com/attr/ opw-4369487 Forward-Port-Of: odoo/enterprise#75896
Versions: ---------- - 17.0 Steps to Reproduce ------------ - Create a product and add the template of the field service project. - Create a sale order. - Open the project updates. - We do not see the SO and SOL buttons. Issue ------------ - SO and SOL smart button was removed on project updates in this commit https://github.com/odoo/enterprise/commit/7a82c52fb007ad0f827dd5d124f80d6195bff919 Fix ---------- - We are adding the SO and SOL buttons back. - So the user can at
Original PR description
Versions: ---------- - 17.0 Steps to Reproduce ------------ - Create a product and add the template of the field service project. - Create a sale order. - Open the project updates. - We do not see the SO and SOL buttons. Issue ------------ - SO and SOL smart button was removed on project updates in this commit https://github.com/odoo/enterprise/commit/7a82c52fb007ad0f827dd5d124f80d6195bff919 Fix ---------- - We are adding the SO and SOL buttons back. - So the user can at least see the linked data. task-3887972 Forward-Port-Of: odoo/enterprise#75587 Forward-Port-Of: odoo/enterprise#67793
In ES localization Tax Report 349 is an informative tax return report for intra-Community operations. Currently, the tax report will show amounts from credit notes in the invoices section, instead of the refunds section Steps to reproduce: - Have an ES Company setup - Create and confirm credit note with: - EU partner - Type for mod 349: A - Go to Accounting > Reporting > Tax Report - Select Report: Tax Report (Mod 349) (ES) Issue: Credit Notes appear in the invoices section inst
Original PR description
In ES localization Tax Report 349 is an informative tax return report for intra-Community operations. Currently, the tax report will show amounts from credit notes in the invoices section, instead of the refunds section Steps to reproduce: - Have an ES Company setup - Create and confirm credit note with: - EU partner - Type for mod 349: A - Go to Accounting > Reporting > Tax Report - Select Report: Tax Report (Mod 349) (ES) Issue: Credit Notes appear in the invoices section instead of the refunds section opw-4358330 Forward-Port-Of: odoo/enterprise#75808 Forward-Port-Of: odoo/enterprise#75266
Some were out of date See community PR for details about email template changes
Original PR description
Some were out of date See community PR for details about email template changes
`quality_iot` listens continuously for measure updates. It also provides a "take measure" button for devices that don't send automatically their measure. On caliper devices, measures are sent continuously, so methods to read value once were not implemented, resulting in a error if we tried to call them. To avoid displaying an error popup, we implemented those actions on caliper drivers. opw-4332476 Forward-Port-Of: odoo/enterprise#75847
Original PR description
`quality_iot` listens continuously for measure updates. It also provides a "take measure" button for devices that don't send automatically their measure. On caliper devices, measures are sent continuously, so methods to read value once were not implemented, resulting in a error if we tried to call them. To avoid displaying an error popup, we implemented those actions on caliper drivers. opw-4332476 Forward-Port-Of: odoo/enterprise#75847
PoS was displaying a dependency error when trying open the printer selection popup to print a daily sale report. opw-4171163 Forward-Port-Of: odoo/enterprise#75809
Original PR description
PoS was displaying a dependency error when trying open the printer selection popup to print a daily sale report. opw-4171163 Forward-Port-Of: odoo/enterprise#75809
This commit resolves an issue where users encounter a serialization error when attempting to retrieve accounts. The currency_id is now correctly passed and managed to prevent the "currency object is not serializable" error. no task id Forward-Port-Of: odoo/enterprise#75908
Original PR description
This commit resolves an issue where users encounter a serialization error when attempting to retrieve accounts. The currency_id is now correctly passed and managed to prevent the "currency object is not serializable" error. no task id Forward-Port-Of: odoo/enterprise#75908