Daily updates from Odoo
Wednesday, February 5, 2025
82 changes
18 changes
Resolved issues and error corrections
The attendance kiosk now displays the manual identification back button and employee profile photos correctly within their containers. This prevents cropped visuals and makes the kiosk experience cleaner for employees using check-in features.
Original PR description
Issue: When using the kiosk in versions 17.0 & 17.2, 2 visual issues arise: - when trying to identify manually, the "Go back" arrow is cropped out of its' container - when identified, the user's profile picture is cropped out of the greeting container Steps to reproduce: - Install the attendance module - Go to Kiosk Mode - Identify Manually Cause: For the "Go back arrow", its' position in the container is set to the top left corner (absolute 0;0). The problem is that these coordinates are set for the center of the button and not its' top-left end. For the profile pictures, they are displayed through "t" fields without any specific container. They thus have no styling/margination. Since the overall style has already been revamped in 17.4, a simple "bandaid" fix should do. Ticket: opw-4366047
Miscellaneous changes
Currently, when closing the session, you would encounter an issue if the a refund payment was done using bank payment method and on the journal, the SEPA Credit Transfer is positionned first in the sequence. Steps to reproduce: ------------------- * Install `l10n_fr`, `point_of_sale`, and `account_sepa` * Switch to the `FR Company` * In the **Invoicing** app, select **Configuration** > **Journals** * Select the `Bank` journal * Set proper IBAN account * In **Outgoing Payments**, move `
Original PR description
Currently, when closing the session, you would encounter an issue if the a refund payment was done using bank payment method and on the journal, the SEPA Credit Transfer is positionned first in the…
Currently, when closing the session, you would encounter an issue if the a refund payment was done using bank payment method and on the journal, the SEPA Credit Transfer is positionned first in the sequence. Steps to reproduce: ------------------- * Install `l10n_fr`, `point_of_sale`, and `account_sepa` * Switch to the `FR Company` * In the **Invoicing** app, select **Configuration** > **Journals** * Select the `Bank` journal * Set proper IBAN account * In **Outgoing Payments**, move `SEPA Credit Transfer` to the top * In **Point of sale**, open pos shop * Select any product, change the price or qty to be negative (or make a refund for an order with no customer) * Select `Bank` payment method * Validate * Try closing session > Observation: Closing session error: An error has occurred when trying to close the sesion. You will be redirected to the back-end to manually close the session. * In the backend, try to close the session > Observation: To record payments with False, the recipient bank account must be manually validated. You should go on the partner bank account in order to validate it. Why the fix: ------------ The first payment_method_line will be used among the available payment method lines: https://github.com/odoo/odoo/blob/ae4c01ea7c9a5709a5f5ebcaded06fd91bdabae3/addons/account/models/account_payment.py#L461-L465 https://github.com/odoo/odoo/blob/ae4c01ea7c9a5709a5f5ebcaded06fd91bdabae3/addons/account/models/account_payment.py#L470-L475 In the context of the point of sale, using SEPA CT in the context of refunds does not make too much sense. Indeed, in the pos a refund can be done on an order which is not related to a client. By definition, when using SEPA your are supposed to know the client and it bank account number. We exclude the possibility of using SEPA CT when creating refund account payments coming from the Pos. opw-4310781 Forward-Port-Of: odoo/odoo#195784
When we display more than one chart in the mobile view, the height of the elements is being adjusted to fill 100%, which in some cases causes a size that makes it impossible to view the chart.  To solve this, we have added a div that will encompass the chart and set a minimum height as defined in the spreadsheets, ensuring that the elements are always displayed correctly.  To solve this, we have added a div that will encompass the chart and set a minimum height as defined in the spreadsheets, ensuring that the elements are always displayed correctly.  cc @Tecnativa TT50972 ping @chienandalu @pedrobaeza --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196364 Forward-Port-Of: odoo/odoo#181335
### Steps to reproduce: - In the settings: - Add a second language say FR + Change the language - Enable Multi-step routes - Put your warehouse in receipt in 2-steps. - Create a storable product with a different FR name and a set vendor - Click on the "Reordering Rules" smart button of the product form - Create a reordering rule using the buy route for your product - Add a quantity to reorder > "Order Once" - Open the associated purchase order in a second window - Repeat the operation
Original PR description
### Steps to reproduce: - In the settings: - Add a second language say FR + Change the language - Enable Multi-step routes - Put your warehouse in receipt in 2-steps. - Create a storable product with…
### Steps to reproduce: - In the settings: - Add a second language say FR + Change the language - Enable Multi-step routes - Put your warehouse in receipt in 2-steps. - Create a storable product with a different FR name and a set vendor - Click on the "Reordering Rules" smart button of the product form - Create a reordering rule using the buy route for your product - Add a quantity to reorder > "Order Once" - Open the associated purchase order in a second window - Repeat the operation of adding a quantity to reorder > "Order Once" ** A new POL is created instead of being merged to the first one** ### Cause of the issue: Clicking on Order once will trigger a call of the `_run_pull`. At the end of this call, a stock move will be created and confirmed but the user of the env will be replaced by a SUPERUSER_ID for access rights purposes: https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/stock/models/stock_rule.py#L283-L286 However, while the move data's were correctly generated using the language of the user that clicked on order once: https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/stock/models/stock_rule.py#L278 https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/stock/models/stock_rule.py#L315 The language that will be used during the action confirm to compare with the picking description in the procurement values will be the language of the new user that is the SUPERUSER_ID in en_US: https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/stock/models/stock_move.py#L1451-L1456 This will lead to a set (and incorrect) `product_description_variants` on that procurement. However, this value will be used to determine in the `_run_buy` if an existing POL could absorb the newly created need: https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/purchase_stock/models/stock_rule.py#L131-L135 https://github.com/odoo/odoo/blob/39d7207aae187d055f19c7bce41df8110c045185/addons/purchase_stock/models/purchase_order_line.py#L341-L350 Since already existing POL will not be found to match the incorrect `product_description_variants` a new one will be created on that same PO. ### Fix: We do not rely on the language of the user in case it is the SUPERUSER_ID. opw-4397376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192751
Tax account_tax_template_s_iva0_g_i was added in 17.0. Init hook will load the data from account.tax-es_common.csv (_l10n_es_edi_facturae_post_init_hook) when upgrading from 16.0 and fail because account_tax_template_s_iva0_g_i does not exists yet. Removing account_tax_template_s_iva0_g_i from account.tax-es_common.csv prevent the bug and l10n_es_edi_facturae_tax_type will still be set to 1 as it is the default value. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/114680 For
Original PR description
Tax account_tax_template_s_iva0_g_i was added in 17.0. Init hook will load the data from account.tax-es_common.csv (_l10n_es_edi_facturae_post_init_hook) when upgrading from 16.0 and fail because account_tax_template_s_iva0_g_i does not exists yet. Removing account_tax_template_s_iva0_g_i from account.tax-es_common.csv prevent the bug and l10n_es_edi_facturae_tax_type will still be set to 1 as it is the default value. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/114680 Forward-Port-Of: odoo/odoo#196360
Fixes a small issue when loading translations of multiple chart templates at once. An update to that method added a parameter with the same name as a local variable, and the way it has been done means that the template_data used in each subsequent loop will always be the ones from the first loop only, effectively ignoring the other chart templates. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196359
Original PR description
Fixes a small issue when loading translations of multiple chart templates at once. An update to that method added a parameter with the same name as a local variable, and the way it has been done means that the template_data used in each subsequent loop will always be the ones from the first loop only, effectively ignoring the other chart templates. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196359
**Steps to reproduce**: - Activate recurring revenues and open the form in mobile - The expected revenue, duration and probability is not properly displayed, it's gets out of the container. **After this PR:** - they will displayed currently, plus we'll not show `at` in mobile view. Task-4438997 Forward-Port-Of: odoo/odoo#196283 Forward-Port-Of: odoo/odoo#193060
Original PR description
**Steps to reproduce**: - Activate recurring revenues and open the form in mobile - The expected revenue, duration and probability is not properly displayed, it's gets out of the container. **After this PR:** - they will displayed currently, plus we'll not show `at` in mobile view. Task-4438997 Forward-Port-Of: odoo/odoo#196283 Forward-Port-Of: odoo/odoo#193060
### Issue: Curently, the reservation state of a production is computed from the status of the move raws that are not picked. This includes moves wihtout demands which should not infer with the reservation state at all. ### Steps to reproduce: - In the settings, Enable "Multi-Step Routes" - Go to Inventory > Configuration > Warehouse Management > Warehouses - Put your warehouse in 2 steps-manufacturing - Create a final product (FP) tracked by Serial number, and 2 storable components:
Original PR description
### Issue: Curently, the reservation state of a production is computed from the status of the move raws that are not picked. This includes moves wihtout demands which should not infer with the…
### Issue:
Curently, the reservation state of a production is computed from the status of the move raws that are not picked. This includes moves wihtout demands which should not infer with the reservation state at all.
### Steps to reproduce:
- In the settings, Enable "Multi-Step Routes"
- Go to Inventory > Configuration > Warehouse Management > Warehouses
- Put your warehouse in 2 steps-manufacturing
- Create a final product (FP) tracked by Serial number, and 2 storable components: COMP1 and COMP2
- Create a BOM for FP:
- Component lines:
- 1 x COMP1
- 0 x COMP2 !!
- Operations:
- OP1 with an instruction of type "register production"
1. Create an MO for 1 x FP > Confirm
2. Validate the pick transfer for 1 unit of COMP1
> Currently OP1 is marked as ready
3. Mark the component line of COMP1 as "picked"
#### > OP1 is in waiting status
Same result as 3:
3'. Go to the shopfloor > register production from the MO card
#### > This will pick the COMP1 raw move and OP1 will disappear because of the "ready" filter
### Cause of the issue:
Since you manufacture in 2 steps, the state of the raw move of COMP2 is waiting even though its demand is 0 (before and after you validated the pick move for COMP1). However, only non picked moves are considered to be relevant in the computation of the reservation state of the MO: https://github.com/odoo/odoo/blob/d8fc04f5875dbd3098e58f382d0cea3c7c7c38af/addons/mrp/models/mrp_production.py#L613-L621 Once you pick the COMP1 move which should be the only relevant one the reservation state of the MO becomes computed solely based on the state of the COMP2 raw move and becomes "waiting". In turns, this triggers a recomputation of the state of the workorders and flagging it as waiting: https://github.com/odoo/odoo/blob/d8fc04f5875dbd3098e58f382d0cea3c7c7c38af/addons/mrp/models/mrp_workorder.py#L148-L165
opw-4383004
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#196388**Problem**: Removing spaces impacts composed values like (`padding: 10px 20px` → `padding: 10px20px`), making them invalid. **Solution**: Replace multiple spaces with a single space instead of removing them, to ensure composed values remain intact. **Steps to Reproduce**: 1. Open Email Templates > any template. 2. Add `padding: 10px 20px` to a `tr` element. 3. Save the template. 4. Observe that padding is not applied. --- I confirm I have signed the CLA and read the PR guidelin
Original PR description
**Problem**: Removing spaces impacts composed values like (`padding: 10px 20px` → `padding: 10px20px`), making them invalid. **Solution**: Replace multiple spaces with a single space instead of removing them, to ensure composed values remain intact. **Steps to Reproduce**: 1. Open Email Templates > any template. 2. Add `padding: 10px 20px` to a `tr` element. 3. Save the template. 4. Observe that padding is not applied. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196376
Since HS Code field is now also used in USPS connector, the help text of `hs_code` field on `product_template` needs to be updated. Also the POT file containing module titles and descriptions is updated. Task-3759325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196035 Forward-Port-Of: odoo/odoo#187405
Original PR description
Since HS Code field is now also used in USPS connector, the help text of `hs_code` field on `product_template` needs to be updated. Also the POT file containing module titles and descriptions is updated. Task-3759325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196035 Forward-Port-Of: odoo/odoo#187405
The base.group_user did not have the access right to read overtime_id, which is necessary for filtering allocations that do not have a null overtime_id. The access right was granted to base.group_user only when the allocation state is either draft or confirm. task-4452360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196339 Forward-Port-Of: odoo/odoo#193797
Original PR description
The base.group_user did not have the access right to read overtime_id, which is necessary for filtering allocations that do not have a null overtime_id. The access right was granted to base.group_user only when the allocation state is either draft or confirm. task-4452360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196339 Forward-Port-Of: odoo/odoo#193797
Having a credit limit set to 0 means 'no limit', user has to set it to 0.01 to have a minimum limit. This can be confusing for the user, so add a little help message to the fields in both partner and settings views. A better solution should be to use the `ResPartner.use_partner_credit_limit` field to be able to set 0$ limit to specifics partner, but this can't be done in stable (computed, non stored field). opw-4479163 Forward-Port-Of: odoo/odoo#196300 Forward-Port-Of: odoo/odoo#1948
Original PR description
Having a credit limit set to 0 means 'no limit', user has to set it to 0.01 to have a minimum limit. This can be confusing for the user, so add a little help message to the fields in both partner and settings views. A better solution should be to use the `ResPartner.use_partner_credit_limit` field to be able to set 0$ limit to specifics partner, but this can't be done in stable (computed, non stored field). opw-4479163 Forward-Port-Of: odoo/odoo#196300 Forward-Port-Of: odoo/odoo#194886
`module_type` is not required. This leads to some code-modules to have null value in the column. When this happens an error occurs if we try to open the form view of the module in Apps. Steps to reproduce: 1. Install a custom module. 2. Modify the `module_type` to `NULL` via SQL (note that the column is not required) 3. Try to open the module in the Apps menu. We get an error like: ``` Can't fetch records(s) ... They might have been deleted. ``` This issue is impacting multiple
Original PR description
`module_type` is not required. This leads to some code-modules to have null value in the column. When this happens an error occurs if we try to open the form view of the module in Apps. Steps to reproduce: 1. Install a custom module. 2. Modify the `module_type` to `NULL` via SQL (note that the column is not required) 3. Try to open the module in the Apps menu. We get an error like: ``` Can't fetch records(s) ... They might have been deleted. ``` This issue is impacting multiple DBs post upgrade. Since this is a new field the value is not filled in some cases. It is also possible that due to misconfiguration the value is set to something other than `official`. In this patch we propose to fetch the information only for modules that are already marked as `industry`. opw-4516992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195540
Steps to reproduce: - Go to the "/blog" page. - Click on "Configuration > Blogs" in the main navbar. - Create at least 15 new blogs with "Astronomy" as the name. - Go back to the "/blog" page. - Bug: The navbar overflows the page to the right, causing a horizontal scrollbar to appear. After this commit, the navbar no longer overflows, and the list items are displayed on multiple lines. [opw-4507558](https://www.odoo.com/web#id=4507558&cids=1&menu_id=4720&action=333&active_id=1695&
Original PR description
Steps to reproduce: - Go to the "/blog" page. - Click on "Configuration > Blogs" in the main navbar. - Create at least 15 new blogs with "Astronomy" as the name. - Go back to the "/blog" page. - Bug: The navbar overflows the page to the right, causing a horizontal scrollbar to appear. After this commit, the navbar no longer overflows, and the list items are displayed on multiple lines. [opw-4507558](https://www.odoo.com/web#id=4507558&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#196050 Forward-Port-Of: odoo/odoo#195859
Currently signup.js also defines SignUpForm, which overrides the reset password behavior. This bug is not present in 16.0, so I used the same name for the registry that is being used in 16.0. Forward-Port-Of: odoo/odoo#196389
Original PR description
Currently signup.js also defines SignUpForm, which overrides the reset password behavior. This bug is not present in 16.0, so I used the same name for the registry that is being used in 16.0. Forward-Port-Of: odoo/odoo#196389
Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible
Original PR description
Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible person is removed from the batch transfer, this change is not applied to the individual transfers linked to it. opw-4519994 Forward-Port-Of: odoo/odoo#196487 Forward-Port-Of: odoo/odoo#196333
**Issue:** Users are able to delete timesheets associated with public holidays, unlike regular time off requests **Steps to Reproduce:** - Ensure "Time Off" is enabled in the Timesheet settings. - Time Off > Configurations > Public Holidays. - Create a new public holiday. - Timesheet > My Timesheet (list view). - Attempt to delete the timesheet entry corresponding to the public holiday. The entry is deleted without any warning. opw-4464411 --- I confirm I have s
Original PR description
**Issue:** Users are able to delete timesheets associated with public holidays, unlike regular time off requests **Steps to Reproduce:** - Ensure "Time Off" is enabled in the Timesheet settings. - Time Off > Configurations > Public Holidays. - Create a new public holiday. - Timesheet > My Timesheet (list view). - Attempt to delete the timesheet entry corresponding to the public holiday. The entry is deleted without any warning. opw-4464411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195379
Previously, the Mail Failure icon was a .JPG, which lacked transparency. While this was not noticeable in Odoo Light Mode, it resulted in a visible white background in Dark Mode. This commit replaces the JPG with an SVG, ensuring proper transparency. | Current (17.0) | Fix | |--------|--------| |  |  | |  |  | |  |  | task-4531425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196400
25 changes
Enhancements to existing features
The Indian payroll contract form now has improved help text for TDS-related fields. This makes it easier for HR and payroll users to understand the field purpose and enter the correct information.
Original PR description
task-4529300
The Brazilian AvaTax module now marks NCM tax classification codes as protected during installation instead of handling them again during later module updates. This reduces the risk of update-related disruption while preserving the intended tax code data setup.
Original PR description
This is a follow-up for a bug fix made in stable [1]. In master we can remove the init() hook on the model, which ran on module update, and instead rely on the post_init_hook during module installation. task-4374334 [1] https://github.com/odoo/enterprise/pull/77805
Resolved issues and error corrections
This fix updates an internal reference after the Indian GST reporting component was merged into the main Indian reports module. It helps prevent configuration or reporting errors caused by the old reference while keeping the change low-impact for users.
Original PR description
Update the reference XML ID from `l10n_in_reports_gstr` to `l10n_in_reports` as `l10n_in_reports_gstr` has been merged into `l10n_in_reports`. ref: https://github.com/odoo/enterprise/pull/75451/commits/03b2aceef289c14bd5d32355c14045fb72485ea7
Features or functions removed from Odoo
This change removes older workaround code in Studio that manually refreshed display names. The underlying issue is now fixed elsewhere, so removing the workaround lowers maintenance risk without changing normal user workflows.
Original PR description
https://github.com/odoo/enterprise/pull/6183 adds a weird manual call to _compute_display_name() to fix a registry issue of generated by base_automation. Another fix was created to fix this first fix in https://github.com/odoo/enterprise/pull/21746/commits/7b5dfa9792fc0d3ba8ccb810999f39de8ea404f1. But actually https://github.com/odoo/odoo/pull/39233 fixes the root issue. Then remove the two first weird fixes.
Code cleanup and technical improvements
This update aligns several Enterprise apps with a newer internal way of retrieving grouped data, following the related platform change. It should not change day-to-day workflows, but it helps keep reporting, planning, documents, appointments, manufacturing, field service, and accounting features maintainable and consistent.
Original PR description
https://github.com/odoo/odoo/pull/163300 https://github.com/odoo/upgrade/pull/6682 https://github.com/odoo/documentation/pull/11354
Miscellaneous changes
Forward-Port-Of: odoo/enterprise#78409 Forward-Port-Of: odoo/enterprise#77743
Original PR description
Forward-Port-Of: odoo/enterprise#78409 Forward-Port-Of: odoo/enterprise#77743
Before this commit, when a subscription move was posted all sale.order.log without effective_date were updated. As a result, some upsell flows could be wrong: - Create a contract, invoice it. Create log is effective. - Remove discount for next year. without invoicing. The log is not effective. - A few days later, in the middle of the period, upsell and invoice the upsell. Only the upsell change log should be effective - At the end of the invoicng period, renew the contract with
Original PR description
Before this commit, when a subscription move was posted all sale.order.log without effective_date were updated. As a result, some upsell flows could be wrong: - Create a contract, invoice it. Create…
Before this commit, when a subscription move was posted all sale.order.log without effective_date were updated. As a result, some upsell flows could be wrong: - Create a contract, invoice it. Create log is effective. - Remove discount for next year. without invoicing. The log is not effective. - A few days later, in the middle of the period, upsell and invoice the upsell. Only the upsell change log should be effective - At the end of the invoicng period, renew the contract with a new invoice: the discount log should be effective. With this commit the effective match the accouting date - A subscription start: effective_date = deferred_start_date - An upsell is invoiced: effective_date = deferred_start_date only for the log generated by the upsell - A subscription is churn or renewed: All the log without effective_date: effective_date = deferred_end_date - A subscription is reopen: All the log with the effective_date = deferred_end_date get effective_date = False task id: 4452545 Forward-Port-Of: odoo/enterprise#77765
Before this commit, if you drag and drop a partner name from the form view of bank_reconciliation in the file import dropzone, a traceback is raise. This commit fix this issue by hiding the dropzone when user is not dragging a file. Linked:https://github.com/odoo/odoo/pull/193355 opw-4366605 Forward-Port-Of: odoo/enterprise#78576 Forward-Port-Of: odoo/enterprise#76565
Original PR description
Before this commit, if you drag and drop a partner name from the form view of bank_reconciliation in the file import dropzone, a traceback is raise. This commit fix this issue by hiding the dropzone when user is not dragging a file. Linked:https://github.com/odoo/odoo/pull/193355 opw-4366605 Forward-Port-Of: odoo/enterprise#78576 Forward-Port-Of: odoo/enterprise#76565
This is the counterpart to the community PR allowing certain `div` elements (baseContainer) to be handled by the editor with the features commonly used inside `p` elements. See community PR for a more detailed explanation. task-4260398 and task-4294440 Forward-Port-Of: odoo/enterprise#78497 Forward-Port-Of: odoo/enterprise#75187
Original PR description
This is the counterpart to the community PR allowing certain `div` elements (baseContainer) to be handled by the editor with the features commonly used inside `p` elements. See community PR for a more detailed explanation. task-4260398 and task-4294440 Forward-Port-Of: odoo/enterprise#78497 Forward-Port-Of: odoo/enterprise#75187
Bug === The icon in the definition popover are currently black in dark mode, and it should be light gray. The reason is that the component that it uses changed, but the CSS in the properties component wasn't updated (we now use a more permissive rule to avoid future similar issue). Task-4543117 Forward-Port-Of: odoo/enterprise#78386
Original PR description
Bug === The icon in the definition popover are currently black in dark mode, and it should be light gray. The reason is that the component that it uses changed, but the CSS in the properties component wasn't updated (we now use a more permissive rule to avoid future similar issue). Task-4543117 Forward-Port-Of: odoo/enterprise#78386
There are two errors raised when importing a winbook file: 1) `psycopg2.ProgrammingError: can't adapt type 'account.account'` 2) `ValueError: Invalid field 'title' on model 'res.partner'` Number one is occuring because we pass a recordset instead of an id in the create vals. Number two is occuring because the field 'title' has been removed by https://github.com/odoo/odoo/commit/0b8bd891fad1c84607fe147a32d705917341fed7 opw-4499212 Forward-Port-Of: odoo/enterprise#78399
Original PR description
There are two errors raised when importing a winbook file: 1) `psycopg2.ProgrammingError: can't adapt type 'account.account'` 2) `ValueError: Invalid field 'title' on model 'res.partner'` Number one is occuring because we pass a recordset instead of an id in the create vals. Number two is occuring because the field 'title' has been removed by https://github.com/odoo/odoo/commit/0b8bd891fad1c84607fe147a32d705917341fed7 opw-4499212 Forward-Port-Of: odoo/enterprise#78399
Bug === 1. Open your profile -> My Documents 2. Switch to list view => You can not open the preview The reason is that the JS of the list view is not loaded, because we don't execute the right action. Task-4546797 Forward-Port-Of: odoo/enterprise#78492
Original PR description
Bug === 1. Open your profile -> My Documents 2. Switch to list view => You can not open the preview The reason is that the JS of the list view is not loaded, because we don't execute the right action. Task-4546797 Forward-Port-Of: odoo/enterprise#78492
If "Unfold All" is not selected and "Group by Account" is, printing the Depreciation Schedule won't print the unfolded lines. Furthermore, if you unfold some lines and then refresh, all the lines are refolded. This behaviour is different than the other reports, where the lines you unfold are printed and remembered during a refresh. The fix is to mark the parent lines generated by `group_by_account` as unfolded if the line is present in `options['unfolded_lines']`. task-4507580 F
Original PR description
If "Unfold All" is not selected and "Group by Account" is, printing the Depreciation Schedule won't print the unfolded lines. Furthermore, if you unfold some lines and then refresh, all the lines are refolded. This behaviour is different than the other reports, where the lines you unfold are printed and remembered during a refresh. The fix is to mark the parent lines generated by `group_by_account` as unfolded if the line is present in `options['unfolded_lines']`. task-4507580 Forward-Port-Of: odoo/enterprise#78424 Forward-Port-Of: odoo/enterprise#78074
Since this [commit](https://github.com/odoo/enterprise/commit/a067f8421e3058507f3e25088d94e33122ecdd1e#diff-0e37484af3f832073947594d460e7a6039698cbee82232e2c9b35c0aff3a59b3), the `default_account_id` is set as an `account.account` record, instead of its `id`. no-task Forward-Port-Of: odoo/enterprise#78529
Original PR description
Since this [commit](https://github.com/odoo/enterprise/commit/a067f8421e3058507f3e25088d94e33122ecdd1e#diff-0e37484af3f832073947594d460e7a6039698cbee82232e2c9b35c0aff3a59b3), the `default_account_id` is set as an `account.account` record, instead of its `id`. no-task Forward-Port-Of: odoo/enterprise#78529
Fix the drag_and_drop run of sign_tour to fit in the new tour system. Forward-Port-Of: odoo/enterprise#78524
Original PR description
Fix the drag_and_drop run of sign_tour to fit in the new tour system. Forward-Port-Of: odoo/enterprise#78524
Problem ---------- The SHIF is based on the gross and not the basic. There is no SHIF Relief Objective ---------- Correct the SHIF implementation Solution ---------- Get GROSS in SHIF computation rather than BASIC Remove SHIF Relief Rule task-4414345 Forward-Port-Of: odoo/enterprise#75804
Original PR description
Problem ---------- The SHIF is based on the gross and not the basic. There is no SHIF Relief Objective ---------- Correct the SHIF implementation Solution ---------- Get GROSS in SHIF computation rather than BASIC Remove SHIF Relief Rule task-4414345 Forward-Port-Of: odoo/enterprise#75804
Steps to reproduce: ------- - Install the `project_timesheet_forecast` module. - Open Planning > Pivot View. - Click on "Insert in Spreadsheet." - Confirm the action. Issue: --------- While inserting into the spreadsheet, the readgroup result does not have `effective_hours` and `percentage_hours`, which causes a traceback. EX: [{'__count': 6, 'allocated_hours_sum_id': 50.0, 'effective_hours_sum_id': 0.0, percentage_hours_sum_id': 0.0, '__domain'
Original PR description
Steps to reproduce: ------- - Install the `project_timesheet_forecast` module. - Open Planning > Pivot View. - Click on "Insert in Spreadsheet." - Confirm the action. Issue: --------- While inserting…
Steps to reproduce:
-------
- Install the `project_timesheet_forecast` module.
- Open Planning > Pivot View.
- Click on "Insert in Spreadsheet."
- Confirm the action.
Issue:
---------
While inserting into the spreadsheet, the readgroup result does not have `effective_hours` and `percentage_hours`,
which causes a traceback.
EX:
[{'__count': 6, 'allocated_hours_sum_id': 50.0, 'effective_hours_sum_id': 0.0,
percentage_hours_sum_id': 0.0, '__domain': ['&', ('start_datetime', '!=', False),
('end_datetime', '!=', False)]}]
Root Cause:
----------------------
The `read_group` result does not always contain the expected key, causing a traceback when accessed.
Fix:
--------
Used a getter method to safely retrieve the value. If the key is missing, it returns `None` instead
of raising an error.
Example:
--------------
temp = {'a': 1}
temp['b'] -> tracrback
temp.get('b') -> None
ticket-4497656
Forward-Port-Of: odoo/enterprise#78154We always send the product name, but sometimes users want to add more information to the electronic invoice. It makes more sense to send the line description (account.move.line's name field) instead. That allows the user to specify what they want and also aligns better with what the API expects (their field is called "description", not "productName"). To avoid changing function signatures in stable we override _l10n_br_build_avatax_line and browse the account.move.line using line_id. In ma
Original PR description
We always send the product name, but sometimes users want to add more information to the electronic invoice. It makes more sense to send the line description (account.move.line's name field) instead. That allows the user to specify what they want and also aligns better with what the API expects (their field is called "description", not "productName"). To avoid changing function signatures in stable we override _l10n_br_build_avatax_line and browse the account.move.line using line_id. In master we'll clean it up by providing "description" directly in _get_line_data_for_external_taxes() for both account.move and sale.order. This also fixes a mistake that cleared errors for service transactions (introduced in the merge of l10n_br_avatax_services [1]). [1] https://github.com/odoo/enterprise/pull/64714 task-4401787 Forward-Port-Of: odoo/enterprise#78125 Forward-Port-Of: odoo/enterprise#77610
NF-e invoices can optionally include sent packages. This integrates with the stock module to provide a way for users to specify packages on invoices. Typically EDI is done before products are sent out ("ordered quantity" invoicing policy). To handle this the user can enable 2-step picking. In the first step they can record how they will package the products. After that, the packages can be included on the invoice for EDI. At a later time products can be delivered to the customer in the last s
Original PR description
NF-e invoices can optionally include sent packages. This integrates with the stock module to provide a way for users to specify packages on invoices. Typically EDI is done before products are sent…
NF-e invoices can optionally include sent packages. This integrates with the stock module to provide a way for users to specify packages on invoices.
Typically EDI is done before products are sent out ("ordered quantity" invoicing policy). To handle this the user can enable 2-step picking. In the first step they can record how they will package the products. After that, the packages can be included on the invoice for EDI. At a later time products can be delivered to the customer in the last step. We provide a picking smart button in the invoice form view to easily navigate to the related pickings to sort out the packaging. This is typically done by a dedicated person who handles everything related to EDI.
Note that for products to be included in packages they must be storable (is_storable). The stock module allows to package
non-storable products as well, but in those cases the resulting stock.quant.package's are empty (no quant_ids).
task-4298921
## TODO
- [ ] translations
Forward-Port-Of: odoo/enterprise#78315
Forward-Port-Of: odoo/enterprise#75252Don't warn if products used on service invoices have an empty l10n_br_source_origin field. It's only needed for goods, and is in fact hidden on service products. opw-4536842 Forward-Port-Of: odoo/enterprise#78466
Original PR description
Don't warn if products used on service invoices have an empty l10n_br_source_origin field. It's only needed for goods, and is in fact hidden on service products. opw-4536842 Forward-Port-Of: odoo/enterprise#78466
Solves 2 issues related to the report builders. Also cleans the onWillUpdateProps as advised by the Framework JS team. Issue 1: Steps to reproduce: - Go to Accounting -> Configuration -> Accounting Reports - Create a new report with 2 lines - drag the bottom line on top of the first one -> The list order is properly handled - Press the save button -> The list order is back to its original form. Cause of the issue: When saving, the list.props.list.records is equal to it
Original PR description
Solves 2 issues related to the report builders. Also cleans the onWillUpdateProps as advised by the Framework JS team. Issue 1: Steps to reproduce: - Go to Accounting -> Configuration -> Accounting Reports - Create a new report with 2 lines - drag the bottom line on top of the first one -> The list order is properly handled - Press the save button -> The list order is back to its original form. Cause of the issue: When saving, the list.props.list.records is equal to its original order and therefore needs to be ordered based on the sequence. Issue 2: -> solved in related community PR - Create a report with 2 lines, line 2 being a child of line 1 - Drag line 2 above line 1 -> Validation error Cause of the issue: - The backend constraint receives line not ordered by sequence task-4328098 Forward-Port-Of: odoo/enterprise#78332 Forward-Port-Of: odoo/enterprise#74177
Steps to reproduce the bug: - Create a storable product “P1” - Component: C1 - Operation: OP1 - Create a manufacturing order to produce one unit of P1 - Confirm the MO and validate it - Go to the product P1 -> Cost analysis Problem: a traceback Is triggered: self._obj.execute(query, params) psycopg2.errors.UndefinedColumn: column wo.product_id does not exist LINE 2: wo.product_id, ^ HINT: Perhaps you meant to reference the column "wo.production_id". The field `product_id` in `mr
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” - Component: C1 - Operation: OP1 - Create a manufacturing order to produce one unit of P1 - Confirm the MO and validate it - Go to the product P1 -> Cost analysis Problem: a traceback Is triggered: self._obj.execute(query, params) psycopg2.errors.UndefinedColumn: column wo.product_id does not exist LINE 2: wo.product_id, ^ HINT: Perhaps you meant to reference the column "wo.production_id". The field `product_id` in `mrp_workorder` is a related field (`related='production_id.product_id'`), meaning it does not exist as a physical column in the database. The SQL query was directly referencing `wo.product_id`, which caused the error. Solution: Instead of `wo.product_id`, the query now retrieves `product_id` from `mrp_production` opw-4525278 Forward-Port-Of: odoo/enterprise#78311
The print button should be invisible when no `line_ids` are added, which implies that the `compute_sheet` was not triggered. task-4491103 Forward-Port-Of: odoo/enterprise#78403 Forward-Port-Of: odoo/enterprise#77848
Original PR description
The print button should be invisible when no `line_ids` are added, which implies that the `compute_sheet` was not triggered. task-4491103 Forward-Port-Of: odoo/enterprise#78403 Forward-Port-Of: odoo/enterprise#77848
At the moment, the allowed groupbys for the standard report engines (account codes, domain, tax tags) need to be stored fields on `account.move.line`, or be defined in the custom handler. We want to be able to group by any field that is searchable and has `_field_to_sql` implemented for it. For example, for consolidation, users might want to create a non-stored field related to `account_id.code` and group by it. After this commit, groupbys can be any searchable field for which `_field_to_s
Original PR description
At the moment, the allowed groupbys for the standard report engines (account codes, domain, tax tags) need to be stored fields on `account.move.line`, or be defined in the custom handler. We want to be able to group by any field that is searchable and has `_field_to_sql` implemented for it. For example, for consolidation, users might want to create a non-stored field related to `account_id.code` and group by it. After this commit, groupbys can be any searchable field for which `_field_to_sql` is defined, regardless of whether it is stored or not. task-4259552 Forward-Port-Of: odoo/enterprise#78419 Forward-Port-Of: odoo/enterprise#71813
Some URLs in the digest emails are currently broken due to an outdated URL format. ### Steps to reproduce * Install `digest` and `crm` modules * Go to Settings > Technical > Digest Emails * Select the "Your Odoo Periodic Digest" digest and send it * Check the sent email and click on any of the "Open Email" links You should encounter an error indicating that the action does not exist. Although the reproduction steps use the `crm` module as an example, this issue occurs with all the
Original PR description
Some URLs in the digest emails are currently broken due to an outdated URL format. ### Steps to reproduce * Install `digest` and `crm` modules * Go to Settings > Technical > Digest Emails * Select the "Your Odoo Periodic Digest" digest and send it * Check the sent email and click on any of the "Open Email" links You should encounter an error indicating that the action does not exist. Although the reproduction steps use the `crm` module as an example, this issue occurs with all the modules listed in the title. ### Cause The "Open Report" URLs were not updated to account for the new URL format. opw-4405288 opw-4502625 Forward-Port-Of: odoo/enterprise#78394 Forward-Port-Of: odoo/enterprise#77282
39 changes
Enhancements to existing features
Preparation tickets in Point of Sale now show ordered products and notes in a larger text size. This makes kitchen or preparation staff tickets easier to read, helping reduce mistakes and speed up order handling.
Original PR description
This commit increases the text size of the ordered product and notes on the preparation ticket, ensuring better readability. task-4535901
Resolved issues and error corrections
Fixes a visual issue in the website editor where resizing page elements could briefly make the scrollbar jump or flicker. This makes editing pages feel smoother and avoids distracting layout changes during routine website customization.
Original PR description
Since commit [1], which moved the scroll out of the `#wrapwrap`, when we resize an element, the size of the scroll bar increases suddenly for no apparent reason, creating a flicker effect. This…
Since commit [1], which moved the scroll out of the `#wrapwrap`, when we resize an element, the size of the scroll bar increases suddenly for no apparent reason, creating a flicker effect. This happens because when we start resizing, a `div` is added at the end of the body, with a `height` set at `100%`. It was added in commit [2], when the website was moved in an iframe, in order for the mouse events to not be absorbed by it. The scroll bar flicker is therefore due to the addition of this `div` in the body, which makes the page bigger. Before commit [1], the body had its `overflow` property set to `hidden`, which is why adding the `div` had no visual effect, since it was hidden. (Note that the body has a fixed size, which is the size of the viewport with no overflow.) But with commit [1], this property has been removed, making the `div` appear at the bottom of the page. To fix this issue, we could simply set this `div` height to `0px` or its `top` position to 0, so it would never overflow the body. But in fact, it appears that this `div` is simply not necessary anymore since commit [3], which restored the overlay computation. This commit therefore removes the handler in charge of adding this `div` when we start resizing, as it is not needed anymore. [1]: https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e [2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af [3]: https://github.com/odoo/odoo/commit/2ae4e6434112a676c1cfa100e88fd756fe17f000 task-4190506
When a refused applicant is restored, the referral page now shows them as ongoing instead of incorrectly marking them as not hired. This keeps recruitment and referral information aligned for users reviewing applicant progress.
Original PR description
Description of the issue/feature this PR addresses: The `reset_applicant` method previously did not reset the `referral_state` to `'progress'`, causing the referral page to incorrectly display the applicant as "not hired" even when their actual state was ongoing. This commit explicitly sets `referral_state` to `'progress'` to ensure proper state management when an applicant is restored. opw-4523156 Related commit: f48ae97c2cadcdc085d32be25be365fdbb5605ef Current behavior before PR: Refuse an applicant and restore it, go to the referral app, the state will be displayed as not hired instead of ongoing Desired behavior after PR is merged: It should display as ongoing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale now prepares its synchronization process as soon as it starts, before contacting the server. This helps avoid startup timing issues and makes request handling more reliable for cashiers and stores.
Original PR description
Initialize the synchronization class at startup of the PoS before making any request to the server. This will ensure that the synchronization class is ready to handle the requests.
This change prevents an automated test tool from opening the Attendance kiosk menu, which was causing test failures. It helps keep routine quality checks reliable without changing normal user workflows.
Original PR description
Fixing Click All test broken since 662081ca3ad31170961eaf384f8aa2311d39f086
Product pages now limit unusually tall images so they do not make the page excessively long. This keeps shopping pages easier to browse when merchants upload narrow, very tall product photos.
Original PR description
In commit[1] we implemented improvement for the images on the product page which makes the single image fill the total width of the column. While it was fitting most of cases, uploading an image with particular aspect ratio w/ a height significantly longer than the width will render a very long image, extending the page. This fix constraints the height to a maximum of 75vh, avoiding extra long images. Note: the fix is done in CSS to be stable friendly, in master the goal will be to implement a dropdown allowing precise aspect ratio for single images. This will require improvement on the way the carousel / grid render it's single image. This will likely be handled in the e-commerce redesign (task-4252024) [1]: odoo/odoo@da76f10558ea240a5f1b539cd4ce3ed3fc6628ab opw-4458614 task-4522225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where resequencing a payment's journal entry changed the journal entry number but left the related payment with the old reference. Payments and their accounting entries now stay consistently named, reducing confusion during reconciliation and audits.
Original PR description
- Configure an outstanding receipt account (e.g., Bank) for the Bank journal. - Create an invoice and process the payment. When attempting to resequence the journal entry corresponding to the `account.payment`, the journal entry is renamed, but the `account.payment` record is not updated accordingly. https://github.com/odoo/odoo/commit/01b87f1230beac0568f4e3b1b76e547909506892 made the journal entry optional for payments, which broke the resequence. opw-4437481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The course website test setup now avoids confusing demo courses with the intended test course. This helps keep automated checks accurate and reduces the chance of unnoticed issues in the course experience.
Original PR description
The slide course member tour tests use a channel called `Basics of Gardening - Test`. When the course is completed, clicking on `End course` will redirect the user to the courses home page. Since there is already a course (from demo data) called `Basics of Gardening`, the selector in the tour test actually selects this as the first match not the test course and the tour continues with the wrong course. It doesn't crash because both demo and test courses are public, so it's possible for demo and portal users to access them anyway and add/update a comment is done on the demo course. By this commit: - Demo data is removed in the tests to ensure that there is no collision between demo data and test data. - Since there are no predefined messages in the test data (the tour flow relied on the demo data messages before), the `update` does not happen in the tour without demo data. Some extra steps are also added to check the update message .
The mobility budget field is now limited to Belgian employee contracts instead of appearing on every contract when the feature is installed. This reduces confusion for users working with contracts outside Belgium and keeps country-specific payroll information relevant.
Original PR description
Issue: Mobility budget is shown in every contract if it is installed on the db - make the budegt only visible for BE Task: 4529227
The Planning Gantt progress bar now shows flexible employees' expected hours down to the minute instead of rounding to whole hours. This prevents schedules such as 42 hours 30 minutes per week from appearing as only 42 hours, giving managers a more accurate view of planned capacity.
Original PR description
This commit aims to ensure that the expected working hours for flexible resources are not rounded to the hours when displayed on the Gantt progress bar. Previously, the total hours were being rounded to the hours, which could lead to inaccuracies in the representation of the expected working hours on the gantt view. By changing the rounding to the minutes, we ensure that the Gantt progress bar accurately reflects the precise hours worked by flexible resources. Steps to reproduce: ------------------- 1. Create an employee with flexible hours ex. 42:30h per week (8:30h per day) 2. Create a shift for the same employee on planning. 3. In the gantt view, when setting the date range to a week, the expected working hours of the period is showing 42h instead of 42:30h task-id: 4506633
This fixes an automated walkthrough in the Sign app so it works correctly with the updated tour system. It helps ensure the document signing setup flow can be reliably tested, reducing the risk of issues reaching users.
Original PR description
Fix the drag_and_drop run of sign_tour to fit in the new tour system.
This update fixes an issue that could prevent Chilean electronic invoicing point-of-sale orders from validating and syncing correctly. Businesses using this localization should see fewer interruptions when processing POS orders.
Original PR description
Before this commit, validating an order resulted in an error because the wrong model "account_move" was used instead of "account.move". opw-4543705
The Documents control panel now keeps its action buttons usable and neatly displayed on narrow screens and mobile devices. This prevents awkward button resizing while ensuring users can still access all available actions.
Original PR description
When you reduce the screen width or view the page on devices with small screens, the control panel button group rearranges itself in an unsightly way (e.g. excessive button height). For mobile devices, we use overflow auto on the action btns of the panel. Then they keep their aspects and are still accessible to users. FW-PORT until 18.1 task-4471881
This fix prevents scheduled Dutch SBR status checks from crashing after a prior certificate handling change. Businesses using the Dutch reporting flow should see more reliable automated status updates without manual intervention.
Original PR description
In this PR odoo/enterprise/pull/64323, certificates were refactored. However, one method has passed through the net and was left using the old way. This commit fixes that by removing the call and using the new refactored certificates opw-4423435
This update fixes an automated test issue affecting the restaurant preparation display. It helps keep the restaurant workflow validation reliable and prevents false failures in the release checks.
Original PR description
Fix runbot error: 113710
Fixed an issue that could cause Planning pivot data to fail when inserted into a spreadsheet. This improves reliability for users exporting planning information, especially when some expected workload fields are unavailable.
Original PR description
Steps to reproduce: ------- - Install the `project_timesheet_forecast` module. - Open Planning > Pivot View. - Click on "Insert in Spreadsheet." - Confirm the action. Issue: --------- While inserting…
Steps to reproduce:
-------
- Install the `project_timesheet_forecast` module.
- Open Planning > Pivot View.
- Click on "Insert in Spreadsheet."
- Confirm the action.
Issue:
---------
While inserting into the spreadsheet, the readgroup result does not have `effective_hours` and `percentage_hours`,
which causes a traceback.
EX:
[{'__count': 6, 'allocated_hours_sum_id': 50.0, 'effective_hours_sum_id': 0.0,
percentage_hours_sum_id': 0.0, '__domain': ['&', ('start_datetime', '!=', False),
('end_datetime', '!=', False)]}]
Root Cause:
----------------------
The `read_group` result does not always contain the expected key, causing a traceback when accessed.
Fix:
--------
Used a getter method to safely retrieve the value. If the key is missing, it returns `None` instead
of raising an error.
Example:
--------------
temp = {'a': 1}
temp['b'] -> tracrback
temp.get('b') -> None
ticket-4497656Miscellaneous changes
Currently signup.js also defines SignUpForm, which overrides the reset password behavior. This bug is not present in 16.0, so I used the same name for the registry that is being used in 16.0. Forward-Port-Of: odoo/odoo#196389
Original PR description
Currently signup.js also defines SignUpForm, which overrides the reset password behavior. This bug is not present in 16.0, so I used the same name for the registry that is being used in 16.0. Forward-Port-Of: odoo/odoo#196389
`module_type` is not required. This leads to some code-modules to have null value in the column. When this happens an error occurs if we try to open the form view of the module in Apps. Steps to reproduce: 1. Install a custom module. 2. Modify the `module_type` to `NULL` via SQL (note that the column is not required) 3. Try to open the module in the Apps menu. We get an error like: ``` Can't fetch records(s) ... They might have been deleted. ``` This issue is impacting multiple
Original PR description
`module_type` is not required. This leads to some code-modules to have null value in the column. When this happens an error occurs if we try to open the form view of the module in Apps. Steps to reproduce: 1. Install a custom module. 2. Modify the `module_type` to `NULL` via SQL (note that the column is not required) 3. Try to open the module in the Apps menu. We get an error like: ``` Can't fetch records(s) ... They might have been deleted. ``` This issue is impacting multiple DBs post upgrade. Since this is a new field the value is not filled in some cases. It is also possible that due to misconfiguration the value is set to something other than `official`. In this patch we propose to fetch the information only for modules that are already marked as `industry`. opw-4516992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195540
In this PR, - Set the default department for the Plans smart button. - If there is no plan, it will open the form view. Task-4356557 Forward-Port-Of: odoo/odoo#196430 Forward-Port-Of: odoo/odoo#190938
Original PR description
In this PR, - Set the default department for the Plans smart button. - If there is no plan, it will open the form view. Task-4356557 Forward-Port-Of: odoo/odoo#196430 Forward-Port-Of: odoo/odoo#190938
Fixes a small issue when loading translations of multiple chart templates at once. An update to that method added a parameter with the same name as a local variable, and the way it has been done means that the template_data used in each subsequent loop will always be the ones from the first loop only, effectively ignoring the other chart templates. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196359
Original PR description
Fixes a small issue when loading translations of multiple chart templates at once. An update to that method added a parameter with the same name as a local variable, and the way it has been done means that the template_data used in each subsequent loop will always be the ones from the first loop only, effectively ignoring the other chart templates. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196359
Having a credit limit set to 0 means 'no limit', user has to set it to 0.01 to have a minimum limit. This can be confusing for the user, so add a little help message to the fields in both partner and settings views. A better solution should be to use the `ResPartner.use_partner_credit_limit` field to be able to set 0$ limit to specifics partner, but this can't be done in stable (computed, non stored field). opw-4479163 Forward-Port-Of: odoo/odoo#196300 Forward-Port-Of: odoo/odoo#1948
Original PR description
Having a credit limit set to 0 means 'no limit', user has to set it to 0.01 to have a minimum limit. This can be confusing for the user, so add a little help message to the fields in both partner and settings views. A better solution should be to use the `ResPartner.use_partner_credit_limit` field to be able to set 0$ limit to specifics partner, but this can't be done in stable (computed, non stored field). opw-4479163 Forward-Port-Of: odoo/odoo#196300 Forward-Port-Of: odoo/odoo#194886
**Steps to reproduce**: - Activate recurring revenues and open the form in mobile - The expected revenue, duration and probability is not properly displayed, it's gets out of the container. **After this PR:** - they will displayed currently, plus we'll not show `at` in mobile view. Task-4438997 Forward-Port-Of: odoo/odoo#196283 Forward-Port-Of: odoo/odoo#193060
Original PR description
**Steps to reproduce**: - Activate recurring revenues and open the form in mobile - The expected revenue, duration and probability is not properly displayed, it's gets out of the container. **After this PR:** - they will displayed currently, plus we'll not show `at` in mobile view. Task-4438997 Forward-Port-Of: odoo/odoo#196283 Forward-Port-Of: odoo/odoo#193060
Tax account_tax_template_s_iva0_g_i was added in 17.0. Init hook will load the data from account.tax-es_common.csv (_l10n_es_edi_facturae_post_init_hook) when upgrading from 16.0 and fail because account_tax_template_s_iva0_g_i does not exists yet. Removing account_tax_template_s_iva0_g_i from account.tax-es_common.csv prevent the bug and l10n_es_edi_facturae_tax_type will still be set to 1 as it is the default value. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/114680 For
Original PR description
Tax account_tax_template_s_iva0_g_i was added in 17.0. Init hook will load the data from account.tax-es_common.csv (_l10n_es_edi_facturae_post_init_hook) when upgrading from 16.0 and fail because account_tax_template_s_iva0_g_i does not exists yet. Removing account_tax_template_s_iva0_g_i from account.tax-es_common.csv prevent the bug and l10n_es_edi_facturae_tax_type will still be set to 1 as it is the default value. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/114680 Forward-Port-Of: odoo/odoo#196360
Steps to Reproduce: 1. Enter Edit mode. 2. Drag and drop the Tabs snippet into the editor. 3. Click at the end of the text within a tab or select the entire text and press Enter. 4. Observe that the tab splits, creating a new tab. Issue: When pressing the Enter key within a tab element, the tab fails the `isUnbreakable()` check during the Keydown event, causing it to split and create a new tab. This behavior is unintended and disrupts the user experience. Solution: The `isUnbreak
Original PR description
Steps to Reproduce: 1. Enter Edit mode. 2. Drag and drop the Tabs snippet into the editor. 3. Click at the end of the text within a tab or select the entire text and press Enter. 4. Observe that the tab splits, creating a new tab. Issue: When pressing the Enter key within a tab element, the tab fails the `isUnbreakable()` check during the Keydown event, causing it to split and create a new tab. This behavior is unintended and disrupts the user experience. Solution: The `isUnbreakable()` function has been updated to ensure that nav items (tabs) are treated as non-splittable elements. This prevents the tab from being split when the Enter key is pressed. Additionally, a test case has been added to cover the scenarios outlined in [commit]( https://github.com/odoo/odoo/commit/439e491608bab07f3f001d38b7774040a4b18980) as well to ensure the fix is effective. task-4316648 Forward-Port-Of: odoo/odoo#196159 Forward-Port-Of: odoo/odoo#193239
When we display more than one chart in the mobile view, the height of the elements is being adjusted to fill 100%, which in some cases causes a size that makes it impossible to view the chart.  To solve this, we have added a div that will encompass the chart and set a minimum height as defined in the spreadsheets, ensuring that the elements are always displayed correctly.  To solve this, we have added a div that will encompass the chart and set a minimum height as defined in the spreadsheets, ensuring that the elements are always displayed correctly.  cc @Tecnativa TT50972 ping @chienandalu @pedrobaeza --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196364 Forward-Port-Of: odoo/odoo#181335
Currently a ``ParseError`` is arising when the user upgrades the ``event_sale`` module after deleting the ``Event Registration`` product from sales. Steps to reproduce: --- - Install ``Sale_management`` and ``event`` module (without demo data) - Open ``Products`` in Sales > Delete ``Event Registration`` - Now upgrade ``event_sale`` module - The error appears in the log. Traceback: --- ``` Exception: Cannot update missing record 'event_product.product_product_event' ParseError: w
Original PR description
Currently a ``ParseError`` is arising when the user upgrades the ``event_sale`` module after deleting the ``Event Registration`` product from sales. Steps to reproduce: --- - Install…
Currently a ``ParseError`` is arising when the user upgrades the ``event_sale`` module after deleting the ``Event Registration`` product from sales.
Steps to reproduce:
---
- Install ``Sale_management`` and ``event`` module (without demo data)
- Open ``Products`` in Sales > Delete ``Event Registration``
- Now upgrade ``event_sale`` module
- The error appears in the log.
Traceback:
---
```
Exception: Cannot update missing record 'event_product.product_product_event'
ParseError: while parsing /home/odoo/src/odoo/saas-18.1/addons/event_sale/data/event_sale_data.xml:4, somewhere inside <record id="event_product.product_product_event" model="product.product">
<field name="invoice_policy">order</field>
</record>
```
This commit resolves the issue by preventing the creation of a product using ``forcecreate="False"``.
sentry-5731062091
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#195433**Steps to reproduce:** - Create a storable product `P1` with the following BoM: - Qty: 1 unit - Components: - C1, C2, C3: 3 units - Create a MO to produce one unit of `P1`; - Confirm the order; - Update the product's `Quantity` to 1 at least; *The quantities of `To Consume` and `Quantity` columns in the `Components` tab of the notebook are automatically set to 3.* - Update the field `Quantity` of components to: - **C1**: 1 unit - **C2**: 3 units -
Original PR description
**Steps to reproduce:** - Create a storable product `P1` with the following BoM: - Qty: 1 unit - Components: - C1, C2, C3: 3 units - Create a MO to produce one unit of `P1`; - Confirm the order; -…
**Steps to reproduce:**
- Create a storable product `P1` with the following BoM:
- Qty: 1 unit
- Components:
- C1, C2, C3: 3 units
- Create a MO to produce one unit of `P1`;
- Confirm the order;
- Update the product's `Quantity` to 1 at least;
*The quantities of `To Consume` and `Quantity` columns in the `Components` tab of the notebook are automatically set to 3.*
- Update the field `Quantity` of components to:
- **C1**: 1 unit
- **C2**: 3 units
- **C3**: 4 units
___
**Issue:**
On a Manufacturing Order, if a component's quantity is:
- **C1**: less than the <ins>total needed</ins> value → highlights in green;
- **C2**: equal to the value → highlights in black;
- **C3**: higher than the value → highlights in orange.
___
**Expected:**
On a Manufacturing Order, if a component's quantity is:
- **C1**: less -> black;
- **C2**: equal -> green;
- **C3**: higher -> orange.
___
**Cause:**
Text decorations are based on a wrong logic by getting the quantities from wrong field. This field has been changed during an apocalypse.
https://github.com/odoo/odoo/blob/c43297435cfcaf560d5c952ac3c4a383a6f1dc28/addons/mrp/views/mrp_production_views.xml#L405-L406
___
**Fix:**
Reset good field to check quantities, inspired by Odoo 16 using the computed `should_consume_qty` value to check the consumption status:
https://github.com/odoo/odoo/blob/67c78b38e794333eae55758ad4610515df5c49d2/addons/mrp/views/mrp_production_views.xml#L342-L343
___
**Forward:**
To forward up to master.
Odoo 17 :
```
<field name="quantity" string="Quantity"
decoration-success="product_uom_qty - quantity > -0.0001 and product_uom_qty - quantity < 0.0001"
decoration-warning="quantity - product_uom_qty > 0.0001"
```
___
opw-4393156
opw-4391582
opw-4391600
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#196291
Forward-Port-Of: odoo/odoo#190162Some labels in the website editor's sidebar were not translatable, while all the others were. In this commit we make the following parts translatable: - The header of the "Field" options - The "Custom Text" new field name - The "Existing field" header in the selection list of existing field - "Option", "Radio", "Checkbox", and "List" for list-type fields [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#196180 Forward-Port-Of: odoo/odoo#194014
Original PR description
Some labels in the website editor's sidebar were not translatable, while all the others were. In this commit we make the following parts translatable: - The header of the "Field" options - The "Custom Text" new field name - The "Existing field" header in the selection list of existing field - "Option", "Radio", "Checkbox", and "List" for list-type fields [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#196180 Forward-Port-Of: odoo/odoo#194014
A recent change modified the unsubscription flow to make it more resilient to automated security agents. Unfortunately, the implementation of this change breaks if the Website module is installed, and the flow becomes unusable. This commit makes it so that the unsubscription flow works once more, without compromising on resilience to security agents. task-4364446 Forward-Port-Of: odoo/odoo#196187 Forward-Port-Of: odoo/odoo#196154
Original PR description
A recent change modified the unsubscription flow to make it more resilient to automated security agents. Unfortunately, the implementation of this change breaks if the Website module is installed, and the flow becomes unusable. This commit makes it so that the unsubscription flow works once more, without compromising on resilience to security agents. task-4364446 Forward-Port-Of: odoo/odoo#196187 Forward-Port-Of: odoo/odoo#196154
This commit change a bit the behaviour of drag & drop feature in multiple account view. The main goal is to avoid users to drag and drop text in files drop zones. So now, if a user is dragging a text, we hide the files drop zones. Linked:https://github.com/odoo/enterprise/pull/76565 opw-4366605 Forward-Port-Of: odoo/odoo#193355
Original PR description
This commit change a bit the behaviour of drag & drop feature in multiple account view. The main goal is to avoid users to drag and drop text in files drop zones. So now, if a user is dragging a text, we hide the files drop zones. Linked:https://github.com/odoo/enterprise/pull/76565 opw-4366605 Forward-Port-Of: odoo/odoo#193355
Steps to reproduce ================== - Activate the assets debug mode - Print a report => The footer is missing Cause of the issue ================== The sames fonts are used in the header and footer. A first request is made ```http GET /web/static/fonts/lato/Lato-Reg-webfont.woff HTTP/1.1 Accept: */* Cookie: REDACTED Connection: Keep-Alive Accept-Encoding: gzip Accept-Language: en-US,* User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko)
Original PR description
Steps to reproduce ================== - Activate the assets debug mode - Print a report => The footer is missing Cause of the issue ================== The sames fonts are used in the header and…
Steps to reproduce ================== - Activate the assets debug mode - Print a report => The footer is missing Cause of the issue ================== The sames fonts are used in the header and footer. A first request is made ```http GET /web/static/fonts/lato/Lato-Reg-webfont.woff HTTP/1.1 Accept: */* Cookie: REDACTED Connection: Keep-Alive Accept-Encoding: gzip Accept-Language: en-US,* User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34 HTTP/1.0 200 OK Server: Werkzeug/2.0.2 Python/3.11.11 Etag: "1710849406-32964-706485214" Expires: Tue, 28 Jan 2025 13:18:36 GMT Content-Disposition: inline; filename=Lato-Bla-webfont.woff Content-Type: application/font-woff Date: Tue, 28 Jan 2025 13:18:36 GMT Last-Modified: Tue, 19 Mar 2024 11:56:46 GMT Content-Length: 32964 Cache-Control: no-cache, max-age=0 Accept-Ranges: bytes ``` The second request from the footer is ```http GET /web/static/fonts/lato/Lato-Reg-webfont.woff HTTP/1.1 Cache-Control: no-cache Pragma: no-cache If-Modified-Since: Tue, 19 Mar 2024 11:56:46 GMT User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34 Cookie: REDACTED Connection: Keep-Alive Accept-Encoding: gzip If-None-Match: "1710849406-32964-706485214" Accept: */* Accept-Language: en-US,* HTTP/1.0 304 NOT MODIFIED Server: Werkzeug/2.0.2 Python/3.11.11 Date: Tue, 28 Jan 2025 13:18:36 GMT Accept-Ranges: bytes Content-Disposition: inline; filename=Lato-Bla-webfont.woff Cache-Control: no-cache, max-age=0 Expires: Tue, 28 Jan 2025 13:18:36 GMT Etag: "1710849406-32964-706485214" ``` When running wkhtmltopdf manually, we obtain the following output: ``` Warning: Received createRequest signal on a disposed ResourceObject's NetworkAccessManager. This might be an indication of an iframe taking too long to load. ``` This indicates that wkhtmltopdf is not handling the cache headers correctly and fails to recognize the fact that it should reuse the previously received version of the file. Solution ======== In production, odoo should run behind a reverse proxy that handles static files, and the debug assets mode should not be used. Nevertheless, since wkhtmltopdf misinterprets cache headers, we simply remove them in case opw-4413445 Forward-Port-Of: odoo/odoo#195826
When sending templates en masse to multiple recipients they may sometimes have the same number. If their numbers are the same, and the template resolves to the same value there is no need to send them the template multiple times which could be considered as spam. Now if all template variables resolve to the same value, messages will be canceled immediately Similarly to what is done for emails. task-4029026 Forward-Port-Of: odoo/enterprise#78223 Forward-Port-Of: odoo/enterprise#66033
Original PR description
When sending templates en masse to multiple recipients they may sometimes have the same number. If their numbers are the same, and the template resolves to the same value there is no need to send them the template multiple times which could be considered as spam. Now if all template variables resolve to the same value, messages will be canceled immediately Similarly to what is done for emails. task-4029026 Forward-Port-Of: odoo/enterprise#78223 Forward-Port-Of: odoo/enterprise#66033
Bug === The icon in the definition popover are currently black in dark mode, and it should be light gray. The reason is that the component that it uses changed, but the CSS in the properties component wasn't updated (we now use a more permissive rule to avoid future similar issue). Task-4543117 Forward-Port-Of: odoo/enterprise#78386
Original PR description
Bug === The icon in the definition popover are currently black in dark mode, and it should be light gray. The reason is that the component that it uses changed, but the CSS in the properties component wasn't updated (we now use a more permissive rule to avoid future similar issue). Task-4543117 Forward-Port-Of: odoo/enterprise#78386
The new module introduces these 2 reports: 1. VAT control statement (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 2. VIES report (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV The new module also has the tax report XML export logic. The logic was moved here because the new field of tax office was needed in tax repor
Original PR description
The new module introduces these 2 reports: 1. VAT control statement (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 2. VIES report (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV The new module also has the tax report XML export logic. The logic was moved here because the new field of tax office was needed in tax reports XML export. Documenation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHDP3 task-3698642 task-3762956 task-4087283 Forward-Port-Of: odoo/enterprise#78323 Forward-Port-Of: odoo/enterprise#56896
Using the latest data from the Brazilian government [1]. No codes were removed, this contains only new codes and description updates to existing ones. [1] https://www.gov.br/receitafederal/pt-br/assuntos/aduana-e-comercio-exterior/classificacao-fiscal-de-mercadorias/download-ncm-nomenclatura-comum-do-mercosul opw-4522735 Forward-Port-Of: odoo/enterprise#78253
Original PR description
Using the latest data from the Brazilian government [1]. No codes were removed, this contains only new codes and description updates to existing ones. [1] https://www.gov.br/receitafederal/pt-br/assuntos/aduana-e-comercio-exterior/classificacao-fiscal-de-mercadorias/download-ncm-nomenclatura-comum-do-mercosul opw-4522735 Forward-Port-Of: odoo/enterprise#78253
**How to reproduce:** - As Mitchel Admin, create an appointment type, keep it unpublished - Send an invite (with token) to Demo - Log in as Demo (User access level) - Book a meeting with your manager - You get a calendar event in your agenda - Try to open its form **Before this PR:** It gives access error because the user does not have permission to read the appointment type. **Technical reason:** The record rules only grant access if the appointment is scheduled based on resource
Original PR description
**How to reproduce:** - As Mitchel Admin, create an appointment type, keep it unpublished - Send an invite (with token) to Demo - Log in as Demo (User access level) - Book a meeting with your manager - You get a calendar event in your agenda - Try to open its form **Before this PR:** It gives access error because the user does not have permission to read the appointment type. **Technical reason:** The record rules only grant access if the appointment is scheduled based on resources or if the user is part of the staff. **After this PR:** Users will be able to access the appointment type because sudo will be added. Task-4526059 Forward-Port-Of: odoo/enterprise#78155
Before this commit, if you drag and drop a partner name from the form view of bank_reconciliation in the file import dropzone, a traceback is raise. This commit fix this issue by hiding the dropzone when user is not dragging a file. Linked:https://github.com/odoo/odoo/pull/193355 opw-4366605 Forward-Port-Of: odoo/enterprise#76565
Original PR description
Before this commit, if you drag and drop a partner name from the form view of bank_reconciliation in the file import dropzone, a traceback is raise. This commit fix this issue by hiding the dropzone when user is not dragging a file. Linked:https://github.com/odoo/odoo/pull/193355 opw-4366605 Forward-Port-Of: odoo/enterprise#76565
The print button should be invisible when no `line_ids` are added, which implies that the `compute_sheet` was not triggered. task-4491103 Forward-Port-Of: odoo/enterprise#78403 Forward-Port-Of: odoo/enterprise#77848
Original PR description
The print button should be invisible when no `line_ids` are added, which implies that the `compute_sheet` was not triggered. task-4491103 Forward-Port-Of: odoo/enterprise#78403 Forward-Port-Of: odoo/enterprise#77848
Forward-Port-Of: odoo/enterprise#78460
Original PR description
Forward-Port-Of: odoo/enterprise#78460