Thursday, March 20, 2025
23 changes · master
Enhancements to existing features
Planning kanban cards now show assigned resources with avatar-style visuals instead of tag labels. This makes roles easier to scan at a glance and preserves helpful color cues for faster identification.
Original PR description
Call the avatar widget on role.resource_ids in kanban view. Get the field color. related: https://github.com/odoo/odoo/pull/153129 task-3516745
The Gantt view styling was adjusted so repeated CSS rules are generated only once instead of during every loop. This reduces unnecessary stylesheet output and helps keep the interface code lighter without changing how users interact with Gantt views.
Original PR description
This commit avoids to generate the same CSS rules for each iteration of the loop instead of setting them once, letting only the rules that actually depends on the loop to be generated during iteration.
The Knowledge app now uses a more standard way to display font-based icons. This small cleanup improves consistency with common web practices and helps reduce potential display or compatibility issues.
Original PR description
This commit replaces the non-standard HTML tag `<icon>` with the more common `<i>` tag used for font based icons.
Field service task menus now show the activity view before the pivot report view. This makes day-to-day task follow-up more immediately accessible while keeping reporting views available.
Original PR description
This commit moves the activity view before pivot view in tasks actions. task-4647282
Resolved issues and error corrections
Changing the screen orientation for an IoT kiosk no longer sends the request to an invalid address. This ensures kiosk display rotation settings can be updated reliably from the IoT form.
Original PR description
Introduced in commit 27a58bc. Steps to reproduce: 1. Configure an IoT box as a kiosk 2. In the IoT form view, change the Screen Orientation and save your changes. 3. The request will fail, and if you look in the developer tools you will see the request went to `undefined/hw_proxy...` instead of `<iot_box_ip>/hw_proxy...`. task-4658229
Code cleanup and technical improvements
Miscellaneous changes
Forward-Port-Of: odoo/enterprise#81772
Original PR description
Forward-Port-Of: odoo/enterprise#81772
In dee57c5a85e26e57159a6eb66de0b2f1f581c64b, which adds prefixes to the states of the model `hr.appraisal`, a search domain on an unrelated model has unfortunately been affected too. This commit fixes the search domain in `_compute_completed_survey_count` which looks at the state of `survey.user_input`, which is not prefixed. Before this commit, the Feedbacks stat button on an appraisal will always show "0 / X", because the filtered state doesn't exist. After this commit, it will show the
This change aligns how record creation customizations are written across several Odoo Enterprise apps. It is an internal cleanup that helps automated checks pass consistently and makes future maintenance safer, with no expected day-to-day impact for users.
Original PR description
odoo/odoo#202106
Original PR description
In dee57c5a85e26e57159a6eb66de0b2f1f581c64b, which adds prefixes to the states of the model `hr.appraisal`, a search domain on an unrelated model has unfortunately been affected too. This commit fixes the search domain in `_compute_completed_survey_count` which looks at the state of `survey.user_input`, which is not prefixed. Before this commit, the Feedbacks stat button on an appraisal will always show "0 / X", because the filtered state doesn't exist. After this commit, it will show the correct number. Task-id: none Forward-Port-Of: odoo/enterprise#81712
Create a new module to export payroll data for Prisma. task-3750799 Forward-Port-Of: odoo/enterprise#81500 Forward-Port-Of: odoo/enterprise#72114
Original PR description
Create a new module to export payroll data for Prisma. task-3750799 Forward-Port-Of: odoo/enterprise#81500 Forward-Port-Of: odoo/enterprise#72114
Steps to reproduce ================== - Install hr_timesheets - Go to Timesheets > All Timesheets - Use the week scale - Scroll to the bottom => Take note of the last record (e.g.: Walter Horton) - Now use a mobile viewport - Make sure the week scale is still applied - Scroll to the bottom => The last record is not the same one as the desktop view Cause of the issue ================== The grid view uses a virtual scroll hook in order to not have to many dom nodes in memory at th
Original PR description
Steps to reproduce ================== - Install hr_timesheets - Go to Timesheets > All Timesheets - Use the week scale - Scroll to the bottom => Take note of the last record (e.g.: Walter Horton) -…
Steps to reproduce ================== - Install hr_timesheets - Go to Timesheets > All Timesheets - Use the week scale - Scroll to the bottom => Take note of the last record (e.g.: Walter Horton) - Now use a mobile viewport - Make sure the week scale is still applied - Scroll to the bottom => The last record is not the same one as the desktop view Cause of the issue ================== The grid view uses a virtual scroll hook in order to not have to many dom nodes in memory at the same time. For this to work, we need a consistent row height. On mobile, when grouping by x amount of fields, they are stacked on top of each other. When grouping by more than 2 fields, there wasn't enough space to display them all.  The `grid-template-rows` was set to auto on mobile in order to accomodate that case. Using auto means we no longer have a consistent row height. Solution ======== We restore the `gridTemplateRows` and allocate extra space when needed.  opw-4208357 Forward-Port-Of: odoo/enterprise#81697 Forward-Port-Of: odoo/enterprise#80476
## Problem When reversing an invoice and making a credit note on a subscription, the email template was still "Invoice: Sending" instead of choosing the credit note template "Credit Note: Sending". The condition on the following code was always True, meaning the super method, that is used to decide which template to take in case of a credit note, was never called. https://github.com/odoo/enterprise/blob/eb1eff85d2119a34997067fedb602e963a5d6f02/sale_subscription/models/account_move_send.py#L9-L1
Original PR description
## Problem When reversing an invoice and making a credit note on a subscription, the email template was still "Invoice: Sending" instead of choosing the credit note template "Credit Note: Sending". The condition on the following code was always True, meaning the super method, that is used to decide which template to take in case of a credit note, was never called. https://github.com/odoo/enterprise/blob/eb1eff85d2119a34997067fedb602e963a5d6f02/sale_subscription/models/account_move_send.py#L9-L14 ## Steps to reproduce - Take an invoice created through a subscription, reverse it (credit note action) - Try to send it - See that the email template is "Invoice: Sending" and not "Credit Note: Sending" ## Fix A condition was added to differentiate an invoice from a credit note. opw-4455155 Forward-Port-Of: odoo/enterprise#81143 Forward-Port-Of: odoo/enterprise#79331
Problem: The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted. Solution: Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed. Task-4626855 Forward-Po
Original PR description
Problem: The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted. Solution: Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed. Task-4626855 Forward-Port-Of: odoo/enterprise#80760
To reproduce the issue: 1. Confirm a SO with partner P 2. Create/Edit an helpdesk team - Returns: True 3. Create a ticket for P 4. Open its form view 5. Click on return Error: a traceback appears "ValueError: Expected singleton: stock. picking()" The return button loads the wizard `stock.return.picking`. In this model, we try to find a related done picking: https://github.com/odoo/enterprise/blob/7215e4abd904ebdff3bd85c2c2f3002b1f5593b1/helpdesk_stock/wizard/stock_picking_retur
Original PR description
To reproduce the issue: 1. Confirm a SO with partner P 2. Create/Edit an helpdesk team - Returns: True 3. Create a ticket for P 4. Open its form view 5. Click on return Error: a traceback appears…
To reproduce the issue: 1. Confirm a SO with partner P 2. Create/Edit an helpdesk team - Returns: True 3. Create a ticket for P 4. Open its form view 5. Click on return Error: a traceback appears "ValueError: Expected singleton: stock. picking()" The return button loads the wizard `stock.return.picking`. In this model, we try to find a related done picking: https://github.com/odoo/enterprise/blob/7215e4abd904ebdff3bd85c2c2f3002b1f5593b1/helpdesk_stock/wizard/stock_picking_return.py#L24-L31 Which, in the above case, does not exist. Later, we call a method on that picking: https://github.com/odoo/odoo/blob/8f527e93de2d64111904f1fcc5813e8b8ea0e4ba/addons/stock/wizard/stock_picking_return.py#L100-L104 Where `_can_return` is a `ensure_one` method, hence the error. The return button is only displayed in some conditions: https://github.com/odoo/enterprise/blob/3d8bb40fcad00068e12f21b623390c959d3fd19c/helpdesk_stock/views/helpdesk_ticket_views.xml#L35 Here is the problem: `has_partner_picking` can be `True` if we find some related SOL, which is useless, the only thing that matters are the related pickings. OPW-4591280 Forward-Port-Of: odoo/enterprise#81378
In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount. To improve clarity: - Negative values are now displayed instead of being forced to 0. - The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed. Task-4589150 Forward-Port-Of: odoo/enterprise#797
Original PR description
In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount. To improve clarity: - Negative values are now displayed instead of being forced to 0. - The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed. Task-4589150 Forward-Port-Of: odoo/enterprise#79793
The test ensures that pos moves with caba taxes are also included in the tax report and behave the same as non-caba taxes. This was necessary since the closing moves do not create caba entries anymore. (See the community commit) Forward-Port-Of: odoo/enterprise#81747 Forward-Port-Of: odoo/enterprise#81505
Original PR description
The test ensures that pos moves with caba taxes are also included in the tax report and behave the same as non-caba taxes. This was necessary since the closing moves do not create caba entries anymore. (See the community commit) Forward-Port-Of: odoo/enterprise#81747 Forward-Port-Of: odoo/enterprise#81505
…bling companies Steps to reproduce: 1. Create a company with two branches. 2. Create an asset model in each branch. 3. Go to the main company's chart of accounts. 4. Select the 'Fixed Asset' account and enable 'Automate Asset'. 5. Assign both branches' asset models to 'Asset Model'. 6. Create a vendor bill in one of the branches using the parent company's 'Fixed Asset' account. Observed behavior: - Two assets are created—one for each model assigned to the 'Fixed Asset' account.
Original PR description
…bling companies Steps to reproduce: 1. Create a company with two branches. 2. Create an asset model in each branch. 3. Go to the main company's chart of accounts. 4. Select the 'Fixed Asset' account and enable 'Automate Asset'. 5. Assign both branches' asset models to 'Asset Model'. 6. Create a vendor bill in one of the branches using the parent company's 'Fixed Asset' account. Observed behavior: - Two assets are created—one for each model assigned to the 'Fixed Asset' account. Expected behavior: - Only one asset should be created, using the asset model corresponding to the branch. - Sibling companies should only access their parent's resources (asset models) and not each other's. This fix ensures that asset models are correctly scoped within their respective branches. opw-4494439 Forward-Port-Of: odoo/enterprise#81589
Made new pull request as old one https://github.com/odoo/enterprise/pull/79702 was not with correct name. Now Odoo and enterprise pull requests repo has same branch name. Forward-Port-Of: odoo/enterprise#81759 Forward-Port-Of: odoo/enterprise#81335
Original PR description
Made new pull request as old one https://github.com/odoo/enterprise/pull/79702 was not with correct name. Now Odoo and enterprise pull requests repo has same branch name. Forward-Port-Of: odoo/enterprise#81759 Forward-Port-Of: odoo/enterprise#81335
Issue: Validating deliveries of storable products linked to a subscription will not update the delivered_qty untill the subscription has been invoiced and hence wont allow you to invoice it at all if the invoicing is based on delivered qty. ### Steps to reproduce: - Create a recurring product which inventory is tacked by quantity and which invoicing policy is based on delivered quantity. - Put 10 units in stock. - Create a monthly subscription for 1 unit of that product. - Confirm the s
Original PR description
Issue: Validating deliveries of storable products linked to a subscription will not update the delivered_qty untill the subscription has been invoiced and hence wont allow you to invoice it at all if…
Issue: Validating deliveries of storable products linked to a subscription will not update the delivered_qty untill the subscription has been invoiced and hence wont allow you to invoice it at all if the invoicing is based on delivered qty. ### Steps to reproduce: - Create a recurring product which inventory is tacked by quantity and which invoicing policy is based on delivered quantity. - Put 10 units in stock. - Create a monthly subscription for 1 unit of that product. - Confirm the subscription - Validate the associated delivery #### > The qty_delivered of the sol is still at 0 and the subscription can't be invoiced. ### Cause of the issue: Starting from Commit b3ed4416f9b8e37604a9aa38a1f38c3504e22fdf (18.0) we will create the first delivery linked to a subscription rather than waiting for the cron to be triggered. These delivery moves are correctly linked to the related sale order lines of the subscription. However, since future deliveries will also be created and linked to that same sol we need to consider only the outgoing and incoming moves related to the current billing period to determine the qty_delivered. This step is achieved with an override of the `_get_out_going_incoming_moves`: https://github.com/odoo/odoo/blob/a6280b2a5173fad65e62af0ba72cb8721939d709/addons/sale_stock/models/sale_order_line.py#L193-L200 https://github.com/odoo/enterprise/blob/dde492541aa253771f905d0a77650aa35fea0e8c/sale_subscription_stock/models/sale_order_line.py#L27-L34 but this always leads to an empty record set since the order was never invoiced making the`next_invoice_date` and hence the `period_end` coincide with the `start_date` of the order. opw-4628212 Forward-Port-Of: odoo/enterprise#81749
### Issue: You can not print label for an mo is the qty_producing is at 0. ### Steps to reproduce: - Create a storable product FP tracked by LOT. - Create a bom for that product with 1 operation containing an instruction of type: "print label" - Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0). - Process the operation in the shopfloor and print label #### > The printed label is empty. ### Cause of the issue:
Original PR description
### Issue: You can not print label for an mo is the qty_producing is at 0. ### Steps to reproduce: - Create a storable product FP tracked by LOT. - Create a bom for that product with 1 operation…
### Issue: You can not print label for an mo is the qty_producing is at 0. ### Steps to reproduce: - Create a storable product FP tracked by LOT. - Create a bom for that product with 1 operation containing an instruction of type: "print label" - Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0). - Process the operation in the shopfloor and print label #### > The printed label is empty. ### Cause of the issue: The qty of label printed depends solely on the qty_producing of the workorder but in case this one is not set we should rather rely on the qty to be produced. https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L344-L351 https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L327-L332 opw-4583573 Forward-Port-Of: odoo/enterprise#81478 Forward-Port-Of: odoo/enterprise#80802
### Issue: The current qty forecast of rental orders does not rely on incoming and outgoing quantities that could happen prior to the location period and would hence modify the availability forecast. ### Steps to reproduce: - Create a storable product that can be rented put 100 units in stock. - Create a sale order for 10 units of that product, confirm and confirm the delivery planned for next week. - Create a rental order for 5 units of that product for a period ulterior to the deliv
Original PR description
### Issue: The current qty forecast of rental orders does not rely on incoming and outgoing quantities that could happen prior to the location period and would hence modify the availability forecast.…
### Issue: The current qty forecast of rental orders does not rely on incoming and outgoing quantities that could happen prior to the location period and would hence modify the availability forecast. ### Steps to reproduce: - Create a storable product that can be rented put 100 units in stock. - Create a sale order for 10 units of that product, confirm and confirm the delivery planned for next week. - Create a rental order for 5 units of that product for a period ulterior to the delivery. - Look at the forecast rentable quantity. #### > It should be 90 but it is 100. ### Cause of the issue: The forcasted quantity of a rental order line is based on the `qty_available` of the product: https://github.com/odoo/enterprise/blob/01b6a70348ffa11a9ead2558571b1ccfa1dd3cbb/sale_stock_renting/models/sale_order_line.py#L115-L129 https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L31-L43 However, this quantity does not take the incoming and outgoing moves that are planned to happend prior or during the location. In case the renting period starts at an ultarior date than today, it should rather be based on the `virtual_available` quantity of the product: https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L44-L55 (note that since we need to take into account each of the incoming and outgoing moves that could happen prior to the location, the `from_date` context key needs to be set to today). opw-4552760 Forward-Port-Of: odoo/enterprise#81532 Forward-Port-Of: odoo/enterprise#81127
Currently it's not possible for a public user to send themselves a message over whatsapp when the message contains information linked to a record This is because most records do not allow public users from reading them. This bypass is fairly safe as event whatsapp users can only select fields from `_get_whatsapp_safe_fields` which are considered safe to be rendered by SU in the first place. So you cannot simply create any template and render it as a public user. Additional: The phone f
Original PR description
Currently it's not possible for a public user to send themselves a message over whatsapp when the message contains information linked to a record This is because most records do not allow public users from reading them. This bypass is fairly safe as event whatsapp users can only select fields from `_get_whatsapp_safe_fields` which are considered safe to be rendered by SU in the first place. So you cannot simply create any template and render it as a public user. Additional: The phone formatter should be able to guess the country of a record based on the country of its partner task-4199766 Forward-Port-Of: odoo/enterprise#81650 Forward-Port-Of: odoo/enterprise#70608
Partial fix of changes applied in: https://github.com/odoo/enterprise/pull/78465 rb-145524 rb-145525 Forward-Port-Of: odoo/enterprise#81753
Original PR description
Partial fix of changes applied in: https://github.com/odoo/enterprise/pull/78465 rb-145524 rb-145525 Forward-Port-Of: odoo/enterprise#81753
**Problem**: When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration. Ad
Original PR description
**Problem**: When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos…
**Problem**:
When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration.
Additionally, there is another issue related to live synchronization in version 18.0. When clicking the "Order" button, the request is sent only if the file is linked to a preparation display see here https://github.com/odoo/enterprise/blob/18.0/pos_preparation_display/static/src/override/point_of_sale/pos_store.js#L37.
As a result, if the display is linked to an archived POS config, live synchronization will not function correctly.
- How to reproduce:
* Assign one pos config to preparation display
* Archive the assigned config
* Open another pos config.
* Kitchen display is not loaded
**Solution**:
Change the domain to include displays with no configs, or with no active config.
opw-4504623
Forward-Port-Of: odoo/enterprise#81722
Forward-Port-Of: odoo/enterprise#80117