Monday, August 12, 2024
30 changes · saas-17.4
Resolved issues and error corrections
Invoices created from Sales or Purchase orders now keep the product name on each invoice line. This makes invoice line descriptions consistent with accounting invoices and prevents confusion from missing product names.
Original PR description
Description of the issue this commit addresses: When the new product/label widget was designed on the invoice form, a compatibility patch was applied to the sale and the purchase app to make sure the…
Description of the issue this commit addresses: When the new product/label widget was designed on the invoice form, a compatibility patch was applied to the sale and the purchase app to make sure the line name contained what was needed. Since then a redesign of the feature was made and the line name contains the product name again. It's only in the Invoice Lines tab that the name is removed from the name attribute so it isn't displayed twice. The regexes that removed the product name from the label for invoices coming from the Sales and the Purchase apps are therefore causing a discordance in the behaviors from the accounting app and from those two. --- Desired behavior after this commit is merged: After this commit, creating an invoice from a Sale or a Purchase creates invoices lines with the product name inside the name attribute to keep the same behavior everywhere. --- sale PR commit: https://github.com/odoo/odoo/pull/152869/commits/dc33e2f10b44dd957836650c775840dd79f5b8bd purchase PR commit: https://github.com/odoo/odoo/pull/152869/commits/82064d84da04fca373637b37b710a6f6e02da81a no task-feedback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Production analysis now uses a safer fallback when looking up default values, so reports are less likely to show missing or duplicated information. This helps users get the expected data when creating or reviewing bills of materials.
Original PR description
This commit fixes a small bug in the SQL. It removes an unused join with company_id to avoid adding unnecessary lines. Additionally, it uses fields_id instead of ir_prop.name and adds fallback options for ir_prop. If the res_id is not found in the database, the ir_prop without a res_id or company_id will be used. To test it, simply open the production analysis, create a BOM, and verify that the expected fields are correctly populated.
Planning shift templates now handle invalid end-hour values more safely when users create or update them. Instead of causing an application error, the system applies the existing validation logic so users can correct the input normally.
Original PR description
This traceback arises when the user gives an invalid hour value to the end date, while creating or updating a planning template. To reproduce this issue: 1) Install `Planning` 2) Create a new `shift template` from planning configuration 3) Give an invalid hour value to the end date (greater than 24) 4) Try to save the record. Error:- ``` ValueError: hour must be in 0..23 ``` When the user gives an invalid hour value to the end date and tries to save it, a compute method triggers in which hour is used to calculate the end time. https://github.com/odoo/enterprise/blob/14b37f4141f1c73712d2c5ce16e5fc815e2a6a9b/planning/models/planning_template.py#L37-L38 Which leads to the traceback. Already a condition is there to check the invalid hours for start time. By just modifying the existing condition we can resolve this issue. sentry-5655372261
Purchase order lines now show the correct budget warning color when quantities are greater than one. This prevents budgets from appearing exceeded too early, helping buyers make decisions based on accurate budget status.
Original PR description
### Steps to reproduce: - Create a new Budget with type Expense - Add budget line (ex: Administration) and a period - Open the budget - Create a new RFQ that uses the analytic distribution set on the budget - With a quantity greater than 1, the line should appear red before the budget is reached - For example with a budget of 10000 and a quantity of 2 then the line is red if the price is greater than 2500 ### Cause: Line in question : `(budget.committed_amount + line.price_subtotal * (line.product_qty - line.qty_invoiced)) > budget.budget_amount` The calculation uses `price_subtotal` which is the total amount without taxes, so it already includes the quantity. ### Solution: Use `price_unit` instead of `price_subtotal`. opw-4002330
Fixed an issue that could cause accounting reports to fail when users selected a comparison filter. This improves reliability when viewing comparative financial reports by ensuring dates are handled consistently.
Original PR description
We get an error when selecting a comparison filter in accounting reports, because we try to compare a `datetime.dateime` with a `datetime.date` object. opw-4066879
Miscellaneous changes
If you were to refresh on a skipped question, the next_page_or_question would not be populated therefore causing any reference to this fail. There should not be a case where there is no next_page_or_question in _prepare_survey_data as the _get_next_page_or_question is only expecting an empty question in survey_submit. Adding a fallback to look for the next skipped question or page for when the next_skipped_page in the post parameter is lost in the http request through refreshing will allow th
Original PR description
If you were to refresh on a skipped question, the next_page_or_question would not be populated therefore causing any reference to this fail. There should not be a case where there is no next_page_or_question in _prepare_survey_data as the _get_next_page_or_question is only expecting an empty question in survey_submit. Adding a fallback to look for the next skipped question or page for when the next_skipped_page in the post parameter is lost in the http request through refreshing will allow this to work as expected. opw-4088129 Forward-Port-Of: odoo/odoo#175933
Before this commit, replying to a message from email author lead to a crash. Steps to reproduce: - Set notification preferences to "Handle in Odoo", in user preferences - Follow a record with chatter - Send a message on the followed record so that it's received by another follower by email - Follower replies to message from email client - Open Inbox in Discuss app and click on "Reply" action on that message => Crash `Cannot read property of undefined (reading 'name')` This happens bec
Original PR description
Before this commit, replying to a message from email author lead to a crash. Steps to reproduce: - Set notification preferences to "Handle in Odoo", in user preferences - Follow a record with chatter - Send a message on the followed record so that it's received by another follower by email - Follower replies to message from email client - Open Inbox in Discuss app and click on "Reply" action on that message => Crash `Cannot read property of undefined (reading 'name')` This happens because the reply-to text above composer when using the message reply feature assumed that the author is necessarily a partner. This is not necessarily the case: some message just have an email address as author. This commit fixes the issue by correctly showing the address email when replying to such a message. opw-4092015 Forward-Port-Of: odoo/odoo#176312 Forward-Port-Of: odoo/odoo#176139
Set Company country to India Create a TAX as follows - Amount: 15% - Included in price: False - Tax repartition line: - 100.00% of tax to 100560 Tax Receivable - -100.00% of tax to 999999 Undistributed Profits/Losses Open Bank Reconciliation Widget Create a statement Match with Manual operation Select created tax Issue: created tax lines have no amount This occurs because when computing the tax amounts with compute_all if the configuration of tax is price included (enforced
Original PR description
Set Company country to India Create a TAX as follows - Amount: 15% - Included in price: False - Tax repartition line: - 100.00% of tax to 100560 Tax Receivable - -100.00% of tax to 999999 Undistributed Profits/Losses Open Bank Reconciliation Widget Create a statement Match with Manual operation Select created tax Issue: created tax lines have no amount This occurs because when computing the tax amounts with compute_all if the configuration of tax is price included (enforced from context) and the tax is in cache we use the computed amount. Unfortunately in this particular configuration the amount is 0 opw-3986439 Forward-Port-Of: odoo/odoo#176200 Forward-Port-Of: odoo/odoo#173674
If the module l10n_be was installed and you tried to invoice a settled order, you got a traceback Steps to reproduce: ------------------- * Install l10n_be_pos_sale module * Open PoS in a non belgian company * Import an order from sales in PoS * Try to invoice it > Observation: You get a traceback Why the fix: ------------ Intracom taxes where not set and was causing a traceback. opw-4089625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-
Original PR description
If the module l10n_be was installed and you tried to invoice a settled order, you got a traceback Steps to reproduce: ------------------- * Install l10n_be_pos_sale module * Open PoS in a non belgian company * Import an order from sales in PoS * Try to invoice it > Observation: You get a traceback Why the fix: ------------ Intracom taxes where not set and was causing a traceback. opw-4089625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176226 Forward-Port-Of: odoo/odoo#175397
It was reported that on some locales (eg) Japan the snailmail styling was not properly applied. This was due to the selector in snailmail styling which was incorrect for a multi-company setup. Targeting `.o_company_1_layout` will break the selector for any company which is not the first one. task-4099258 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175821
Original PR description
It was reported that on some locales (eg) Japan the snailmail styling was not properly applied. This was due to the selector in snailmail styling which was incorrect for a multi-company setup. Targeting `.o_company_1_layout` will break the selector for any company which is not the first one. task-4099258 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175821
Current behaviour: --- When trying to make a xmlrpc call to search_read a crm lead that has a property, we get a traceback. Steps to reproduce: --- 1. Install CRM 2. Go to the Pipeline 3. Open any lead 4. Click on Actions > Add properties 5. Input anything as value, then save 6. Make a xmlrpc call to retrieve leads (see below) 7. Traceback `models.execute_kw(db, uid, password, 'crm.lead', 'search_read', [])` Cause of the issue: --- Feature introduction: https://github.com/od
Original PR description
Current behaviour: --- When trying to make a xmlrpc call to search_read a crm lead that has a property, we get a traceback. Steps to reproduce: --- 1. Install CRM 2. Go to the Pipeline 3. Open any…
Current behaviour: --- When trying to make a xmlrpc call to search_read a crm lead that has a property, we get a traceback. Steps to reproduce: --- 1. Install CRM 2. Go to the Pipeline 3. Open any lead 4. Click on Actions > Add properties 5. Input anything as value, then save 6. Make a xmlrpc call to retrieve leads (see below) 7. Traceback `models.execute_kw(db, uid, password, 'crm.lead', 'search_read', [])` Cause of the issue: --- Feature introduction: https://github.com/odoo/odoo/commit/87307a9010c6c872fe6c746d5ece378ad90d038f Change from `None` to `False`: https://github.com/odoo/odoo/commit/608bffff59c9444f59a282dbdc43c207704223cc Issue caused by: https://github.com/odoo/odoo/commit/da48700b59da49cdc810eac31a8617fcaa0dc2a8 (Due to the modification of `convert_to_read_multi`) When adding `PropertiesDefinition` to an existing record, it doesn't go through `_add_default_values` again, thus making `None` not being replaced by `False`. https://github.com/odoo/odoo/blob/cd9c69bd7d9b21e6220a49f88f22160de33c5e06/odoo/fields.py#L3616 opw-3940841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172689
Translated text that contains multiple interpolated values should always use named placeholders. Otherwise, sprintf will always insert the values in the same order, which may not match the order of the placeholders after translation in a language with a different syntax. Forward-Port-Of: odoo/odoo#175515 Forward-Port-Of: odoo/odoo#175332
Original PR description
Translated text that contains multiple interpolated values should always use named placeholders. Otherwise, sprintf will always insert the values in the same order, which may not match the order of the placeholders after translation in a language with a different syntax. Forward-Port-Of: odoo/odoo#175515 Forward-Port-Of: odoo/odoo#175332
A field from sale was used in point_of_sale. Introduced here https://github.com/odoo/odoo/pull/173389 opw-4005925-1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176265
Original PR description
A field from sale was used in point_of_sale. Introduced here https://github.com/odoo/odoo/pull/173389 opw-4005925-1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176265
### Steps to reproduce: - Install Sale and Project modules - Create a service product that creates project - Create a quotation with the created service product and confirm it - Click on the project smart button - Try sharing the project ### Current behavior before PR: An error gets triggered when trying to share a project from SO. This happens because the share link that is shown in the share project wizard is not the correct one /mail/view?model=sale.order&res_id=318&access_token
Original PR description
### Steps to reproduce: - Install Sale and Project modules - Create a service product that creates project - Create a quotation with the created service product and confirm it - Click on the project…
### Steps to reproduce: - Install Sale and Project modules - Create a service product that creates project - Create a quotation with the created service product and confirm it - Click on the project smart button - Try sharing the project ### Current behavior before PR: An error gets triggered when trying to share a project from SO. This happens because the share link that is shown in the share project wizard is not the correct one /mail/view?model=sale.order&res_id=318&access_token=" it will have the sale.order data because of the action_stack the context will have the active_model as sale.order and active_id as SO id which will lead to generation of the wrong link. ### Desired behavior after PR is merged: While opening the share project wizard we will add the project's data to the context to replace the sale.order data so we can have the link generated correctly /mail/view?model=project.project&res_id=178&access_token= opw-4087926 Forward-Port-Of: odoo/odoo#175903
Denmark government need a way to get ec sales. So now we have a report dedicated to denmark with an export to a CSV format This require us to add the triangular sales tax task-4080107 Backporting: https://github.com/odoo/odoo/pull/157211/commits/a6bd4048a20fada2822692107b57dbcd20d2baf9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174810
Original PR description
Denmark government need a way to get ec sales. So now we have a report dedicated to denmark with an export to a CSV format This require us to add the triangular sales tax task-4080107 Backporting: https://github.com/odoo/odoo/pull/157211/commits/a6bd4048a20fada2822692107b57dbcd20d2baf9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174810
In Luxembourg, the "Société national des chemins de Fer Luxembourgeois" expects the `PartyLegalEntity/CompanyID` to be filled with the "Registre de Commerce et des Sociétés" (RCS), which is normally filled on the `company_registry` of the supplier company. Before this commit, we filled this tag with the VAT (which is also filled in the `PartyTaxScheme/CompanyID`). The peppol official documentation states: 1. `PartyTaxScheme/CompanyID`: "The Seller's VAT identifier (also known as Seller
Original PR description
In Luxembourg, the "Société national des chemins de Fer Luxembourgeois" expects the `PartyLegalEntity/CompanyID` to be filled with the "Registre de Commerce et des Sociétés" (RCS), which is normally…
In Luxembourg, the "Société national des chemins de Fer Luxembourgeois" expects the `PartyLegalEntity/CompanyID` to be filled with the "Registre de Commerce et des Sociétés" (RCS), which is normally filled on the `company_registry` of the supplier company. Before this commit, we filled this tag with the VAT (which is also filled in the `PartyTaxScheme/CompanyID`). The peppol official documentation states: 1. `PartyTaxScheme/CompanyID`: "The Seller's VAT identifier (also known as Seller VAT identification number) or the local identification (defined by the Seller’s address) of the Seller for tax purposes or a reference that enables the Seller to state his registered tax status." [1] 2. `PartyLegalEntity/CompanyID`: "An identifier issued by an official registrar that identifies the Seller as a legal entity or person." [2] Consequently, it is not certain whether the company_registry should always be used to fill the element `PartyLegalEntity/CompanyID` or not, hence we only use it in Luxembourg for now. [1] https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-AccountingSupplierParty/cac-Party/cac-PartyTaxScheme/cbc-CompanyID/ [2] https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-AccountingSupplierParty/cac-Party/cac-PartyLegalEntity/cbc-CompanyID/ opw-4075457 Forward-Port-Of: odoo/odoo#175379
**Steps to reproduce the bug:** - Create two storable products: “P1” and “P2.” - Create a picking: - Product: “P1” - Quantity: 10 - Create a second picking: - Product: “P2” - Quantity: 10 - Confirm both pickings. - Set both moves to picked. - Add them to a wave. - Go to the wave and set the quantity of P1 to 0 while keeping `picked=True`. - Validate the wave. **Problem:** The picking of P1 is detached from the wave, but the move remains picked. As a result, `_compute_show_check_avail
Original PR description
**Steps to reproduce the bug:** - Create two storable products: “P1” and “P2.” - Create a picking: - Product: “P1” - Quantity: 10 - Create a second picking: - Product: “P2” - Quantity: 10 - Confirm both pickings. - Set both moves to picked. - Add them to a wave. - Go to the wave and set the quantity of P1 to 0 while keeping `picked=True`. - Validate the wave. **Problem:** The picking of P1 is detached from the wave, but the move remains picked. As a result, `_compute_show_check_availability` returns `False`, causing the check availability button to stay invisible. opw-4016209 Forward-Port-Of: odoo/odoo#176375
### Steps to reproduce: - Create 2 storable product - Update the on hand quantity to 100 only for the first one - Create an confirm an SO 75 units of each - Set the done qty to 50 on both moves and create a backorder - Print delivery slip for the original picking #### > The Ordered quantity is wrong on the product with no stock on hand (50 instead of 75). ### Cause of the issue: If there's no on hand qty the backorder move will not be associated to any `move_line` so that the `qty_
Original PR description
### Steps to reproduce: - Create 2 storable product - Update the on hand quantity to 100 only for the first one - Create an confirm an SO 75 units of each - Set the done qty to 50 on both moves and…
### Steps to reproduce: - Create 2 storable product - Update the on hand quantity to 100 only for the first one - Create an confirm an SO 75 units of each - Set the done qty to 50 on both moves and create a backorder - Print delivery slip for the original picking #### > The Ordered quantity is wrong on the product with no stock on hand (50 instead of 75). ### Cause of the issue: If there's no on hand qty the backorder move will not be associated to any `move_line` so that the `qty_ordered` will not be updated by these lines: https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L785-L791 Furthermore, since they are not cancelled, they are filtered out here and hence do not update the `qty_ordered` by these lines either: https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L813-L816 https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L831 ### Fix: We modify the filter meant for empty move lines so that moves that are not confirmed and are not associated to any `move_line` contribute to the `qty_ordered` via these: https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L831 However, since we do not want a move that is fully backordered to appear on the delivery slip we need to filter out all the line keys that will be created, because they pass our new filtering condition (but didn't pass the old one), here: https://github.com/odoo/odoo/blob/41a8acd89f90215dc48caf2822507c14fc78feca/addons/stock/models/stock_move_line.py#L819-L821 opw-3957193 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176196 Forward-Port-Of: odoo/odoo#175113
Steps to reproduce in 17.0: There's no way to reproduce the issue in 17.0 because the faulty getter in only called on positions in the active sheet (pivot autofill, global filter auto-matching) Steps to reproduce in saas-17.1: - insert a pivot in a blank spreadsheet - delete all pivot formulas - insert a new sheet - in the new sheet: - in A1: type "1" - in A2: =ODOO.PIVOT(A1) - activate the first sheet again - Open the Data menu => the pivot 1 is marked as being unused, even th
Original PR description
Steps to reproduce in 17.0: There's no way to reproduce the issue in 17.0 because the faulty getter in only called on positions in the active sheet (pivot autofill, global filter auto-matching) Steps to reproduce in saas-17.1: - insert a pivot in a blank spreadsheet - delete all pivot formulas - insert a new sheet - in the new sheet: - in A1: type "1" - in A2: =ODOO.PIVOT(A1) - activate the first sheet again - Open the Data menu => the pivot 1 is marked as being unused, even though it's used in the second sheet Task: 3859472 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#169180 Forward-Port-Of: odoo/odoo#161108
It's really unintuitive and non-Odoo to have to close the filter box to be able to apply a filter on reports. Let's change that. We now delay let user click on filters while it's loading. We then delay filters that make a rpc call by 500 ms. The goal being that we don't do 5 calls if the user wants to select 5 journals. It implies several difficulties, including a reloading of the data or the options that were done when clicking. For that, we use loadingCallHash (to know if the options sent
Original PR description
It's really unintuitive and non-Odoo to have to close the filter box to be able to apply a filter on reports. Let's change that. We now delay let user click on filters while it's loading. We then delay filters that make a rpc call by 500 ms. The goal being that we don't do 5 calls if the user wants to select 5 journals. It implies several difficulties, including a reloading of the data or the options that were done when clicking. For that, we use loadingCallHash (to know if the options sent by the python are the ones needed to be reloaded). task-3912381 Forward-Port-Of: odoo/enterprise#67192
Before this commit: Steps 1) Install l10n_es_reports 2) Switch to ES company 3) Create a EU vendor (any except SPAIN) + add TIN 4) Create a bill with last month date 5) Reverse that bill with current month date 6) Go to Tax reports 7) Switch to Tax Report (Mod 349) (ES) 8) Choose date range: This Month 9) Generate BOE => It shows an error with a traceback `/l10n_es_reports/models/aeat_tax_reports.py", line 1257, in _write_type2_refund_records previous_report_amoun
Original PR description
Before this commit:
Steps
1) Install l10n_es_reports
2) Switch to ES company
3) Create a EU vendor (any except SPAIN) + add TIN
4) Create a bill with last month date
5) Reverse that bill with current month date
6) Go to Tax reports
7) Switch to Tax Report (Mod 349) (ES)
8) Choose date range: This Month
9) Generate BOE
=> It shows an error with a traceback `/l10n_es_reports/models/aeat_tax_reports.py", line 1257, in _write_type2_refund_records
previous_report_amount = invoice_line_data['columns'][0]['no_format']
TypeError: 'NoneType' object is not subscriptable`
After this commit:
BOE in mod349 is generated properly without errors
opw-4055702
Forward-Port-Of: odoo/enterprise#68096As negative invoice lines, aka global discounts, are not accepted by the Ecuador government, we transform them into discounts of the positives lines for the e-invoice. task-3752009 Forward-Port-Of: odoo/enterprise#63822
Original PR description
As negative invoice lines, aka global discounts, are not accepted by the Ecuador government, we transform them into discounts of the positives lines for the e-invoice. task-3752009 Forward-Port-Of: odoo/enterprise#63822
The BelastingDienst returns an error if the format for the 'ProfessionalAssociationForTaxServiceProvidersName' tag is not respected. The string value in that tag should not exceed 20 characters.µ opw-4075462 Forward-Port-Of: odoo/enterprise#67813 Forward-Port-Of: odoo/enterprise#67635
Original PR description
The BelastingDienst returns an error if the format for the 'ProfessionalAssociationForTaxServiceProvidersName' tag is not respected. The string value in that tag should not exceed 20 characters.µ opw-4075462 Forward-Port-Of: odoo/enterprise#67813 Forward-Port-Of: odoo/enterprise#67635
Denmark government need a way to get ec sales. So now we have a report dedicated to denmark with an export to a CSV format task: 4080107 Backporting: https://github.com/odoo/enterprise/pull/58413/commits/d9f7ccdfd062fdc4e372951ff65a5f09046ad7b7 Forward-Port-Of: odoo/enterprise#67517
Original PR description
Denmark government need a way to get ec sales. So now we have a report dedicated to denmark with an export to a CSV format task: 4080107 Backporting: https://github.com/odoo/enterprise/pull/58413/commits/d9f7ccdfd062fdc4e372951ff65a5f09046ad7b7 Forward-Port-Of: odoo/enterprise#67517
Problem: The quality_score field is not received in the response while syncing all the templates. As a result, the default 'none' quality will be applied to all the templates. And the same goes while syncing a single template. It will only be updated when Meta posts a request on the webhook to update the template quality. Solution: The quality_score field can only be received if we explicitly ask for the quality_score field in an API request, But the problem is that only the quality_sco
Original PR description
Problem: The quality_score field is not received in the response while syncing all the templates. As a result, the default 'none' quality will be applied to all the templates. And the same goes while syncing a single template. It will only be updated when Meta posts a request on the webhook to update the template quality. Solution: The quality_score field can only be received if we explicitly ask for the quality_score field in an API request, But the problem is that only the quality_score field will be received here. Due to this, the API request to sync a single template and multiple templates are modified, and all the basic fields like name, components, language, status, category, and ID are included along with the quality_score field so we receive all basic fields and quality_score field. Task-3908894 Forward-Port-Of: odoo/enterprise#61150
Issue ----- When adding formating to an appointment button linked to a specific type of appointment, the button will lead to all appointments instead of just the specific type. Change ----- Since buttons can have custom formatting, this will add HTML elements inside the button element. Therefore, we need to take into account that the target of the event may not be the button itself. opw-4080512 Forward-Port-Of: odoo/enterprise#68037
Original PR description
Issue ----- When adding formating to an appointment button linked to a specific type of appointment, the button will lead to all appointments instead of just the specific type. Change ----- Since buttons can have custom formatting, this will add HTML elements inside the button element. Therefore, we need to take into account that the target of the event may not be the button itself. opw-4080512 Forward-Port-Of: odoo/enterprise#68037
Before this commit: Sendcloud request adds a phone number instead of a mobile number first during the check. For many carriers, Sendcloud requires real mobile numbers instead of (landline) phone number. After this commit: Mobile number is checked before the phone number and added to the request if available. opw-4005520 Forward-Port-Of: odoo/enterprise#66480
Original PR description
Before this commit: Sendcloud request adds a phone number instead of a mobile number first during the check. For many carriers, Sendcloud requires real mobile numbers instead of (landline) phone number. After this commit: Mobile number is checked before the phone number and added to the request if available. opw-4005520 Forward-Port-Of: odoo/enterprise#66480
Some reports display some informational columns (like the VAT for a partner, or the country of origin). These columns sometimes prevent the `Hide Lines at 0` option to correctly do its work: the desired behavior of this option is to hide the lines where the amounts are null. It shouldn't care about the "informational" columns, that are usually always present This commit force the `Hide Lines at 0` feature to ignore columns displaying information other than float, integer of monetary ones.
Original PR description
Some reports display some informational columns (like the VAT for a partner, or the country of origin). These columns sometimes prevent the `Hide Lines at 0` option to correctly do its work: the desired behavior of this option is to hide the lines where the amounts are null. It shouldn't care about the "informational" columns, that are usually always present This commit force the `Hide Lines at 0` feature to ignore columns displaying information other than float, integer of monetary ones. task-4006235 Forward-Port-Of: odoo/enterprise#67638 Forward-Port-Of: odoo/enterprise#65622
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive the MTO Route - With CO1 create a route with a buy action and destination CO1/stock - With CO2 create a route with a manufacture action - Go to Inventory > Configuration > Products > Attributes - Create a product att
Original PR description
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to…
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive the MTO Route - With CO1 create a route with a buy action and destination CO1/stock - With CO2 create a route with a manufacture action - Go to Inventory > Configuration > Products > Attributes - Create a product attribute with a value that "is_custom" - Create a storable product P with using MTO and tour CO1 and CO2 routes - Set CO2 as a vendor for the product - With CO1, create a SO for 1 unit of your product P - a popup asks you for a custom product attribute value, write "test" - Confirm the SO > Automatically creates a PO (w/ description) - Confirm the PO > Automatically create an SO in CO2 (w/ description) - Confirm the SO in CO2 > Automatically create an MO #### Issue: #### The custom description is missing on the final MO. #### Note: If you were to create an SO directly in CO2 for 1 unit of P, the custom description associated with the custom attribute value would be present on the associated MO. ### Cause of the issue: The MO is created by a procurement generated from the SOL during the call of the `_action_launch_stock_rule` method: https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale_stock/models/sale_order_line.py#L345 The custom description that will appear on the MO and containing the informations related to the custom attribute values is generated here: https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale_stock/models/sale_order_line.py#L267 However, this method will return an empty string because the `product_custom_attribute_value_ids` is absent from our SOL https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale/models/sale_order_line.py#L338-L347 On the other hand, this `product_custom_attribute_value_ids` was set and is still existing on the original SO that started the flow in CO1. The reason that it is not present anymore on the last SO is because this SOL field has no equivalent on the `purchase.order.line` model and the information was therefore forgotten on the MO and has not been transferred directly from the PO of CO1 to the SO of CO2. ### Fix: We rely on the `sale_line_id` field of the `purchase.order.line` model in order to determine the original SOL of the final SOL and update the `product_custom_attribute_value_ids` accordingly. ### Note: As a side effect of our change in `sale_purchase_stock` linking our sol to the pol via the procurement commit 63ef74b can be reverted since the message is already automatically posted (the message is now written by the user who cancelled the SO rather than Odoobot). opw-3998861 --- Forward-Port-Of: odoo/enterprise#67650 Forward-Port-Of: odoo/enterprise#67172
Enterprise adaptations of the community branch. Steps to reproduce in 17.0: There's no way to reproduce the issue in 17.0 because the faulty getter in only called on positions in the active sheet (pivot autofill, global filter auto-matching) Steps to reproduce in saas-17.1: - insert a pivot in a blank spreadsheet - delete all pivot formulas - insert a new sheet - in the new sheet: - in A1: type "1" - in A2: =ODOO.PIVOT(A1) - activate the first sheet again - Open the Data menu =>
Original PR description
Enterprise adaptations of the community branch. Steps to reproduce in 17.0: There's no way to reproduce the issue in 17.0 because the faulty getter in only called on positions in the active sheet (pivot autofill, global filter auto-matching) Steps to reproduce in saas-17.1: - insert a pivot in a blank spreadsheet - delete all pivot formulas - insert a new sheet - in the new sheet: - in A1: type "1" - in A2: =ODOO.PIVOT(A1) - activate the first sheet again - Open the Data menu => the pivot 1 is marked as being unused, even though it's used in the second sheet Task: 3859472 Forward-Port-Of: odoo/enterprise#64540 Forward-Port-Of: odoo/enterprise#60329