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
16 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
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
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
### 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