Friday, March 28, 2025
47 changes · saas-18.2
Enhancements to existing features
Helpdesk now suggests the customer as a recipient even when they already follow the conversation. This keeps customer communication options consistent and helps teams avoid missing the right recipient when replying.
Original PR description
Even if follower, customer is now suggested. Task-4668703
Resolved issues and error corrections
Sales administrators now appear correctly as available salespeople when assigning responsibility for a sales order. This fixes a dropdown issue that could prevent teams from assigning orders to the right internal user.
Original PR description
Versions -------- - saas-18.2 - master Steps ----- 1. Create a new user with Sales / Adminstrator rights; 2. create a sales order; 3. assign new user to sales order. Issue ----- User doesn't show up in the dropdown. Cause ----- Commit 34a50e83e6540 changed which results you get when searching on groups. Previously, any implied group would be included by default. Now, you have to use the `all_group_ids` to include transitive groups. Solution -------- Use `all_group_ids` in the `user_id` field's domain. opw-4662889
Features or functions removed from Odoo
The signing app no longer keeps old predefined signing roles because the updated interface now creates signing rules directly on each template when needed. This cleanup reduces obsolete data and updates related examples and automated checks across signing, HR, recruitment, and rental flows without changing the core signing experience.
Original PR description
- Since the big UI refactor in the sign app, the sign item roles are not used anymore and rules are added on the template on the run - This commit aims to clean up the data file of these roles and update the tests not to use them Task: 4646742
Miscellaneous changes
Versions -------- - 18.0+ Steps ----- 1. Have a combo product; 2. confirm a quotation with the combo product; 3. fully invoice confirmed quotation; 4. go back to quotation. Issue ----- The "Create Invoice" button is still visible. Clicking on it will create an invoice with only the combo product on it (none of its constituent products). Cause ----- Commit 602ef86b8dcad changed how combo product lines get invoiced. Instead of display type `product`, they get displayed as `line
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a combo product; 2. confirm a quotation with the combo product; 3. fully invoice confirmed quotation; 4. go back to quotation. Issue ----- The "Create…
Versions -------- - 18.0+ Steps ----- 1. Have a combo product; 2. confirm a quotation with the combo product; 3. fully invoice confirmed quotation; 4. go back to quotation. Issue ----- The "Create Invoice" button is still visible. Clicking on it will create an invoice with only the combo product on it (none of its constituent products). Cause ----- Commit 602ef86b8dcad changed how combo product lines get invoiced. Instead of display type `product`, they get displayed as `line_section` lines. The `_compute_qty_invoiced` method requires the line to have linked `invoice_lines` that have a `quantity` value to properly calculate the quantity invoiced, and later on, the quantity to invoice: https://github.com/odoo/odoo/blob/bac9ed6d84ff64ef39741cb66afdf565c7e9f221/addons/sale/models/sale_order_line.py#L907-L913 Because these values aren't passed when creating an invoice line, the `qty_to_invoice` value of the combo product line will never be 0. Solution -------- Pass the requisite fields to the invoice line create values, along with the `optional_values` to ensure the correct `sequence` value gets used. opw-4633972 Forward-Port-Of: odoo/odoo#203829 Forward-Port-Of: odoo/odoo#203131
This fix makes point of sale automated checks wait for local browser data updates to finish before refreshing. It helps prevent intermittent runbot failures, improving confidence in test results without changing normal user workflows.
Original PR description
When refreshing during tours, we need to ensure that all indexedDB transaction are done, otherwise we can have some issues. Runbot errors: 161174, 161175
Issue ===== In the `mrp_bom_form_view` BoM form view, the `many2one_uom` field widget use the field `product_tmpl_id` as its `product_field` which is related to `product.template` model. The issue is, in the `uom.Many2OneUomField` template, we define the `productModel` attribute by looking at the **record's model**: if it's `product.template`, we use it, otherwise we use `product.product`. Here, the model is `mrp.bom`, so `product.product` is used. That leads to an issue in `Many2XUomTagsAu
Original PR description
Issue ===== In the `mrp_bom_form_view` BoM form view, the `many2one_uom` field widget use the field `product_tmpl_id` as its `product_field` which is related to `product.template` model. The issue…
Issue ===== In the `mrp_bom_form_view` BoM form view, the `many2one_uom` field widget use the field `product_tmpl_id` as its `product_field` which is related to `product.template` model. The issue is, in the `uom.Many2OneUomField` template, we define the `productModel` attribute by looking at the **record's model**: if it's `product.template`, we use it, otherwise we use `product.product`. Here, the model is `mrp.bom`, so `product.product` is used. That leads to an issue in `Many2XUomTagsAutocomplete` `updateReferenceUnit` because we search for a `product.product` with the id of a `product.template`. If it exists a product variant with this id, the error is not visible because we use the UoM reference of the wrong product but all works good. But if there is no product variant for this id, there is a traceback. How to reproduce ================ - Install MRP; - Enable Units of Measure; - Open a BoM form view; - Select a Product (`product.template` field) with an id where no `product.product` exists with this exact same id -> Traceback. Fix === To fix this issue, we removed the condition in the template and get the model on the field itself in the `setup`. If the field model is not `product.product` or `product.template`, we throw an error. The same change is done for both `Many2XUomTagsAutocomplete` and `Many2ManyUomTagsField` since they follow the same logic. Also, the test/tour `test_mrp_bom_product_catalog` was sometime affected by this issue, now the UoM setting is always active for this test to minimize the chance to got an nondeterministic error. Runbot build error: 135062 Forward-Port-Of: odoo/odoo#202030
Before this PR, live chats were sometimes displayed under the wrong category. Steps to reproduce: - Ensure you have one live chat pinned in the sidebar. - Go to the inbox, fold the live chat category. - Reload the page. - Open the live chat category. - The chat is displayed under the wrong category. Since [1], the t-key used in the side bar template is the index of the category which is not reliable. Change it to the id field which is also unique but more reliable. [1]: https://git
Original PR description
Before this PR, live chats were sometimes displayed under the wrong category. Steps to reproduce: - Ensure you have one live chat pinned in the sidebar. - Go to the inbox, fold the live chat category. - Reload the page. - Open the live chat category. - The chat is displayed under the wrong category. Since [1], the t-key used in the side bar template is the index of the category which is not reliable. Change it to the id field which is also unique but more reliable. [1]: https://github.com/odoo/odoo/pull/203150  Forward-Port-Of: odoo/odoo#203673 Forward-Port-Of: odoo/odoo#203416
The CSS of global filters in dashboard was broken if there was too many filters or if a filter was too tall (e.g. relation filter with many options). This commit fixes those issues. Now the filters are wrapped in multiple lines if there are too many filters. That mean that we have to define a fixed width for the filters, otherwise the filters won't be aligned over multiple lines and will be ugly. The commit also adds max-height and overflow on the filters to avoid the filters being too tall.
Original PR description
The CSS of global filters in dashboard was broken if there was too many filters or if a filter was too tall (e.g. relation filter with many options). This commit fixes those issues. Now the filters…
The CSS of global filters in dashboard was broken if there was too many filters or if a filter was too tall (e.g. relation filter with many options). This commit fixes those issues. Now the filters are wrapped in multiple lines if there are too many filters. That mean that we have to define a fixed width for the filters, otherwise the filters won't be aligned over multiple lines and will be ugly. The commit also adds max-height and overflow on the filters to avoid the filters being too tall. It also changes the style of the `Select period...` option to be more placeholder-like. Note: the same fix cannot easily be done in 16.0, because there the date picker isn't a popover there, this adding `overflow` to the CSS breaks it. Task: [4624108](https://www.odoo.com/web#id=4624108&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#203855 Forward-Port-Of: odoo/odoo#201391
When a quotation has been confirmed, the invoice generated and confirmed by an accountant, the salesman of that first quotation has access to the invoice and its button "Send & Print". However, when trying to generate the document and send it, he receives an access right error. The salesman should be able to Send & Print when the invoice has been confirmed by an accountant. task-4378899 Forward-Port-Of: odoo/odoo#203473 Forward-Port-Of: odoo/odoo#191823
Original PR description
When a quotation has been confirmed, the invoice generated and confirmed by an accountant, the salesman of that first quotation has access to the invoice and its button "Send & Print". However, when trying to generate the document and send it, he receives an access right error. The salesman should be able to Send & Print when the invoice has been confirmed by an accountant. task-4378899 Forward-Port-Of: odoo/odoo#203473 Forward-Port-Of: odoo/odoo#191823
Steps to reproduce: - Create two products, both in AVCO cost method - Create another product with a standard_price of 100 - Create a bom to produce an AVCO product and has the other one as byproduct. Also use the last one as component - Create a MO for 1 unit of that bom and produce it - Unbuild the MO Issue: The valuation layer created for the byproduct in the unbuild will use the value of the main product of the MO instead of its counterpart. opw-4623337 --- I confirm I have si
Original PR description
Steps to reproduce: - Create two products, both in AVCO cost method - Create another product with a standard_price of 100 - Create a bom to produce an AVCO product and has the other one as byproduct. Also use the last one as component - Create a MO for 1 unit of that bom and produce it - Unbuild the MO Issue: The valuation layer created for the byproduct in the unbuild will use the value of the main product of the MO instead of its counterpart. opw-4623337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203118 Forward-Port-Of: odoo/odoo#201627
FIX FOR MASTER −1 ------------------------------------------------------- After version 15 they display types stopped doing anything. Make them change the visual style again. task-4554655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203464 Forward-Port-Of: odoo/odoo#201186
Original PR description
FIX FOR MASTER −1 ------------------------------------------------------- After version 15 they display types stopped doing anything. Make them change the visual style again. task-4554655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203464 Forward-Port-Of: odoo/odoo#201186
In this commit, we're removing the initial delay from macro.js. This parameter was introduced to try to optimize macro execution times. However, in practice, it doesn't change much. The debounceDelay is only used if there's a trigger in a step. 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#20
Original PR description
In this commit, we're removing the initial delay from macro.js. This parameter was introduced to try to optimize macro execution times. However, in practice, it doesn't change much. The debounceDelay is only used if there's a trigger in a step. 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#203505
Required upgrade to sdk 5.65.0 or higher: https://docs.adyen.com/online-payments/release-notes/?Web+Components%2FDrop-in=&title%5B0%5D=Web+Components%2FDrop-in#releaseNote=2024-05-27-web-componentsdrop-in-5.65.0 Upgrade sdk to 6.9.0 and api to 71 task-4649327 Forward-Port-Of: odoo/odoo#202498
Original PR description
Required upgrade to sdk 5.65.0 or higher: https://docs.adyen.com/online-payments/release-notes/?Web+Components%2FDrop-in=&title%5B0%5D=Web+Components%2FDrop-in#releaseNote=2024-05-27-web-componentsdrop-in-5.65.0 Upgrade sdk to 6.9.0 and api to 71 task-4649327 Forward-Port-Of: odoo/odoo#202498
- Open a Contact; - Click on the Accounting tab; Before this commit, a recursion occurred which blocked the interface. This issue arises due to the FieldMany2ManyTagsBanks component always saving the record on its setup. Additionally, since [1], a saved record without changes will be updated with the initial values. This will generate a re-rendering and the FieldMany2ManyTagsBanks will force the record to be saved again, and this will create a recursion. Now, the FieldMany2ManyTagsBanks w
Original PR description
- Open a Contact; - Click on the Accounting tab; Before this commit, a recursion occurred which blocked the interface. This issue arises due to the FieldMany2ManyTagsBanks component always saving the record on its setup. Additionally, since [1], a saved record without changes will be updated with the initial values. This will generate a re-rendering and the FieldMany2ManyTagsBanks will force the record to be saved again, and this will create a recursion. Now, the FieldMany2ManyTagsBanks will only save dirty records. opw-4675973 opw-4676949 opw-4677092 opw-4677086 opw-4677856 opw-4678211 [1] : https://github.com/odoo/odoo/commit/43fb8a45ac629c1883ca9521a8879cf19ca7538b Forward-Port-Of: odoo/odoo#203818
Versions -------- - 18.0+ Steps ----- 1. Create a quotation; 2. add a product with taxes. Issue ----- Depending on the company tax setting, the only "Amount" viewable from the sale order line view is either `price_total` or `price_subtotal`. There's no way to easily add the other column to the view. Cause ----- The Pricepocalypse changed the view in commit 5bfd603d0cae5 to make only one "Amount" column available. Solution -------- Add the other amount as an optional fie
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a quotation; 2. add a product with taxes. Issue ----- Depending on the company tax setting, the only "Amount" viewable from the sale order line view is either `price_total` or `price_subtotal`. There's no way to easily add the other column to the view. Cause ----- The Pricepocalypse changed the view in commit 5bfd603d0cae5 to make only one "Amount" column available. Solution -------- Add the other amount as an optional field. opw-4574399 Forward-Port-Of: odoo/odoo#203215
See commit messages for details. Fixes runbot issue [105000](https://runbot.odoo.com/odoo/runbot.build.error/105000) Enterprise: https://github.com/odoo/enterprise/pull/82189 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203556 Forward-Port-Of: odoo/odoo#203472
Original PR description
See commit messages for details. Fixes runbot issue [105000](https://runbot.odoo.com/odoo/runbot.build.error/105000) Enterprise: https://github.com/odoo/enterprise/pull/82189 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203556 Forward-Port-Of: odoo/odoo#203472
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#201427
Original PR description
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#201427
- Adjusting fetchmail_server behavior to read specific fuel taxes from vendor bills, which can be extended for other taxes. - Adding the functionality of manually uploading CL EDI documents through fetchmail_server functions. Unrecognized documents are parsed as vendor bills. task-4359365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203744 Forward-Port-Of: odoo/odoo#190873
Original PR description
- Adjusting fetchmail_server behavior to read specific fuel taxes from vendor bills, which can be extended for other taxes. - Adding the functionality of manually uploading CL EDI documents through fetchmail_server functions. Unrecognized documents are parsed as vendor bills. task-4359365 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203744 Forward-Port-Of: odoo/odoo#190873
Before version 18, even if the response was Incorrect in the headers, it would still process the XML itself to see if e.g. there was a more detailed error message in there. Here, we just add the errors together again: the one from the header and the one from the response. 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
Original PR description
Before version 18, even if the response was Incorrect in the headers, it would still process the XML itself to see if e.g. there was a more detailed error message in there. Here, we just add the errors together again: the one from the header and the one from the response. 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#203132
Steps to reproduce: - Add a mega menu to the menu. - Enter edit mode. - Open the mega menu. - Click on a snippet category. - Bug: A traceback occurs. This was due to the absence of drop zones on the page for non-inline snippets when a mega menu was open. After this commit, we ensure that drop zones are present when clicking. Forward-Port-Of: odoo/odoo#200908
Original PR description
Steps to reproduce: - Add a mega menu to the menu. - Enter edit mode. - Open the mega menu. - Click on a snippet category. - Bug: A traceback occurs. This was due to the absence of drop zones on the page for non-inline snippets when a mega menu was open. After this commit, we ensure that drop zones are present when clicking. Forward-Port-Of: odoo/odoo#200908
…ring orders **Issue:** When using a language other than English and setting the Manufacturing Order name field to read-only via Studio, the name is not automatically converted into a unique value. As a result, after saving the first order (which defaults to "New"), any subsequent order creation fails with an error, stating that the name must be unique. **Steps to Reproduce:** 1. Install the Manufacturing app. 2. Install the Studio app. 3. Change the language to one other than English.
Original PR description
…ring orders **Issue:** When using a language other than English and setting the Manufacturing Order name field to read-only via Studio, the name is not automatically converted into a unique value.…
…ring orders
**Issue:**
When using a language other than English and setting the Manufacturing Order name field to read-only via Studio, the name is not automatically converted into a unique value. As a result, after saving the first order (which defaults to "New"), any subsequent order creation fails with an error, stating that the name must be unique.
**Steps to Reproduce:**
1. Install the Manufacturing app.
2. Install the Studio app.
3. Change the language to one other than English.
4. Navigate to Manufacturing > Operations > Manufacturing Orders.
5. Create a new Manufacturing Order.
6. Open Studio and set the name field to read-only.
7. Save the first Manufacturing Order with the default name ("New").
8. Attempt to create another Manufacturing Order.
9. Error: The system prevents saving due to a duplicate name.
Expected Behavior: The Manufacturing Order name should be automatically updated to a unique value upon saving, regardless of the selected language.
Actual Behavior: The name remains "New", but it is not translated when using a different language. Since the name field is set to read-only, the system does not trigger the automatic conversion to a unique name. As a result, when attempting to create another order, the system detects a duplicate and prevents saving due to a name conflict.
**Root Cause**
The system always sets the default name to "New" in English. However, the automatic name conversion process expects a translated name before updating it to a unique value. Because "New" remains untranslated, the system does not recognize it as a placeholder and fails to convert it.
**Fix**
Modify the default value of the name field to use a localized translation like it’s done for the sale order https://github.com/odoo/odoo/blob/7bc38562f1988ba15525c04168e30c06a8f1d33c/addons/sale/models/sale_order.py#L55. This ensures that the default name is translated according to the user's language, allowing the system to properly detect and replace it with a unique value when saving.
Opw-4553109
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#200138Steps to reproduce: - Create a non-storable product (e.g. a service) - Create a new RFQ - Add that product to a PO line Issue: The forecast icon is visible, even though the product is non-storable and the forecast doesn't make any sense. 73170f0 was a bit too optimistic on the invisible condition, as it needs a field directly on the model to be able to check these clauses. So we add a related as it's done for other. opw-4672513 --- I confirm I have signed the CLA and read the PR
Original PR description
Steps to reproduce: - Create a non-storable product (e.g. a service) - Create a new RFQ - Add that product to a PO line Issue: The forecast icon is visible, even though the product is non-storable and the forecast doesn't make any sense. 73170f0 was a bit too optimistic on the invisible condition, as it needs a field directly on the model to be able to check these clauses. So we add a related as it's done for other. opw-4672513 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203545
An incorrect date being represented (14/11/2007 is displayed as 20/07/1114) on the payment field. The date was parsed two times with the format of the user's language, while the first parse should be based on the current format of the database. To reproduce: - Change user language to Spanish or French. - Register a payment for an invoice with a payment date between October 1st and December 31st, from 2001 to 2012. - "Paid on 20/07/1114" appears. Ticket [link](https://www.odoo.com/odoo/
Original PR description
An incorrect date being represented (14/11/2007 is displayed as 20/07/1114) on the payment field. The date was parsed two times with the format of the user's language, while the first parse should be based on the current format of the database. To reproduce: - Change user language to Spanish or French. - Register a payment for an invoice with a payment date between October 1st and December 31st, from 2001 to 2012. - "Paid on 20/07/1114" appears. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4486653) opw-4486653 Forward-Port-Of: odoo/odoo#203535 Forward-Port-Of: odoo/odoo#202258
Example of steps: - Install `web_studio` - Add a file field anywhere in a view form via Studio - Use pdf_viewer widget on this file field - Close Studio - Create a new record - Upload a pdf - Save - You have no way to download the pdf Since https://github.com/odoo/odoo/commit/8a755d58330218b550efc0fea2f98800151c09a5 This commit allow users to do it by adding a new download button between the existing edit and remove button. Since opw-4630186 Forward-Port-Of: odoo/odoo#203687
Original PR description
Example of steps: - Install `web_studio` - Add a file field anywhere in a view form via Studio - Use pdf_viewer widget on this file field - Close Studio - Create a new record - Upload a pdf - Save - You have no way to download the pdf Since https://github.com/odoo/odoo/commit/8a755d58330218b550efc0fea2f98800151c09a5 This commit allow users to do it by adding a new download button between the existing edit and remove button. Since opw-4630186 Forward-Port-Of: odoo/odoo#203687
A new tag is necessary to calculate deductibles expenses associated to 190 AEAT report. It isn't a percent tax, it's a new tag to can set it in move lines and calculate this box from 190 AEAT report. 190 AEAT report (190 AEAT) isn't now included in Odoo, but it could be added in the future. Meanwhile the tax can be used in oca module `l10n_es_aeat_mod_190' or you can do a filter for this tax and fill in the report manually. https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_reg
Original PR description
A new tag is necessary to calculate deductibles expenses associated to 190 AEAT report. It isn't a percent tax, it's a new tag to can set it in move lines and calculate this box from 190 AEAT report. 190 AEAT report (190 AEAT) isn't now included in Odoo, but it could be added in the future. Meanwhile the tax can be used in oca module `l10n_es_aeat_mod_190' or you can do a filter for this tax and fill in the report manually. https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_100_199/archivos_24/DISENOS_LOGICOS_190-2024.pdf https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/GI10/Instrucciones/instr_mod190_es_es.pdf @moduon MT-8853 @rafaelbn @etobella @pedrobaeza @jco-odoo @chklop --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203367 Forward-Port-Of: odoo/odoo#198546
Creating a physical gift card in the PoS without an expiration date led to an Odoo error. Steps to reproduce: ------------------- * Open a PoS * Add a gift card * Click on Sell physical gift card? * Input a unique code and a value * Remove the default expiration date * Click on Add Balance > Observation: TypeError: value.toFormat is not a function at serializeDate Why the fix: ------------ the addBalance() method was trying to format the expiration date with serializeDate(t
Original PR description
Creating a physical gift card in the PoS without an expiration date led to an Odoo error.
Steps to reproduce:
-------------------
* Open a PoS
* Add a gift card
* Click on Sell physical gift card?
* Input a unique code and a value
* Remove the default expiration date
* Click on Add Balance
> Observation:
TypeError: value.toFormat is not a function
at serializeDate
Why the fix:
------------
the addBalance() method was trying to format the expiration date with serializeDate(this.state.expirationDate) without verrifing that it exists.
opw-4623141
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#202985
Forward-Port-Of: odoo/odoo#201543### Issue: It happens due to many reasons that the `stock.quant` object and the `stock.move.line` loose their synchronization and it could have a difference between the sum of `stock.move.line` and the quantity/reserved quantity on the stock.quant. Starting from 18.0: Commit 766ec99dbc2701a237f082f3fb124793d9dfe596 the action `_clean_reservations` is called in the `_quant_tasks` to reconcile both. However, this action is performed in `inventory_mode` when we access quant view: https://githu
Original PR description
### Issue: It happens due to many reasons that the `stock.quant` object and the `stock.move.line` loose their synchronization and it could have a difference between the sum of `stock.move.line` and…
### Issue: It happens due to many reasons that the `stock.quant` object and the `stock.move.line` loose their synchronization and it could have a difference between the sum of `stock.move.line` and the quantity/reserved quantity on the stock.quant. Starting from 18.0: Commit 766ec99dbc2701a237f082f3fb124793d9dfe596 the action `_clean_reservations` is called in the `_quant_tasks` to reconcile both. However, this action is performed in `inventory_mode` when we access quant view: https://github.com/odoo/odoo/blob/82aa55b90e64defb6dd6707c5cebf74fba6b74d3/addons/stock/models/stock_quant.py#L394-L398 https://github.com/odoo/odoo/blob/82aa55b90e64defb6dd6707c5cebf74fba6b74d3/addons/stock/models/stock_quant.py#L1301-L1304 In certain cases this causes an invalid operation. For instance because we can not create a quants in a location that does not belong to a company`inventory_move`. This happens because the company_id of the quant will be false: https://github.com/odoo/odoo/blob/82aa55b90e64defb6dd6707c5cebf74fba6b74d3/addons/stock/models/stock_quant.py#L57 But the `company_id` of the product will not and hence will fail the `check_company` performed for inventory_move: https://github.com/odoo/odoo/blob/82aa55b90e64defb6dd6707c5cebf74fba6b74d3/addons/stock/models/stock_quant.py#L306-L311 https://github.com/odoo/odoo/blob/82aa55b90e64defb6dd6707c5cebf74fba6b74d3/odoo/models.py#L4354-L4355 ### Steps to reproduce: - In the settings enable intercompany transactions and multi-step routes - Create a storable product P and set the product company_id - Create an internal transfer from the inter-company transit to stock for 1 unit of P - Confirm the picking and set a quantity of 1 - Delete the quant that was created in inter-company transit with a reserved quantity of 1 (this can be done via a server action). - Inventory > Reporting > Locations > Invalid operation: inter-company transit belongs to company "False" and product "P" belongs to an other company. opw-4635684 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202924
### Issue: The community runs of the test: `test_portal_subcontractor_record_production_with_dropship` fail since the field `backorder_ids` of the mrp.production model is part of the `stock_barcode_mrp` module (part of the entreprise repo). runbot-build-error-159951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203654
Original PR description
### Issue: The community runs of the test: `test_portal_subcontractor_record_production_with_dropship` fail since the field `backorder_ids` of the mrp.production model is part of the `stock_barcode_mrp` module (part of the entreprise repo). runbot-build-error-159951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203654
**Problem**: Power buttons overlap long placeholders, causing UI issues. **Solution**: Adjust power button positioning based on the placeholder's width. **Steps to Reproduce**: 1. Change language to **Spanish**. 2. Open the **editor**. 3. Focus on an input field. - **Issue**: Power buttons overlap the placeholder. **opw-4584709** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203063
Original PR description
**Problem**: Power buttons overlap long placeholders, causing UI issues. **Solution**: Adjust power button positioning based on the placeholder's width. **Steps to Reproduce**: 1. Change language to **Spanish**. 2. Open the **editor**. 3. Focus on an input field. - **Issue**: Power buttons overlap the placeholder. **opw-4584709** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203063
**Problem**: Some email templates (e.g., "Mail: Install Request") contain self-closing `<span>` elements, which are not parsed correctly in the editor. This leads to broken styles upon saving changes. **Solution**: Convert self-closing `<span>` elements into properly opened and closed `<span>` tags. **Steps to reproduce**: 1. Open the email template **"Mail: Install Request"**. 2. Apply any change and save. - **Issue**: Styles are completely broken. **opw-4633229** --- I c
Original PR description
**Problem**: Some email templates (e.g., "Mail: Install Request") contain self-closing `<span>` elements, which are not parsed correctly in the editor. This leads to broken styles upon saving changes. **Solution**: Convert self-closing `<span>` elements into properly opened and closed `<span>` tags. **Steps to reproduce**: 1. Open the email template **"Mail: Install Request"**. 2. Apply any change and save. - **Issue**: Styles are completely broken. **opw-4633229** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203657
Have an action with multiple views (eg form,kanban,list) When the action spawns on its first view, the feature worked well: there were no breadcrumbs. Click on the view switcher to another view type. Before this commit, the breadcrumbs appeared for that step on. After this commit, the breadcrumbs do not appear for the whole action. task-4583126 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I
Original PR description
Have an action with multiple views (eg form,kanban,list) When the action spawns on its first view, the feature worked well: there were no breadcrumbs. Click on the view switcher to another view type. Before this commit, the breadcrumbs appeared for that step on. After this commit, the breadcrumbs do not appear for the whole action. task-4583126 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#203540 Forward-Port-Of: odoo/odoo#202712
In this commit, save the record when we install the payment terminal from the form widget. Steps: --- - Go to payment method config - Click on new - Journal = bank & Integration = terminal - Select a payment provider to download - the page refreshes and loses the data that is configured task - 4653445 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202108
Original PR description
In this commit, save the record when we install the payment terminal from the form widget. Steps: --- - Go to payment method config - Click on new - Journal = bank & Integration = terminal - Select a payment provider to download - the page refreshes and loses the data that is configured task - 4653445 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202108
The E-invoicing is mandatory in Jordan, and most of the users need it. So, it's simpler if they have it already installed when they install the base module. task-4669464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203266
Original PR description
The E-invoicing is mandatory in Jordan, and most of the users need it. So, it's simpler if they have it already installed when they install the base module. task-4669464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203266
Follow-up of b5cc3c15, forgotten change in saas-18.1 FW-port. Task-4678100 Forward-Port-Of: odoo/enterprise#82312
Original PR description
Follow-up of b5cc3c15, forgotten change in saas-18.1 FW-port. Task-4678100 Forward-Port-Of: odoo/enterprise#82312
This PR fixes non-deterministic issues with a unit test in the appointment module. The issue was coming from the gantt range being separately from the mounting of the view. This could sometimes be a problem, as the second "get_gantt_data" RPC could return *after* the helper responsible for selecting the range called a `runAllTimers` that would drastically increase the current time, and thus affect the RPC payload. The fix here is to include the desired range directly in the view arch,
Original PR description
This PR fixes non-deterministic issues with a unit test in the appointment module. The issue was coming from the gantt range being separately from the mounting of the view. This could sometimes be a…
This PR fixes non-deterministic issues with a unit test in the appointment module. The issue was coming from the gantt range being separately from the mounting of the view. This could sometimes be a problem, as the second "get_gantt_data" RPC could return *after* the helper responsible for selecting the range called a `runAllTimers` that would drastically increase the current time, and thus affect the RPC payload. The fix here is to include the desired range directly in the view arch, instead of selecting the range manually from the UI. Furthermore, when trying to reproduce the non-deterministic behavior of the test mentioned above by slowing down RPCs, other gantt tests showed constitently failing results due to a poor architecture relying on animation frames instead of waiting for network calls. These tests have been fixed preventively to avoid potential timing issues. Fixes runbot issues: - [159865](https://runbot.odoo.com/odoo/runbot.build.error/159865) - [161300](https://runbot.odoo.com/odoo/runbot.build.error/161300) - [161490](https://runbot.odoo.com/odoo/runbot.build.error/161490) Community: https://github.com/odoo/odoo/pull/203472 Forward-Port-Of: odoo/enterprise#82246 Forward-Port-Of: odoo/enterprise#82189
The list of approvers is computed based on the selected category for the approval request. Before the fix, the list would keep previous approvers when changing the category. This could lead to issues where users could add themselves as approvers on unauthorized categories. Steps to reproduce: - Create an approval request category (c1) with yourself as approver. - Create another approval request category (c2) with someone else as approver. - Create a request with category c1 and change to c
Original PR description
The list of approvers is computed based on the selected category for the approval request. Before the fix, the list would keep previous approvers when changing the category. This could lead to issues where users could add themselves as approvers on unauthorized categories. Steps to reproduce: - Create an approval request category (c1) with yourself as approver. - Create another approval request category (c2) with someone else as approver. - Create a request with category c1 and change to category c2. - You are now an approver of the approval request. This commit fixes the issue by reseting the list of approvers to only take the ones configured on the category. task-4637083 Forward-Port-Of: odoo/enterprise#82133 Forward-Port-Of: odoo/enterprise#81129
- Adjusting fetchmail_server behavior to read specific fuel taxes from vendor bills, which can be extended for other taxes. - Adding the functionality of manually uploading CL EDI documents to account_move. Unrecognized documents are parsed as vendor bills. - Adjusting fetchmail_server methods to work with manual upload process. - Adding relevant tests for specific fuel taxes. task-4359365 Forward-Port-Of: odoo/enterprise#82336 Forward-Port-Of: odoo/enterprise#76630
Original PR description
- Adjusting fetchmail_server behavior to read specific fuel taxes from vendor bills, which can be extended for other taxes. - Adding the functionality of manually uploading CL EDI documents to account_move. Unrecognized documents are parsed as vendor bills. - Adjusting fetchmail_server methods to work with manual upload process. - Adding relevant tests for specific fuel taxes. task-4359365 Forward-Port-Of: odoo/enterprise#82336 Forward-Port-Of: odoo/enterprise#76630
Version: 18.0 When the invoice is a refund, it should reduce the achievement's amount and not increase it. opw-4610960 Forward-Port-Of: odoo/enterprise#82111 Forward-Port-Of: odoo/enterprise#81671
Original PR description
Version: 18.0 When the invoice is a refund, it should reduce the achievement's amount and not increase it. opw-4610960 Forward-Port-Of: odoo/enterprise#82111 Forward-Port-Of: odoo/enterprise#81671
When drag-and-dropping a CSV in the bank journal, the statements lines don't get reconciled directly while they should (if a reco model allows it). Users have to wait for the auto-reconcile cron to run. After the statement and its lines have been created through import, we now trigger the cron computation. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4545446) opw-4545446 Forward-Port-Of: odoo/enterprise#82006 Forward-Port-Of: odoo/enterprise#81587
Original PR description
When drag-and-dropping a CSV in the bank journal, the statements lines don't get reconciled directly while they should (if a reco model allows it). Users have to wait for the auto-reconcile cron to run. After the statement and its lines have been created through import, we now trigger the cron computation. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4545446) opw-4545446 Forward-Port-Of: odoo/enterprise#82006 Forward-Port-Of: odoo/enterprise#81587
Forward-Port-Of: odoo/enterprise#82209
Original PR description
Forward-Port-Of: odoo/enterprise#82209
task-4577617 Forward-Port-Of: odoo/enterprise#80252
Original PR description
task-4577617 Forward-Port-Of: odoo/enterprise#80252
This commit ensures that sheet names in exported excel files are unique. The names may not be unique in case a composite report contains multiple section reports all having the same very long prefix. An example to that could be found in l10n_fr_reports: 1) IMB - Intermediate management balances 2) IMB - Intermediate management balances (2024) task-4678129 Forward-Port-Of: odoo/enterprise#82381 Forward-Port-Of: odoo/enterprise#82333
Original PR description
This commit ensures that sheet names in exported excel files are unique. The names may not be unique in case a composite report contains multiple section reports all having the same very long prefix. An example to that could be found in l10n_fr_reports: 1) IMB - Intermediate management balances 2) IMB - Intermediate management balances (2024) task-4678129 Forward-Port-Of: odoo/enterprise#82381 Forward-Port-Of: odoo/enterprise#82333
When we have a lot of data in the germany company we face a performance issue while exporting as zip file - modified the l10n_de_datev_export_to_zip function to search for the needed data rather that calling get lines again that improves the performance by 65%. - modified _format_column_values to add if options.get('export_mode') == 'file' not do formating to save time task-4502158 Forward-Port-Of: odoo/enterprise#81171
Original PR description
When we have a lot of data in the germany company we face a performance issue while exporting as zip file
- modified the l10n_de_datev_export_to_zip function to search for the needed data rather that calling get lines again that improves the performance by 65%.
- modified _format_column_values to add if options.get('export_mode') == 'file' not do formating to save time
task-4502158
Forward-Port-Of: odoo/enterprise#81171Purpose ======= Currently, we need a write access on a document to post message in it. We want the reader of the documents to be able to post. Task-4677687 Forward-Port-Of: odoo/enterprise#82302
Original PR description
Purpose ======= Currently, we need a write access on a document to post message in it. We want the reader of the documents to be able to post. Task-4677687 Forward-Port-Of: odoo/enterprise#82302
Issue: - Try to pay zero amount subscrption traceback. Cause: - From payment we send `None` amount when there is no amount and we try to compare the amount and because of that it gives traceback. Fix: - Set zero to amount if it is None. Forward-Port-Of: odoo/enterprise#82042
Original PR description
Issue: - Try to pay zero amount subscrption traceback. Cause: - From payment we send `None` amount when there is no amount and we try to compare the amount and because of that it gives traceback. Fix: - Set zero to amount if it is None. Forward-Port-Of: odoo/enterprise#82042
It is possible for a user to sync an existing whatsapp account and only after install some whatsapp bridge module. In that case the user will get an error as the template is created on the existing account with an existing name. We now prevent using the default value if a template with the same name already exists on it. task-4369979 Forward-Port-Of: odoo/enterprise#82260 Forward-Port-Of: odoo/enterprise#79786
Original PR description
It is possible for a user to sync an existing whatsapp account and only after install some whatsapp bridge module. In that case the user will get an error as the template is created on the existing account with an existing name. We now prevent using the default value if a template with the same name already exists on it. task-4369979 Forward-Port-Of: odoo/enterprise#82260 Forward-Port-Of: odoo/enterprise#79786
Versions -------- - 17.0+ Steps ----- 1. Have a salesman user without accounting rights; 2. assign user to a subscription; 3. create an invoice for the subscription; 4. assign a different salesman to the subscription; 5. as the initial salesman, try to close the subscription. Issue ----- Depending on the state of the cache, one of two things happen: 1. You get a validation error, saying the subscription has no invoices. 2. You get an access error if the invoice lines exist in t
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a salesman user without accounting rights; 2. assign user to a subscription; 3. create an invoice for the subscription; 4. assign a different salesman to the subscription; 5. as the initial salesman, try to close the subscription. Issue ----- Depending on the state of the cache, one of two things happen: 1. You get a validation error, saying the subscription has no invoices. 2. You get an access error if the invoice lines exist in the cache. Cause ----- The salesman only has read access to their own invoices. The first error happens because they cannot search for others' invoices. The second error happens because they cannot read the cached records. Solution -------- Use `sudo` to check for existing invoices. opw-4554639 Forward-Port-Of: odoo/enterprise#82243