Wednesday, February 5, 2025
45 changes · saas-18.1
Resolved issues and error corrections
This fix keeps customer action buttons accessible in Point of Sale even when a customer name or details are very long. It improves the customer selection popup layout so staff can continue serving customers without the interface breaking or hiding key actions.
Original PR description
Handle case where customer name is too long causing the customer action buttons inaccessible. - Put `width` and `text-break` on partner name column. - Enable overflow-x on the partner modal (so that if the partner infos are too long, its buttons are still accessible). - Remove weird left/right border on partner line inside customer popup. task-id: 4547853 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Project task list now lets the system automatically size the task ID column instead of using a fixed narrow width. This prevents IDs from becoming hidden or unreadable when there are many tasks or when users sort by ID.
Original PR description
Before this commit, the column of task id displayed in list view of all tasks menu is too small when there are many tasks stored in DB. Moreover, if the user wants to sort the tasks by ID, the column collapses. This commit reverts the hardcoded size set on that column to let the framework computes the column size. Steps to reproduce the issue: ---------------------------- 1. Create a good amount of task (over 1000) 2. Go to Projects > Tasks > All tasks 3. Display the ID column in the list view. 4. Sort by ID Expected Behavior ----------------- The content of the column should still be visible. Current Behavior ---------------- The column size is recomputed and the size is too small to directly see its content. opw-4524749
The Tags field now suppresses the browser's built-in autocomplete suggestions so they no longer overlap Odoo's own dropdown. This restores the previous behavior and makes selecting existing tags clearer for users.
Original PR description
Steps: - Open a task - Click on "Tags" field input Actual result: - Autocomplete is there and can hide dropdown (partially or fully)  Expected result: - Autocomplete is really off by default for many2x field - No autocompletion like before 18.1, we already have one as it's a dropdown opw-4551051 Caused by: https://github.com/odoo/odoo/commit/9c0f5612e9fab514116e2385338d8fc1ce42b821
Message highlighting in Mail is now easier to see, including in dark mode. The update replaces a disruptive visual effect with a clearer highlight animation, making selected messages stand out without reducing the readability of surrounding messages.
Original PR description
The current message highlight isn't really visible in dark mode. It's also not really visible at all, and it "breaks" the UI by making the other messages a bit less visible. This PR removes the translation and creates a highlight animation. Task-4543530 
The Helpdesk ticket list no longer forces the ticket reference column into a very narrow width. This lets longer ticket numbers display more clearly, making it easier for support teams to identify the right tickets.
Original PR description
Before this commit, the column of ticket ref field displayed in the list view of `helpdesk.ticket` has a size set to 30px. That hardcoded size makes the visibility of the content inside that column harder when the reference contains more than 6 digits. This commit removes the hardcoded size to let the framework computes the column size as before. opw-4524749
Miscellaneous changes
Fixing Click All test broken since 662081ca3ad31170961eaf384f8aa2311d39f086 Forward-Port-Of: odoo/odoo#196460
Original PR description
Fixing Click All test broken since 662081ca3ad31170961eaf384f8aa2311d39f086 Forward-Port-Of: odoo/odoo#196460
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#196467 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#196467 Forward-Port-Of: odoo/odoo#194014
Before this commit, for a portal user, the creation of an API key will always be valid for one day. This commit adds the option of selecting a period for which the API key will be valid. The periods proposed take into account of the user's group. Consequently, in the case of a portal user, the administrator must enter a maximum number of days for the portal group (the `api_key_duration` field in the `res.groups` model). opw-4414586 Forward-Port-Of: odoo/odoo#193168
Original PR description
Before this commit, for a portal user, the creation of an API key will always be valid for one day. This commit adds the option of selecting a period for which the API key will be valid. The periods proposed take into account of the user's group. Consequently, in the case of a portal user, the administrator must enter a maximum number of days for the portal group (the `api_key_duration` field in the `res.groups` model). opw-4414586 Forward-Port-Of: odoo/odoo#193168
Currently the different documents are responsible on the move's cancelation. E.g. cancel a SO will delete all the pickings with the same procurement group. Cancel a PO will cancel the receipt an all the moves destination. But in inter company transaction or inter warehouse. The source document is a stock.move directly (or a rr but it's already unlink) Some users delete the receipt from another warehouse but the delivery on the other still exists. So it let pickings that are never cancel in ot
Original PR description
Currently the different documents are responsible on the move's cancelation. E.g. cancel a SO will delete all the pickings with the same procurement group. Cancel a PO will cancel the receipt an all…
Currently the different documents are responsible on the move's cancelation. E.g. cancel a SO will delete all the pickings with the same procurement group. Cancel a PO will cancel the receipt an all the moves destination. But in inter company transaction or inter warehouse. The source document is a stock.move directly (or a rr but it's already unlink) Some users delete the receipt from another warehouse but the delivery on the other still exists. So it let pickings that are never cancel in other companies/warehouses. This commit and an option to allow the cancel propagate upstream. It's hidden under the `stock.cancel_moves_origin` system parameter in order to avoid a huge behavior modification for other users. opw-3274939 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195575 Forward-Port-Of: odoo/odoo#186730
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
This commit increases the text size of the ordered product and notes on the preparation ticket, ensuring better readability. task-4535901 Forward-Port-Of: odoo/odoo#196151
Original PR description
This commit increases the text size of the ordered product and notes on the preparation ticket, ensuring better readability. task-4535901 Forward-Port-Of: odoo/odoo#196151
- 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 h
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 Forward-Port-Of: odoo/odoo#195382
- 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#195453 Forward-Port-Of: odoo/odoo#193440
`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**: - 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
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
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#195506 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#195506 Forward-Port-Of: odoo/odoo#193355
Exact time are shown in discuss since version 18.0. Format was always 24-hour, which is ok for some users but not for others. This commit uses time format of luxon browser based on user locale, so that this is the expected format as the user is used to see in all browser apps. Note that we don't choose DB date format, because discuss app are used by many other users and the custom format on whole DB might make some users happy but others not. In particular, the default en_US language time
Original PR description
Exact time are shown in discuss since version 18.0. Format was always 24-hour, which is ok for some users but not for others. This commit uses time format of luxon browser based on user locale, so…
Exact time are shown in discuss since version 18.0. Format was always 24-hour, which is ok for some users but not for others. This commit uses time format of luxon browser based on user locale, so that this is the expected format as the user is used to see in all browser apps. Note that we don't choose DB date format, because discuss app are used by many other users and the custom format on whole DB might make some users happy but others not. In particular, the default en_US language time format in Odoo uses 24-hour when lots of english americans are used and prefer 12-hour format. Using the locale format of browser, which tend to rely on OS settings, makes (almost) everyone happy. Also the extra AM/PM could lead to size issue on small squashed messages, this commit also fixes it. opw-4482727 Before / After   Forward-Port-Of: odoo/odoo#195668
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 impl
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 Forward-Port-Of: odoo/odoo#195573
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
When the Arabic language was selected, the PoS Restaurant module would error due to date formatting using Arabic numerals. This commit forces Latin digits in the date format to prevent the error. opw-4544010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196368
Original PR description
When the Arabic language was selected, the PoS Restaurant module would error due to date formatting using Arabic numerals. This commit forces Latin digits in the date format to prevent the error. opw-4544010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196368
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
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
Since the class `s_searchbar_input` was translated into Dutch by a translator on Transifex. <sub>See screenshot of the Website `nl.po` file </sub>↓ <kbd></kbd> It is no longer possible to drop the searchbar block onto a webpage when Odoo's language is set to Dutch. In this PR, we add `t-translation="off"` in the xpath that adds this class to the list of droppable element selectors, so it won't be
Original PR description
Since the class `s_searchbar_input` was translated into Dutch by a translator on Transifex. <sub>See screenshot of the Website `nl.po` file </sub>↓…
Since the class `s_searchbar_input` was translated into Dutch by a translator on Transifex. <sub>See screenshot of the Website `nl.po` file </sub>↓ <kbd></kbd> It is no longer possible to drop the searchbar block onto a webpage when Odoo's language is set to Dutch. In this PR, we add `t-translation="off"` in the xpath that adds this class to the list of droppable element selectors, so it won't be translated anymore. We also do the same for other xpath-ed classes that don’t have `t-translation="off"`, to prevent the same issue elsewhere. Since the class is already translated in the existing databases, in stable versions, we add the class a second time to the list of droppable element selectors. This second class won't be translated, which will fix the issue for Dutch users. [opw-4461785](https://www.odoo.com/web#id=4461785&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) ----------- Note: This PR also fix 2 minor bugs: - The text on the button to install a block overflows when translated into certain languages that make it longer. <kbd></kbd> - The `Embed code` block "Click on Edit..." message is not visible on dark background. <kbd></kbd> Forward-Port-Of: odoo/odoo#196286 Forward-Port-Of: odoo/odoo#193819
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#196375 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#196375 Forward-Port-Of: odoo/odoo#194804
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
Before this PR, if a chatbot's last step is redirecting to a URL, a visitor could be trapped in an infinite loop of redirection. This is because the chatbot always replays the last step of the script when the page loads. This PR updated the livechat_active status when all the steps were done and ensured that the chatbot service doesn't start if livechat_active is false. Task-4518285 Forward-Port-Of: odoo/odoo#195429
Original PR description
Before this PR, if a chatbot's last step is redirecting to a URL, a visitor could be trapped in an infinite loop of redirection. This is because the chatbot always replays the last step of the script when the page loads. This PR updated the livechat_active status when all the steps were done and ensured that the chatbot service doesn't start if livechat_active is false. Task-4518285 Forward-Port-Of: odoo/odoo#195429
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195003
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195003
Before this commit, only pointerup was listened and was on the global document. Now, the event is listened on the ownerDocument of the element. Like that, if the element is inside an iframe, it will be correctly listened. The "drop" is also added to the listened events, because sign doesn't use the draggable hook of owl, instead it uses the vanilla drag and drop system of javascript. The dropzone shown during an onboarding tour is also fixed and takes into account the offset of the iframe
Original PR description
Before this commit, only pointerup was listened and was on the global document. Now, the event is listened on the ownerDocument of the element. Like that, if the element is inside an iframe, it will be correctly listened. The "drop" is also added to the listened events, because sign doesn't use the draggable hook of owl, instead it uses the vanilla drag and drop system of javascript. The dropzone shown during an onboarding tour is also fixed and takes into account the offset of the iframe in the top document. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196432
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#195433To reproduce: ============= - create 3 applications for same candidate - open one application and archive/refuse it - refresh the page -> smart button **Other Applications** displays 2 - click on the smart button -> only 2 applications are listed Problem: ======= - when refreshing the page, the context is lost so `other_applications_count` is computed without `active_test=False` so non active records are excluded - when clicking on the smart button, the current record is excluded from
Original PR description
To reproduce: ============= - create 3 applications for same candidate - open one application and archive/refuse it - refresh the page -> smart button **Other Applications** displays 2 - click on the smart button -> only 2 applications are listed Problem: ======= - when refreshing the page, the context is lost so `other_applications_count` is computed without `active_test=False` so non active records are excluded - when clicking on the smart button, the current record is excluded from the domain Solution: ========= - compute `other_applications_count` with `active_test=False` - add the current record in the domain when clicking on the smart button opw-4488834 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196110
**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#190162In this commit, we fix multiple tours on step that can cause non deterministic behaviors by adding additionnal steps to ensure tour is well on the way to taking the right path. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195973
Original PR description
In this commit, we fix multiple tours on step that can cause non deterministic behaviors by adding additionnal steps to ensure tour is well on the way to taking the right path. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195973
First commit introduces the allow_hierachy_operators description on relational fields while second commit allows to use the hierarchical operators (child_of/parent_of) on these fields inside the domain selector while also allowing multiselection with these operators. task-4492974 Forward-Port-Of: odoo/odoo#194909
Original PR description
First commit introduces the allow_hierachy_operators description on relational fields while second commit allows to use the hierarchical operators (child_of/parent_of) on these fields inside the domain selector while also allowing multiselection with these operators. task-4492974 Forward-Port-Of: odoo/odoo#194909
This commit will update some taxes: - Update the purchase tax accounts - Add new 0% EX tax - Delete EX RS 20% & EX RS -20% In the tax report: - Change the name of the report - Add a new record task: 4244715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195131 Forward-Port-Of: odoo/odoo#185947
Original PR description
This commit will update some taxes: - Update the purchase tax accounts - Add new 0% EX tax - Delete EX RS 20% & EX RS -20% In the tax report: - Change the name of the report - Add a new record task: 4244715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195131 Forward-Port-Of: odoo/odoo#185947
This fix updates the taxes and the modelo 390 tax report Task: 4453629 Enterprise PR: https://github.com/odoo/enterprise/pull/77941 Forward-Port-Of: odoo/odoo#196101 Forward-Port-Of: odoo/odoo#195380
Original PR description
This fix updates the taxes and the modelo 390 tax report Task: 4453629 Enterprise PR: https://github.com/odoo/enterprise/pull/77941 Forward-Port-Of: odoo/odoo#196101 Forward-Port-Of: odoo/odoo#195380
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#78037 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#78037 Forward-Port-Of: odoo/enterprise#76565
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
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
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
Forward-Port-Of: odoo/enterprise#77743
Original PR description
Forward-Port-Of: odoo/enterprise#77743
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
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#78154This commit updates the BOE mod390 export for 2024 Task: 4453629 Community PR: https://github.com/odoo/odoo/pull/195380 Forward-Port-Of: odoo/enterprise#78342 Forward-Port-Of: odoo/enterprise#77941
Original PR description
This commit updates the BOE mod390 export for 2024 Task: 4453629 Community PR: https://github.com/odoo/odoo/pull/195380 Forward-Port-Of: odoo/enterprise#78342 Forward-Port-Of: odoo/enterprise#77941
Changes: 1. On click chatter button, scrolldown to chatter so that we know what happens. 2. Don't show 'Folders' if a record is selected. 3. Properly show control action buttons. 4. Display folder/files into 2 columns, 3 columns if landscape on mobile. Task-4380904 Forward-Port-Of: odoo/enterprise#76233
Original PR description
Changes: 1. On click chatter button, scrolldown to chatter so that we know what happens. 2. Don't show 'Folders' if a record is selected. 3. Properly show control action buttons. 4. Display folder/files into 2 columns, 3 columns if landscape on mobile. Task-4380904 Forward-Port-Of: odoo/enterprise#76233