Wednesday, September 4, 2024
67 changes · saas-17.2
Resolved issues and error corrections
This fix prevents very small delivery quantities from being shown with long, confusing decimal values in the Barcode app. Users now see quantities rounded and formatted consistently with their unit-of-measure settings, improving clarity during warehouse operations.
Original PR description
### Steps to reproduce: - Enable "Units of Measure" in the settings - Inventory > Configuration > Units of Measures > UomCategories - Click on Unit and change the rounding precision from 0.01 to…
### Steps to reproduce: - Enable "Units of Measure" in the settings - Inventory > Configuration > Units of Measures > UomCategories - Click on Unit and change the rounding precision from 0.01 to 0.0001 - In debug: Settings > Technical > Database Structure > Decimal Accuracy - Change the Decimal Accuracy to 4 Digits - Create and mark as to do a delivery order for 1 unit of a product 1 that you have in stock - Barcode > Operations > Delivery Orders > "your delivery" - Click on the pencil to change the quantity of the move line to 0.0153 > You are redirected to the view of the picking and the line is displayed as: **0.015300000000000001/1.0** Cause of the issue: The float system of Odoo introduce inaccuracies at high rounding precision. When you set the qty_done of the `stock.move.line` to 0.0153 the framework is going to format this float value to be written as 0.015300000000000001. Fix: To not alter comparison using backend values we format the float in the view. opw-4110401
Planning users who choose Add to Calendar now receive the expected calendar file instead of being taken to an internal planning screen. This restores the intended flow and helps users add shifts or planning events to their calendar without confusion.
Original PR description
When an internal user with planning access performs the Add to Calendar action, the planning backend view opens instead of downloading the ICS file.This commit fixed this behavior. task-3978534
This update makes an automated website editor test more stable by adding checks that wait for the page content to be ready before continuing. This reduces random test failures and helps keep website changes safer to release.
Original PR description
In this commit, we fix undeterministic test_html_editor_scss tour. To fix this behavior, we add few additionnal steps to check the state of DOM before continuing the tour.
This fix improves Odoo's internal web test environment so tests can identify the correct page element instead of accidentally selecting test framework overlays. It helps make automated test results more reliable and reduces false failures during development.
Original PR description
This commit introduces a global mock for the document `elementFromPoint` and `elementsFromPoint` methods, so that it ignores both Hoot's fixture and UI container. This has been done since when not debugging a test, the fixture is z-indexed behind the body and both of these methods would consider them accordingly, meaning that production code relying on these methods would consistently get the Hoot UI or the body instead of the desired element. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Before this commit, Using the "request signature" option allowed users to create templates on the fly, which could lead to errors. In this commit, the Creation of templates on the fly from the wizard is no longer allowed. task-4069128 Forward-Port-Of: odoo/enterprise#67232
Original PR description
Before this commit, Using the "request signature" option allowed users to create templates on the fly, which could lead to errors. In this commit, the Creation of templates on the fly from the wizard is no longer allowed. task-4069128 Forward-Port-Of: odoo/enterprise#67232
Current behaviour: --- When you create a campaign, if you add more activity (56) than the default pager limit (40) The next pager page will be empty (instead of showing the remaining 16 activities) Steps to reproduce: --- 1. Go to Marketing Automation 2. Create a campaign 3. Create more than 40 activities 4. Alternate parents/child when creating 5. The pager will appear, with at least 2 pages 6. Go to the second page 7. Nothing displayed NB: When inputting the number of activitie
Original PR description
Current behaviour: --- When you create a campaign, if you add more activity (56) than the default pager limit (40) The next pager page will be empty (instead of showing the remaining 16 activities)…
Current behaviour: --- When you create a campaign, if you add more activity (56) than the default pager limit (40) The next pager page will be empty (instead of showing the remaining 16 activities) Steps to reproduce: --- 1. Go to Marketing Automation 2. Create a campaign 3. Create more than 40 activities 4. Alternate parents/child when creating 5. The pager will appear, with at least 2 pages 6. Go to the second page 7. Nothing displayed NB: When inputting the number of activities in the pager, everything is rendered fine. Cause of the issue: --- To be displayed, the activities are hierarchised, by finding child and parents (`_getSortedRecordsByHierarchy`) However this system works great when all the records are given. Using a pager, some records are not used in the hierarchy, causing the outputted list to be incomplete. (ie if an activity A is in the first 40 and the child in the last 16, it will not be rendered correctly) Fix: --- Disabling the pager by setting a higher limit opw-4006610 Forward-Port-Of: odoo/enterprise#69154 Forward-Port-Of: odoo/enterprise#67979
Before this commit, some tests were failing because the time was not correctly frozen. The failing test could be seen when run like this: faketime '2024-08-31 02:01:00 UTC' ./odoo-bin -c ... runbot errors: 76518, 76519, 76520 Forward-Port-Of: odoo/enterprise#69267
Original PR description
Before this commit, some tests were failing because the time was not correctly frozen. The failing test could be seen when run like this: faketime '2024-08-31 02:01:00 UTC' ./odoo-bin -c ... runbot errors: 76518, 76519, 76520 Forward-Port-Of: odoo/enterprise#69267
We noticed that in production, eTIMS regularly fails to respond within the timeout of 30s when we send an invoice. Since this happens fairly often, this PR aims to improve the error message so that the user knows there is nothing they can do except wait for a bit and then retry. We also increase the timeout to 45s, on the off chance that this might improve things somewhat. taskid: none Forward-Port-Of: odoo/enterprise#69099 Forward-Port-Of: odoo/enterprise#69049
Original PR description
We noticed that in production, eTIMS regularly fails to respond within the timeout of 30s when we send an invoice. Since this happens fairly often, this PR aims to improve the error message so that the user knows there is nothing they can do except wait for a bit and then retry. We also increase the timeout to 45s, on the off chance that this might improve things somewhat. taskid: none Forward-Port-Of: odoo/enterprise#69099 Forward-Port-Of: odoo/enterprise#69049
**Steps to reproduce:** - Install Accounting, Sales and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Create a SO for a Peruvian customer (e.g. Comercial Constructora) - Confirm the SO - Create a down payment - Confirm the down payment - Send it to Peru UBL 2.1 **Issue:** The Electronic Service Operator (OSE) responds with an error because an item is declared without unit of measure. **Cause:** From saas-17.1, there is no product associated to a down payment line
Original PR description
**Steps to reproduce:** - Install Accounting, Sales and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Create a SO for a Peruvian customer (e.g. Comercial Constructora) - Confirm the SO - Create a down payment - Confirm the down payment - Send it to Peru UBL 2.1 **Issue:** The Electronic Service Operator (OSE) responds with an error because an item is declared without unit of measure. **Cause:** From saas-17.1, there is no product associated to a down payment line anymore. **Solution:** For down payment line, use the code (i.e. NIU) of the default unit of measure (i.e. Units), which was the default UoM of the down payment product before saas-17.1. opw-4057252 Forward-Port-Of: odoo/enterprise#69124
…ew ro Version: 17.0 Steps: Click on the schedule feature in the rental module. Click on the 'New' to create the rental order. Issue : When a user clicks on the "Schedule" feature in the rental module and then clicks on "New" to create a rental order, the rental period feature is disabled, and the payment period appears instead. Cause : The issue is caused by the condition invisible="not is_rental_order" on the rental_start_date field. fix: To fix this issue, we remove the invis
Original PR description
…ew ro Version: 17.0 Steps: Click on the schedule feature in the rental module. Click on the 'New' to create the rental order. Issue : When a user clicks on the "Schedule" feature in the rental module and then clicks on "New" to create a rental order, the rental period feature is disabled, and the payment period appears instead. Cause : The issue is caused by the condition invisible="not is_rental_order" on the rental_start_date field. fix: To fix this issue, we remove the invisible="not is_rental_order" condition from the rental_start_date field definition. This ensures that the rental period feature is always visible when creating a new rental order. opw-4016866 Forward-Port-Of: odoo/enterprise#69163 Forward-Port-Of: odoo/enterprise#66904
### Steps to reproduce: - Install the module "l10n_ec" and switch to Ecuadorian company - Go to Accounting > Configuration > Ecuadorian SRI > Digital Certificates SRI - When uploading a p12 file with the country name "Ecuador" and not "EC" - An error pops up but does not tell the right reason ### Cause: The cryptography library only accepts country names in the form of 2 character country code, so it raises an error. If an error occurs during the loading of the file, the error message w
Original PR description
### Steps to reproduce: - Install the module "l10n_ec" and switch to Ecuadorian company - Go to Accounting > Configuration > Ecuadorian SRI > Digital Certificates SRI - When uploading a p12 file with the country name "Ecuador" and not "EC" - An error pops up but does not tell the right reason ### Cause: The cryptography library only accepts country names in the form of 2 character country code, so it raises an error. If an error occurs during the loading of the file, the error message will always be "Error loading certificate %s, check that password is correct and file type is p12". ### Solution: As we cannot display the error messages of external libraries (here the cryptography library), this commit adds the reason "The country name is not a 2 character country code." in the error message. opw-4116914 Forward-Port-Of: odoo/enterprise#69194 Forward-Port-Of: odoo/enterprise#68633
Steps to reproduce (in odoo) - Open a spreadsheet - do something such that there's a least one revisions - leave the spreadsheet => non-deterministic concurrent update because we save the thumbnail and we snapshot at the same time. I'm able to reproduce more when my laptop power setting is on "performance" compared to "balanced" Task: 4080148 Forward-Port-Of: odoo/enterprise#68918
Original PR description
Steps to reproduce (in odoo) - Open a spreadsheet - do something such that there's a least one revisions - leave the spreadsheet => non-deterministic concurrent update because we save the thumbnail and we snapshot at the same time. I'm able to reproduce more when my laptop power setting is on "performance" compared to "balanced" Task: 4080148 Forward-Port-Of: odoo/enterprise#68918
The case: - I want to organise all my shop in order to be able to serve all the rental orders I planed for a week. And resupply the shop with different interwarehouse transfers The issue, rental orders create a retun picking directly and their forecast could easily reach zero. (even more on small renting period) An existing solution: Correctly set a small lead time on reordering rule in order to have a fix day in order to have the forecast. However it only works if people check the reple
Original PR description
The case: - I want to organise all my shop in order to be able to serve all the rental orders I planed for a week. And resupply the shop with different interwarehouse transfers The issue, rental…
The case: - I want to organise all my shop in order to be able to serve all the rental orders I planed for a week. And resupply the shop with different interwarehouse transfers The issue, rental orders create a retun picking directly and their forecast could easily reach zero. (even more on small renting period) An existing solution: Correctly set a small lead time on reordering rule in order to have a fix day in order to have the forecast. However it only works if people check the replenishment report everyday and don't have weekend. And if they use automatic RR they lose the control over the warehouse that should resupply the product. Also they can't use the visibility days feature and plan for a week. In order to allow a better planning and flexibility we add a small parameter to ignore the returns of rental order. That way the forecast ignore returns and allow visibilty. BUT it's DANGEROUS. Because it means that outgoing after return won't be correctly forecasted. So the user have to use a small lead time. E.g. Global lead days = 70 days, do a rental order in 10 days (for a day) and another in 20 days. With the parameter enable, it will suggest 2 units. However it should be one since one is returned. Forward-Port-Of: odoo/enterprise#69015
This commit adds the field `l10n_mx_edi_payment_method_id` to the website checkout, so that the customer can choose the correct option to be saved into the sale order and to fill the attribute in the XML. Purpose: In Mexican electronic invoicing, some fields are mandatory for signing an invoice. Now, on e-commerce, one field is missing to avoid requests to cancel invoices due to lack of information. This missing field is "Payment way" (l10n_mx_edi_payment_method_id). This commit also rest
Original PR description
This commit adds the field `l10n_mx_edi_payment_method_id` to the website checkout, so that the customer can choose the correct option to be saved into the sale order and to fill the attribute in the XML. Purpose: In Mexican electronic invoicing, some fields are mandatory for signing an invoice. Now, on e-commerce, one field is missing to avoid requests to cancel invoices due to lack of information. This missing field is "Payment way" (l10n_mx_edi_payment_method_id). This commit also restructures the placement of `t-if`/`div`s so that they appear in the right places and not generate empty divs. task-id: 4064069 Forward-Port-Of: odoo/enterprise#68902
Before this commit, the section transaction without statement didn't count the reconciled entries, and so the balance of the account was wrong. To fix that we putted a new custom engine function that will trigger the _bank_reconciliation_report_custom_engine_common with False for the "from_statement" and False for the "unreconciled" variables. With that the query will get all the transaction reconciled or not that are not from a statement. There was also a problem if the reconcile rate was
Original PR description
Before this commit, the section transaction without statement didn't count the reconciled entries, and so the balance of the account was wrong. To fix that we putted a new custom engine function that will trigger the _bank_reconciliation_report_custom_engine_common with False for the "from_statement" and False for the "unreconciled" variables. With that the query will get all the transaction reconciled or not that are not from a statement. There was also a problem if the reconcile rate was 0, which didn't when having only unreconciled entries but now that we can have that, it needed to be modified. task: 4110491 Forward-Port-Of: odoo/enterprise#68594
In the payment report, a space was missing between the VAT label and the span "Emitter Acc. Ben.". In order to don't rely on spaces, a ps-1 class was added in both "Emitter Acc. Ben." and "Emitter Acc. Ord.". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#68954 Forward-Port-Of: odoo/enterprise#53722
Original PR description
In the payment report, a space was missing between the VAT label and the span "Emitter Acc. Ben.". In order to don't rely on spaces, a ps-1 class was added in both "Emitter Acc. Ben." and "Emitter Acc. Ord.". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#68954 Forward-Port-Of: odoo/enterprise#53722
Performs test of a related commit in communiy: [FIX] mail: include whatsapp in webpush notifications There are couple of components in the notification architecture. For the sake of illustration let's simplify it with the following: Sender -> Queuer -> Receiver Queuer is an FMC backend, so we should only be concerned about the other two. Receiver which is just a frontend service worker that will generate notifications as soon as he receives an event. The issue (before this commit) was in the
Original PR description
Performs test of a related commit in communiy: [FIX] mail: include whatsapp in webpush notifications There are couple of components in the notification architecture. For the sake of illustration let's simplify it with the following: Sender -> Queuer -> Receiver Queuer is an FMC backend, so we should only be concerned about the other two. Receiver which is just a frontend service worker that will generate notifications as soon as he receives an event. The issue (before this commit) was in the Sender part, which was skipping whatsapp type message generation. [Reproduce] - Configure Whatsapp account, include user A in "Notify users" - Allow notifications in your browser (chat icon/ OdooBot suggestion) - Send a whatsapp message to the configured whatsapp number - BUG: Push notification not showing up opw-3720699 Forward-Port-Of: odoo/enterprise#68807 Forward-Port-Of: odoo/enterprise#68453
With this commit, some rules category are fixed : deduction, allowance are set only on employee rule. One file's name changed to be coherent with others payrolls. task-4069829 Forward-Port-Of: odoo/enterprise#68889
Original PR description
With this commit, some rules category are fixed : deduction, allowance are set only on employee rule. One file's name changed to be coherent with others payrolls. task-4069829 Forward-Port-Of: odoo/enterprise#68889
Forward-Port-Of: odoo/enterprise#68981 Forward-Port-Of: odoo/enterprise#67980
Original PR description
Forward-Port-Of: odoo/enterprise#68981 Forward-Port-Of: odoo/enterprise#67980
From the IoT Box form view, we display the connected devices: they were readonly. Now, they are editable, avoiding us from going to the "Device" page, then look for the device in the list. Forward-Port-Of: odoo/enterprise#68966
Original PR description
From the IoT Box form view, we display the connected devices: they were readonly. Now, they are editable, avoiding us from going to the "Device" page, then look for the device in the list. Forward-Port-Of: odoo/enterprise#68966
Once we clicked the "Pair" button, a notification showing "No new IoT Box found." was displayed. We want to avoid that. Forward-Port-Of: odoo/enterprise#69002
Original PR description
Once we clicked the "Pair" button, a notification showing "No new IoT Box found." was displayed. We want to avoid that. Forward-Port-Of: odoo/enterprise#69002
Add the Colombian E-Commerce localization module that includes: * Add fields to the checkout form: City, Identification Type, Fiscal Regimen, and Obligation Type. * Validate new fields. * Change the label name for 'Vat' to 'Identification Number' * Show obligation type and fiscal regimen blocks only when the identification type is 'NIT'. * Take into account the identification type when validating the VAT in the checkout form. related: https://github.com/odoo/odoo/pull/169205 task-28
Original PR description
Add the Colombian E-Commerce localization module that includes: * Add fields to the checkout form: City, Identification Type, Fiscal Regimen, and Obligation Type. * Validate new fields. * Change the label name for 'Vat' to 'Identification Number' * Show obligation type and fiscal regimen blocks only when the identification type is 'NIT'. * Take into account the identification type when validating the VAT in the checkout form. related: https://github.com/odoo/odoo/pull/169205 task-2856566 Forward-Port-Of: odoo/enterprise#68786 Forward-Port-Of: odoo/enterprise#64786
This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285 Forward-Port-Of: odoo/enterprise#68489 Forward-Port-Of: odoo/enterprise#63481
Original PR description
This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285 Forward-Port-Of: odoo/enterprise#68489 Forward-Port-Of: odoo/enterprise#63481
Current behaviour: --- Sometimes when clicking "Put in pack", the whole page freezes and gives a 503 error. Steps to reproduce: --- 1. Go to Settings, Inventory 2. Activate Packages 3. Go to Products 4. Create a new product 5. Set inventory > Tracking: By Lots 6. Go to Operations > Receipts 7. Create a new receipt for the product 8. Set the Demand quantity to 13.5 9. Click on Mark as Todo 10. Go to Barcode, operations, receipts 11. Select the last created receipt 12. Edit the l
Original PR description
Current behaviour: --- Sometimes when clicking "Put in pack", the whole page freezes and gives a 503 error. Steps to reproduce: --- 1. Go to Settings, Inventory 2. Activate Packages 3. Go to Products 4. Create a new product 5. Set inventory > Tracking: By Lots 6. Go to Operations > Receipts 7. Create a new receipt for the product 8. Set the Demand quantity to 13.5 9. Click on Mark as Todo 10. Go to Barcode, operations, receipts 11. Select the last created receipt 12. Edit the line, input 5.66, save 13. Click on Put in pack 14. The whole page freezes Cause of the issue: --- Caused by: https://github.com/odoo/enterprise/commit/42e9c378b0766e98a93605d0c2bc0797e3995734 The content of `pageLines` can be modified, thus the loop can never end. Fix: --- Shallow copy of `this.pageLines` (similar than in `get groupedLines()` in `BarcodeModel`) opw-4060843 Forward-Port-Of: odoo/enterprise#68448
Create a new payslip Select Employee and contract Compute Sheet Create Draft Entry > Post Draft Entry Cancel payslip Issue: The system will attempt to reset to draft and unlink the associated invoice In some cases this is not ideal: due to regulations, we might need to preserve an audit trail to have auditable journal entries After this commit the system would unlink only draft entries and reverse already posted move, similar to what we do for expenses opw-4075244 Forward-Port-Of:
Original PR description
Create a new payslip Select Employee and contract Compute Sheet Create Draft Entry > Post Draft Entry Cancel payslip Issue: The system will attempt to reset to draft and unlink the associated invoice In some cases this is not ideal: due to regulations, we might need to preserve an audit trail to have auditable journal entries After this commit the system would unlink only draft entries and reverse already posted move, similar to what we do for expenses opw-4075244 Forward-Port-Of: odoo/enterprise#68945 Forward-Port-Of: odoo/enterprise#68044
A `_logger.critical` call was mistakenly committed in the `SixDriver.py` file. It has now been removed. Task: 3995682 Forward-Port-Of: odoo/enterprise#66641
Original PR description
A `_logger.critical` call was mistakenly committed in the `SixDriver.py` file. It has now been removed. Task: 3995682 Forward-Port-Of: odoo/enterprise#66641
Before this PR, the `test_postcommit` test would occasionally fail in a non-deterministic manner. This test ensures that the bus sends notifications after bus records are committed. However, we weren't waiting for the notification to occur before checking the expected channels. As a result, the check could happen too early, leading to test failures. This PR ensures that we wait for the notifications to be sent before verifying that each channel received them. runbot-76481 Forward-Port-Of:
Original PR description
Before this PR, the `test_postcommit` test would occasionally fail in a non-deterministic manner. This test ensures that the bus sends notifications after bus records are committed. However, we weren't waiting for the notification to occur before checking the expected channels. As a result, the check could happen too early, leading to test failures. This PR ensures that we wait for the notifications to be sent before verifying that each channel received them. runbot-76481 Forward-Port-Of: odoo/odoo#178767
When using a fiscal position that map account. If you use automatic stock valuation and make an order in the PoS, the account used where not mapped correctly for all the account move lines. Steps to reproduce: ------------------- * Turn on automatic stock valuation for the category `All` * The category use account A and account B for expense and income * Create a fiscal position that matches account A and B to any other account * Open PoS and make an order > Observation: Go back to the
Original PR description
When using a fiscal position that map account. If you use automatic stock valuation and make an order in the PoS, the account used where not mapped correctly for all the account move lines. Steps to reproduce: ------------------- * Turn on automatic stock valuation for the category `All` * The category use account A and account B for expense and income * Create a fiscal position that matches account A and B to any other account * Open PoS and make an order > Observation: Go back to the order and look at the move lines linked to the order. One of the lines still use an account that hasn't been mapped Why the fix: ------------ We make sure that when creating the stock valuation lines the account are correctly mapped using `order_id.fiscal_position_id.map_account` opw-4086609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177557 Forward-Port-Of: odoo/odoo#177369
Create a new payslip Select Employee and contract Compute Sheet Create Draft Entry > Post Draft Entry Cancel payslip Issue: The system will attempt to reset to draft and unlink the associated invoice In some cases this is not ideal: In Indian government for example, requires audit trail report for private limited companies, so user can't delete journal entries after posting once. Backporting method `_unlink_or_reverse` from 17.0 [1] to be used in the related PR https://github.com/odoo
Original PR description
Create a new payslip Select Employee and contract Compute Sheet Create Draft Entry > Post Draft Entry Cancel payslip Issue: The system will attempt to reset to draft and unlink the associated invoice In some cases this is not ideal: In Indian government for example, requires audit trail report for private limited companies, so user can't delete journal entries after posting once. Backporting method `_unlink_or_reverse` from 17.0 [1] to be used in the related PR https://github.com/odoo/enterprise/pull/68044 [1] https://github.com/odoo/odoo/blob/66bfab54748a56072ed9ff144f4a39366b606a06/addons/account/models/account_move.py#L3772-L3785 opw-4075244 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#177963 Forward-Port-Of: odoo/odoo#176792
Somes files need freezegun to run in master. We add this module in the new image 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#178002
Original PR description
Somes files need freezegun to run in master. We add this module in the new image 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#178002
Before this commit, reloading a sale order imported into the POS would result in the loss of the link between the POS order line and the sale order line. opw-4120046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177776
Original PR description
Before this commit, reloading a sale order imported into the POS would result in the loss of the link between the POS order line and the sale order line. opw-4120046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177776
This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285 Forward-Port-Of: odoo/odoo#176861 Forward-Port-Of: odoo/odoo#175563
Original PR description
This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285 Forward-Port-Of: odoo/odoo#176861 Forward-Port-Of: odoo/odoo#175563
Refactor the `_create_out_svl` and `_create_dropshipped_svl` methods in the `stok.move` model to separate the vals list generation from the `create` call. These new methods facilitate overwrites in custom modules. This split is already present for the `_create_in_svl` method. Forward-Port-Of: odoo/odoo#177590
Original PR description
Refactor the `_create_out_svl` and `_create_dropshipped_svl` methods in the `stok.move` model to separate the vals list generation from the `create` call. These new methods facilitate overwrites in custom modules. This split is already present for the `_create_in_svl` method. Forward-Port-Of: odoo/odoo#177590
Make _onChangeState to be inheritable by adding it to website_sale.js and returning a promise. Adapt the _onChangeState in PE localization for the inheritance by calling _super method and returning a promise. related: https://github.com/odoo/enterprise/pull/64786 task-2856566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177624 Forward-Port-Of: odoo/odoo#169205
Original PR description
Make _onChangeState to be inheritable by adding it to website_sale.js and returning a promise. Adapt the _onChangeState in PE localization for the inheritance by calling _super method and returning a promise. related: https://github.com/odoo/enterprise/pull/64786 task-2856566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177624 Forward-Port-Of: odoo/odoo#169205
Before when using `html-to-canvas` to render the receipt, sometime the css was missing. This was due to the loading time of the css. Each time we want to render the receipt, we need to load the css and then render it. Now we are using `html-to-image` which is more reliable and faster. It doesn't have the issue of missing css. It use the stylesheet of the current page instead of reloading it. --- ### Attributions [bubkoo/html-to-image](https://github.com/bubkoo/html-to-image) Forward-Por
Original PR description
Before when using `html-to-canvas` to render the receipt, sometime the css was missing. This was due to the loading time of the css. Each time we want to render the receipt, we need to load the css and then render it. Now we are using `html-to-image` which is more reliable and faster. It doesn't have the issue of missing css. It use the stylesheet of the current page instead of reloading it. --- ### Attributions [bubkoo/html-to-image](https://github.com/bubkoo/html-to-image) Forward-Port-Of: odoo/odoo#177625 Forward-Port-Of: odoo/odoo#173512
### Steps to reproduce: - Enable Multi-Step routes in the settings - Go Inventory > Configuration > Warehouse Management > Warehouses - Enable 2-step manufacturing on your Warehouse - Create 2 storable products: - product P: tracked by SN - product COMP: tracked by lot - Update the "on hand qty" of COMP by creating a lot with 10 units - Create and confirm a manufacturing order for 1 unit of P - Change the qty producing to 1 then assign a serial number to the final product - Validate t
Original PR description
### Steps to reproduce: - Enable Multi-Step routes in the settings - Go Inventory > Configuration > Warehouse Management > Warehouses - Enable 2-step manufacturing on your Warehouse - Create 2…
### Steps to reproduce: - Enable Multi-Step routes in the settings - Go Inventory > Configuration > Warehouse Management > Warehouses - Enable 2-step manufacturing on your Warehouse - Create 2 storable products: - product P: tracked by SN - product COMP: tracked by lot - Update the "on hand qty" of COMP by creating a lot with 10 units - Create and confirm a manufacturing order for 1 unit of P - Change the qty producing to 1 then assign a serial number to the final product - Validate the transfer of components from stock to preproduction (The lot is automatically used on this transfer as it is available) ### Expected behavior: Since the lot of COMP was used in the transfer from stock to preproduction it should be displayed on the raw move of the MO. ### Current behavior: The raw move is not updated. Note: if the transfer is validated before we set the qty producing the lot of the component is correctly updated. ### Cause of the issue: When the `qty_producing` is changed, the '_set_qty_producing' is called in order to adapt the quantities of the MO (produce only one unit and consume accordingly): https://github.com/odoo/odoo/blob/b26129c1ed6eb4806569e05d90c17dd9aa2e4c02/addons/mrp/models/mrp_production.py#L809-L811 https://github.com/odoo/odoo/blob/37c67ba6d2bef0bdca715619f117c3124ef5d334/addons/mrp/models/mrp_production.py#L1215-L1231 Now, changing the quantity of the stock move of the component to a positive quantity will trigger the inverse method '_set_quantity' of that field to adapt reservation by creating a stock.move.line. Therefore, validating the transfer of components from stock to pre-production will not update the lot of components on the raw move because the computed need will be at 0 here: https://github.com/odoo/odoo/blob/3097ea49705a1b6319be9677152d65ebe3ce515b/addons/stock/models/stock_move.py#L1689-L1697 and the '_update_reserved_quantity' call will therefore be empty. follow up of commit d7148a7 opw-3925894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177894
Issue ----- If an image has a width or height of 1, crop_resize will fail if we are trying to resize it to a vertical format (max_height/max_width > 1) if the original image has a height of 1, or to a horizontal format if the original image has a width of 1. This is because the calculated new_w/new_h of the cropped image will be 0. Steps to reproduce ----- The issue typically happens when a mail includes spacer images with a height or width of 1 and they get uploaded as documents and
Original PR description
Issue ----- If an image has a width or height of 1, crop_resize will fail if we are trying to resize it to a vertical format (max_height/max_width > 1) if the original image has a height of 1, or to a horizontal format if the original image has a width of 1. This is because the calculated new_w/new_h of the cropped image will be 0. Steps to reproduce ----- The issue typically happens when a mail includes spacer images with a height or width of 1 and they get uploaded as documents and a thumbnail is generated. An easier way to reproduce in v16.0 (in v15.0 we resize to a square format): 1. Install Documents. 2. Upload an image with a width of 1. -> Error 500 opw-4053926 Forward-Port-Of: odoo/odoo#177885 Forward-Port-Of: odoo/odoo#176632
Issue: ====== Can't add content at the end/start of button Steps to reproduce the issue: ============================= - Use chrome - Install events - Go to website/events/conference for architects (demo data) - Open editor and edit - Put the cursor at the end of the "Get The direction" button - Try to add some text, nothing happens Note: it works in firefox Origin of the issue: ==================== Chrome doesn't support the following case correctly when the selection is at
Original PR description
Issue: ====== Can't add content at the end/start of button Steps to reproduce the issue: ============================= - Use chrome - Install events - Go to website/events/conference for architects (demo data) - Open editor and edit - Put the cursor at the end of the "Get The direction" button - Try to add some text, nothing happens Note: it works in firefox Origin of the issue: ==================== Chrome doesn't support the following case correctly when the selection is at the start or at the end of the text. ``` <div contenteditable="false"> <a contenteditable="true" href="http://www.example.com"> <p> abcde </p> </a> </div> ``` The `p` element inside the `a` was introduced in [1]. Solution: ========= Unwrap the content of the `p` elements inside `a` element the same way we do for `li` elements. opw-3878459 [1]: https://github.com/odoo/odoo/commit/4a890e1f92a665dd53f17ee57b4e7792c33da7db Forward-Port-Of: odoo/odoo#169765
* PROPBLEM: since https://github.com/odoo/odoo/pull/173719 we have moved from init to post_init which will make timesheet_task_id of hr.leave.type can't set value because in post_init company.leave_timesheet_task_id will be set * SOLUTION: fill it in post_init instead 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 Fo
Original PR description
* PROPBLEM: since https://github.com/odoo/odoo/pull/173719 we have moved from init to post_init which will make timesheet_task_id of hr.leave.type can't set value because in post_init company.leave_timesheet_task_id will be set * SOLUTION: fill it in post_init instead 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#177605 Forward-Port-Of: odoo/odoo#177008
Problem: When a discount is based on quantity and we update the quantity to a value that does not have a discount, the stale discount value remains. Steps to reproduce: - Create a product with two vendor lines for the same vendor but different discounts based on quantity: - Vendor1: Quantity 10 - Discount 5% - Vendor1: Quantity 20 - Discount 10% - Create a new quotation with the product and set the quantity to 10. - Update the quantity to 20. - Update the quantity to 1. The 10% discoun
Original PR description
Problem: When a discount is based on quantity and we update the quantity to a value that does not have a discount, the stale discount value remains. Steps to reproduce: - Create a product with two vendor lines for the same vendor but different discounts based on quantity: - Vendor1: Quantity 10 - Discount 5% - Vendor1: Quantity 20 - Discount 10% - Create a new quotation with the product and set the quantity to 10. - Update the quantity to 20. - Update the quantity to 1. The 10% discount still appears, even though it should have been removed. opw-4123984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177404
Suppose the following structure: ---------------------------------------------- BoM of Main kit: - BoM Type: Kit - Quantity: 4 - Components: * 1 x Sub kit A * 1 x Sub kit B BoM of Subkit A: - BoM Type: Kit - Quantity: 1 - Components: * 2 x Component A (Cost: $10, Storable) BoM of Subkit B: - BoM Type: Kit - Quantity: 1 - Components: * 2 x Component B (Cost: $6, Storable) When creating a sale order for 1 Main Kit, delivering the components
Original PR description
Suppose the following structure: ---------------------------------------------- BoM of Main kit: - BoM Type: Kit - Quantity: 4 - Components: * 1 x Sub kit A * 1 x Sub kit B BoM of Subkit A: - BoM…
Suppose the following structure:
----------------------------------------------
BoM of Main kit:
- BoM Type: Kit
- Quantity: 4
- Components:
* 1 x Sub kit A
* 1 x Sub kit B
BoM of Subkit A:
- BoM Type: Kit
- Quantity: 1
- Components:
* 2 x Component A (Cost: $10, Storable)
BoM of Subkit B:
- BoM Type: Kit
- Quantity: 1
- Components:
* 2 x Component B (Cost: $6, Storable)
When creating a sale order for 1 Main Kit, delivering the components and posting the invoice, the Cost Of Goods Sold computed by the _stock_account_get_anglo_saxon_price_unit method was ignoring the COGS for the Subkit B.
This is due to the commit https://github.com/odoo/odoo/commit/31e1352df686d8a23628ade83d321929c49d6f4e which fetches the BOMs from the stock moves linked to the Sale Order. As no component is present directly in the bom lines of the Main Kit BOM, the bom was omitted.
Now, if the product's bom is not present in the stock move's bom, we'll fetch one the old way.
opw-4033293
Forward-Port-Of: odoo/odoo#177248
Forward-Port-Of: odoo/odoo#174853### Steps to reproduce: - Create a MO for a product without BOM (no need of components) - Go to the "Work Orders" tab and create 2 operations: op1 and op2 - Confirm the MO - Start the operation waiting for an other WO (op2) - Create a third operation: op3 - Save #### > Validation Error: You cannot create a cyclic dependency. ### Cause of the Issue: During the creation of op3, all the workorders of our MO will be confirmed to ensures that the links of the 3 operations are correctly
Original PR description
### Steps to reproduce: - Create a MO for a product without BOM (no need of components) - Go to the "Work Orders" tab and create 2 operations: op1 and op2 - Confirm the MO - Start the operation…
### Steps to reproduce: - Create a MO for a product without BOM (no need of components) - Go to the "Work Orders" tab and create 2 operations: op1 and op2 - Confirm the MO - Start the operation waiting for an other WO (op2) - Create a third operation: op3 - Save #### > Validation Error: You cannot create a cyclic dependency. ### Cause of the Issue: During the creation of op3, all the workorders of our MO will be confirmed to ensures that the links of the 3 operations are correctly made: https://github.com/odoo/odoo/blob/d2ce6622f2d6f1917dc319112a688e35a73c2088/addons/mrp/models/mrp_workorder.py#L469-L474 This will trigger a call of the `_link_workorders_and_moves` to re-link them all. However, during this call since op2 has been started the order of the workorders will be op2 > op1 rather than op1 > op2 and since the MO has no bom nor `operation_id` the records will not be reordered correctly before being linked: https://github.com/odoo/odoo/blob/d2ce6622f2d6f1917dc319112a688e35a73c2088/addons/mrp/models/mrp_production.py#L1472-L1473 https://github.com/odoo/odoo/blob/d2ce6622f2d6f1917dc319112a688e35a73c2088/addons/mrp/models/mrp_production.py#L1485-L1487 This will create a loop on the m2m dependency since op1 will be blocked by op2 and op2 is already blocked by op1. This is detected by the framework which raises the error. opw-4105603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177402
### Steps to reproduce: - Create and confirm a delivery for 10 units of a product P - Change the quantity of the move to 5 and mark it as picked - Click on the "detailed operations" button of the picking - Change the quantity of the move line to 3 - Create a new line for 2 units (this would make sense if you want to register 2 lots for instance the flow is kepts as simple possible) - Go back to the delivery, validate and create a back order #### > A back order is created for 7 units r
Original PR description
### Steps to reproduce: - Create and confirm a delivery for 10 units of a product P - Change the quantity of the move to 5 and mark it as picked - Click on the "detailed operations" button of the…
### Steps to reproduce: - Create and confirm a delivery for 10 units of a product P - Change the quantity of the move to 5 and mark it as picked - Click on the "detailed operations" button of the picking - Change the quantity of the move line to 3 - Create a new line for 2 units (this would make sense if you want to register 2 lots for instance the flow is kepts as simple possible) - Go back to the delivery, validate and create a back order #### > A back order is created for 7 units rather than 5 and the original delivery was validated for only 3 units. ### Cause of the issue: When you create a new move line on the picking from the detailed operation it is linked to the move of the picking via these lines: https://github.com/odoo/odoo/blob/4c79aceb3a6c08453f9ec66131e1bc525eae140c/addons/stock/models/stock_move_line.py#L325-L331 However, while the move is marked as picked, the newly created move line is not. As such during the `_action_done` of the stock move, the new sml will be unlinked from the move: https://github.com/odoo/odoo/blob/4c79aceb3a6c08453f9ec66131e1bc525eae140c/addons/stock/models/stock_move.py#L1865-L1872 opw-4100293 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178017
In #97883, the Hungarian localization was translated from Hungarian into English. After that, some Hungarian translations for tax names, tax descriptions and tax report lines were lost. This commit aims at ensuring the translations are added and bringing Hungarian taxes in conformity with best practices. Specifically, this commit changes tax names in descriptions according to the tax naming conventions. task-4132407 --- I confirm I have signed the CLA and read the PR guidelines at
Original PR description
In #97883, the Hungarian localization was translated from Hungarian into English. After that, some Hungarian translations for tax names, tax descriptions and tax report lines were lost. This commit aims at ensuring the translations are added and bringing Hungarian taxes in conformity with best practices. Specifically, this commit changes tax names in descriptions according to the tax naming conventions. task-4132407 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178242 Forward-Port-Of: odoo/odoo#177928
Since the refactor https://github.com/odoo/odoo/pull/110188, the welcome page had several bugs: 1) The `fa-microphone-slash` icon was displayed when the microphone was on instead of when the microphone was mute. 2) The localStorage keys `discuss_call_preview_join_mute` and `discuss_call_preview_join_video` were set with booleans, while the localStorage stores as strings, which made them always truthy as soon as they were set. 3) The microphone preview was not working as the `srcObject`
Original PR description
Since the refactor https://github.com/odoo/odoo/pull/110188, the welcome page had several bugs: 1) The `fa-microphone-slash` icon was displayed when the microphone was on instead of when the…
Since the refactor https://github.com/odoo/odoo/pull/110188, the welcome page had several bugs: 1) The `fa-microphone-slash` icon was displayed when the microphone was on instead of when the microphone was mute. 2) The localStorage keys `discuss_call_preview_join_mute` and `discuss_call_preview_join_video` were set with booleans, while the localStorage stores as strings, which made them always truthy as soon as they were set. 3) The microphone preview was not working as the `srcObject` of the audio element was `undefined` because we were using `this.audioStream` instead of `this.state.audioStream`. 4) Before the refactor, the preview was automatically started when opening the welcome page, this commit restores this behavior: https://github.com/odoo/odoo/blob/16.0/addons/mail/static/src/models/discuss_public_view.js#L46-L49 5) Streams (tracks) were not closed after leaving the welcome view, nor was it checked whether they were still needed after the `getUserMedia` promise. Forward-Port-Of: odoo/odoo#177953 Forward-Port-Of: odoo/odoo#177525
### Steps to reproduce: - Install Time-off module - Create new allocation for an employee for 1 day - Create a leave for this employee with more than 1 day -error will be raised- - Edit the leave to be for just one day and validate it - Refuse this leave and mark it as draft - Change the dates to be more than 1 day ### Current behavior before PR: It is expected to raise an Error each time an employee tries to have a leave which has more days than the allocation he has but this is
Original PR description
### Steps to reproduce: - Install Time-off module - Create new allocation for an employee for 1 day - Create a leave for this employee with more than 1 day -error will be raised- - Edit the leave to…
### Steps to reproduce: - Install Time-off module - Create new allocation for an employee for 1 day - Create a leave for this employee with more than 1 day -error will be raised- - Edit the leave to be for just one day and validate it - Refuse this leave and mark it as draft - Change the dates to be more than 1 day ### Current behavior before PR: It is expected to raise an Error each time an employee tries to have a leave which has more days than the allocation he has but this is not happening when the leave is in draft state. So the employee can submit a leave with days more than the allocation. This issue is happening because when checking if there is excess days in the leave we don't take leaves in draft state into considertion. https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_employee.py#L387:L391 ### Desired behavior after PR is merged: After editing the leaves_domain we are now taking draft leaves into cosideration when we are checking the leave validity. opw-4090572 Forward-Port-Of: odoo/odoo#176936
[FIX] mail: include whatsapp in webpush notifications There are couple of components in the notification architecture. For the sake of illustration let's simplify it with the following: Sender -> Queuer -> Receiver Queuer is an FMC backend, so we should only be concerned about the other two. Receiver which is just a frontend service worker that will generate notifications as soon as he receives an event. The issue (before this commit) was in the Sender part, which was skipping whatsapp
Original PR description
[FIX] mail: include whatsapp in webpush notifications There are couple of components in the notification architecture. For the sake of illustration let's simplify it with the following: Sender -> Queuer -> Receiver Queuer is an FMC backend, so we should only be concerned about the other two. Receiver which is just a frontend service worker that will generate notifications as soon as he receives an event. The issue (before this commit) was in the Sender part, which was skipping whatsapp type message generation. [Reproduce] - Configure Whatsapp account, include user A in "Notify users" - Allow notifications in your browser (chat icon/ OdooBot suggestion) - Send a whatsapp message to the configured whatsapp number - BUG: Push notification is not showing up opw-3720699 Forward-Port-Of: odoo/odoo#177686 Forward-Port-Of: odoo/odoo#175638
We get an error when validating a stock picking with a branch company Steps: - Create a company C with a branch B - Set env.companies to both C and B, and env.company to either C or B - Create product P with company set as B, a standard_price > 0 and a product category set to 'Automated' and valuation != 'standard' - Make a stock picking from/to B for product P - Try to validate picking -> UserError: 'Incompatible companies on records' This is because the account move is created with main c
Original PR description
We get an error when validating a stock picking with a branch company Steps: - Create a company C with a branch B - Set env.companies to both C and B, and env.company to either C or B - Create product P with company set as B, a standard_price > 0 and a product category set to 'Automated' and valuation != 'standard' - Make a stock picking from/to B for product P - Try to validate picking -> UserError: 'Incompatible companies on records' This is because the account move is created with main company instead of branch company. opw-4105551 Forward-Port-Of: odoo/odoo#176501
Steps to reproduce: - Go to a website blog post page > Drop a "Table of Content" snippet inside the blog post content. - Switch to translation mode > Try to translate a TOC title > The corresponding navigation label won't be automatically updated. - Save > The translation will be applied depending on whether the title and the navbar item have exactly the same content or not [*]. Starting from [1], the translation of a "Table of Content" navigation label was automatically applied
Original PR description
Steps to reproduce: - Go to a website blog post page > Drop a "Table of Content" snippet inside the blog post content. - Switch to translation mode > Try to translate a TOC title > The corresponding…
Steps to reproduce:
- Go to a website blog post page > Drop a "Table of Content" snippet
inside the blog post content.
- Switch to translation mode > Try to translate a TOC title > The
corresponding navigation label won't be automatically updated.
- Save > The translation will be applied depending on whether the title
and the navbar item have exactly the same content or not [*].
Starting from [1], the translation of a "Table of Content" navigation
label was automatically applied (only the text content) when the
corresponding title was translated, and the user was also warned when
trying to edit them directly in "translation" mode.
This implementation relied on the field observers mechanism to
synchronize translations for the table of content navigation and content
headers.
Unfortunately, the field mutations handler doesn't take translation
fields into consideration when they are part of another field's DOM:
1. Before trying to set the updated field value on its duplicates in the
DOM, the handler is using `_pauseOdooFieldObservers()` to `disconnect()`
all the observers of other fields to prevent receiving mutations from
its own updates.
2. In translation mode, and when the updated field has some inner
translation `<span/>`s, their observers will be disconnected too, and
their mutations will never be linked to the right target.
3. Finally, the `_observeOdooFieldChanges()` is used to observe the
fields again.
Let's take the following example:
```
<div data-oe-model="...">
<span data-oe-translation-initial-sha="...">Text Content</span>
</div>
```
In this case, two observers are created, one for the `[data-oe-model]`
(`O1`) and the other for the `[data-oe-translation-initial-sha]` (`O2`).
When editing the "Text Content" of the `<span/>`, `O1` will be triggered
(for the parent field) and will temporarily disconnect all other fields
observers (including (`O2`)) and as a consequence, `O2` won't be able to
synchronize the value of the translation field on the ones with the same
`data-oe-translation-initial-sha` (which is the same situation as in a
"Table of Content" block).
The goal of this commit is to simply prevent disconnecting inner
translation field observers to allow the translation synchronization
inside a parent field DOM.
[*]: Remark: when a TOC title and its navigation item have different DOM
(e.g., the font color of the title changed), the code from [1] will
always temporarily set the same `data-oe-translation-initial-sha` on
both of them (and restore the original ones before saving), which
explains the different translation values when the field observers are
not working correctly.
[1]: https://github.com/odoo/odoo/commit/5776a358e1b42186d2c26c9bc25010a12811f416
opw-3990039
opw-3888871
Forward-Port-Of: odoo/odoo#178439
Forward-Port-Of: odoo/odoo#176198Set up email alias for Vendor Bill journal Send email with docx attachment to alias Bill is created Issue: No attachment is present This commit will extend 827b536942a67e91d4283ebd2bf50db5141f0abe to allow more formats opw-4092311 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#178106
Original PR description
Set up email alias for Vendor Bill journal Send email with docx attachment to alias Bill is created Issue: No attachment is present This commit will extend 827b536942a67e91d4283ebd2bf50db5141f0abe to allow more formats opw-4092311 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#178106
Before 17 process_coa_translations might have been needed in multi_lang localizations, but it is no longer needed. It is also not called. No task linked. Just saw it checking other stuff. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178508
Original PR description
Before 17 process_coa_translations might have been needed in multi_lang localizations, but it is no longer needed. It is also not called. No task linked. Just saw it checking other stuff. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178508
When rendering a template in the render mixin urls are converted from local to full without consideration for the website of the record being processed. We now pass the base url of the record, fetched with `get_base_url` so that email links link to the proper website when needed. task-4104753 Forward-Port-Of: odoo/odoo#178737 Forward-Port-Of: odoo/odoo#176152
Original PR description
When rendering a template in the render mixin urls are converted from local to full without consideration for the website of the record being processed. We now pass the base url of the record, fetched with `get_base_url` so that email links link to the proper website when needed. task-4104753 Forward-Port-Of: odoo/odoo#178737 Forward-Port-Of: odoo/odoo#176152
This commit make card column with 100% for 3 column grid in order to not have forth blank space in mobile view and display on product par row in mobile. opw-4052977 Forward-Port-Of: odoo/odoo#178487
Original PR description
This commit make card column with 100% for 3 column grid in order to not have forth blank space in mobile view and display on product par row in mobile. opw-4052977 Forward-Port-Of: odoo/odoo#178487
If you created an event using GNOME Evolution/Calendar, it could add an `X-EVOLUTION-ENDDATE` parameter to the event's `RRULE`. When that happens, if the event is pushed to a Google Calendar and synced in Odoo, all participants' calendars stop syncing from there onwards. <details> ``` 2024-06-26 07:10:57,942 41 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(15,)] Calendar Synchro - Exception : unsupported property: X-EVOLUTION-ENDDATE=20371102T114500Z ! Traceback
Original PR description
If you created an event using GNOME Evolution/Calendar, it could add an `X-EVOLUTION-ENDDATE` parameter to the event's `RRULE`. When that happens, if the event is pushed to a Google Calendar and…
If you created an event using GNOME Evolution/Calendar, it could add an `X-EVOLUTION-ENDDATE` parameter to the event's `RRULE`.
When that happens, if the event is pushed to a Google Calendar and synced in Odoo, all participants' calendars stop syncing from there onwards.
<details>
```
2024-06-26 07:10:57,942 41 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(15,)] Calendar Synchro - Exception : unsupported property: X-EVOLUTION-ENDDATE=20371102T114500Z !
Traceback (most recent call last):
File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 100, in _sync_all_google_calendar
user.with_user(user).sudo()._sync_google_calendar(google)
File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 78, in _sync_google_calendar
synced_recurrences = self.env['calendar.recurrence'].with_context(write_dates=recurrences_write_dates)._sync_google2odoo(recurrences)
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 185, in _sync_google2odoo
odoo_record.with_context(dont_notify=True)._write_from_google(gevent, vals)
File "/opt/odoo/auto/addons/google_calendar/models/calendar_recurrence_rule.py", line 88, in _write_from_google
super()._write_from_google(gevent, vals)
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 304, in _write_from_google
self.write(vals)
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 71, in write
result = super().write(vals)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3808, in write
fields[0].determine_inverse(real_recs)
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1401, in determine_inverse
determine(self.inverse, records)
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 98, in determine
return needle(*args)
File "/opt/odoo/auto/addons/calendar/models/calendar_recurrence.py", line 219, in _inverse_rrule
values = self._rrule_parse(recurrence.rrule, recurrence.dtstart)
File "/opt/odoo/auto/addons/calendar/models/calendar_recurrence.py", line 366, in _rrule_parse
rule = rrule.rrulestr(rule_str, dtstart=date_start)
File "/usr/local/lib/python3.10/site-packages/dateutil/rrule.py", line 1730, in __call__
return self._parse_rfc(s, **kwargs)
File "/usr/local/lib/python3.10/site-packages/dateutil/rrule.py", line 1698, in _parse_rfc
raise ValueError("unsupported property: "+name)
ValueError: unsupported property: X-EVOLUTION-ENDDATE=20371102T114500Z
```
</details>
In https://discourse.gnome.org/t/working-with-evolution-mail-and-web-calendar-using-rrule-fail-because-of-x-evolution-enddate-in-rrule/19710/3 it explains why this happens and how it's actually a supported feature of RFC 5545.
Dateutil doesn't support that feature. It just fails with `ValueError`. Progress is being tracked in https://github.com/dateutil/dateutil/pull/1374.
Regarding what matters to Odoo, we can just strip any X-named params from the RRULE prefix and live happy with the rest (or fail if there's really a wrongly-formatted RRULE param). This way we avoid dateutil to fail unnecessarily and unlock users Google calendars synchronizations.
@moduon MT-6287
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#171784Because the signature is precomputed and includes the server URL, when running with a non-standard port the test fails as the port does not match the original value used to precompute the signature. - reset `web.base.url` to its default / precomputation value. - patch `TestPaymentTransaction.base_url` to return the same, as that is what `PaymentHttpCommon._build_url` uses to... build the url. Forward-Port-Of: odoo/odoo#178584
Original PR description
Because the signature is precomputed and includes the server URL, when running with a non-standard port the test fails as the port does not match the original value used to precompute the signature. - reset `web.base.url` to its default / precomputation value. - patch `TestPaymentTransaction.base_url` to return the same, as that is what `PaymentHttpCommon._build_url` uses to... build the url. Forward-Port-Of: odoo/odoo#178584
Prior to this commit: If you were in debug=1 or debug=assets prior to opening the PoS, it would be lost when opening the pos session from the backend. This can be particularly problematic on mobile app as the user can not modify the url manually. Being in debug mode on the PoS is useful to have the debug window and troubleshoot with the asset code After this commit: The PoS is opened with the same debug mode than the browser session Forward-Port-Of: odoo/odoo#178569
Original PR description
Prior to this commit: If you were in debug=1 or debug=assets prior to opening the PoS, it would be lost when opening the pos session from the backend. This can be particularly problematic on mobile app as the user can not modify the url manually. Being in debug mode on the PoS is useful to have the debug window and troubleshoot with the asset code After this commit: The PoS is opened with the same debug mode than the browser session Forward-Port-Of: odoo/odoo#178569
When using a loyalty program that apply a discount on the cheapest line the combo "title" would always be selected as it's price is 0. And the reward would then not be applied. Steps to reproduce: ------------------- * Create a combo product with atleast 2 combo choices * Create a loyalty program that gives a discount on the cheapest line * Open a PoS and add the combo product > Observation: The reward cannot be applied Why the fix: ------------ When tryin to apply the discount, in
Original PR description
When using a loyalty program that apply a discount on the cheapest line the combo "title" would always be selected as it's price is 0. And the reward would then not be applied. Steps to reproduce: ------------------- * Create a combo product with atleast 2 combo choices * Create a loyalty program that gives a discount on the cheapest line * Open a PoS and add the combo product > Observation: The reward cannot be applied Why the fix: ------------ When tryin to apply the discount, in the `_getCheapestLine` function we make sure to filter lines that are combo "title" opw-4033960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178414 Forward-Port-Of: odoo/odoo#177062
### Steps to reproduce: - Install the 'l10n_uk' module - The module "l10n_uk_bacs" is not installed, but it should ### Solution: Add a post init hook in `l10n_uk` to download `l10n_uk_bacs`. opw-4122475 Forward-Port-Of: odoo/odoo#178331
Original PR description
### Steps to reproduce: - Install the 'l10n_uk' module - The module "l10n_uk_bacs" is not installed, but it should ### Solution: Add a post init hook in `l10n_uk` to download `l10n_uk_bacs`. opw-4122475 Forward-Port-Of: odoo/odoo#178331
Versions -------- - 17.0+ Steps ----- 1. Create a loyalty program that applies on future orders; 2. disable it for eCommerce; 3. create a card for you with adequate points for a reward; 4. go to website shop; 5. add product to cart; 6. go to shopping cart view. Issue ----- Claimable reward is display despite being disabled for eCommerce. Cause ----- The `_get_claimable_and_showable_rewards` method doesn't take a program's `ecommerce_ok` field into account when searching for
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a loyalty program that applies on future orders; 2. disable it for eCommerce; 3. create a card for you with adequate points for a reward; 4. go to website shop; 5. add product to cart; 6. go to shopping cart view. Issue ----- Claimable reward is display despite being disabled for eCommerce. Cause ----- The `_get_claimable_and_showable_rewards` method doesn't take a program's `ecommerce_ok` field into account when searching for cards. Solution -------- In the domain used, use the result of `_get_program_domain` to ensure only applicable cards from applicable program's are retrieved. opw-3997371 Forward-Port-Of: odoo/odoo#178243
### Issue: The bank accounts of a company are not accessible from the branches of this company. ### Steps to reproduce: - In Settings, create a company and a branch company - In the contact app, add a bank account for the company - Switch to the branch company - In the Accounting app, create a Customer invoice - In the "Other Info", change the Company to the branch - The bank account created does not show up in the selection of the field "Recipient Bank" ### Cause: The current doma
Original PR description
### Issue: The bank accounts of a company are not accessible from the branches of this company. ### Steps to reproduce: - In Settings, create a company and a branch company - In the contact app, add…
### Issue:
The bank accounts of a company are not accessible from the branches of this company.
### Steps to reproduce:
- In Settings, create a company and a branch company
- In the contact app, add a bank account for the company
- Switch to the branch company
- In the Accounting app, create a Customer invoice
- In the "Other Info", change the Company to the branch
- The bank account created does not show up in the selection of the field "Recipient Bank"
### Cause:
The current domain is `domain="[('partner_id', '=', bank_partner_id)]"` which is only taking the res.partner.bank record linked with the partner of the company (bank_partner_id).
### Solution:
The solution must work on companies not partners and use the 'parent_of' keyword so that the branches can access the records. Changing the domain to `[('partner_id.ref_company_ids', 'parent_of', company_id)]` works.
### Note:
- The field `ref_company_ids` is an old field that is almost not used anymore, but it is the only link between res.partner.bank and the company it is linked to.
- This domain used `partner_id.ref_company_ids` in an old version of Odoo, but it was changed in this commit: https://github.com/odoo/odoo/commit/1db371721f3549276ee622e8b4369db7ce13863c because of a bug. I did not manage to reproduce the bug in v17 with this fix.
Ticket [link](https://www.odoo.com/odoo/project.task/4027680)
opw-4027680
Forward-Port-Of: odoo/odoo#173287When a table of content is edited, the anchor ids to each of its h1 and h2 headings are re-generated in order to make the possibly updated navigation links target each individual heading. These ids are generated based on time for the table of content itself and a unique id for the heading. Because of this when links are defined to target those headings anchors, the links do not reference the correct id anymore if the table of content snippet is edited in any way. This commit fixes this
Original PR description
When a table of content is edited, the anchor ids to each of its h1 and h2 headings are re-generated in order to make the possibly updated navigation links target each individual heading. These ids are generated based on time for the table of content itself and a unique id for the heading. Because of this when links are defined to target those headings anchors, the links do not reference the correct id anymore if the table of content snippet is edited in any way. This commit fixes this issue's general case by keeping track of a generated id for the table of content, and assigning ids to headings in their sequence order. Steps to reproduce: - Drop a "Table of Content" block - Define a link to a heading (`#table_of_content_heading_...`) - Save - Edit - Select table of content => The link anchor does not match the heading id anymore. opw-3974850 Forward-Port-Of: odoo/odoo#178576 Forward-Port-Of: odoo/odoo#169408
**Steps:** - Go to Shop - Add a product to the wishlist. - Access the Wishlist page and apply the Mobile View. - Apply Zoom on the mobile view **Issue:** - For some languages (like French) the full button can't be seen at the standard 100% view. Also a column of image is shown extra even though the image is not displayed **Fix:** - Removing the column of image for smaller screens will resolve our issue, and we would be able to see the button upto a lot more zooming ratio. **Affec
Original PR description
**Steps:** - Go to Shop - Add a product to the wishlist. - Access the Wishlist page and apply the Mobile View. - Apply Zoom on the mobile view **Issue:** - For some languages (like French) the full button can't be seen at the standard 100% view. Also a column of image is shown extra even though the image is not displayed **Fix:** - Removing the column of image for smaller screens will resolve our issue, and we would be able to see the button upto a lot more zooming ratio. **Affected version:** 17.0~master opw-4089951 Forward-Port-Of: odoo/odoo#178329
The pricelist discount policy is always visibile in 17+, and some users may change it to display discounts in the PoS. Nevertheless, if the sale discounts are not enabled, saving the settings will reset the value to 'hide discounts'. Since the group is ambiguous, has been moved to sale in 17.2, and the discount policy feature is removed in 18, we'll restrict the reset of the discount policies only when the discount group is effectively disabled manually, not any time the settings are saved
Original PR description
The pricelist discount policy is always visibile in 17+, and some users may change it to display discounts in the PoS. Nevertheless, if the sale discounts are not enabled, saving the settings will reset the value to 'hide discounts'. Since the group is ambiguous, has been moved to sale in 17.2, and the discount policy feature is removed in 18, we'll restrict the reset of the discount policies only when the discount group is effectively disabled manually, not any time the settings are saved. opw-4019168 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178347
### Steps to reproduce: - Enable multisteps route in the settings - Create a storable product P and put 10 units in WH/Stock/Shelf - Create and confirm an SO for 1 unit of P - Go to the associated delivery and change the Source Location to WH/Stock/Shelf - Back to the SO, click on the chart icon > view forecast - Unreserve the 1 unit currently used by your picking ### Issue: While you have 10 units in WH/Stock/Shelf perfectly suitable to fulfill the demand of the picking, instead o
Original PR description
### Steps to reproduce: - Enable multisteps route in the settings - Create a storable product P and put 10 units in WH/Stock/Shelf - Create and confirm an SO for 1 unit of P - Go to the associated…
### Steps to reproduce: - Enable multisteps route in the settings - Create a storable product P and put 10 units in WH/Stock/Shelf - Create and confirm an SO for 1 unit of P - Go to the associated delivery and change the Source Location to WH/Stock/Shelf - Back to the SO, click on the chart icon > view forecast - Unreserve the 1 unit currently used by your picking ### Issue: While you have 10 units in WH/Stock/Shelf perfectly suitable to fulfill the demand of the picking, instead of displaying a line allowing you to reserve the 1 unit, you have a line telling you that the qty is "not available" -1 unit associated with the SO. If you go back to the SO: the chart icon is displayed red and the details displayed in the availability widget shows a: "No future availability". ### Cause of the issue: The chart icon is red because the JS detects a forecasted issue: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/sale_stock/static/src/widgets/qty_at_date_widget.xml#L8 This issue comes from the fact that the demand is not expected to be fulfilled since the `free_qty_today` of the SOL is smaller than its `qty_to_deliver`: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L45 https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L54-L55 The reason for this forecasted issue is that the `free_qty_today` is computed to be -1 rather than 1 here: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/sale_stock/models/sale_order_line.py#L80-L82 since the `move.forecast_availability` is itself -1 rather than 1. Note that if the source of the move was still WH/Stock rather than WH/Stock/Shelf both of these value would be set to +1 and the issue would not appear. However, the `forecast_availability` of moves is not correctly computed if the location_id of the move is a strict sublocation of the warehouse. To be more precise, the forecasted availability is set to a negative quantity here: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/stock/models/stock_move.py#L470-L472 since the report line computed in the `_get_forecast_availability_outgoing` specifies that 'replenishment_filled' is False and should not be: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/stock/models/stock_move.py#L2228 We are finally at the core of the problem, the replenishement is not filled because in the `_get_report_lines`, the `currents` dict used to compute both the reserved and the on hand quantity only updates the quantity of the warehouse if the location belongs to the warehouse: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/stock/report/stock_forecasted.py#L327-L330 As such, 0 units are considered to be available in these locations and nothing can be taken from stock for these moves: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/stock/report/stock_forecasted.py#L236-L242 which of course result in the impossibility to fulfill the replenishment opw-3979953 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172106
Since Chrome 128, the default headless mode has been updated to the "new" engine (which is closer to the regular rendering engine). This new mode only supports the window_size syntax where the seperator is a colon. Note: this syntax was already supported by previous Chrome versions. This commit forces the conversion to this new syntax because the old one is plainly ignored starting from Chrome 128, preventing "mobile" tests - at least - from being run in the proper resolution. Refe
Original PR description
Since Chrome 128, the default headless mode has been updated to the "new" engine (which is closer to the regular rendering engine). This new mode only supports the window_size syntax where the seperator is a colon. Note: this syntax was already supported by previous Chrome versions. This commit forces the conversion to this new syntax because the old one is plainly ignored starting from Chrome 128, preventing "mobile" tests - at least - from being run in the proper resolution. Reference: https://chromium.googlesource.com/chromium/src/+/b9b39a430f71c710d16aafcc67278ef77440c18d Forward-Port-Of: odoo/odoo#178687 Forward-Port-Of: odoo/odoo#178320
**Current behavior before PR:** When an email template is posted inside the chatter, the content overflows in the x-direction, causing a UI issue where the message bubble does not handle the overflow properly.  **Desired behavior after PR is merged:** The issue has been fixed, making the message content scrollable inside the message bubble, preventing overflow and maintaining proper UI appeara
Original PR description
**Current behavior before PR:** When an email template is posted inside the chatter, the content overflows in the x-direction, causing a UI issue where the message bubble does not handle the overflow properly.  **Desired behavior after PR is merged:** The issue has been fixed, making the message content scrollable inside the message bubble, preventing overflow and maintaining proper UI appearance. **Task**-4083373 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178889 Forward-Port-Of: odoo/odoo#175472
Currently, a traceback is occurring when the user tries to download a card for a child partner of type `other` having no name. To reproduce this issue: 1) Install `Contacts` 2) Create a record in `Contact & Addresses` of type as `Other Addresses` in an existing contact 3) Now open the above-created contact 4) Download the Vcard for that record Error:- ``` AttributeError: 'bool' object has no attribute 'replace' ``` As you can see name is only required when the type is 'c
Original PR description
Currently, a traceback is occurring when the user tries to download a card for a child partner of type `other` having no name. To reproduce this issue: 1) Install `Contacts` 2) Create a record in…
Currently, a traceback is occurring when the user tries to download a card
for a child partner of type `other` having no name.
To reproduce this issue:
1) Install `Contacts`
2) Create a record in `Contact & Addresses` of type as `Other Addresses`
in an existing contact
3) Now open the above-created contact
4) Download the Vcard for that record
Error:-
```
AttributeError: 'bool' object has no attribute 'replace'
```
As you can see name is only required when the type is 'contact'.
When the user creates a partner record without a name and tried to download the Vcard, it led to a traceback.
Because the name was used in the Vcard, which is false in this case. https://github.com/odoo/odoo/blob/6abe8da981e10f56eb50d07e8c53dcf97422f0c4/addons/web/models/res_partner.py#L30
**Note:-**
Also in the below line, `/web_enterprise/partner/<model("res.partner"):partner>/vcard`
route was never used anywhere in the Odoo except in one test case.
which was also introduced from the same PR through which the above route was added.
Because `Vcard` was initially in `enterprise` and later shifted to `community`.
https://github.com/odoo/odoo/blob/6abe8da981e10f56eb50d07e8c53dcf97422f0c4/addons/web/controllers/vcard.py#L16-L17
This commit will resolve this issue by taking the `complete name`
when the partner record failed to provide the name.
sentry-5673082917
Forward-Port-Of: odoo/odoo#176166