Odoo Changelog — 2024-09-10

Tuesday, September 10, 2024

50 changes

Branch: saas-17.2

29 changes

Improvements(2)

Enhancements to existing features

[IMP] hr: convert tests to hoot

PR #176343

Coresaas-17.2hr

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

#tests#quality#maintenance

[IMP] mail: add some basic canned response tests

PR #157973

Coresaas-17.2mail

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.

#tests#canned responses#quality

Bug Fixes(4)

Resolved issues and error corrections

[FIX] point_of_sale: install pos with demo data

PR #178218

Coresaas-17.2point_of_sale

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

Other(23)

Miscellaneous changes

[FW][FIX] stock: handle immediate transfers reception report

PR #179708

Coresaas-17.2stock

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#177545

Branch: master

19 changes

Improvements(5)

Enhancements to existing features

[DRAFT][IMP] sale_renting: simplify kanban archs

PR #67236

Enterprisemastersale_renting

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

Branch: 17.0

2 changes

Bug Fixes(2)

Resolved issues and error corrections

[FW][FIX] hr_payroll: fix design issue in hr_payroll

PR #69761

Enterprise17.0hr_payroll

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

#ui#payroll#design

### 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

**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#177545

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

**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 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

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

**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#178015

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: 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 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#67132

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#69398

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` 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

### 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

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 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 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

Branch: saas-17.2

Improvements(2)

[IMP] hr: convert tests to hoot

[IMP] mail: add some basic canned response tests

Bug Fixes(4)

[FIX] point_of_sale: install pos with demo data

Other(23)

[FW][FIX] stock: handle immediate transfers reception report

Branch: master

Improvements(5)

[DRAFT][IMP] sale_renting: simplify kanban archs

Branch: 17.0

Bug Fixes(2)

[FW][FIX] hr_payroll: fix design issue in hr_payroll

Branch: saas-17.2

Improvements(2)

[IMP] hr: convert tests to hoot

[IMP] mail: add some basic canned response tests

Bug Fixes(4)

[FIX] point_of_sale: install pos with demo data

Other(23)

[FW][FIX] stock: handle immediate transfers reception report

Branch: master

Improvements(5)

[DRAFT][IMP] sale_renting: simplify kanban archs

Branch: 17.0

Bug Fixes(2)

[FW][FIX] hr_payroll: fix design issue in hr_payroll

[FIX] base: the aliases for the action in the path shouldn' have an u…

[FIX] pos_restaurant: show only highest dominant category

[FIX] l10n_mx: fix readonly traceback when deactivating a view inside the get_view

[FW][IMP] l10n_it_edi, l10n_it_edi_imp: Document type and Payment method

[FW][FIX] im_livechat: res.users create right with erp_manager

[FW][FIX] web: Hide label from percentpie widget in list view

[FW][FIX] point_of_sale: fix missing iot build dependancy and rights

[FW][REF] hw_drivers: save iot config files in odoo.conf

[FW][FIX] base: enable partial matching for contact reference search

[FW][FIX] website_event: sanitize event tags for mobile compatibility

[FW][FIX] website_profile: responsive edit profile page

[FW][FIX] mrp_{account,subcontracting_dropshipping}: stop redundant multiply

[FW][FIX] portal, point_of_sale: return new instance of fields list

[FW][IMP] l10n_es_edi_facturae: add reference tag on invoice lines

[FW][FIX] pos_loyalty: fix discount on specific product value

[FW][FIX] point_of_sale: ensure optional products display from info popup

[FW][FIX] barcodes: forbid creation of invalid barcode pattern

[FW][FIX] point_of_sale : differentiate between self-order and normal order numbers

[FW][FIX] purchase_mrp,mrp_account: no force price_unit when component

[FW][FIX] bus: adapt test to custom imbus & cron_trigger notifications

[FW][FIX] pos_sale: fix invoice with multiple tax combination downpayment

[FW][FIX] spreadsheet: prevent crash from SpreadsheetShareButton

[FW][FIX] analytic: give access to analytic account to child company

[FW][FIX] l10n_mt: fix typo from "Matla" to "Malta"

[FW][FIX] l10n_id_efaktur: fix traceback when Download e-Faktur

[DRAFT][IMP] sign: hide the `Request Signature` action for project todo form view

[IMP] approvals, frontdesk: simplify kanban archs

[IMP] helpdesk, helpdesk_timesheet: simplify kanban archs

[IMP] all: replace <tree> in <list>

Other(14)

[FW][FIX] l10n_co_dian: Support Document - misc fixes

[FW][ADD] l10n_uy_edi: new module

[FW][FIX] l10n_co_edi_website_sale: Tour tests fail due to stepDelay argument

[FW][FIX] planning_*: gantt form view display unassign button

[FW][FIX] {test_}whatsapp: adding support for leading zeros

[FW][FIX] account_reports: traceback in consolidation dashboard

[FW][FIX] marketing_automation: removing pager

[FW][FIX] {website_,}product_barcodelookup: process image response

[FW][FIX] hr_appraisal: fix width employee name on appraisal

[FW][FIX] stock_barcode_mrp: not redirect to backend from barcode backorder

[FW][IMP] l10n_in_reports_gstr: improve GSTR 2B Matching

[FW][FIX] l10n_be_hr_payroll: void representation fees on long-term leave

[FW][FIX] industry_fsm_sale: modify the so item domain

[FW][FIX] iot: use one websocket channel instead of one per company

[FIX] l10n_co_edi_website_sale: Tour tests fail due to stepDelay argument