Tuesday, February 4, 2025
27 changes · saas-17.4
Resolved issues and error corrections
Upgrading the event sales module no longer triggers an error if the default Event Registration product was previously deleted. This prevents unnecessary upgrade failures and keeps maintenance smoother for users who removed that product.
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 ``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-prThis update corrects an automated test problem in the Restaurant point-of-sale bill-splitting flow. It helps keep Odoo's quality checks stable so future updates can be validated reliably.
Original PR description
Fix runbot error. Runbot error: 111506
Property definition popover icons now use the correct light gray color in dark mode instead of appearing black. This improves readability and keeps the interface consistent for users working with dark mode enabled.
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
Miscellaneous changes
**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#190162[FIX] l10n_hu_edi: price include tax Price unit was not properly calculated: * Didn't remove the discount. * Didn't take into account price included taxes. We also removed a test use case that didn't make sense. Task-id: 4236755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190095
Original PR description
[FIX] l10n_hu_edi: price include tax Price unit was not properly calculated: * Didn't remove the discount. * Didn't take into account price included taxes. We also removed a test use case that didn't make sense. Task-id: 4236755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190095
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
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entr
Original PR description
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today,…
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entries which have simply not been posted yet. Reconciliation should be deferred until these moves are no longer in draft. **Steps to reproduce:** 1. Activate another currency, define some rate for today and another (different) rate for tomorrow 2. Create a product with FIFO and real-time costing & valuation 3. Create an initial purchase for the product, receive then bill normally 4. Create another purchase order and receive the product 5. Create the invoice, set the invoie date for tomorrow 6. Post the invoice -> Open the `Exchange Difference` journal to see the entries which should not have been generated **Cause of the issue:** After creating the AMLs which represent the difference in reception/bill unit price of the product, they are caught here: https://github.com/odoo/odoo/blob/971400771a31c05641a8672f6b1d85afaa9c4a19/addons/account/models/account_move.py#L3575 and designated as future moves, not to be posted at this time. At the end of the `_post()` stack: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L229 where there would normally be some `correction_amls`, they weren't created here because the AMLs for the price diff were not posted- so the price diff entry is generated. **Fix:** Wait for pending (`state == 'draft'`) AMLs that are part of some `AccountMove`'s valuation to be no longer in draft before allowing reconciliation with a currency exchange difference. opw-4266652 Forward-Port-Of: odoo/odoo#195073 Forward-Port-Of: odoo/odoo#193971
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#195942 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#195942 Forward-Port-Of: odoo/odoo#194014
…sively The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, this commit introduces a new context key: 'no_exchange_difference_no_recursive'. task-id:
Original PR description
…sively The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, this commit introduces a new context key: 'no_exchange_difference_no_recursive'. task-id: 4531511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196074 Forward-Port-Of: odoo/odoo#195814
- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product margin report, the `total_margin` for **Product A** is shown as 3000, even though we only sold for 1000 (as shown in the balance report). A similar issue occurs when a line on an invoice has a negative price, for instance, due to a discount on a sales order. Similarly: - Create a vendor bill
Original PR description
- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product…
- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product margin report, the `total_margin` for **Product A** is shown as 3000, even though we only sold for 1000 (as shown in the balance report). A similar issue occurs when a line on an invoice has a negative price, for instance, due to a discount on a sales order. Similarly: - Create a vendor bill with **Product B**, with a cost of 1000 and a quantity of 2. - Add a line with **Product B**, with the same cost but a quantity of -1. In the product margin report, the `total_cost` for **Product B** is shown as 3000, even though we only bought for 1000. In `_compute_product_margin_fields_values`, the SQL query takes the absolute value of the balance of every account move line to compute `total`. This means negative values become positive and are added to the positive values instead of canceling each other out, creating the above issues. As a result, the product margin report does not align with the balance sheet. The absolute value is used because `total` is used to compute statistics related to both `out_invoice` (e.g., turnover) and `in_invoice` (e.g., total cost), which both need to be positive. However, the same result can be achieved by inverting the sign for `out_invoice`. opw-4342691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193440
Before this commit: Steps 1) Create 3 statement lines in bank journal 2) Cancel the journal entry of the middle one 3) Try to add the first and third lines to a statement => It shows an `Invalid Operation: Unable to create a statement due to missing transactions. You may want to reorder the transactions before proceeding` This happens because the lines are considered non-contiguous due to the canceled middle line. After this commit: This operation can be performed as the missing line
Original PR description
Before this commit: Steps 1) Create 3 statement lines in bank journal 2) Cancel the journal entry of the middle one 3) Try to add the first and third lines to a statement => It shows an `Invalid Operation: Unable to create a statement due to missing transactions. You may want to reorder the transactions before proceeding` This happens because the lines are considered non-contiguous due to the canceled middle line. After this commit: This operation can be performed as the missing line is canceled, and it shouldn’t be counted for the contiguity check. Also, it should be considered in the statement assignment, similar to how the statement button works in the widget/kanban view. Recording of reproducing the issue: https://drive.google.com/file/d/1I5xwNie1HL9ifuK0z21a6yWDdqI_xbTU/view?usp=sharing Discussion with OLMA: https://discord.com/channels/678381219515465750/1099994955830796348/1330856829638545429 opw-4385040 Forward-Port-Of: odoo/odoo#194541
Change questionable emails for 2 users. Make new demo CV for them as well because we only had the binary pdfs. Raw latex can be found at (google drive): * https://drive.google.com/file/d/1AyRguPcTRrt_7ySXAYE3L9TP4mHnwMNs/view?usp=drive_link * https://drive.google.com/file/d/1e-2JlO3hEbaf6haFTF5TdCy6kx73xOgX/view?usp=drive_link task-4507003 Forward-Port-Of: odoo/odoo#194804
Original PR description
Change questionable emails for 2 users. Make new demo CV for them as well because we only had the binary pdfs. Raw latex can be found at (google drive): * https://drive.google.com/file/d/1AyRguPcTRrt_7ySXAYE3L9TP4mHnwMNs/view?usp=drive_link * https://drive.google.com/file/d/1e-2JlO3hEbaf6haFTF5TdCy6kx73xOgX/view?usp=drive_link task-4507003 Forward-Port-Of: odoo/odoo#194804
### Description of the issue/feature this PR addresses: - Small font sizes ("8", "10", "12") were unavailable in the font size dropdown. These options were only required in the backend and not where custom input for font sizes is provided. ### Desired behavior after PR is merged: - The font size options "8", "10", and "12" are now included in the dropdown. The `d-none` class is conditionally applied to these options based on the value of `showResponsiveFontSizesBadges`. task-3829323
Original PR description
### Description of the issue/feature this PR addresses:
- Small font sizes ("8", "10", "12") were unavailable in the font size dropdown. These options were only required in the backend and not where custom input for font sizes is provided.
### Desired behavior after PR is merged:
- The font size options "8", "10", and "12" are now included in the dropdown. The `d-none` class is conditionally applied to these options based on the value of `showResponsiveFontSizesBadges`.
task-3829323
Forward-Port-Of: odoo/odoo#194365Previously, opening the product info popup would fail if a product had multiple sellers with the same name but different prices and delays. opw-4472861 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195682 Forward-Port-Of: odoo/odoo#195617
Original PR description
Previously, opening the product info popup would fail if a product had multiple sellers with the same name but different prices and delays. opw-4472861 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195682 Forward-Port-Of: odoo/odoo#195617
**Problem**: The function `_getColumnSize` returns the size of the columns. When `gridIndex = columnSize;` is assigned and `columnSize` equals 12, it causes an overflow in the `grid` array. This leads to invalid elements being passed to `_applyColspan`. **Solution**: Ensure `_applyColspan` is only called when `gridIndex` is within valid bounds. **Steps to reproduce**: 1. Open an email marketing template. 2. Extend the "Centered Logo" snippet to the maximum size (`col-12`). 3. Observe
Original PR description
**Problem**: The function `_getColumnSize` returns the size of the columns. When `gridIndex = columnSize;` is assigned and `columnSize` equals 12, it causes an overflow in the `grid` array. This leads to invalid elements being passed to `_applyColspan`. **Solution**: Ensure `_applyColspan` is only called when `gridIndex` is within valid bounds. **Steps to reproduce**: 1. Open an email marketing template. 2. Extend the "Centered Logo" snippet to the maximum size (`col-12`). 3. Observe a traceback error. opw-4381159 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193255
**Problem**: When `u` or `s` tags are applied, changing the `font-size` wraps the text inside these tags instead of applying it to the tags themselves. For example, `a<u>b</u>c` → `a<u><font>b</font></u>c`, which results in an inconsistent appearance. **Solution**: Ensure that the `span` for font size is applied to the highest non-block ancestor to maintain proper styling. **Steps to Reproduce**: 1. Add text. 2. Apply underline. 3. Increase font size. 4. Observe that the underline
Original PR description
**Problem**: When `u` or `s` tags are applied, changing the `font-size` wraps the text inside these tags instead of applying it to the tags themselves. For example, `a<u>b</u>c` → `a<u><font>b</font></u>c`, which results in an inconsistent appearance. **Solution**: Ensure that the `span` for font size is applied to the highest non-block ancestor to maintain proper styling. **Steps to Reproduce**: 1. Add text. 2. Apply underline. 3. Increase font size. 4. Observe that the underline remains the original size instead of scaling with the text. opw-3086072 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195569
For the same reason as [1], this commit adds the parameter "sanitize_overridable=True" to the "description_motivational" field of "gamification" model. This ensures that users with sufficient rights can properly edit the motivational description. This issue is difficult to reproduce in 16.0, as no blocks contain `<button>` elements. However, in 18.0, some snippets—such as `accordion` or the new `image gallery`—include button elements, making the issue more apparent. Steps to reproduce (in
Original PR description
For the same reason as [1], this commit adds the parameter "sanitize_overridable=True" to the "description_motivational" field of "gamification" model. This ensures that users with sufficient rights can properly edit the motivational description. This issue is difficult to reproduce in 16.0, as no blocks contain `<button>` elements. However, in 18.0, some snippets—such as `accordion` or the new `image gallery`—include button elements, making the issue more apparent. Steps to reproduce (in 18.0): - Open website module - Go to /slides - Add a carousel snippet to the side panel > Save - Traceback [1]: https://github.com/odoo/odoo/commit/0cd42f8b55e2ab8f214653556b5bde4b54281972 opw-4272357 Forward-Port-Of: odoo/odoo#195777
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#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#66033
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
… rec widget The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, let's use 'no_exchange_difference_no_recursive'. See the test in this commit. task
Original PR description
… rec widget The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, let's use 'no_exchange_difference_no_recursive'. See the test in this commit. task-id: 4531511 Forward-Port-Of: odoo/enterprise#78324 Forward-Port-Of: odoo/enterprise#78205
### The Issue: In `l10n_es` 347 serves to declare operations within Spain. 349 serves to declare operations in other EU countries https://github.com/odoo/enterprise/commit/9d79ed1128e76e8553a7cc39e790de4369345eec However, when creating an invoice for a Spanish customer, the field `Type for mod 349` is set despite the field `Available for Mod349` being False. ### How to Reproduce: 1. Install `l10n_es`. 2. Create an invoice for a Spanish customer and check that field 347 (AEAT tab)
Original PR description
### The Issue: In `l10n_es` 347 serves to declare operations within Spain. 349 serves to declare operations in other EU countries…
### The Issue: In `l10n_es` 347 serves to declare operations within Spain. 349 serves to declare operations in other EU countries https://github.com/odoo/enterprise/commit/9d79ed1128e76e8553a7cc39e790de4369345eec However, when creating an invoice for a Spanish customer, the field `Type for mod 349` is set despite the field `Available for Mod349` being False. ### How to Reproduce: 1. Install `l10n_es`. 2. Create an invoice for a Spanish customer and check that field 347 (AEAT tab) is set as regular operation. 3. Add both fields (type for 347 and type for 349) to the customer invoices list view using Studio. 4. Observe that for invoices where 347 is set, 349 is also set (E-Suministros/Supplies). ### Cause: In the `account_move` model of `l10n_es_reports`, the field `l10n_es_reports_mod349_invoice_type` was being set with a default value even when `Available for Mod349` is False. opw-4339292 Forward-Port-Of: odoo/enterprise#77699 Forward-Port-Of: odoo/enterprise#76042
Currently, integer fields cannot be selected as unicity fields in marketing campaigns. ### Steps to reproduce * Install `marketing_automation` * Open a marketing campaign form view and try to set the "Unicity based on" field to an integer field. You will notice that integer fields are missing from the selection. ### Cause A small typo in the domain filter: Odoo uses `integer` instead of `int` for field types. opw-4492606 Forward-Port-Of: odoo/enterprise#78289
Original PR description
Currently, integer fields cannot be selected as unicity fields in marketing campaigns. ### Steps to reproduce * Install `marketing_automation` * Open a marketing campaign form view and try to set the "Unicity based on" field to an integer field. You will notice that integer fields are missing from the selection. ### Cause A small typo in the domain filter: Odoo uses `integer` instead of `int` for field types. opw-4492606 Forward-Port-Of: odoo/enterprise#78289
issue: in the payslip menu item To pay shows 'draft', 'verify' payslips instead of 'done' fix: change the action domain to refleact the needed filteration Task: 4487458 Forward-Port-Of: odoo/enterprise#77775
Original PR description
issue: in the payslip menu item To pay shows 'draft', 'verify' payslips instead of 'done' fix: change the action domain to refleact the needed filteration Task: 4487458 Forward-Port-Of: odoo/enterprise#77775
If the statement name is too long, it is not truncated, making it impossible to access the button displaying the statement total. Steps to reproduce: - Go to the accounting dashboard - In the Bank journal, select statements - Open a statement and rename it with a long name that occupies the full width of the left column in the reconciliation page The fix truncates the text and adds its full value in the `title` attribute for better accessibility. Before:  After:  opw-4414518 Forward-Port-Of: odoo/enterprise#77495
**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
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