Search
Navigate
Branch
Tuesday, September 10, 2024
61 changes
30 changes
Enhancements to existing features
The HR module's automated tests were converted to a newer testing framework. This improves maintainability and reliability of internal quality checks without changing user-facing HR functionality.
Original PR description
This PR aims to convert QUnit tests which rely on hr/test_utils to hoot. Part of Task-3818666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds basic automated checks for canned responses in the Mail app. These tests help catch permission or behavior issues earlier, reducing the risk of regressions in future updates.
Resolved issues and error corrections
Installing Point of Sale with demo data could fail when Barcode had already been installed because the demo tax setup lacked a matching tax group for the active company. This fix adds the required demo tax group fallback so the installation completes successfully in that scenario.
Original PR description
### Steps to reproduce: - Create a fresh db with demo data - Activate the "stock_barcode" module - Activate the "point_of_sale" module #### > Error: operation cannot be completed ### Cause of the…
### Steps to reproduce: - Create a fresh db with demo data - Activate the "stock_barcode" module - Activate the "point_of_sale" module #### > Error: operation cannot be completed ### Cause of the issue: Activating the "stock_barcode" module will create a second company. When you activate point of sale with the demo data, it will first install accounting and create a tax group for company 2 and then create the pos demo data: https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/point_of_sale/data/point_of_sale_demo.xml#L74-L78 However, during since no tax group is specified for this account.tax, it is expected to be computed here: https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/account/models/account_tax.py#L221-L222 But since no tax group was created for the current company, this computation will fail to give a result https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/account/models/account_tax.py#L232-L235 and the transaction will be aborted. ### Fix: We create a tax group demo data that will be associated to the same company as the one for which our demo tax is created and hence provide a fall back value in case no other tax group was created. opw-4141575 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
**Current behavior:** Creating an immediate transfer and attempting to allocate it for some existing document will not work- a valid document will not show up in the list of sources. **Expected behavior:** A source that logically matches the immediate transfer should be found for allocation. **Steps to reproduce:** 1. Enable the reception report setting 2. Create a delivery for some product and confirm it 3. Create a receipt transfer and create a move line (not move) for
Original PR description
**Current behavior:** Creating an immediate transfer and attempting to allocate it for some existing document will not work- a valid document will not show up in the list of sources. **Expected…
**Current behavior:**
Creating an immediate transfer and attempting to allocate it for
some existing document will not work- a valid document will not
show up in the list of sources.
**Expected behavior:**
A source that logically matches the immediate transfer should
be found for allocation.
**Steps to reproduce:**
1. Enable the reception report setting
2. Create a delivery for some product and confirm it
3. Create a receipt transfer and create a move line (not move)
for the same amount of the product in the delivery
4. Validate the picking, click the `Allocation` smart button ->
See that the delivery is not listed
**Cause of the issue:**
After the quantity field changes on stock move/move lines, in
`ReceptionReport::_get_report_values()` a move that is created
for an immediate transfer will have a `product_qty == 0`. This
means it is never added as a dict key which is later used to
search for moves belonging to allocation sources.
**Fix:**
Use `move.quantity` when `move.product_qty == 0` to gather valid
out documents when creating the report data.
opw-4075871
Forward-Port-Of: odoo/odoo#17754525 changes
New functionality added to Odoo
Point of Sale can now use Avalara AvaTax to calculate taxes during checkout. This helps businesses apply more accurate tax amounts in POS transactions when they rely on AvaTax for compliance.
Original PR description
Adding `pos_avatax` module that allow to calculate taxes using the Avatax service. taskId: 4135131 Thank to @jot-odoo for his help on this task. Community: https://github.com/odoo/odoo/pull/178079
6 changes
Enhancements to existing features
This update improves the Uruguay electronic invoicing (EDI) system by switching to a dedicated service endpoint. This change enhances the reliability and performance of electronic invoice processing for businesses operating in Uruguay, ensuring better integration with local tax authorities.
Original PR description
no task
This fixes how action aliases are shown in URL paths so they no longer include an unwanted underscore. The change helps keep navigation links cleaner and more consistent for users and integrations.
Original PR description
…ndercore 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
Restaurant point-of-sale order buttons now show only the most relevant product category when a product belongs to multiple categories. This avoids confusing duplicate category labels and makes order information clearer for staff.
Original PR description
Steps to reproduce : - Install pos_restaurant - Go to products - Set 2 pos_categories in a product - Open restaurant and add that product to order Issue : Both categories will be shown in order button and also not in correct sequence. Cause : Trying to show all categories and not the dominant once. Fix : Showing only the dominant once to make it more relatable. task: 3976224
This change adjusts mail/discuss behavior related to WhatsApp notifications so users receive the expected alerts. It aims to correct notification handling in conversations, reducing confusion when messages are sent through WhatsApp.
Original PR description
WIP, needs to be retargetted probably 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
This fix prevents an error from appearing in Odoo logs when users open Accounting settings with the Mexican localization installed in a replicated database setup. It adjusts when configuration view changes are applied so the settings page remains stable during testing and read-only operations.
Original PR description
To reproduce: - Launch Odoo instance with the option --db_replica_host='' - Install l10n_mx - access Settings > Accounting - You'll get the error in the log The Issue During testing, attempting to modify a field's state using the 'get_views' function, which is marked as read-only, results in a read-only error. The Fix: To resolve this, apply changes only when we are not in test mode and ensure the view is initially imported as inactive. runbot-60422 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
This commit will add some document types but also changed a bit the way we manage document type. We now let the possibility to the user to choose the document type he wants thanks to a manyToOne field to a new model. In this commit, we will also add the italian payment method needed for the edi. For that we added a selection field that can be filled with the payment method of the payment or by manually choosing a value. In the journal of bank, we can add some new payment method, by defau
Original PR description
This commit will add some document types but also changed a bit the way we manage document type. We now let the possibility to the user to choose the document type he wants thanks to a manyToOne field to a new model. In this commit, we will also add the italian payment method needed for the edi. For that we added a selection field that can be filled with the payment method of the payment or by manually choosing a value. In the journal of bank, we can add some new payment method, by default the italian payment method will be MP05. In case of partial payment we choose to take the payment method of the first one. task-3770458 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171795
Scenario: - install im_livechat - create a new user with a user that has base.group_erp_manager (Administration > Access Rights) => Access Error because user doesn't have write access to res.users.settings record. Why: res.users.settings model requires base.group_system to be able to write on records of other users, but the res.users method _inverse_livechat_username and _inverse_livechat_lang_ids are writing on it with current users. Fix: Use the return value of `res.users.settings()
Original PR description
Scenario: - install im_livechat - create a new user with a user that has base.group_erp_manager (Administration > Access Rights) => Access Error because user doesn't have write access to res.users.settings record. Why: res.users.settings model requires base.group_system to be able to write on records of other users, but the res.users method _inverse_livechat_username and _inverse_livechat_lang_ids are writing on it with current users. Fix: Use the return value of `res.users.settings()._find_or_create_for_user` for writing since they are returned in superuser mode. opw-4157859 Forward-Port-Of: odoo/odoo#179412
Specification: When creating a percent pie widget in the list view using Studio, the field's name has been added after percent pie, which is not user-friendly. Expected behavior: The duplicate label should not be visible in the list view. Task-3942207 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179102
Original PR description
Specification: When creating a percent pie widget in the list view using Studio, the field's name has been added after percent pie, which is not user-friendly. Expected behavior: The duplicate label should not be visible in the list view. Task-3942207 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179102
IoT Box image build was failing due to missing `libffi-dev` pkg. In addition to that, the previously moved `odoo.conf` was inaccessible due to incorrect access rights. This commit fixes these two problems. Forward-Port-Of: odoo/odoo#179535
Original PR description
IoT Box image build was failing due to missing `libffi-dev` pkg. In addition to that, the previously moved `odoo.conf` was inaccessible due to incorrect access rights. This commit fixes these two problems. Forward-Port-Of: odoo/odoo#179535
We currently save all configurations (db url, enterprise code, token, ...) in different text files. Now we store them all in the already existing file (`odoo.conf`), easy to write and load from python and bash. We also moved the `odoo.conf` file to `/home/pi` on the physical IoT Box, to avoid overwriting it while checking out a new branch. Based on PR from Olivier Monnom (mool): [https://github.com/odoo/odoo/pull/145365](https://github.com/odoo/odoo/pull/145365) Task: 2093535 Forward-
Original PR description
We currently save all configurations (db url, enterprise code, token, ...) in different text files. Now we store them all in the already existing file (`odoo.conf`), easy to write and load from python and bash. We also moved the `odoo.conf` file to `/home/pi` on the physical IoT Box, to avoid overwriting it while checking out a new branch. Based on PR from Olivier Monnom (mool): [https://github.com/odoo/odoo/pull/145365](https://github.com/odoo/odoo/pull/145365) Task: 2093535 Forward-Port-Of: odoo/odoo#173866
Problem: When searching for a reference in contacts, the search checks for an exact match. However, the expected behavior is to use `ilike` to allow partial matches. Steps to reproduce: - Add a reference to any contact (e.g., crutest). - In the list of contacts, search for cru. - No contact will appear. opw-4133302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179678 Forward-Port-Of: odoo/odoo#177864
Original PR description
Problem: When searching for a reference in contacts, the search checks for an exact match. However, the expected behavior is to use `ilike` to allow partial matches. Steps to reproduce: - Add a reference to any contact (e.g., crutest). - In the list of contacts, search for cru. - No contact will appear. opw-4133302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179678 Forward-Port-Of: odoo/odoo#177864
Category tags names are used directly as selectors. Adding spaces to the names leads to tracebacks. Reproduce --- - Install website_event - Create new event category with spaces in it - Open mobile view of all events - Select the category collapsible -> BUG opw-4009122 Forward-Port-Of: odoo/odoo#178850
Original PR description
Category tags names are used directly as selectors. Adding spaces to the names leads to tracebacks. Reproduce --- - Install website_event - Create new event category with spaces in it - Open mobile view of all events - Select the category collapsible -> BUG opw-4009122 Forward-Port-Of: odoo/odoo#178850
- install website_profile - open /profile/edit - BUG: see content overflow in mobile opw-4123897 Forward-Port-Of: odoo/odoo#179324
Original PR description
- install website_profile - open /profile/edit - BUG: see content overflow in mobile opw-4123897 Forward-Port-Of: odoo/odoo#179324
**Current behavior:** Having a product produced via kit bom with FIFO & automated costing method and valuation in a sale order with delivery via dropship: When the orders and transfers are completed and the sale order is invoiced, the stock output and expense account on the invoice will have a credit and dedit (respectively) which is too high (the degree is proportional to the `product_qty` of each move in the dropship transfer). **Expected behavior:** The account entry lines should be a
Original PR description
**Current behavior:** Having a product produced via kit bom with FIFO & automated costing method and valuation in a sale order with delivery via dropship: When the orders and transfers are completed…
**Current behavior:** Having a product produced via kit bom with FIFO & automated costing method and valuation in a sale order with delivery via dropship: When the orders and transfers are completed and the sale order is invoiced, the stock output and expense account on the invoice will have a credit and dedit (respectively) which is too high (the degree is proportional to the `product_qty` of each move in the dropship transfer). **Expected behavior:** The account entry lines should be accurate to the cost of the kit components. **Steps to reproduce:** 1. Create a kit_product such that: - It has FIFO cost method and automated valuation - Has a component in a kit bom, also with FIFO and automated valuation as well as a vendor with non-zero price 2. Create a sale order for 2 of the kit product and set the SOL route to dropship 3. Confirm the sale order, purchase order, and validate the dropship transfer 4. Create an invoice for the sale order and confirm/post it 5. Observe that the stock output and expense accounts have a credit and debit (respectively) for 2x the correct amount **Cause of the issue:** The `product_qty` of each move in the dropship is errantly multiplied with the result of `_compute_average_price()`- this qty has already been taken into account. **Fix:** Remove this piece of the calculation. opw-4050777 Forward-Port-Of: odoo/odoo#178976 Forward-Port-Of: odoo/odoo#176296
Since [1], the `MANDATORY_BILLING_FIELDS` are now returned through the method `/portal._get_mandatory_fields`: https://github.com/odoo/odoo/blob/b454a060a41961b7e0c9cc1ee6ec77b5cca1ec75/addons/portal/controllers/portal.py#L421-L423 Where `MANDATORY_BILLING_FIELDS` is a list defined on the class: https://github.com/odoo/odoo/blob/b454a060a41961b7e0c9cc1ee6ec77b5cca1ec75/addons/portal/controllers/portal.py#L134-L136 This is a problem: the value is an object, so if the list is modified during
Original PR description
Since [1], the `MANDATORY_BILLING_FIELDS` are now returned through the method `/portal._get_mandatory_fields`:…
Since [1], the `MANDATORY_BILLING_FIELDS` are now returned through the method `/portal._get_mandatory_fields`: https://github.com/odoo/odoo/blob/b454a060a41961b7e0c9cc1ee6ec77b5cca1ec75/addons/portal/controllers/portal.py#L421-L423 Where `MANDATORY_BILLING_FIELDS` is a list defined on the class: https://github.com/odoo/odoo/blob/b454a060a41961b7e0c9cc1ee6ec77b5cca1ec75/addons/portal/controllers/portal.py#L134-L136 This is a problem: the value is an object, so if the list is modified during a call, the method will then return that modified list instead of the initial one. For instance, in `l10n_ec_website_sale`, we add some values to that list: https://github.com/odoo/odoo/blob/10b7c27a4fc873c6220d63a0686f484e92ae906b/addons/l10n_ec_website_sale/controllers/portal.py#L14-L17 Then, if we call again `_get_mandatory_fields` with a company that is not EC, we will still have `l10n_latam_identification_type_id` and `vat` in the list of mandatory fields. That is incorrect. Looking at builds on runbot, some of them failed because of that error. This is the case with the FW of [2] on 17.4 which is blocked because of the above issue. Indeed, this commit contains a tour that checkouts a cart with an EC company. And, in 17.4, this flow leads to a call of `_get_mandatory_fields`. As explained, we will therefore add the EC mandatory fields. So, if [2] is part of the code, and if we try to run this: `--test-tags=.test_checkout_address_ec,.test_qr_code_receipt_mx` Where the first test comes from [2] and the second one is an existing test in the code, it will fail: the first test will add some values in `MANDATORY_BILLING_FIELDS`. Then, during the second test, at some point we also check the mandatory fields: the method will return the modified list (i.e., with the EC fields), and we will not have any value for these unexpected fields -> the test will fail [1] 9b9b0ee4c2d8a8a66e5e0456acbb780e5d8d6456 [2] 732b4fbbf3009769708f9c9cba57609d22f2a570 Forward-Port-Of: odoo/odoo#177349
When an invoice is linked to a sale order or more, the ReceiverTransactionReference tag should be included in the Factura-E XML per invoice line with the value of the Customer Reference field of the Sale Order linked to that line. This commit handles this. task-4134422 Forward-Port-Of: odoo/odoo#178360
Original PR description
When an invoice is linked to a sale order or more, the ReceiverTransactionReference tag should be included in the Factura-E XML per invoice line with the value of the Customer Reference field of the Sale Order linked to that line. This commit handles this. task-4134422 Forward-Port-Of: odoo/odoo#178360
Currently, when applying two discounts (from loyalty programs) that are applied on specific products, the second discount value does not match with the setup of the reward. Steps to reproduce: ------------------- * Go to the **Point of Sale** App * Create a new product, P -> Price 100$, no tax applied * Under **Products** select **Discount & loyalty** * Create a new loyalty program * Rule 10 points per $ spent * Reward 1: 10$ on P for 10 points * Reward 2: 50$ on P for 40 points
Original PR description
Currently, when applying two discounts (from loyalty programs) that are applied on specific products, the second discount value does not match with the setup of the reward. Steps to reproduce:…
Currently, when applying two discounts (from loyalty programs) that are applied on specific products, the second discount value does not match with the setup of the reward. Steps to reproduce: ------------------- * Go to the **Point of Sale** App * Create a new product, P -> Price 100$, no tax applied * Under **Products** select **Discount & loyalty** * Create a new loyalty program * Rule 10 points per $ spent * Reward 1: 10$ on P for 10 points * Reward 2: 50$ on P for 40 points * Open shop session * Add P to the order * Add reward 1 * Add reward 2 > Observation: The first reward is 10$ but the second is 55$ Why the fix: ------------ We will use the example from the given steps to explain what happens. https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1376-L1377 On the first line of the above `discountable` and `discountablePerTax` will be 100. On the second line `discountable` will be 90 as the order total is 90, as the discount is counted here. https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1417 Here we have `masDiscount` being 50 (`reward.discount`). Thus we end up with `discountFactor = min(1, 0.555)`. This factor is later on used to set the price of the discount line. The price is set up as follow. https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1426 Where entry one corresponds to the value of `discountablePerTax` which is 100. Thus the discount is valued at `0.555 * 100 = 55.5$`. To solve this we make `discountable` and `discountablePerTax` account for the discounts that aleady apply on the same product. We then look at what happens in the function `_getDiscountableOnSpecific` as in our case it corresponds to `getDiscountable`. https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1250-L1251 As this comment says we don't want to discount more than what is available. In our case only 90$ are available since we have already applied the 10$ discount. https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1269-L1273 We see that when we scan through the order lines, only discount from the same reward as the one we are trying to apply are counted. In short, if we were trying to apply another 10$ discount instead of the 50, then the line would be counted. But since the 10$ and 50$ discounts apply on the same product, they should both be counted. We want to add more discount lines to `linesToDisount` because at the end, it is used compute `discountable` and `discountablePerTax`. https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1331-L1341 We want to add the discount lines that applies to at least one product of the current reward. But we also need to check if that common product is on the order. If we imagine reward 1 applied on P1, reward 2 applied on P1 and P2 but we only have P2 in the order then reward 1 should not count when applying reward 2. We filter on the `reward_type` to exclude lines that are related to free products rewards. With the current change there is a difference in behaviors when the discount is a percentage or a fixed amount. Since we now count the discounts at the end, we can remove this part of the code as it would count twice the discounts that are percentages. https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1298-L1309 opw-4083557 Forward-Port-Of: odoo/odoo#179379 Forward-Port-Of: odoo/odoo#178352
Prior to this commit, clicking on an optional product within the product info popup would fail to locate the optional product due to product template filtering applied to product variants. This commit resolves the issue by applying product template filtering exclusively for variants, ensuring optional products are correctly displayed from the product info popup. opw-4097824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo
Original PR description
Prior to this commit, clicking on an optional product within the product info popup would fail to locate the optional product due to product template filtering applied to product variants. This commit resolves the issue by applying product template filtering exclusively for variants, ensuring optional products are correctly displayed from the product info popup. opw-4097824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176168
### Steps to reproduce: - Go to Inventory > Configutation > Products > Barcode Nomenclatures - Click on Default Nomenclature > Add a line with the invalid barcode Pattern: "****" and put that one on the top of the list - Open a POS session > click on the list icon on the right corner - Debug window > enter any barcode and scan #### > Odoo Error: Invalid regular expression "****" ### Cause of the issue: The pattern field of the barcode.rule model that we created does not lead to a
Original PR description
### Steps to reproduce: - Go to Inventory > Configutation > Products > Barcode Nomenclatures - Click on Default Nomenclature > Add a line with the invalid barcode Pattern: "****" and put that one on the top of the list - Open a POS session > click on the list icon on the right corner - Debug window > enter any barcode and scan #### > Odoo Error: Invalid regular expression "****" ### Cause of the issue: The pattern field of the barcode.rule model that we created does not lead to a valid regular expression but is used as such by the String.match calls done in the "barcode_parser": https://github.com/odoo/odoo/blob/28871371c39bcc164e167842cf7212ce05f49a51/addons/barcodes/static/src/js/barcode_parser.js#L124-L130 opw-4100030 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179473 Forward-Port-Of: odoo/odoo#178096
**Steps to reproduce:** 1- Install POS and POS restaurant 2- Activate self ordering 3- Create a self order from the mobile menu 4- Create another order from the Shop POS **Current behavior before PR:** There is a conflict happening in order numbers between Self order and other orders where at some point we might have two orders with the same number. This is happening because when adding the order from Shop we get the sequence number from the JS side in Order class https://github.com
Original PR description
**Steps to reproduce:** 1- Install POS and POS restaurant 2- Activate self ordering 3- Create a self order from the mobile menu 4- Create another order from the Shop POS **Current behavior before…
**Steps to reproduce:** 1- Install POS and POS restaurant 2- Activate self ordering 3- Create a self order from the mobile menu 4- Create another order from the Shop POS **Current behavior before PR:** There is a conflict happening in order numbers between Self order and other orders where at some point we might have two orders with the same number. This is happening because when adding the order from Shop we get the sequence number from the JS side in Order class https://github.com/odoo/odoo/blob/d82ffde0b316c52f726c247bf6f3d38e2e73e405/addons/point_of_sale/static/src/app/store/models.js#L1383 but in case of self order. We get it from ir_sequence https://github.com/odoo/odoo/blob/d82ffde0b316c52f726c247bf6f3d38e2e73e405/addons/pos_self_order/controllers/orders.py#L19 So we don't have a shared sequence between them. **Desired behavior after PR is merged:** We are now creating another sequence for self-order and as agreed with the PO we will have 'S' before the order number if the order is self-order opw-3809595 Forward-Port-Of: odoo/odoo#162119
**Current behavior:** Having some product with FIFO cost method, if you use it as a component in an MO, confirm and produce all, then unlock the MO and adjust the component quantity to be smaller than originally entered, the standard price of the product will be set to zero. **Expected behavior:** This operation should not affect the standard price of the product. **Steps to reproduce:** 1. Create a product with FIFO cost method and real time valuation 2. Create a purchase
Original PR description
**Current behavior:** Having some product with FIFO cost method, if you use it as a component in an MO, confirm and produce all, then unlock the MO and adjust the component quantity to be smaller…
**Current behavior:**
Having some product with FIFO cost method, if you use it as a
component in an MO, confirm and produce all, then unlock the MO
and adjust the component quantity to be smaller than originally
entered, the standard price of the product will be set to zero.
**Expected behavior:**
This operation should not affect the standard price of the
product.
**Steps to reproduce:**
1. Create a product with FIFO cost method and real time
valuation
2. Create a purchase order for 10 of the fifo product, set the
price unit on the order line to 100
3. Confirm the order and receive the product
4. Create a manufacturing order for 1 of some other product, and
set the components to be 100 of the fifo product
5. Confirm the MO, consume the fifo product and produce all
6. Unlock the order and set the quantity of components consumed
to 1 (from 100)
7. Observe that the standard price of fifo product is now 0
**Cause of the issue:**
A move for an MrpProduction record has a price unit == 0. Commit
https://github.com/odoo/odoo/commit/1fb4d356b5115a82dbbb004efe2e26917021b339 forces use of this when a move's picking type is
manufacturing, however it should be a narrower condition to only
do so when the move corresponds to the finished moves of a
manufacturing order.
**Fix:**
Moves for components of a production should not be able to
modify the `standard_price` of the moved product- only the final
product's cost should be able to change based on the value of
such a move.
Use a product's `standard_price` field when creating SVLs for
moves corresponding to raw production moves.
opw-4134037
Forward-Port-Of: odoo/odoo#178015When a custom postgresql function is used (`ODOO_NOTIFY_FUNCTION` environment variable is set), testing to listen to imbus should be skipped --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178986
Original PR description
When a custom postgresql function is used (`ODOO_NOTIFY_FUNCTION` environment variable is set), testing to listen to imbus should be skipped --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178986
When you made a downpayment on an order that contains different products with different unique tax combination, each invoice line would show that it's linked to all the sale order lines. Steps to reproduce: ------------------- * Create some taxes T1 T2 and T3 * Create an order with 3 lines and put one tax on each line * Open the PoS and make a downpayment for the order * Pay and invoice the order > Observation: Each line in the invoice show that it is applying the downpayment to the co
Original PR description
When you made a downpayment on an order that contains different products with different unique tax combination, each invoice line would show that it's linked to all the sale order lines. Steps to reproduce: ------------------- * Create some taxes T1 T2 and T3 * Create an order with 3 lines and put one tax on each line * Open the PoS and make a downpayment for the order * Pay and invoice the order > Observation: Each line in the invoice show that it is applying the downpayment to the complete sale order Why the fix: ------------ We make sure to only show the sale order line that have the same tax combination opw-4089408 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178061
Steps to reproduce ================== - Use Epiphany (a webkit based browser, like Safari) - Add `time.sleep(3)` inside `action_get_share_url` to simulate a slow network as it isn't possible inside the epiphany devtools - Go to dashboard - Click on Share => NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. Cause of the issue ================== The delay between the user click
Original PR description
Steps to reproduce ================== - Use Epiphany (a webkit based browser, like Safari) - Add `time.sleep(3)` inside `action_get_share_url` to simulate a slow network as it isn't possible inside the epiphany devtools - Go to dashboard - Click on Share => NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. Cause of the issue ================== The delay between the user click and the actual copy is to slow for the trused event to be recognized as the origin of the copy. It is thus not allowed. Note that it also fails in Chrome if the document is out of focus in the meantime. Solution ======== Wrap the copy in a try catch. If it fails, the user can always use the copy button. opw-4144551 Forward-Port-Of: odoo/odoo#178852
Steps to reproduce: - Have two Companies A and B - Create an Analytic Account (AA) for Company A - In B (A multiselected), create an invoice: company=Company B Set the AA analytic Distribution - Unselect company A and try to enter the invoice Issue: Access error Solution: After discussion with PO tsb, children companies need to have access to analytic account (and analytic related stuff) from parent opw-3764627 Forward-Port-Of: odoo/odoo#179282
Original PR description
Steps to reproduce: - Have two Companies A and B - Create an Analytic Account (AA) for Company A - In B (A multiselected), create an invoice: company=Company B Set the AA analytic Distribution - Unselect company A and try to enter the invoice Issue: Access error Solution: After discussion with PO tsb, children companies need to have access to analytic account (and analytic related stuff) from parent opw-3764627 Forward-Port-Of: odoo/odoo#179282
Problem: The account tax report was displaying "Matla" instead of "Malta" Purpose: Fix the type to stay consistent with naming conventions opw-4134520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178110
Original PR description
Problem: The account tax report was displaying "Matla" instead of "Malta" Purpose: Fix the type to stay consistent with naming conventions opw-4134520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178110
Currently, a traceback is occurring when the user tries to download multiple e-Faktur at a time. To reproduce this issue: 1) Install `l10n_id_efaktur` 2) Select multiple customer invoices from an accounting 3) Try to `Download e-Faktur` from actions Error:- ``` ValueError: Expected singleton: account.move(65, 57,) ``` This is because when the user selects multiple invoices, the `self` contains multiple recordsets. Which leads to a traceback when `l10n_id_need_kode_transaksi` is
Original PR description
Currently, a traceback is occurring when the user tries to download multiple e-Faktur at a time. To reproduce this issue: 1) Install `l10n_id_efaktur` 2) Select multiple customer invoices from an accounting 3) Try to `Download e-Faktur` from actions Error:- ``` ValueError: Expected singleton: account.move(65, 57,) ``` This is because when the user selects multiple invoices, the `self` contains multiple recordsets. Which leads to a traceback when `l10n_id_need_kode_transaksi` is accessing from self. https://github.com/odoo/odoo/blob/4f044aade6e2a461c854899a8854474e3b22b6d5/addons/l10n_id_efaktur/models/account_move.py#L134-L139 Already a loop is there in that method, so by just changing self with record we can resolve this issue. sentry-5809438159 Forward-Port-Of: odoo/odoo#179597
Odoo now includes payroll localization for Jordan, covering local salary structures, rules, and contract fields. The update also connects payroll with accounting so Jordan payroll entries can be posted more consistently, with basic tests added to help protect the setup.
Original PR description
Payroll localization for Jordan Ticket [3243941](https://www.odoo.com/odoo/project.task/3243941)
Enhancements to existing features
WhatsApp channels now support sub-threads, helping teams keep related customer messages grouped more clearly. This improves conversation tracking and makes it easier for users to follow separate discussion topics within the same channel.
Original PR description
task-3972988
Failed quantities from quality checks are now separated into their own stock moves instead of only separate move lines. This helps ensure follow-up warehouse rules, such as moving failed goods to another location, are applied correctly; quantity-based quality checks are also avoided for manufacturing orders.
Original PR description
Previous to this commit, failed quantities in quality checks controlled per quantity were split into a separate move line in the same stock move. This prevents triggering additional push rules, specially if failed quantities are moved to a different location. This commit splits the failed quantities into their own move. Task-4063922
Department visibility has been expanded so managers can access department sections even without broader HR permissions. This helps managers better understand activity and context within their own departments while keeping the change focused on HR-related views and reports.
The rental sales kanban views were simplified to make them easier to read and maintain. This updates the layout to use newer Odoo interface patterns, helping ensure a more consistent experience without changing core business workflows.
Original PR description
In this commit we have simplified the kanban arch for the sale and their related modules.the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of <field/> tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use <field name="..." widget="image"/> instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color="color_field_name" on root node Task-3992107
The Studio customization icon is now hidden from the systray when users open a project to-do form. This prevents users from accessing Studio actions in a context where they are not intended, reducing confusion and keeping the form experience focused.
Original PR description
- master ### Improvement Studio icon will disabled from systray for project todo form view. task - 3995765
Approval and Frontdesk kanban card layouts were simplified to use newer interface building blocks. This makes the views easier to maintain and helps keep the user experience aligned with current Odoo standards.
Original PR description
In this commit we have simplified the kanban arch for the approvals and frontdesk modules.the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of `<field/>` tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use <field name=... widget=image/> instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node Task-3992107
Helpdesk ticket and team cards were simplified to use newer standard layouts and controls. This makes the interface easier to maintain and helps keep Helpdesk aligned with current Odoo UI practices, with limited direct impact on daily workflows.
Original PR description
In this commit we have simplified the kanban arch for the helpdesk and helpdesk_timesheet modules.the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of `<field/>` tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use <field name=... widget=image/> instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node Task-3992107
This update replaces an outdated internal label used for list views across several accounting-related screens. The change helps keep the product terminology consistent and reduces confusion for future maintenance, with little expected impact on day-to-day users.
Original PR description
Remove historical error from semantically incorrect <tree>. Viewtiverse task-3599136 task-27709
Resolved issues and error corrections
This fixes an issue where editing a food delivery order in Point of Sale and going back could create duplicate order lines. Orders now keep the correct line identity, reducing billing mistakes and manual cleanup for restaurant staff.
Original PR description
Steps: - Install pos_urban_piper - Open Point of Sale. - Configure Food Delivery Connector for one of pos - Place a test order. - Edit order and add a new product. - Press Back button Issue: - Duplicate orderline is been created. Fix: - uuid was not handled while creating orderline which is been taken care of from this commit. task-4147488
Miscellaneous changes
task-4068657 Forward-Port-Of: odoo/enterprise#68619
Original PR description
task-4068657 Forward-Port-Of: odoo/enterprise#68619
New module for electronic invoicing Forward-Port-Of: odoo/enterprise#69605 Forward-Port-Of: odoo/enterprise#51266
Original PR description
New module for electronic invoicing Forward-Port-Of: odoo/enterprise#69605 Forward-Port-Of: odoo/enterprise#51266
The stepDelay argument in the l10n_co_edi_website_sale tour tests fails when loading the js for the tours https://runbot.odoo.com/web/#id=77298&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form Forward-Port-Of: odoo/enterprise#69732
Original PR description
The stepDelay argument in the l10n_co_edi_website_sale tour tests fails when loading the js for the tours https://runbot.odoo.com/web/#id=77298&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form Forward-Port-Of: odoo/enterprise#69732
Since the convertion of the gantt view to OWL in saas-16.1 the search_default_* type context is no longer passed from the gantt view to the gantt.form dialog window of a record, thus the "I am unavailable" button couldn't appear anymore replaced the search_default domain by 'my_planning_action' in planning gantt view and transmited the corresponding context through the openDialog method in the planning_gantt_controller Task-3819134 Forward-Port-Of: odoo/enterprise#69714 Forward-Port-Of: o
Original PR description
Since the convertion of the gantt view to OWL in saas-16.1 the search_default_* type context is no longer passed from the gantt view to the gantt.form dialog window of a record, thus the "I am unavailable" button couldn't appear anymore replaced the search_default domain by 'my_planning_action' in planning gantt view and transmited the corresponding context through the openDialog method in the planning_gantt_controller Task-3819134 Forward-Port-Of: odoo/enterprise#69714 Forward-Port-Of: odoo/enterprise#59226
Current behaviour: --- Ivory Coast phone numbers aren't formatted correctly `0708151718 => 225708151718` Expected behaviour: --- `0708151718 => 2250708151718` National number leading zero should be preserved Steps to reproduce: --- ```py from ... import phone_validation as wa_phone_validation wa_phone_validation.wa_phone_format( record, number='0708151718', force_format="WHATSAPP", ) ``` Result => `'225708151718'` Should be => `'2250708151718'` NB: record has an
Original PR description
Current behaviour: --- Ivory Coast phone numbers aren't formatted correctly `0708151718 => 225708151718` Expected behaviour: --- `0708151718 => 2250708151718` National number leading zero should be…
Current behaviour:
---
Ivory Coast phone numbers aren't formatted correctly
`0708151718 => 225708151718`
Expected behaviour:
---
`0708151718 => 2250708151718`
National number leading zero should be preserved
Steps to reproduce:
---
```py
from ... import phone_validation as wa_phone_validation
wa_phone_validation.wa_phone_format(
record, number='0708151718',
force_format="WHATSAPP",
)
```
Result => `'225708151718'`
Should be => `'2250708151718'`
NB: record has an Ivory Coast `country_id`
Cause of the issue:
---
`WHATSAPP format` is country_code + national_number
But because `national_number` is an `int`, the leading zero gets removed.
Fix:
---
See [phonenumbers/phonenumber.py](https://github.com/daviddrysdale/python-phonenumbers/blob/7f60158f325ed2ee14212b71ef7e7dc2ce5f01bb/python/phonenumbers/phonenumber.py#L124 )
The `italian_leading_zero` is set True when the national number starts with a zero,
and it should be kept. (ie: Italian numbers) `number_of_leading_zeros` counts the zeros.
Taking those into account when formatting.
opw-3963124
Forward-Port-Of: odoo/enterprise#67132Open consolidation dashboard Try to access any Consolidated Balance Traceback File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 4766, in _get_annotations_domain_date_from if options['date']['filter'] in {'today', 'custom'} and options['date']['mode'] == 'single': ~~~~~~~^^^^^^^^ KeyError: 'date' This occurs because when opening consolidation reports a custom inizializer will remove the date from options dict https://github.com/odoo/enterprise/blob
Original PR description
Open consolidation dashboard
Try to access any Consolidated Balance
Traceback
File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 4766, in _get_annotations_domain_date_from if options['date']['filter'] in {'today', 'custom'} and options['date']['mode'] == 'single': ~~~~~~~^^^^^^^^
KeyError: 'date'
This occurs because when opening consolidation reports a custom inizializer will remove the date from options dict https://github.com/odoo/enterprise/blob/67986c6492f38703b0ec4c81199dab1e4d8fc3d6/account_consolidation/report/trial_balance.py#L38
opw-4154017
Forward-Port-Of: odoo/enterprise#69398Current behaviour: --- When you create a campaign, if you add more activity (56) than the default pager limit (40) The next pager page will be empty (instead of showing the remaining 16 activities) Steps to reproduce: --- 1. Go to Marketing Automation 2. Create a campaign 3. Create more than 40 activities 4. Alternate parents/child when creating 5. The pager will appear, with at least 2 pages 6. Go to the second page 7. Nothing displayed NB: When inputting the number of activitie
Original PR description
Current behaviour: --- When you create a campaign, if you add more activity (56) than the default pager limit (40) The next pager page will be empty (instead of showing the remaining 16 activities)…
Current behaviour: --- When you create a campaign, if you add more activity (56) than the default pager limit (40) The next pager page will be empty (instead of showing the remaining 16 activities) Steps to reproduce: --- 1. Go to Marketing Automation 2. Create a campaign 3. Create more than 40 activities 4. Alternate parents/child when creating 5. The pager will appear, with at least 2 pages 6. Go to the second page 7. Nothing displayed NB: When inputting the number of activities in the pager, everything is rendered fine. Cause of the issue: --- To be displayed, the activities are hierarchised, by finding child and parents (`_getSortedRecordsByHierarchy`) However this system works great when all the records are given. Using a pager, some records are not used in the hierarchy, causing the outputted list to be incomplete. (ie if an activity A is in the first 40 and the child in the last 16, it will not be rendered correctly) Fix: --- Disabling the pager by setting a higher limit opw-4006610 Forward-Port-Of: odoo/enterprise#69363 Forward-Port-Of: odoo/enterprise#67979
Step to reproduce: 1. Setup barcodelookup 2. Try with 7501030682332 Error: an Odoo Error is displayed "AttributeError: 'dict' object has no attribute 'content'" Getting the image leads to a 418 response and in such case, we return a dict with few informations https://github.com/odoo/enterprise/blob/abcffc2744f9867fc63bb4e658fcfc1c9cba573f/product_barcodelookup/tools/barcode_lookup_service.py#L19-L25 but the current code considers that the response will always have be a `Response` ob
Original PR description
Step to reproduce: 1. Setup barcodelookup 2. Try with 7501030682332 Error: an Odoo Error is displayed "AttributeError: 'dict' object has no attribute 'content'" Getting the image leads to a 418 response and in such case, we return a dict with few informations https://github.com/odoo/enterprise/blob/abcffc2744f9867fc63bb4e658fcfc1c9cba573f/product_barcodelookup/tools/barcode_lookup_service.py#L19-L25 but the current code considers that the response will always have be a `Response` object with a content: https://github.com/odoo/enterprise/blob/9319cfa788033bda7a0be084075c6dd2fd82e8ac/product_barcodelookup/models/product_template.py#L44-L46 sentry-5790228190 Forward-Port-Of: odoo/enterprise#69419
The employee name is cropped if too long on the appraisal form view. The field can be extended to full width to handle any name. Task: 4163637 Forward-Port-Of: odoo/enterprise#69409
Original PR description
The employee name is cropped if too long on the appraisal form view. The field can be extended to full width to handle any name. Task: 4163637 Forward-Port-Of: odoo/enterprise#69409
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a product P (no need for a bom) - Create and confirm a manufacturing order for 2 units of the product - Go to the barcode module > operations > manufacturing > the MO - Register only one unit of P and produce #### > A backorder is automatically created but you are redirected to t
Original PR description
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a…
### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a product P (no need for a bom) - Create and confirm a manufacturing order for 2 units of the product - Go to the barcode module > operations > manufacturing > the MO - Register only one unit of P and produce #### > A backorder is automatically created but you are redirected to the backend. ### Note: If you were in "ask" on create backorder or if your product had a bom and you did not register the quantities of consumed components, a pop up would appear and resolving the pop up would redirect you to the kanban view of mrp.production in the barcode module. ### Cause of the issue: The issue was originally solved by commit d90acab by overriding the `action_backorder` however, since commit 1e5c82f the action_backorder is no more part of the flow in "always" flows. opw-3890886 Forward-Port-Of: odoo/enterprise#69540 Forward-Port-Of: odoo/enterprise#69169
Description: - This PR introduces an Rs. 1 tolerance for amount matching to prevent unnecessary bill creation for minor discrepancies (e.g., paisa differences). It also improves bill reference number matching by handling special characters and comparing numerically as text. Impact: - Reduces unnecessary bill creation. - Enhances accuracy in matching bill reference numbers. Task ID: 3975209 Forward-Port-Of: odoo/enterprise#66121
Original PR description
Description: - This PR introduces an Rs. 1 tolerance for amount matching to prevent unnecessary bill creation for minor discrepancies (e.g., paisa differences). It also improves bill reference number matching by handling special characters and comparing numerically as text. Impact: - Reduces unnecessary bill creation. - Enhances accuracy in matching bill reference numbers. Task ID: 3975209 Forward-Port-Of: odoo/enterprise#66121
Versions -------- - 16.0+ Steps ----- 1. Enable Belgian localization; 2. create a public holiday; 3. have a contracted employee with CP200 salary structure; 4. make sure they get representation fees; 5. create a month-long maternity leave overlapping the holiday; 6. generate a payslip for that month. Issue ----- Employee receives representation fees, meant to compensate work expenses, despite not having worked that month. Cause ----- Representation fee calculation is curren
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Belgian localization; 2. create a public holiday; 3. have a contracted employee with CP200 salary structure; 4. make sure they get representation fees; 5. create a month-long maternity leave overlapping the holiday; 6. generate a payslip for that month. Issue ----- Employee receives representation fees, meant to compensate work expenses, despite not having worked that month. Cause ----- Representation fee calculation is currently based on "paid days" rather than days where the employee worked. As maternity leave is unpaid, the employee would normally not get representation fee, but because of the paid public holiday, the calculation continues as if the worker wasn't on leave. Solution -------- Check the `work_entry_type_id` of worked days, and skip representation fee calculation if all have `is_leave` set to `True`. opw-3908980 Forward-Port-Of: odoo/enterprise#69742 Forward-Port-Of: odoo/enterprise#68462
Steps to reproduce the bug: 1. Install the Sales and Loyalty apps. 2. Create a sales order for 'client x' and assign a loyalty reward to it. 3. Invoice the sales order with a down payment. 4. Navigate to the Helpdesk app and create a ticket for 'client x'. 5. Create a task for the ticket and check the Sales order item list. Issue: The sales order item list incorrectly includes down payments and loyalty rewards due to an imprecise domain. Solution: Adding a domain function that we ca
Original PR description
Steps to reproduce the bug: 1. Install the Sales and Loyalty apps. 2. Create a sales order for 'client x' and assign a loyalty reward to it. 3. Invoice the sales order with a down payment. 4. Navigate to the Helpdesk app and create a ticket for 'client x'. 5. Create a task for the ticket and check the Sales order item list. Issue: The sales order item list incorrectly includes down payments and loyalty rewards due to an imprecise domain. Solution: Adding a domain function that we can override computed field where it's necessary, to filter the sale_order_line records accurately. opw-4001226 odoo pr : https://github.com/odoo/odoo/pull/173667 Forward-Port-Of: odoo/enterprise#69570 Forward-Port-Of: odoo/enterprise#66388
Using distinct websockets (ws) per company cause a lot of diffent issues, for example: ## Issue this PR solve: ### Multi-company: Assume we have an IoT with no company set. In this case, it should be able to print from any company. In practice, it is not the case as the IoT will listen to the channel of the first company, so it will always fail if the user company is not the first one. Same goes if we have child companies, if C2 is a child company of C1, then C2 should be able to print
Original PR description
Using distinct websockets (ws) per company cause a lot of diffent issues, for example: ## Issue this PR solve: ### Multi-company: Assume we have an IoT with no company set. In this case, it should be…
Using distinct websockets (ws) per company cause a lot of diffent issues, for example: ## Issue this PR solve: ### Multi-company: Assume we have an IoT with no company set. In this case, it should be able to print from any company. In practice, it is not the case as the IoT will listen to the channel of the first company, so it will always fail if the user company is not the first one. Same goes if we have child companies, if C2 is a child company of C1, then C2 should be able to print too. With current code it is not the case as C1 and C2 will have distincts channels ### Change of IoT company: When the IoT start, it makes a call to know its channel (see iot/setup route). However, if we change the company set on the IoT, it should change its channel to match the one of newly set company. In practice it is not the case and will only happen on the next iot/setup call (which happen each 3 seconds call in theory IF new devices are detected) ### Simplicity Help simplifying the code as it was sometime complicated to be get the right websocket. For example, when the IoT reply back that the operation completed, see `/iot/printer/status` route. Relying on the IoT device company might be wrong as if no company is set, we don't know the company that the user who did the request is, so we might send on the bus on the wrong channel. In this case, the document did print but the pop-up will still pop ### Visibility The iot.channel had no practical way to be browsed as there is no view defined for this model. The only feasible way to get its data for a functional would be to run a server action or create a view. Using a system parameter is more practical and only accessible for admin users ## Downside of this PR: - system parameter could be modified manually - websocket send/receive more messages - stability: to ease the transition, I tried to get the existing ws channel using basic heuristics, but it might be wrong (if a company other than the first is set on the IoT). In the worst case, they will have to restart their IoT to get the new channel opw-4038176 Forward-Port-Of: odoo/enterprise#68308 Forward-Port-Of: odoo/enterprise#66573
Resolved issues and error corrections
This update corrects a layout issue in the HR Payroll module where the "Availability in Structure" field was displayed in the wrong position. The fix ensures the field appears in the correct location alongside other input type settings, improving the user interface organization and usability.
Original PR description
This commit fix a design issue in the hr_payroll where the "Availability in Structure" field was incorrectly positioned among other input types. task-4050183 Forward-Port-Of: odoo/enterprise#67532
Fixed an issue in Odoo Studio where the editor menu was not updating when users switched between different tabs such as views and automations. Now the menu properly refreshes to reflect the selected tab, improving the user experience when navigating between different studio features.
Original PR description
Before this commit, in studio, the editorMenu was not updated when clicking on a different tab (views, automations etc...) After this commit, the menu is updated.
This update fixes failing automated tests in the Colombian EDI website sales module. The tests were breaking due to an incorrect stepDelay argument in the test code. This fix ensures that the automated testing process runs smoothly without errors.
Original PR description
The stepDelay argument in the l10n_co_edi_website_sale tour tests fails when loading the js for the tours https://runbot.odoo.com/web/#id=77298&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form
This fix resolves a crash that occurred when users tried to view the Cash Flow Statement report under certain journal configurations. The issue happened when the system couldn't find payment accounts to query, causing a database error. Now the report will display properly even when payment accounts are unavailable.
Original PR description
Currently, an exception is generated when the user tries to open the "Cash Flow Statement" report. Steps to produce an error: - install 'Accounting Reports' - Open Accounting > Configuration >…
Currently, an exception is generated when the user tries to open the "Cash Flow Statement" report.
Steps to produce an error:
- install 'Accounting Reports'
- Open Accounting > Configuration > Accounting > Journals
- Now delete all journals except "Miscellaneous Operations"
- change type of "Miscellaneous Operations" to sales > sale
- Click Reporting > click "Cash Flow Statement" >>> exception occurs
Stack Trace:
```
SyntaxError: syntax error at or near ")"
LINE 28: ... AND account_move_line.account_id NOT IN ((), ())
^
File "odoo/http.py", line 2373, in __call__
response = request._serve_db()
File "odoo/http.py", line 1903, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1966, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1933, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2177, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 4872, in get_report_information
'lines': self._get_lines(options, all_column_groups_expression_totals=all_column_groups_expression_totals, warnings=warnings),
File "home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 2275, in _get_lines
dynamic_lines = self._get_dynamic_lines(options, all_column_groups_expression_totals, warnings=warnings)
File "home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 2705, in _get_dynamic_lines
rslt = self.env[self.custom_handler_model_name]._dynamic_lines_generator(self, options, all_column_groups_expression_totals, warnings=warnings)
File "home/odoo/src/enterprise/saas-17.4/account_reports/models/account_cash_flow_report.py", line 16, in _dynamic_lines_generator
report_data = self._get_report_data(report, options, layout_data)
File "home/odoo/src/enterprise/saas-17.4/account_reports/models/account_cash_flow_report.py", line 57, in _get_report_data
for aml_groupby_account in self._get_liquidity_moves(report, options, currency_table_query, payment_account_ids, cashflow_tag_ids):
File "home/odoo/src/enterprise/saas-17.4/account_reports/models/account_cash_flow_report.py", line 365, in _get_liquidity_moves
self._cr.execute(SQL(' UNION ALL ').join(queries))
File "odoo/sql_db.py", line 347, in execute
res = self._obj.execute(query, params)
```
This is because at the time of query building for getting liquidity moves, it gets an empty tuple from line [1] as we do not have any journals with the type 'bank', 'cash', or 'general'.
This commit will fix the above issue by returning empty report_data when payment_account_ids is empty.
[1] - https://github.com/odoo/enterprise/blob/8fa01948610809d191b75260772782e25ea3a737/account_reports/models/account_cash_flow_report.py#L195
sentry-5555757610This fix prevents the system from automatically overwriting planned dates that users manually set on tasks. Previously, when users entered specific planned hours outside normal working hours, the system would incorrectly replace those dates. Now the system respects user-entered dates while still maintaining automatic scheduling for bulk task operations.
Original PR description
Versions -------- - 15.0+ Steps ----- 1. Have a task assigned to you; 2. ensure planned hours are empty; 3. plan the task partially outside working hours (e.g. 16:00 -> 21:00); 4. save. Issue ----- Planned hours are overwritten. Cause ----- Commit 52536bf8bb5 added logic to provide schedule-based start dates for tasks created in Gantt view, as well as other tasks, by overwriting the provided (default) date values. Solution -------- As of commit 0eda2ab1332, Gantt task dates are planned in JS, and skipped in the back-end due to the `smart_task_scheduling` context value. Therefore we can skip the overwriting of dates if we're working on a single record, which would usually be from a form view. This way, we can still do schedule-based planning when batch processing from list view. opw-3947876 Forward-Port-Of: odoo/enterprise#68909 Forward-Port-Of: odoo/enterprise#65404