Search
Navigate
Branch
Saturday, September 28, 2024
107 changes
6 changes
Miscellaneous changes
When asking for website text replacements to IAP, a timeout of 20 seconds was set. Meaning that after 20 seconds, the user waited for no reason as texts won't be replaced for him (but will be for the next user, using the cache, if still valid). This commit increases that 20 seconds value to 45 seconds. While testing, this 20 seconds timeout is really annoying and from a functional point of view, waiting an extra 25 seconds (at worst) for a much greater chance of having text replacements seems
Original PR description
When asking for website text replacements to IAP, a timeout of 20 seconds was set. Meaning that after 20 seconds, the user waited for no reason as texts won't be replaced for him (but will be for the next user, using the cache, if still valid). This commit increases that 20 seconds value to 45 seconds. While testing, this 20 seconds timeout is really annoying and from a functional point of view, waiting an extra 25 seconds (at worst) for a much greater chance of having text replacements seems acceptable. This will be even more true with the 18.0 new waiting screen which is nicer. Also, it might just be needed to increase that timeout as we may increase the overall delay a bit in future updates to have better quality text replacements. Forward-Port-Of: odoo/odoo#181901
### Steps to reproduce 1. Install `l10n_se`. 2. Switch to a Swedish company. 3. Create and confirm a vendor bill with a price of 200, applying the preconfigured 25% purchase tax. 4. Create and confirm a customer invoice with a price of 200, applying the preconfigured 25% sales tax. 5. Open the tax report. ### Expected behavior - Fält 48 (Input VAT) = 50 - Fält 49 (Output VAT - Input VAT) = 50 - 50 = 0 ### Issue - Input VAT is incorrectly negated, resulting in Fält 48 = -50.
Original PR description
### Steps to reproduce 1. Install `l10n_se`. 2. Switch to a Swedish company. 3. Create and confirm a vendor bill with a price of 200, applying the preconfigured 25% purchase tax. 4. Create and confirm a customer invoice with a price of 200, applying the preconfigured 25% sales tax. 5. Open the tax report. ### Expected behavior - Fält 48 (Input VAT) = 50 - Fält 49 (Output VAT - Input VAT) = 50 - 50 = 0 ### Issue - Input VAT is incorrectly negated, resulting in Fält 48 = -50. - Consequently, Fält 49 is incorrectly calculated as 50 - (-50) = 100. - Additionally, the total for Block G does not match the value in Fält 49. opw-4008171 Enterprise PR: odoo/enterprise#70844 Forward-Port-Of: odoo/odoo#181859 Forward-Port-Of: odoo/odoo#181747
Adding pages to a notebook is required in a few l10n, so providing it by default will help avoid issues when adding pages. An empty notebook does not show, so it should be fine to have it there. Task id # 3639230 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179258
Original PR description
Adding pages to a notebook is required in a few l10n, so providing it by default will help avoid issues when adding pages. An empty notebook does not show, so it should be fine to have it there. Task id # 3639230 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179258
Load taxes in an end script when all modules are loaded ``` Traceback (most recent call last): File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1313, in preload_registries registry = Registry.new(dbname, update_module=update_module) File "<decorator-gen-16>", line 2, in new File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked return func(inst, *args, **kwargs) File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 114, in new o
Original PR description
Load taxes in an end script when all modules are loaded ``` Traceback (most recent call last): File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1313, in preload_registries registry =…
Load taxes in an end script when all modules are loaded
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1313, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 114, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 476, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 364, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 232, in load_module_graph
migrations.migrate_module(package, 'post')
File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 240, in migrate_module
migrate(self.cr, installed_version)
File "/home/odoo/src/odoo/17.0/addons/l10n_uk/migrations/1.1/post-migrate.py", line 7, in migrate
env['account.chart.template'].try_loading('uk', company)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 153, in try_loading
return self._load(template_code, company, install_demo)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 212, in _load
self._post_load_data(template_code, company, template_data)
File "/home/odoo/src/odoo/17.0/addons/l10n_uk/models/template_uk.py", line 38, in _post_load_data
result = super()._post_load_data(template_code, company, template_data)
File "/home/odoo/src/enterprise/17.0/account_reports/models/chart_template.py", line 31, in _post_load_data
company._get_and_update_tax_closing_moves(fields.Date.today(), include_domestic=True)
File "/home/odoo/src/enterprise/17.0/account_reports/models/res_company.py", line 163, in _get_and_update_tax_closing_moves
report, tax_closing_options = tax_closing_move._get_report_options_from_tax_closing_entry()
File "/home/odoo/src/enterprise/17.0/account_reports/models/account_move.py", line 264, in _get_report_options_from_tax_closing_entry
report_options = tax_report.with_context(allowed_company_ids=company_ids).get_options(previous_options=options)
File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 1670, in get_options
initializer(options, previous_options=previous_options)
File "/home/odoo/src/enterprise/17.0/account_reports/models/account_report.py", line 1619, in _init_options_custom
self.env[custom_handler_model]._custom_options_initializer(self, options, previous_options)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 534, in __getitem__
return self.registry[model_name](self, (), ())
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 213, in __getitem__
return self.models[model_name]
KeyError: 'l10n_uk.tax.report.handler'
```
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#181154[REV] l10n_pl: Credit note can be more than the invoice total amount This is a revert for PR https://github.com/odoo/odoo/pull/168252 Reason: The law allow the credit note to be more than the invoice total amount according to the user input task-3965527 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181854
Original PR description
[REV] l10n_pl: Credit note can be more than the invoice total amount This is a revert for PR https://github.com/odoo/odoo/pull/168252 Reason: The law allow the credit note to be more than the invoice total amount according to the user input task-3965527 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181854
in appraisal, the method `_check_validity` is overriden to make different checks in case of `answer_wrong_user`, to make sure that all the checks are OK before handling `answer_wrong_user` case the deadline check should be done before the user check. opw-4128638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179270
Original PR description
in appraisal, the method `_check_validity` is overriden to make different checks in case of `answer_wrong_user`, to make sure that all the checks are OK before handling `answer_wrong_user` case the deadline check should be done before the user check. opw-4128638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179270
3 changes
Miscellaneous changes
We improve the cards of the kanban view of approval rules: - we display the field exclusive_user as an icon (if set) - we add some titles - we put the button "Delegate" on the left - we set the field approver_ids to be readonly Forward-Port-Of: odoo/enterprise#70906
Original PR description
We improve the cards of the kanban view of approval rules: - we display the field exclusive_user as an icon (if set) - we add some titles - we put the button "Delegate" on the left - we set the field approver_ids to be readonly Forward-Port-Of: odoo/enterprise#70906
91 changes
Security fixes and vulnerability patches
Project document folders no longer expose link-only documents to anonymous visitors through the project portal. This closes an access loophole so document permissions are consistently enforced for signed-in users only.
Original PR description
Inside the document folder of a project, create a new folder that is access_internal='view' and access_via_link='none'. Inside that folder create a document that is access_via_link='view'. From the…
Implement support for the generation of EFT files following the requirement of the most popular banks in New Zealand Task id # 3639230 Forward-Port-Of: odoo/enterprise#70990 Forward-Port-Of: odoo/enterprise#69494
Original PR description
Implement support for the generation of EFT files following the requirement of the most popular banks in New Zealand Task id # 3639230 Forward-Port-Of: odoo/enterprise#70990 Forward-Port-Of: odoo/enterprise#69494
Issue 1: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - the employee can answer after the deadline Problem: -------- the method `_check_validity` was overriden in `hr_appraisal_survey` module to do different checks than the original method in `survey` module in case of `validity_code = answer_wrong_user`, but this override bypasses the other checks in the original method like the deadline check. Solution: --------- call
Original PR description
Issue 1: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - the employee can answer after the deadline Problem: -------- the method…
Issue 1: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - the employee can answer after the deadline Problem: -------- the method `_check_validity` was overriden in `hr_appraisal_survey` module to do different checks than the original method in `survey` module in case of `validity_code = answer_wrong_user`, but this override bypasses the other checks in the original method like the deadline check. Solution: --------- call the original method `_check_validity` in the override, to make sure all the checks are done, then if the original method returns `validity_code = answer_wrong_user` we can do our specific checks. Issue 2: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - manager can't see the answers after the deadline Problem: -------- - to display answer in appraisal module we rely on the url of the survey that contains the tokens for suervey/answer - the deadline handling is done in the survey module where the url is dead after the deadline which is not suitable for the appraisal module Solution: --------- - override the method `_get_access_data` and bypass the deadline check in case of appraisal feedback for manager. opw-4128638 Forward-Port-Of: odoo/enterprise#69502
Inside the document folder of a project, create a new folder that is access_internal='view' and access_via_link='none'. Inside that folder create a document that is access_via_link='view'. From the Documents application standpoint, you created a document that cannot be discovered by a public user, unless he get the access-token to that file. But you can access the file via the Project's documents even without the access token, because the conditional `res_id`, `res_model`, `access_via_link` are met. It means that if you're a logged-in portal user you won't see that file as the `user_permission` is correctly `none`. But you can disconnect, become a public user, and get access to the file. --- An explored solution was to create a dedicated "shared" folder for every project/task, and to place all publicly discoverable files within that folder. Files that should be shared on a link-only manner would be placed elsewhere would not be listed but for the portal users. This solution was rejected because it created too many folders. --- The solution here is to restrict accessing documents to logged-in users, so that the single always-valid `user_permission` field can be used and there's no need to re-engineer something for public users.
Enhancements to existing features
The Nano website theme now uses a stronger orange and darker grey palette while keeping its existing visual identity. This makes page content stand out more clearly and supports the ongoing redesign toward a higher-contrast look.
Original PR description
This PR fine-tunes the `primary` and `dark` color of the `theme_nano`. As part of the `theme_nano` redesign, the color palette has been adjusted to a `high-contrast` style. The colors remains in the same tones (orange and dark grey) but are more saturated, to emphasis the content of the theme. task-4178081 part of task-4177975 - requires https://github.com/odoo/design-themes/pull/935 | Master | This PR | |--------|--------| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website theme previews can now correctly display highlighted text using the same simplified content format used in theme customizations. This helps business users see more accurate snippet and new page template previews before adding them to a website.
Original PR description
A highlighted text has the following structure: ``` <span class="o_text_highlight o_text_highlight_[highlightId]" style="--text-highlight-width: ...; --text-highlight-color: ...;"> <span…
A highlighted text has the following structure:
```
<span class="o_text_highlight o_text_highlight_[highlightId]"
style="--text-highlight-width: ...; --text-highlight-color: ...;">
<span class="o_text_highlight_item">
text content (line 1) ...
<svg.../>
</span>
[<br/>]
<span class="o_text_highlight_item">
text content (line 2) ...
<svg.../>
</span>
...
</span>
```
Which is saved in a minimal format that allows the JS code to rebuild
the SVGs when it's needed:
```
<span class="o_text_highlight o_text_highlight_[highlightId]"
style="--text-highlight-width: ...; --text-highlight-color: ...;">
text content ...
</span>
```
The goal of this commit is to use the simplified format for theme
customizations and adapt the code from the "Snippets Preview" and the
"New Page Templates Preview" to be able to build the highlights using
this format when provided in XML.
PR (DT):https://github.com/odoo/design-themes/pull/956
task-4215788This update adjusts Odoo 18 dependency requirements to match supported Ubuntu and Debian distribution versions. It helps ensure smoother installation and maintenance on the intended server platforms.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLAFOUTIS
When users filter bills by Next Payment Date and start a payment, Odoo now includes all installments due up to that selected date instead of requiring them to change the payment date. This makes scheduled installment payments more intuitive and avoids workarounds that could distort the actual payment date.
Original PR description
The idea is that if a user uses a filter on "Next Payment Date", when he pays, he would expect to pay everything that he needs until this date. For instance, imagine a bill with 3 installments. One that was at the end of last month, one for the end of this week and one in 2 months. You want to pay everything for the end of the week, and make the payment today. Currently, the only way to do so would be to change the payment date (to make them overdue), but that's not the same thing. To solve this, we rely on the context to know if it was in the search domain, and then pay everything up to this date. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now preserves more context when opening records through JSON links across views such as kanban, graph, pivot, calendar, and activity. This helps users land on screens with the right filters, domains, and default values, making shared or redirected links more reliable.
Original PR description
Handle additional parameters like the domain and default values from multiple view types: kanban, graph, pivot, calendar, activity. The code is moved to a separate file because it is a specific feature of Odoo and should not be in the same file as the default `/odoo` route. task-3987268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Updated sample company and contact records used in demos, including lunch vendors, applicant details, and event attendee names. This makes demonstration data clearer, more realistic, and less confusing for users evaluating or testing Odoo.
Original PR description
Specifications =============== - Set Sushi shop, The Corner, Coin gourmand, and Pizza Inn as a company - Added a random pizza logo in Pizza inn partner and updated its info - https://tinyurl.com/23qkls8a . - Updated applicant: Owen James, email: owen@yahoo.example.com. - Deleted confusing contact, and replaced with correct Marc demo as needed. - Renamed attendee name in event registration - https://tinyurl.com/2be83fdk Task-4190486
The default Contact Us form layout has been updated to make it clearer and easier to read. This improves the first-use website experience by presenting the form in a more structured way for visitors.
Original PR description
This commit makes the default structure of the form in the contact us page more readable and structured. task-4203857 | Before | After | |--------|--------| | <img width="1350" alt="Screenshot 2024-09-23 at 13 49 10" src="https://github.com/user-attachments/assets/6da22b0e-a186-411c-808a-463431ba3cd1"> | <img width="1303" alt="Screenshot 2024-09-23 at 13 50 05" src="https://github.com/user-attachments/assets/79c43425-a7c6-45e8-b05f-759ea6889263"> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Emoji search now takes recently used emojis into account, so people are more likely to see their preferred options near the top. This makes emoji selection faster and more personalized in everyday communication.
Original PR description
before commit: prior to this commit, recent emojis were not considered in the search. after commit: Updated search to include recent emojis, making them more prominent based on the search term. task-4144979
New databases now show ready-made sample dashboards instead of empty charts and tables, helping users quickly understand the value of the dashboard app. Sample content is added across sales, invoicing, events, expenses, live chat, point of sale, restaurant, and timesheet-related dashboards when no real business records exist yet.
Original PR description
Currently, users with an fresh empty database will only see empty dashboards. They will go through a list of empty tables and charts without any data and probably miss the potential of the dashboard app. For a proper onboarding experience, they should be greeted with a sample dashboard to give them a better idea of the dashboard look and use. Technically, we store sample json files to be used when the main model (the model that is used the most in the dashboard) has no records. task-3947773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Selected tags now appear in bold in tag dropdowns and the "Search more" dialog. This makes it easier for users to see which options are already chosen and reduces selection mistakes.
Original PR description
Before this commit, the user could not see the selected tags in the dropdown nor the "Search more" dialog. This commit makes the tags bold in the dropdown and in the "Search more" dialog. task-3919307
Approval rule cards in Studio now present key details more clearly, including an icon for exclusive approvers and added labels. The Delegate button is easier to find, and approver lists are protected from accidental edits in this view.
Original PR description
We improve the cards of the kanban view of approval rules: - we display the field exclusive_user as an icon (if set) - we add some titles - we put the button "Delegate" on the left - we set the field approver_ids to be readonly
Demo contact records were cleaned up across several apps by merging duplicates, marking organizations correctly as companies, updating locations, logos, and profile pictures. This improves the consistency and realism of sample data used in demonstrations and testing without changing core business workflows.
Original PR description
Specifications =============== - Deleted Aaron Zhu partner and used the existing partner. - Updated US package contacts (e.g., Colorado Department of Revenue, Aurora Finance Department) as companies. - Set ONSS as a company and updated its logo - https://tinyurl.com/22gtcm3w. - Changed the applicant's city to Springfield or equivalent - https://tinyurl.com/27ga6hee. - Merged specified contacts - https://tinyurl.com/2dmbepvx. - Updated several contacts to companies. https://tinyurl.com/25ey7np9 https://tinyurl.com/26rfhg9q https://tinyurl.com/2crn66qg - Updated contacts from planning by adding pictures. Task-4190486
Odoo can now synchronize currency exchange rates using the Bank of Thailand service. This helps businesses operating with Thai baht keep rates up to date automatically, using the most recent available rate from the previous day.
Original PR description
Adds the possibility to synchronize exchange rates using the API provided by the Bank Of Thailand (BOT). Rates are synchronized using yesterday as a date, as they do not provide rates for the current day. Task id # 3724438
New users starting with an empty database will now see sample dashboards instead of blank charts and tables. This helps them understand the value and layout of the dashboard app during onboarding, with examples across accounting, CRM, HR, helpdesk, marketing, manufacturing, and related dashboard areas.
Original PR description
Currently, users with an fresh empty database will only see empty dashboards. They will go through a list of empty tables and charts without any data and probably miss the potential of the dashboard app. For a proper onboarding experience, they should be greeted with a sample dashboard to give them a better idea of the dashboard look and use. Technically, we store sample json files to be used when the main model (the model that is used the most in the dashboard) has no records. task-3947773
Resolved issues and error corrections
This update fixes an issue that could prevent the add-to-cart notification from displaying correctly on the website shop. Customers should now get smoother feedback when adding products to their cart, reducing confusion during checkout preparation.
Original PR description
Owl doesn't accept `null` values for optional props, so we should omit the prop instead of providing a `null` value.
This fixes an error that could occur after a user was granted an exception to remove a sales lock date. Users can now create or edit invoices with dates before the former lock date without encountering a traceback, improving reliability for accounting workflows.
Original PR description
In commit d8bf86fec7b9a0a3f6e0aef2c4c124bc81bfb898 we allowed removing lock dates with an exception.
But when computing the user lock date based on (parent) company lock dates and user exceptions (`_get_user_lock_date`) we still assume that it is not possible.
This is fixed in this commit.
Reproduce traceback
1. Set Sale Lock Date to 2024/08/31
2. Remove Sale Lock Date with an exception for me forever
3. Create an invoice and try to set the invoice date to a date
before 2024/08/31This fixes an issue where the website editor button for loading product categories into mega menus did not correctly trigger category fetching. Website managers can now reliably populate shop navigation menus with categories, improving setup consistency for online stores.
Original PR description
With previous commit f354cb8794c9fd2b5183e520ce292adbe547ba4c, a new feature was introduced to be able to load categories to your mega menu however there was a bug that the button was not synced to fetching the categories Backport of https://github.com/odoo/odoo/pull/181075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue in the website shop where information used by the page was not available in the right place. It helps ensure shopping pages render reliably and prevents minor display or checkout-related disruptions for customers.
Original PR description
A variable was initialized in a subtemplate but read both in the subtemplate and outside of it. It needs to be declared outside of the subtemplate in order to be readable there.
Discount lines in sales loyalty flows no longer show an extra “Discount:” label when no taxes apply. This avoids redundant wording because the product name already identifies the discount, making sales order descriptions clearer for users.
Original PR description
Issue: - When applying a discount without taxes, a 'Discount:' label is shown in the description field, even though the product name already indicates the discount. Fix: - The 'Discount:' description is now suppressed when there are no taxes applied. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error in automated warehouse wave processing caused by grouping items using a field that was not available in that process. It helps ensure picking batches can be created reliably without failing on invalid product category references.
Original PR description
auto_wave do a reference to `product_categ_id`. It only exists on `stock.quant` and not `stock.move.line`. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The cart page now respects mandatory sign-in settings by hiding express checkout for visitors who are not logged in. This prevents shoppers from bypassing required account creation and keeps the checkout flow consistent with the store's policy.
Original PR description
Issue: - When the 'Sign in/up at checkout - mandatory' option is enabled, the 'Express Checkout' button is still visible on the cart page even when the user is not signed in. This causes an inconsistency, as express checkout bypasses the mandatory creation of portal account, which should not be allowed in this mode. Fix: - Added a condition at the t-call of express checkout template to ensure that it is hidden when mandatory sign-in at checkout is activated and user is not signed in. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Creating a task from the website form no longer fails when optional company or phone details are left blank. This prevents users from seeing an error page and helps ensure submitted requests are captured reliably.
Original PR description
Currently, when a user creates a task through the webform without providing a company or phone, a traceback occurs.
Technical details:
- The issue arises when trying to access a key that doesn't exist in a dictionary.
- Example: `test = {'a': 1}`, accessing `test['b']` results in a KeyError.
Solution:
- Replaced direct dictionary access with the `get` method to handle missing keys gracefully.
task-4207886Printing POS session reports with per-employee details no longer gets stuck or disconnects. The reports are now generated one after the other, ensuring both downloads complete reliably and the print dialog closes correctly.
Original PR description
Steps: - Activate 'login with employees' in settings - Open PoS - Make sales and switch between different employees - Close session - Go to reporting, click on Session Report - Check the box "add a report per each employee" - Click on print, if the report layout wizard comes up, print the report. - Again try to print the report. Issue: Stuck on loading then the connection gets lost Cause: Try to process two async requests parallelly to download reports "session report" and "session report per employee" causing them to get stuck on loading then the connection lost FIX: Instead of trying to process two async requests parallel, we will wait for first one to complete then execute the second one. task - 4191502
Project purchase orders now include orders linked through line-level analytic distributions, so project views show a more accurate purchase count. The update also prevents purchase order project changes from overwriting existing line distributions and improves expense analytic allocation when reinvoicing customers.
Original PR description
Steps to reproduce: ------------------- 1. From the Purchase app, create a purchase order (don't link it to any project with the project field) 2. Add a line on the PO with a distribution 3. On the…
Steps to reproduce:
-------------------
1. From the Purchase app, create a purchase order (don't link it to any project with the project field)
2. Add a line on the PO with a distribution
3. On the line, add the project's analytic account
4. Go to the Project > Top bar > Purchase Orders > The new purchase order is not there
Fix:
-------------------
We should take into account the purchase orders whose lines have an analytic distribution corresponding to the project. We will do a second _read_group() call for that purpose.
- Others fixes: - Still in Purchase app, when changing the project_id of the PO, it changes the analytic distribution of all PO lines (including PO lines with non-empty distribution). To be consistent with SO and SO lines, it should only affect PO lines that do not have their analytic distribution set.
- In Expenses app, when changing the 'Customer to Reinvoice' field of an expense, it should automatically fill in the analytic distribution of the expense with the account
of the project of the sale order linked to the 'Customer to Reinvoice'. The problem is that it does not systematically change the analytic distribution if such account exists.
- When creating an expense from the top bar action, and changing the distribution of the expense (the percentage for instance), it does not get saved on saving the record.
task-4191106
version-18.0
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prKanban cards now show their configured color indicator even when the color field is not explicitly included in the view setup. This restores expected visual cues in Planning and helps users quickly distinguish cards by status or category.
Original PR description
Kanban cards can be colored (their left border) dynamically by using the root attribute `highlight_color="color"`, where `color` is the name of the integer field to use as color field. However, before this commit, this required the given `color` to be also defined in the arch, otherwise it wouldn't have been fetched, and no card would be colored. With this commit, we automatically fetch the highlight_color field. This fixes a bug in planning where colors weren't displayed. Task~4215979 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
This update fixes how the website handles modern language code formats in the SEO dialog. It prevents errors when editing or generating SEO information for multilingual websites and keeps behavior consistent across Odoo versions.
Original PR description
[1] fixed the correct application of jsToPyLocale and pyToJsLocale conversions due to the new language code format used in the front-end and was forward-ported to master in [2]. The goal of this commit is to backport [2] to ensure the same API is used in both v.18 and master. [1]: https://github.com/odoo/odoo/commit/2cd53220c39f897c346b8174ac65b5dbd950b67f [2]: https://github.com/odoo/odoo/commit/b012952e511f6ec70218d2fd5ead3cb93a2afd9f task-4210172
Manufacturing order overviews now calculate operation costs more accurately when no expected duration was set. Once production starts or is completed, costs use the real recorded duration for machine and labor time, giving businesses a clearer view of actual manufacturing costs.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product pages no longer fail when the specifications section is empty. This prevents a broken interaction on ecommerce product pages and keeps the shopping experience stable.
Original PR description
Issue: when the product specifications are empty, the `#product_accordion` exists without an `.accordion-item` which fails the `._updateAccordionActiveItem` function. follow-up of task-3987039 task-4215477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes broken navigation arrows in website image gallery slideshows used inside page templates. Visitors can once again move through gallery images as expected, restoring the intended browsing experience.
Original PR description
Since the redesign of `s_image_gallery` in commit 9042b1cae7b630b20e0670788b7a4ed9e4c97609, the arrow anchors has been changed and no longer work in slideshows that are in page templates. To fix this issue, this commit reintroduces the previous ID. task-4215411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes the point-of-sale restaurant tip screen test reliable when orders appear in a different order. It reduces false test failures, helping maintain confidence in the checkout and tipping flow without changing customer-facing behavior.
Original PR description
Fix tests checks, the test 05_tip_screen_tour.js was failing because the order of orders can vary, so we need to change the check to prevent error related to the order of the orders. rb error: 99346
The chatter search panel no longer shows a duplicate search icon above the search bar. This cleans up the interface and avoids confusion when users search messages in chatter.
Original PR description
**Current behavior before PR:** On clicking the search button on chatter. Extra search icon appears above the search bar **Desired behavior after PR is merged:** now after clicking search button on chatter extra icon is removed. task-4206791 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a point-of-sale restaurant issue where moving an order from one table to another could leave one item behind. Staff can now transfer full table orders reliably, reducing billing mistakes and service delays.
Original PR description
Steps to reproduce : --------------------------- - Install the pos_restaurant module. - Place orders on two separate tables, e.g., Table A and Table B. - Use the action button to transfer the order from Table A to Table B. Issue : --------- The last orderline of the table from where we transfer to another table is not transfered to destination table when there is any orderline having different product which is not present in any of the orderlines of the destination table. Cause : ---------- The for loop on orderlines modifies the orderline reference during iteration, causing the loop to skip some lines because the order.lines is altered mid-iteration. Fix : ------ Intead of updating within iteration we will update all lines after completion of the iteration.
The point of sale employee sales report no longer shows duplicate sales entries in session reports, making totals clearer and more reliable. The employee sales details report was also renamed for easier identification.
Original PR description
before this commit: ============== - session sales report was displaying duplicate values. after this commit: ============== - removed duplicate entries from print session sales report - renamed the employee sales details report. task - 4143903
This fix makes invoice payment statuses update correctly when payments are created, confirmed, validated, reconciled, or rejected. Customers now see consistent portal labels such as “Processing payment,” with installment prompts hidden when a payment is already in progress.
Original PR description
Fix the status of invoices when registering a payment. Also improves the portal view depending on the invoice payment state. The following cases assume that no outstanding account is set on the bank…
Fix the status of invoices when registering a payment. Also improves the portal view depending on the invoice payment state. The following cases assume that no outstanding account is set on the bank journal Portal: - In case the invoice payment state is 'in payment', the portal should display "Processing payment", the "Next installment" section should be hidden, and a banner should appear in the popup of the payment (when pressing the "Pay Now" button). Portal list view: - Same payment state should be displayed as in the portal form view, e.g. "Processing Payment" Invoice Payment state: - If a payment is created for an invoice, then the state of the invoice is set to 'in payment' When the invoice is reconciled, and the payment is manually validated (This manual operation of validating the payment will be made automatically in another task) if the payment corresponds to a portion of the invoice amount, the invoice payment state is 'Partial' if the payment corresponds to the full invoice amount, the invoice payment state is 'Paid' If the payment is rejected, then the invoice payment state is reset If the payment is confirmed (before any reco), then the invoice payment state keeps being "in payment" task-4212954 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The debug menu item for viewing raw record data now behaves as it did before, while keeping its updated name. This avoids exposing the option in places like list or kanban views where it was not intended, reducing confusion for users and support teams.
Original PR description
In the PR [1], the behavior of the "View Raw Record Data" debug item changed. It opened the /json route of the current view and it was also available in multi record views (list, kanban, etc.). This commit reverts this behavior change but keeps the renaming. task-4055746 [1]: https://github.com/odoo/odoo/pull/180141
The checkout address page no longer shows a sign-in prompt when sign-in or sign-up at checkout has been disabled. This keeps the checkout experience aligned with the store’s configured customer account policy and avoids confusing shoppers.
Original PR description
Issue: - When 'disabled' option is selected for Sign in/up at checkout, sign-in prompt is still showing on address page. Fix: - Updated the t-if condition to ensure that the sign-in prompt is no longer displayed when the 'disabled' option is selected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Livechat visitors will no longer see their own country flag displayed in the conversation header after sending a message. The flag is now limited to the operator side, reducing unnecessary exposure of visitor location details and keeping the customer-facing chat interface cleaner.
Original PR description
Before this commit, when a visitor posts a message in livechat, the header was showing their country flag. Steps to reproduce: - log in as Mitchell Admin as available operator - log in as Joel Willis (portal user, on another browser context) - open a livechat as Joel and send a message => Country of joel "USA" is visible in header This happens because it was always showing `anonymous_country` when available, which is the visitor country. This commit fixes the issue by limiting the showing of the country flag to the operator of livechat conversation. Before / After  
Portal users can now fold categories in the Discuss sidebar without causing a crash. This keeps the public page experience stable by avoiding an action that only internal users are allowed to save.
Original PR description
The discuss sidebar was recently added to the public page. The state of the sidebar (folded categories) is saved for internal users. Guests and portal users do not have the rights to do this. However, it was only disabled for guests. As a result, folding a category as a portal user would lead to a crash. This PR fixes this issue.
This update improves how taxes are calculated and displayed when prices include tax, especially where rounding can affect invoice totals. It also keeps tax calculation naming consistent between accounting and point of sale, while preserving correct handling for reverse charge taxes.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
SEPA credit transfer files no longer include duplicate issuer or LEI identifier entries. This helps prevent payment file validation issues and reduces the risk of bank rejections caused by repeated information.
Original PR description
Issr and LEI nodes were added twice, because they were handled both in the generic ISO20022 code and the SEPA Credit Transfer override.
Fixed an issue where batch validation and export buttons could stay hidden for bank journals without payment initiation configured when online payments were installed. This ensures accounting teams can validate and export batch payments from the affected journals as intended.
Original PR description
Before this commit, when account_online_payment was installed and no payment initiation was configured on a bank journal, the batch validation and export buttons never appeared on the batch payments made on this journal.
SEPA direct debit batch validation now handles missing setup information more gracefully, such as absent mandates or creditor identifiers. Users receive clearer, better-timed error messages instead of system crashes, making payment batch preparation easier to correct.
Original PR description
[IMP] account_sepa_direct_debit: better sequence of error messages The check validating the collection date was made before we've checked all mandates are in the right state, yet it depended on the…
[IMP] account_sepa_direct_debit: better sequence of error messages
The check validating the collection date was made before we've checked all mandates are in the right state, yet it depended on the mandates to check the minimum collection date available for this batch. We now make it so we first check all the mandates are valid, for usability.
===================================================
[FIX] account_sepa_direct_debit: Don't crash when validating a batch when the company has no creditor identifier
A check for that already existed in validate_batch, raising an error, but it wasn't called in time, and this caused a traceback because the super call had been moved at the beginning of the function.
===================================================
[IMP] account_sepa_direct_debit: clearer error message
===================================================
[FIX] account_sepa_direct_debit: don't crash when trying to generate a batch containing a single SDD payment without mandate
To reproduce:
1) Create a payment for some new partner, using SEPA Direct Debit. Make sure no mandate exists for this partner.
2) Add the payment created in 1 into a new batch. It must be the only payment in it
3) Try validating the batch
====> Traceback
This is because the query checking which mandates are used for the first time receives an empty tuple for its "mandate_ids" parameter. SQL tries to run "... IN ()", which crashes.
After fixing this bug, the same flow still crashes because we're trying to call max() on an empty sequence in validate_batch in order to compute the pre_notification_period. We fix that by adding a new check in order to redirect the user in case some payments of the batch are missing a mandate.This update corrects problems when registering SEPA Direct Debit payments, especially when creating payments for multiple customers at once. It also improves mandate visibility and ensures collection dates account for payments that are already fully paid, reducing payment processing errors.
Original PR description
This fixes issues that arose in 6aa473d, including: - Payments creations in batch from the list view do not handle the multiple partners case - The blue "Valid mandate available" banner does not show when you're not already using the SDD payment method
The trial balance report now opens correctly when horizontal groups are configured. This prevents users from hitting an error screen and keeps financial reporting accessible in affected setups.
Original PR description
Steps to reproduce - Create a horizontal group - open the trial balance -> Traceback Cause of the issue: a None value is set in the 'no_format' key of a line of the report.
Manufacturing order operation costs are now calculated more accurately when production starts or finishes without an expected duration. This improves cost reporting by using actual duration and the relevant machine, labor, and workcenter employee costs where appropriate.
Original PR description
This commit modifies the MO cost of operations. Now, when the production is started and if there is no duration expected on the operation, the mo cost of the operation will be the theorical cost of the real duration (i.e. it will be the result of machine + labour cost for that duration). When the production is done, the same behaviour will be applied, but without the labour cost. The timesheet cost of an operator for the MO cost column is now computed based on the operation's workcenter employee cost.
This fix ensures document access updates run correctly when performed with elevated system rights. It prevents permission checks from incorrectly blocking internal access updates, improving reliability for document sharing and membership changes.
Original PR description
Purpose ======= Skip user permission check, when calling `_action_update_access` in SUDO, like it has been done for `_action_update_members`
Portal users can now preview documents without the Documents portal crashing. This fix improves reliability for external users accessing shared documents.
Original PR description
The commit prevents the Documents portal from crashing when portal users try to preview a document. We prevent the client from raising an error when trying to access an undefined available embedded actions records (not available for portal users.) task-3373836
Subscription sales orders now show only one Create Invoice button after confirmation. This reduces confusion for users and helps keep the invoicing workflow clear and consistent.
Original PR description
Version: - 18.0 Steps to reproduce: - create a subscription sale order - confirm the sale order Issue: - two create invoice button are visible Cause: - The conditions for showing the two "Create Invoice" buttons overlapped, making both appear at the same time Solution: - Adjusted button conditions to ensure only one "Create Invoice" button is displayed when no invoice is created
This fixes an error that could occur when validating multiple payment batches at once. SEPA direct debit batches are now checked correctly, helping prevent failed payment processing workflows.
Original PR description
_check_minimal_collection_date is written in a way where it will break if multiple batches are in self. We fix this by changing the way we check if the constrains should run: we will check the batches in self and only run it if any batch is a sepa batch; and only run it with these.
Reloading an open spreadsheet in Documents no longer sends users back to the main Documents view. This keeps users in the spreadsheet they were working on and avoids workflow interruption.
Original PR description
Steps to reproduce: - open a spreadsheet - reload the page => you're redirected to the main Documents kanban view The url of a spreadsheet looks like `http://localhost:8069/odoo/documents/spreadsheet/26` The code here thinks `spreadsheet/26` is a document access_token
Publicly shared spreadsheets now reload with the latest saved changes instead of reverting to the original empty or outdated version. This prevents viewers using a shared link from seeing missing content after the owner leaves the spreadsheet, improving reliability for shared documents.
Original PR description
Steps to reproduce: - (as an internal user) - create a new empty spreadsheet - do a couple of changes - Share the spreadsheet Anyone with the link: Viewer - open the link in an new incognito tab - (everything fine at this point) - now, leave the spreadsheet in the backend - reload the public spreadsheet page => everything disapeared When the internal user leaves the spreadsheet, a new snapshot is created and pending revisions are archived. When the public user reloads, the data comes from the field `spreadsheet_data` which is the initial data (not the latest snapshot) and doesn't get any revisions (they are archived) I also added a test which gets pending revisions.
Saving a new favourite view from the Project control panel no longer triggers an error. This helps users save their preferred task views reliably without interruption.
Original PR description
…in the control panel When saving a new favourire view from the control panel a traceback would appear. It was because the domain was not parsed correctly in search_model.js when calling the getDomain method from the _getIrFilterDescription method. It was not parsed correctly because 2 parameters given to the method were lost because the getDomain method was overwritten in HighlightProjectTaskSearchModel. After passing the parameters to the super call inside the overwritten getDomain method, the traceback is fixed. task-4207512
Miscellaneous changes
in appraisal, the method `_check_validity` is overriden to make different checks in case of `answer_wrong_user`, to make sure that all the checks are OK before handling `answer_wrong_user` case the deadline check should be done before the user check. opw-4128638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179270
Original PR description
in appraisal, the method `_check_validity` is overriden to make different checks in case of `answer_wrong_user`, to make sure that all the checks are OK before handling `answer_wrong_user` case the deadline check should be done before the user check. opw-4128638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179270
Following 8b9bd6f88eb313dd29b05fc2decff77e6aff8bb8 Add a unit test to cover the UV flag for the webauthn protocol. Forward-Port-Of: odoo/odoo#181869
Original PR description
Following 8b9bd6f88eb313dd29b05fc2decff77e6aff8bb8 Add a unit test to cover the UV flag for the webauthn protocol. Forward-Port-Of: odoo/odoo#181869
Adding pages to a notebook is required in a few l10n, so providing it by default will help avoid issues when adding pages. An empty notebook does not show, so it should be fine to have it there. Task id # 3639230 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179258
Original PR description
Adding pages to a notebook is required in a few l10n, so providing it by default will help avoid issues when adding pages. An empty notebook does not show, so it should be fine to have it there. Task id # 3639230 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179258
[REV] l10n_pl: Credit note can be more than the invoice total amount This is a revert for PR https://github.com/odoo/odoo/pull/168252 Reason: The law allow the credit note to be more than the invoice total amount according to the user input task-3965527 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181854
Original PR description
[REV] l10n_pl: Credit note can be more than the invoice total amount This is a revert for PR https://github.com/odoo/odoo/pull/168252 Reason: The law allow the credit note to be more than the invoice total amount according to the user input task-3965527 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181854
Commit [06346b04] replaced `oe-translation-initial-sha` with `oe-translation-source-sha`. A few occurrences in the code were missed. [06346b04]: https://github.com/odoo/odoo/commit/06346b049a3a13a9a8b63a4f60151ec24fabb59e (No related task) Forward-Port-Of: odoo/odoo#180996
Original PR description
Commit [06346b04] replaced `oe-translation-initial-sha` with `oe-translation-source-sha`. A few occurrences in the code were missed. [06346b04]: https://github.com/odoo/odoo/commit/06346b049a3a13a9a8b63a4f60151ec24fabb59e (No related task) Forward-Port-Of: odoo/odoo#180996
### Steps to reproduce 1. Install `l10n_se`. 2. Switch to a Swedish company. 3. Create and confirm a vendor bill with a price of 200, applying the preconfigured 25% purchase tax. 4. Create and confirm a customer invoice with a price of 200, applying the preconfigured 25% sales tax. 5. Open the tax report. ### Expected behavior - Fält 48 (Input VAT) = 50 - Fält 49 (Output VAT - Input VAT) = 50 - 50 = 0 ### Issue - Input VAT is incorrectly negated, resulting in Fält 48 = -50.
Original PR description
### Steps to reproduce 1. Install `l10n_se`. 2. Switch to a Swedish company. 3. Create and confirm a vendor bill with a price of 200, applying the preconfigured 25% purchase tax. 4. Create and confirm a customer invoice with a price of 200, applying the preconfigured 25% sales tax. 5. Open the tax report. ### Expected behavior - Fält 48 (Input VAT) = 50 - Fält 49 (Output VAT - Input VAT) = 50 - 50 = 0 ### Issue - Input VAT is incorrectly negated, resulting in Fält 48 = -50. - Consequently, Fält 49 is incorrectly calculated as 50 - (-50) = 100. - Additionally, the total for Block G does not match the value in Fält 49. opw-4008171 Enterprise PR: odoo/enterprise#70844 Forward-Port-Of: odoo/odoo#181859 Forward-Port-Of: odoo/odoo#181747
When asking for website text replacements to IAP, a timeout of 20 seconds was set. Meaning that after 20 seconds, the user waited for no reason as texts won't be replaced for him (but will be for the next user, using the cache, if still valid). This commit increases that 20 seconds value to 45 seconds. While testing, this 20 seconds timeout is really annoying and from a functional point of view, waiting an extra 25 seconds (at worst) for a much greater chance of having text replacements seems
Original PR description
When asking for website text replacements to IAP, a timeout of 20 seconds was set. Meaning that after 20 seconds, the user waited for no reason as texts won't be replaced for him (but will be for the next user, using the cache, if still valid). This commit increases that 20 seconds value to 45 seconds. While testing, this 20 seconds timeout is really annoying and from a functional point of view, waiting an extra 25 seconds (at worst) for a much greater chance of having text replacements seems acceptable. This will be even more true with the 18.0 new waiting screen which is nicer. Also, it might just be needed to increase that timeout as we may increase the overall delay a bit in future updates to have better quality text replacements. Forward-Port-Of: odoo/odoo#181901
Before this commit, when a message has a subject different from chatter name e.g. by renaming the record while some messages have been posted prior to rename, the subject was visible in prefix of message text content. The showing of subject is good, but currently the style is almost the same as the text content, and this is put inline before the text content, so the subject looks like actual text content. This commit improves the style so the subject is clearly different from the text cont
Original PR description
Before this commit, when a message has a subject different from chatter name e.g. by renaming the record while some messages have been posted prior to rename, the subject was visible in prefix of message text content. The showing of subject is good, but currently the style is almost the same as the text content, and this is put inline before the text content, so the subject looks like actual text content. This commit improves the style so the subject is clearly different from the text content of the message, when the subject is displayed on UI. Before <img width="999" alt="Screenshot 2024-09-27 at 13 39 23" src="https://github.com/user-attachments/assets/d8a299b6-6c3c-4605-aa36-6f6d8286fdbc"> After <img width="747" alt="Screenshot 2024-09-27 at 13 33 20" src="https://github.com/user-attachments/assets/a3919213-ba08-4662-8079-894183c68536"> Forward-Port-Of: odoo/odoo#181813
*: l10n_ro_edi When a user generate a UBL XML that inherits from ubl 2.0, the Item/Description xml node will only contain the information about the product name, without any description. This commit aims at restoring the behavior before saas-17.4 and gives the full description on that XML value. To make sure it keeps this new behavior, a test was modified in l10n_ro_edi (the ticket origin) to make sure the Description display the `line.name` The change was previously introduced in http
Original PR description
*: l10n_ro_edi When a user generate a UBL XML that inherits from ubl 2.0, the Item/Description xml node will only contain the information about the product name, without any description. This commit aims at restoring the behavior before saas-17.4 and gives the full description on that XML value. To make sure it keeps this new behavior, a test was modified in l10n_ro_edi (the ticket origin) to make sure the Description display the `line.name` The change was previously introduced in https://github.com/odoo/odoo/commit/4f325ef620263c27e095eb49026a677ac617a0ee Similar fix to l10n_es_edi_facturae for reference: https://github.com/odoo/odoo/pull/180315 opw-4213014 Forward-Port-Of: odoo/odoo#181787
Previously done in commit 683deecb51e240c5cbf1fd369e0eeefb0267530d but reverted in the refactor done in commit 0279c53930735b65e9342ca66fbb62ff61ac65f6 Objective: hide placeholder images if no image is provided on product --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181780
Original PR description
Previously done in commit 683deecb51e240c5cbf1fd369e0eeefb0267530d but reverted in the refactor done in commit 0279c53930735b65e9342ca66fbb62ff61ac65f6 Objective: hide placeholder images if no image is provided on product --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181780
Currently, for other payment method options in xendit, the redirect flow will not be triggered. method `_get_specific_rendering_values` is supposed to return the API URL when the payment is not 'card'. Currently, it does the opposite, where it will only return the rendering_values when payment is in card (eventhough it won't be triggered when doing direct flow) 4212477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1817
Original PR description
Currently, for other payment method options in xendit, the redirect flow will not be triggered. method `_get_specific_rendering_values` is supposed to return the API URL when the payment is not 'card'. Currently, it does the opposite, where it will only return the rendering_values when payment is in card (eventhough it won't be triggered when doing direct flow) 4212477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181752
### Steps to reproduce: - Have two companies: COMP1, COMP2 - In the settings Enable Multi-step routes Prior to 17.2: - Inventory > Configuration > Warehouse Management > Locations - Unarchive: Virtual Locations/Inter-company transit and set is Return Locations - With COMP1: Create and confirm a PO with COMP2 as vendor for 10 units of a storable product - Validate the receipt and return. Select the Virtual Locations/Inter-company transit as return location and validate #### > On the POL
Original PR description
### Steps to reproduce: - Have two companies: COMP1, COMP2 - In the settings Enable Multi-step routes Prior to 17.2: - Inventory > Configuration > Warehouse Management > Locations - Unarchive:…
### Steps to reproduce: - Have two companies: COMP1, COMP2 - In the settings Enable Multi-step routes Prior to 17.2: - Inventory > Configuration > Warehouse Management > Locations - Unarchive: Virtual Locations/Inter-company transit and set is Return Locations - With COMP1: Create and confirm a PO with COMP2 as vendor for 10 units of a storable product - Validate the receipt and return. Select the Virtual Locations/Inter-company transit as return location and validate #### > On the POL the received quantity went from 10 to 20 rather than 0 ### Note: Starting from 17.2, the Inter-company transit location is the default location destination of the return rather than (Partner/Vendor). It also changed its reference to `stock_location_inter_company` so that the fix should be adapted in that version. ### Cause of the Issue: Currently, the qty_received is computed with respect to moves linkes to the POL. However, a move is flagged as a return only if the usage of its destination supplier (dropshipping and subcontracting flow excluded): https://github.com/odoo/odoo/blob/f494496b5142af23ee46ce249a1063f9d6caf403/addons/purchase_stock/models/stock_move.py#L247-L249 and if it is not flagged a return, its quantity is counted positively rather than negatively in the received quantity: https://github.com/odoo/odoo/blob/f494496b5142af23ee46ce249a1063f9d6caf403/addons/purchase_stock/models/purchase.py#L348-L370 opw-4190647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181265 Forward-Port-Of: odoo/odoo#180846
The kitchen printing was broken due to a couple of bugs that prevented it from checking the product category correctly, and also using the wrong variable name for the tracking number. This PR fixes those issues. Steps to reproduce: - Go to the settings of default PoS Kiosk - Enable Preparation -> Prepartion Printers, and add a new Printer - Configure either IoT or Epson printer, and add 'Food' product category - Make sure the new printer is added in the Preparation Printers selection
Original PR description
The kitchen printing was broken due to a couple of bugs that prevented it from checking the product category correctly, and also using the wrong variable name for the tracking number. This PR fixes those issues. Steps to reproduce: - Go to the settings of default PoS Kiosk - Enable Preparation -> Prepartion Printers, and add a new Printer - Configure either IoT or Epson printer, and add 'Food' product category - Make sure the new printer is added in the Preparation Printers selection for the Kiosk - Open the kiosk session and make an order with a food item - Printer does not print on order confirmation - EXPECTED BEHAVIOR: Printer prints order details on confirmation --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179803
Problem: When creating a sale order without selecting a partner or if the partner has no language set, the note field displays the default terms in English, regardless of the user's language. It should display the note in the current user's language instead. Steps to reproduce: - Add default terms and conditions in both English and Arabic. - Change the user language to Arabic. - Create a new quotation without selecting a partner. - The note is displayed in English, but it should be in Ar
Original PR description
Problem: When creating a sale order without selecting a partner or if the partner has no language set, the note field displays the default terms in English, regardless of the user's language. It should display the note in the current user's language instead. Steps to reproduce: - Add default terms and conditions in both English and Arabic. - Change the user language to Arabic. - Create a new quotation without selecting a partner. - The note is displayed in English, but it should be in Arabic as per the user’s language while no partner selected yet. opw-4176183 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181185
In the multilevel dropdown, when the submenu dropdown is accessed within the parent dropdown, it closes the parent dropdown, making it inaccessible to the child dropdown menu. We don't want the BS dropdown to close when the sub dropdown is clicked Task-4037692 Forward-Port-Of: odoo/odoo#181541 Forward-Port-Of: odoo/odoo#173269
Original PR description
In the multilevel dropdown, when the submenu dropdown is accessed within the parent dropdown, it closes the parent dropdown, making it inaccessible to the child dropdown menu. We don't want the BS dropdown to close when the sub dropdown is clicked Task-4037692 Forward-Port-Of: odoo/odoo#181541 Forward-Port-Of: odoo/odoo#173269
In 17.0 the add a line of the res.partner.bank is no longer adding a line directly in the list view but opening a wizard. The xpath of the base_iban was no longer working like it should. task:4197710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180865
Original PR description
In 17.0 the add a line of the res.partner.bank is no longer adding a line directly in the list view but opening a wizard. The xpath of the base_iban was no longer working like it should. task:4197710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180865
## Pull Request HOOT (PRHOOT) - part 23 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10
Current behaviour: --- When going to /customers or /partners and selecting a partner, in the References section, if the text is too long, the image will be taking the text height Expected behaviour: --- The image fits the width but not the height Steps to reproduce: --- 1. Go to Website 2. Go to /customers 3. Select a partner that has references 4. Open the editor (top left) 5. Add long text to one of the reference 6. The image will match the text height Cause of the issue:
Original PR description
Current behaviour: --- When going to /customers or /partners and selecting a partner, in the References section, if the text is too long, the image will be taking the text height Expected behaviour: --- The image fits the width but not the height Steps to reproduce: --- 1. Go to Website 2. Go to /customers 3. Select a partner that has references 4. Open the editor (top left) 5. Add long text to one of the reference 6. The image will match the text height Cause of the issue: --- Caused by: https://github.com/odoo/odoo/commit/1efdb96227dab8f1b3bcb8e8854dbad5dd874e69 Fix: --- Removed h-100 and added w-100 opw-3970462 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173363
Before this commit, entering a payment amount with cash rounding higher than one (e.g., 10) incorrectly triggered an error popup every time. opw-4124332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179859 Forward-Port-Of: odoo/odoo#177547
Original PR description
Before this commit, entering a payment amount with cash rounding higher than one (e.g., 10) incorrectly triggered an error popup every time. opw-4124332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179859 Forward-Port-Of: odoo/odoo#177547
In https://github.com/odoo/odoo/pull/152286, we changed the documents that are added to the chatter of a BoM to be added to the product_product directly (or the template if there are no product on the BoM). However, some changes in mail made the just-added document not appear untill reload. This commit fixes it by reloading the chatter when adding an attachment. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178990
Original PR description
In https://github.com/odoo/odoo/pull/152286, we changed the documents that are added to the chatter of a BoM to be added to the product_product directly (or the template if there are no product on the BoM). However, some changes in mail made the just-added document not appear untill reload. This commit fixes it by reloading the chatter when adding an attachment. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178990
In a Spanish company if you don't have a certificate set on the company, the PoS would generate a proforma invoice instead of a normal invoice. Steps to reproduce: ------------------- * Install l10n_es_pos * Remove the l10n_es_edi_facturae_certificate_id from the company * Open PoS * Make an order and invoice it > Observation: The invoice generated is a proforma invoice instead of a normal invoice Why the fix: ------------ When generating the invoice data in `_generate_pdf_and_sen
Original PR description
In a Spanish company if you don't have a certificate set on the company, the PoS would generate a proforma invoice instead of a normal invoice. Steps to reproduce: ------------------- * Install l10n_es_pos * Remove the l10n_es_edi_facturae_certificate_id from the company * Open PoS * Make an order and invoice it > Observation: The invoice generated is a proforma invoice instead of a normal invoice Why the fix: ------------ When generating the invoice data in `_generate_pdf_and_send_invoice` the wizard would have `l10n_es_edi_facturae_checkbox_xml` checked by default This leads to the generation of a specific invoice that will fail because there are no certificate setup on the company. This will then fallback to the proforma invoice. opw-4074779 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179107
Before this commit, draft order line products not loaded into the PoS could cause errors during PoS loading. This fix addresses the issue by ensuring that all products referenced in order lines are loaded into the PoS, preventing such errors. opw-4167214 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180886
Original PR description
Before this commit, draft order line products not loaded into the PoS could cause errors during PoS loading. This fix addresses the issue by ensuring that all products referenced in order lines are loaded into the PoS, preventing such errors. opw-4167214 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180886
when ecommerce access is restricted to logged in users, so that the products are not publicly accessible on the sitemap. Fixes #165222 Finetuning of 5bde2e42c8ec5e943a779ad4b3e1b7142f2d2fcf Forward-Port-Of: odoo/odoo#176391
Original PR description
when ecommerce access is restricted to logged in users, so that the products are not publicly accessible on the sitemap. Fixes #165222 Finetuning of 5bde2e42c8ec5e943a779ad4b3e1b7142f2d2fcf Forward-Port-Of: odoo/odoo#176391
Before this commit: - In the branch's TDS Entry wizard, In the journal field no journal is displayed. After this commit: - In the branch's TDS Entry wizard, In the journal field main company's journal should be displayed. - When a new branch is created, the TDS Journal from the main company should be automatically assigned to the branch. Task-4154543 Forward-Port-Of: odoo/odoo#178933
Original PR description
Before this commit: - In the branch's TDS Entry wizard, In the journal field no journal is displayed. After this commit: - In the branch's TDS Entry wizard, In the journal field main company's journal should be displayed. - When a new branch is created, the TDS Journal from the main company should be automatically assigned to the branch. Task-4154543 Forward-Port-Of: odoo/odoo#178933
Issue 1: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - the employee can answer after the deadline Problem: -------- the method `_check_validity` was overriden in `hr_appraisal_survey` module to do different checks than the original method in `survey` module in case of `validity_code = answer_wrong_user`, but this override bypasses the other checks in the original method like the deadline check. Solution: --------- call
Original PR description
Issue 1: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - the employee can answer after the deadline Problem: -------- the method…
Issue 1: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - the employee can answer after the deadline Problem: -------- the method `_check_validity` was overriden in `hr_appraisal_survey` module to do different checks than the original method in `survey` module in case of `validity_code = answer_wrong_user`, but this override bypasses the other checks in the original method like the deadline check. Solution: --------- call the original method `_check_validity` in the override, to make sure all the checks are done, then if the original method returns `validity_code = answer_wrong_user` we can do our specific checks. Issue 2: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - manager can't see the answers after the deadline Problem: -------- - to display answer in appraisal module we rely on the url of the survey that contains the tokens for suervey/answer - the deadline handling is done in the survey module where the url is dead after the deadline which is not suitable for the appraisal module Solution: --------- - override the method `_get_access_data` and bypass the deadline check in case of appraisal feedback for manager. opw-4128638 Forward-Port-Of: odoo/enterprise#69502
Implement support for the generation of EFT files following the requirement of the most popular banks in New Zealand Task id # 3639230 Forward-Port-Of: odoo/enterprise#70930 Forward-Port-Of: odoo/enterprise#69494
Original PR description
Implement support for the generation of EFT files following the requirement of the most popular banks in New Zealand Task id # 3639230 Forward-Port-Of: odoo/enterprise#70930 Forward-Port-Of: odoo/enterprise#69494
Community PR: odoo/odoo#181747 Forward-Port-Of: odoo/enterprise#70905 Forward-Port-Of: odoo/enterprise#70844
Original PR description
Community PR: odoo/odoo#181747 Forward-Port-Of: odoo/enterprise#70905 Forward-Port-Of: odoo/enterprise#70844
Steps: - create a bom for product A with 1 operation - add 2 steps to that operation with the same title, the same test_type_id and the same component(s) - create a 2 MOs for that bom - in the shopfloor, go on the workcenter for the operation - do: Update Instructions > Improvement Suggestion > Add a Step > validate - do the same for the other MO Issue 1: you get a traceback 'Expected singleton' because it cannot differentiate between the 2 pre-existing steps (same title, same test_t
Original PR description
Steps: - create a bom for product A with 1 operation - add 2 steps to that operation with the same title, the same test_type_id and the same component(s) - create a 2 MOs for that bom - in the…
Steps: - create a bom for product A with 1 operation - add 2 steps to that operation with the same title, the same test_type_id and the same component(s) - create a 2 MOs for that bom - in the shopfloor, go on the workcenter for the operation - do: Update Instructions > Improvement Suggestion > Add a Step > validate - do the same for the other MO Issue 1: you get a traceback 'Expected singleton' because it cannot differentiate between the 2 pre-existing steps (same title, same test_type_id, same component(s)) Issue 2: you get a traceback 'Expected singleton' because with at least 2 open MOs, it will select all checks without `previous_check_id` across all MOs of the same bom Fix: 1) if more than 1 step can be selected, take the first and remove it from the `points` list all the points in that list will be processed only once so it's ok to remove them after using them. 2) make sure that the selected check corresponds to the MO on which we are adding a step. Forward-Port-Of: odoo/enterprise#70753
…ights The setup of the password from a related field would throw errors to user with accountant rights but no administration (settings) rights. This showed other access rights problems with the SBR implementation. The way we want to work with this is: an accountant without settings rights can set up the password through the wizard if no password is stored on the company (for databases that didn't start SBR with the status info module). Once the password is set and is correct (it is the ri
Original PR description
…ights The setup of the password from a related field would throw errors to user with accountant rights but no administration (settings) rights. This showed other access rights problems with the SBR implementation. The way we want to work with this is: an accountant without settings rights can set up the password through the wizard if no password is stored on the company (for databases that didn't start SBR with the status info module). Once the password is set and is correct (it is the right one for the certificate), it shouldn't ask the user to put it again and is thus hidden in the wizard. ticket-4024344 Forward-Port-Of: odoo/enterprise#66096
### Steps to reproduce: - Have two companies: COMP1, COMP2 - In the settings Enable Multi-step routes Prior to 17.2: - Inventory > Configuration > Warehouse Management > Locations - Unarchive: Virtual Locations/Inter-company transit and set is Return Locations - With COMP1: Create and confirm a PO with COMP2 as vendor for 10 units of a storable product - Validate the receipt and return. Select the Virtual Locations/Inter-company transit as return location and validate #### > On the POL
Original PR description
### Steps to reproduce: - Have two companies: COMP1, COMP2 - In the settings Enable Multi-step routes Prior to 17.2: - Inventory > Configuration > Warehouse Management > Locations - Unarchive:…
### Steps to reproduce: - Have two companies: COMP1, COMP2 - In the settings Enable Multi-step routes Prior to 17.2: - Inventory > Configuration > Warehouse Management > Locations - Unarchive: Virtual Locations/Inter-company transit and set is Return Locations - With COMP1: Create and confirm a PO with COMP2 as vendor for 10 units of a storable product - Validate the receipt and return. Select the Virtual Locations/Inter-company transit as return location and validate #### > On the POL the received quantity went from 10 to 20 rather than 0 #### Note: Starting from 17.2, the Inter-company transit location is the default location destination of the return rather than (Partner/Vendor). It also changed its reference to `stock_location_inter_company` so that the fix should be adapted in that version. ### Cause of the Issue: Currently, the qty_received is computed with respect to moves linkes to the POL. However, a move is flagged as a return only if the usage of its destination supplier (dropshipping and subcontracting flow excluded): https://github.com/odoo/odoo/blob/f494496b5142af23ee46ce249a1063f9d6caf403/addons/purchase_stock/models/stock_move.py#L247-L249 and if it is not flagged a return, its quantity is counted positively rather than negatively in the received quantity: https://github.com/odoo/odoo/blob/f494496b5142af23ee46ce249a1063f9d6caf403/addons/purchase_stock/models/purchase.py#L348-L370 opw-4190647 Forward-Port-Of: odoo/enterprise#70802 Forward-Port-Of: odoo/enterprise#70376
### Steps to reproduce * install `l10n_th_reports` * create a Thai company and its branch * using the company selector, ensure the current company is the branch company, while selecting both parent and branch company * open the Thai Tax Report * attempt to export the "Sales Tax Report (xlsx)" You should be met with a traceback about a tax group External ID not being found ### Cause The system looks for an XML ID which is only present in the parent company, while using the branch
Original PR description
### Steps to reproduce * install `l10n_th_reports` * create a Thai company and its branch * using the company selector, ensure the current company is the branch company, while selecting both parent and branch company * open the Thai Tax Report * attempt to export the "Sales Tax Report (xlsx)" You should be met with a traceback about a tax group External ID not being found ### Cause The system looks for an XML ID which is only present in the parent company, while using the branch company opw-4181071 Forward-Port-Of: odoo/enterprise#70467
Some were missing, some terms were added after the original pot push due to delayed freeze time. COM PR: https://github.com/odoo/odoo/pull/181615
Original PR description
Some were missing, some terms were added after the original pot push due to delayed freeze time. COM PR: https://github.com/odoo/odoo/pull/181615
Steps to reproduce: - Employees > Configuration > Working schedules - Set your working schedule to have non round numbers (Not mandatory but makes the issue much easier to reproduce) - Timesheets > Edit to have the required hour total - Sometimes rounding errors will cause the formatting to change (Overtime of +0:00, display in red...) This issue is not deterministic but we currently use exact comparisons between floats to determine the formatting so it could happen anytime. The error mar
Original PR description
Steps to reproduce: - Employees > Configuration > Working schedules - Set your working schedule to have non round numbers (Not mandatory but makes the issue much easier to reproduce) - Timesheets > Edit to have the required hour total - Sometimes rounding errors will cause the formatting to change (Overtime of +0:00, display in red...) This issue is not deterministic but we currently use exact comparisons between floats to determine the formatting so it could happen anytime. The error margin was chosen to be much lower than what a difference of 1min could cause (Since the rounding errors are in the vicinity of 1e-16). opw-4123649 Forward-Port-Of: odoo/enterprise#69845
## Pull Request HOOT (PRHOOT) - part 23 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10
Original PR description
## Pull Request HOOT (PRHOOT) - part 23 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 23 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Community: https://github.com/odoo/odoo/pull/179660 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#70373 Forward-Port-Of: odoo/enterprise#69728
The meaning of inter-company transaction options (i.e. generate Purchase Order / Sale Order) changed in #55350, as they now indicate the opposite of what they used to (as they now take the PoV of the current company). But the conditions of warehouse/receipt type options weren't adapted to the new meaning: - `intercompany_receipt_type_id` is used to generate the purchase order triggered through `intercompany_generate_purchase_orders`. - `intercompany_warehouse_id` is used to know from which
Original PR description
The meaning of inter-company transaction options (i.e. generate Purchase Order / Sale Order) changed in #55350, as they now indicate the opposite of what they used to (as they now take the PoV of the current company). But the conditions of warehouse/receipt type options weren't adapted to the new meaning: - `intercompany_receipt_type_id` is used to generate the purchase order triggered through `intercompany_generate_purchase_orders`. - `intercompany_warehouse_id` is used to know from which warehouse to generate the sale order triggered trhough `intercompany_generate_sale_orders`. Task-4206898 Forward-Port-Of: odoo/enterprise#70660
### Steps to reproduce: - In the setting: enable Rental transfers - Create and confirm a rental order for 1 unit of a product. ##### > 2 transfers are created: one delivery and one receipt - Validate the delivery and then the receipt for your product. - Go back to the setting: disable Rental transfers #### Expected behavior: You are expected to be able to change this setting. In addition, you have already ended each of your flows that was sensitive to this settings so that nothing s
Original PR description
### Steps to reproduce: - In the setting: enable Rental transfers - Create and confirm a rental order for 1 unit of a product. ##### > 2 transfers are created: one delivery and one receipt - Validate…
### Steps to reproduce: - In the setting: enable Rental transfers - Create and confirm a rental order for 1 unit of a product. ##### > 2 transfers are created: one delivery and one receipt - Validate the delivery and then the receipt for your product. - Go back to the setting: disable Rental transfers #### Expected behavior: You are expected to be able to change this setting. In addition, you have already ended each of your flows that was sensitive to this settings so that nothing should be blocking. #### Current behavior: Error: caused by a foreign key violation: "stock_move_rule_id_fkey" on the table "stock_move". ### Cause of the issue: Push and pull Rules were refactored in saas-17.2 see commit a2ea658 along with this refactoring a method was added to delete the rules of the rental route in oreder to update them if the route is disabled: https://github.com/odoo/enterprise/blob/4647c62c3bd05b7346033cfa851770dfc399837e/sale_stock_renting/models/stock_warehouse.py#L15-L20 However, if the rule was already used on a stock move (just like in our flow) these rules will still be referenced by a move and you will not be allowed to delete the rules form the "stock_rule" table without violating the foreign key violation "stock_move_rule_id_fkey" on the "stock_move" table. ### opw-4131426 Forward-Port-Of: odoo/enterprise#70199
Versions: ------------ saas-17.4 Steps to Reproduce: --------------------------- 1. Go to the All Documents menu. 2. Click on "Details" from the kanban dropdown. 3. Select "Request Signature" from the cog menu. Issue: --------- A `ValueError` occurs: `Wrong value for sign.request.reference_doc: 'sign.request,1'`. Cause: --------- The `reference_doc` field restricts the `sign.request` model in the `selection_target_model`. Solution: ----------- Hide the "Request Signature
Original PR description
Versions: ------------ saas-17.4 Steps to Reproduce: --------------------------- 1. Go to the All Documents menu. 2. Click on "Details" from the kanban dropdown. 3. Select "Request Signature" from the cog menu. Issue: --------- A `ValueError` occurs: `Wrong value for sign.request.reference_doc: 'sign.request,1'`. Cause: --------- The `reference_doc` field restricts the `sign.request` model in the `selection_target_model`. Solution: ----------- Hide the "Request Signature" option in the cog menu. task: 4175789 Forward-Port-Of: odoo/enterprise#69928
Some were missing, some terms were added after the original pot push due to delayed freeze time. ENT PR: https://github.com/odoo/enterprise/pull/70779 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Some were missing, some terms were added after the original pot push due to delayed freeze time. ENT PR: https://github.com/odoo/enterprise/pull/70779 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
## Pull Request HOOT (PRHOOT) - part 23 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 23 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Enterprise: https://github.com/odoo/enterprise/pull/69728 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180863 Forward-Port-Of: odoo/odoo#179660