Wednesday, September 4, 2024
21 changes · saas-17.4
Resolved issues and error corrections
This fix ensures a web test restores a temporary browser visibility setting after it runs. It helps prevent one automated test from affecting others, improving confidence in test results without changing user-facing behavior.
Original PR description
Before this commit, the tests of the feature introduced at odoo/odoo@544da24ebc6359895a548c79b3bca4164dcee45c did not clean their mock overrides. NAmely the visibility state of the document. This could be problematic if other test were to do the same thing. After this commit, we revert the mock overrides to make sure we don't alter the test infrastructure. 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 fix adjusts how message display updates are tracked in Odoo Mail, preventing unnecessary internal recalculations during rendering. It helps keep mail and discussion screens responsive while simplifying the related performance checks.
Original PR description
They were put to prevent some re-render of message. However the problem was the test helpers that rely on hooks that were triggered more than once per actual render. This commit fixes the issue by using `onMounted()`/`onPatched` rather than `onRendered`. This allows the remove the `eager: true` on `Message` model computed fields. Also, test `"posting new message should only render relevant part"` has been adapted to be simpler to what's actually being tested.
Features or functions removed from Odoo
Two outdated barcode PDF files were removed from the repository root because they contained an intermediate, incorrect version. This reduces confusion and helps ensure teams use the correct barcode files from the intended location.
Original PR description
commit 073163f1ae3fd2c659653b773d3ed66836eb2cb2 replaced the new barcode files with the correct code but an intermediate version with incorrect barcode has been forgot in the root of the repository
Miscellaneous changes
Currently error is generated when try to edit 'Invoices' or 'Invoices without Payment' reports in studio mode when there is no record. Steps to reproduce: - Install an 'account' and 'web_studio' module (Without demo data). - Navigate to invoicing / Customers / Invoices and open a web studio mode. - Open reports and click on the 'Invoice' or 'Invoices without Payment' reports. - Click on 'EDIT SOURCES'. See Traceback:- ``` TypeError: 'bool' object is not subscriptable File "<
Original PR description
Currently error is generated when try to edit 'Invoices' or 'Invoices without Payment' reports in studio mode when there is no record. Steps to reproduce: - Install an 'account' and 'web_studio'…
Currently error is generated when try to edit 'Invoices' or 'Invoices without Payment' reports in studio mode when there is no record.
Steps to reproduce:
- Install an 'account' and 'web_studio' module (Without demo data).
- Navigate to invoicing / Customers / Invoices and open a web studio mode.
- Open reports and click on the 'Invoice' or 'Invoices without Payment' reports.
- Click on 'EDIT SOURCES'.
See Traceback:-
```
TypeError: 'bool' object is not subscriptable
File "<744>", line 200, in template_744
File "<744>", line 13, in template_744_content
QWebException: Error while render the template
TypeError: 'bool' object is not subscriptable
Template: ir.ui.view(744,)
Path: /t/t
Node: <t t-foreach="tax_totals[\'subtotals\']" t-as="subtotal"/>
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1827, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1825, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 739, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "home/odoo/src/enterprise/saas-17.2/web_studio/controllers/report.py", line 652, in save_report
report_html = self._render_report(report, record_id)
File "home/odoo/src/enterprise/saas-17.2/web_studio/controllers/report.py", line 597, in _render_report
return request.env['ir.actions.report'].with_context(studio=True)._render_qweb_html(report, [record_id] if record_id else [], {"studio": True})
File "home/odoo/src/enterprise/saas-17.2/web_studio/models/ir_actions_report.py", line 24, in _render_qweb_html
return super(IrActionsReport, self)._render_qweb_html(report_ref, docids, data)
File "odoo/addons/base/models/ir_actions_report.py", line 927, in _render_qweb_html
return self._render_template(report.report_name, data), 'html'
File "odoo/addons/base/models/ir_actions_report.py", line 654, in _render_template
return view_obj._render_template(template, values).encode()
File "home/odoo/src/enterprise/saas-17.2/web_studio/models/ir_ui_view.py", line 1302, in _render_template
return super(View, self)._render_template(template, values)
File "odoo/addons/base/models/ir_ui_view.py", line 2024, in _render_template
return self.env['ir.qweb']._render(template, values)
File "odoo/tools/profiler.py", line 302, in _tracked_method_render
return method_render(self, template, values, **options)
File "odoo/addons/base/models/ir_qweb.py", line 594, in _render
result = ''.join(rendering)
File "<748>", line 42, in template_748
File "<748>", line 31, in template_748_content
File "<747>", line 90, in template_747
File "<747>", line 72, in template_747_content
File "<747>", line 60, in template_747_t_call_0
File "<742>", line 2412, in template_742
File "<742>", line 2394, in template_742_content
File "<742>", line 1650, in template_742_t_call_0
File "<744>", line 208, in template_744
```
The issue occurs when the system tries to access a boolean value which is stored in 'Tax_totals' in the 'document_tax_totals' template [1] and this a boolean value is passed into 'tax_totals' from this line [2] because record is not available.
link [1]: https://github.com/odoo/odoo/blob/a8daed02c58ab69cdea57a8f97065e229b07f0ab/addons/account/views/report_invoice.xml#L200-L201
link [2]: https://github.com/odoo/odoo/blob/a8daed02c58ab69cdea57a8f97065e229b07f0ab/addons/account/models/account_move.py#L1348
To resolve the issue, Add a condition that checks whether the 'Tax_totals' is available before call the 'document_tax_totals' template.
sentry-4499699758
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#161249This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285 Forward-Port-Of: odoo/odoo#177353 Forward-Port-Of: odoo/odoo#175563
Original PR description
This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285 Forward-Port-Of: odoo/odoo#177353 Forward-Port-Of: odoo/odoo#175563
Before 17 process_coa_translations might have been needed in multi_lang localizations, but it is no longer needed. It is also not called. No task linked. Just saw it checking other stuff. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178508
Original PR description
Before 17 process_coa_translations might have been needed in multi_lang localizations, but it is no longer needed. It is also not called. No task linked. Just saw it checking other stuff. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178508
### Steps to reproduce: - Enable multisteps route in the settings - Create a storable product P and put 10 units in WH/Stock/Shelf - Create and confirm an SO for 1 unit of P - Go to the associated delivery and change the Source Location to WH/Stock/Shelf - Back to the SO, click on the chart icon > view forecast - Unreserve the 1 unit currently used by your picking ### Issue: While you have 10 units in WH/Stock/Shelf perfectly suitable to fulfill the demand of the picking, instead o
Original PR description
### Steps to reproduce: - Enable multisteps route in the settings - Create a storable product P and put 10 units in WH/Stock/Shelf - Create and confirm an SO for 1 unit of P - Go to the associated…
### Steps to reproduce: - Enable multisteps route in the settings - Create a storable product P and put 10 units in WH/Stock/Shelf - Create and confirm an SO for 1 unit of P - Go to the associated delivery and change the Source Location to WH/Stock/Shelf - Back to the SO, click on the chart icon > view forecast - Unreserve the 1 unit currently used by your picking ### Issue: While you have 10 units in WH/Stock/Shelf perfectly suitable to fulfill the demand of the picking, instead of displaying a line allowing you to reserve the 1 unit, you have a line telling you that the qty is "not available" -1 unit associated with the SO. If you go back to the SO: the chart icon is displayed red and the details displayed in the availability widget shows a: "No future availability". ### Cause of the issue: The chart icon is red because the JS detects a forecasted issue: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/sale_stock/static/src/widgets/qty_at_date_widget.xml#L8 This issue comes from the fact that the demand is not expected to be fulfilled since the `free_qty_today` of the SOL is smaller than its `qty_to_deliver`: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L45 https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L54-L55 The reason for this forecasted issue is that the `free_qty_today` is computed to be -1 rather than 1 here: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/sale_stock/models/sale_order_line.py#L80-L82 since the `move.forecast_availability` is itself -1 rather than 1. Note that if the source of the move was still WH/Stock rather than WH/Stock/Shelf both of these value would be set to +1 and the issue would not appear. However, the `forecast_availability` of moves is not correctly computed if the location_id of the move is a strict sublocation of the warehouse. To be more precise, the forecasted availability is set to a negative quantity here: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/stock/models/stock_move.py#L470-L472 since the report line computed in the `_get_forecast_availability_outgoing` specifies that 'replenishment_filled' is False and should not be: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/stock/models/stock_move.py#L2228 We are finally at the core of the problem, the replenishement is not filled because in the `_get_report_lines`, the `currents` dict used to compute both the reserved and the on hand quantity only updates the quantity of the warehouse if the location belongs to the warehouse: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/stock/report/stock_forecasted.py#L327-L330 As such, 0 units are considered to be available in these locations and nothing can be taken from stock for these moves: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/stock/report/stock_forecasted.py#L236-L242 which of course result in the impossibility to fulfill the replenishment opw-3979953 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172106
When a user creates a new sol, only service-type product should be searched. Before this commit, consumable and other types of product was being searched. task-3972359 Forward-Port-Of: odoo/odoo#178955 Forward-Port-Of: odoo/odoo#178615
Original PR description
When a user creates a new sol, only service-type product should be searched. Before this commit, consumable and other types of product was being searched. task-3972359 Forward-Port-Of: odoo/odoo#178955 Forward-Port-Of: odoo/odoo#178615
Issue ---- The date fields in the activity view aren't displayed according to the language's date/time formats. Steps ----- - Go to Settings -> Translations -> Language. - Use a custom date & time format. - Create a new model that has an activity view, say a project task. You'll see the task's deadline is displayed according to your format (correct behavior). - Add an activity and set a due date. - The "Created" & "Due On" dates don't match your custom format. Cause ----- I
Original PR description
Issue ---- The date fields in the activity view aren't displayed according to the language's date/time formats. Steps ----- - Go to Settings -> Translations -> Language. - Use a custom date & time format. - Create a new model that has an activity view, say a project task. You'll see the task's deadline is displayed according to your format (correct behavior). - Add an activity and set a due date. - The "Created" & "Due On" dates don't match your custom format. Cause ----- In the activity component, the dates weren't formated according to the current language's date/time format but rather a hard-coded one. opw-3929864 Forward-Port-Of: odoo/odoo#174416 Forward-Port-Of: odoo/odoo#168074
Consider an invoice with a cash rounding method selected. The cash rounding is applied to the total of the invoice but not not the payment terms. Currently unrounded amounts can appear in the following cases - Multiple payment term lines - Discount on payment term lines This is can also cause problems for the reconciliation. The cash rounded payment can not be reconciled with the non-cash-rounded payment term amount (since the amounts do not match exactly). After this commit the cash rou
Original PR description
Consider an invoice with a cash rounding method selected. The cash rounding is applied to the total of the invoice but not not the payment terms. Currently unrounded amounts can appear in the…
Consider an invoice with a cash rounding method selected. The cash rounding is applied to the total of the invoice but not not the payment terms. Currently unrounded amounts can appear in the following cases
- Multiple payment term lines
- Discount on payment term lines
This is can also cause problems for the reconciliation. The cash rounded payment can not be reconciled with the non-cash-rounded payment term amount (since the amounts do not match exactly).
After this commit the cash rounding is applied to the payment terms:
- The amount of each payment term line is cash rounded
- The discounted amount of each payment term line is cash rounded
Reproduce:
1. Install module `account` (or `account_accountant`)
2. Create a payment term with 1 line with 10% discount when paid within 30 days. Ensure "Display terms on invoice" is on. (Invoicing / Accounting -> Configuration (menu) -> Payment Terms)
3. Enable "Cash Rounding" in the settings
4. Create a cash rounding with precision 0.05 and rounding method HALF-UP (Invoicing / Accounting -> Configuration (menu) -> Cash Roundings)
5. Create an invoice
- Payment term from step 2
- Cash rounding from step 3 (set in "Other Info" tab) - A line s.t. the total is 868.35 (This value does not need cash rounding)
6. Confirm the invoice
7. Print the invoice: On the PDF the value 781.52 is shown for the payment terms. But the value should be 781.50 due to the cash rounding.
8. Register payment: The amount 781.52 is suggested. But the value should be 781.50 due to the cash rounding. Changing the amount to 781.50 loses the automatic reconciliation.
task-4095505
opw-3985470
Forward-Port-Of: odoo/odoo#178344
Forward-Port-Of: odoo/odoo#176289We still disconnected from wifi unlinking the old file, despite that we moved this configuration to `odoo.conf`. We replaced that. Forward-Port-Of: odoo/odoo#178920
Original PR description
We still disconnected from wifi unlinking the old file, despite that we moved this configuration to `odoo.conf`. We replaced that. Forward-Port-Of: odoo/odoo#178920
As we never kill browser instances, IoT Box gets saturated by browser threads if odoo restarts multiple times. We now kill the browser before starting a new. Forward-Port-Of: odoo/odoo#176941
Original PR description
As we never kill browser instances, IoT Box gets saturated by browser threads if odoo restarts multiple times. We now kill the browser before starting a new. Forward-Port-Of: odoo/odoo#176941
### Steps to reproduce: - Enable Multi-Step Routes in the settings - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable product: - Routes: MTO, manufacture - With a bom - On hand qty: 10 - Create an SO for 15 units and validate - Go back to your product form > forecasted Report #### > Even thought 15 units are made to order 10 units are reported to be taken from stock to fulfill the SO ### Cause of the issue: The lines appe
Original PR description
### Steps to reproduce: - Enable Multi-Step Routes in the settings - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable product: - Routes: MTO,…
### Steps to reproduce: - Enable Multi-Step Routes in the settings - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable product: - Routes: MTO, manufacture - With a bom - On hand qty: 10 - Create an SO for 15 units and validate - Go back to your product form > forecasted Report #### > Even thought 15 units are made to order 10 units are reported to be taken from stock to fulfill the SO ### Cause of the issue: The lines appearing on the reported are computed by the `_get_report_lines` method. During this call, the quantity taken from stock is computed by comparing the demand of the out moves with the quantity currently in stock: https://github.com/odoo/odoo/blob/1fdccad664cad37a69dc960444aa0c318d1bf464/addons/stock/report/report_stock_forecasted.py#L218-L223 This is incorrect because the quantity taken from stock is null if the procure_method of the out move is make_to_stock. ### Note: The issue is not reproducible since 17.0 since the _get_report_lines has been refactored during the stockpocalypse. opw-4010785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177867 Forward-Port-Of: odoo/odoo#176273
Issue: the reserved quantity appearing on the SOL wizard is not well behaved with respect to 2+ steps deliveries. ### Steps to reproduce: - Enable Multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Enable delivery in 2 steps - Create a storable product and put 1 unit in stock - Create and confirm an SO for 1 unit - Click on the chart icon next to the delivered qty #### > the reserved qty is 0 + "No future availability" even though 1
Original PR description
Issue: the reserved quantity appearing on the SOL wizard is not well behaved with respect to 2+ steps deliveries. ### Steps to reproduce: - Enable Multi-step routes in the settings - Inventory >…
Issue: the reserved quantity appearing on the SOL wizard is not well behaved with respect to 2+ steps deliveries. ### Steps to reproduce: - Enable Multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Enable delivery in 2 steps - Create a storable product and put 1 unit in stock - Create and confirm an SO for 1 unit - Click on the chart icon next to the delivered qty #### > the reserved qty is 0 + "No future availability" even though 1 unit is reserved from stock ### Cause of the issue: The reserved qty displayed on the next to the delivered qty on the SOL is the `qty_available_today` computed field of the SOL model. This field is computed by summing the qties of the stock moves linked to the SOL: https://github.com/odoo/odoo/blob/817186b7b896c9a415bd947baf189bf7f1bde321/addons/sale_stock/models/sale_order_line.py#L69 https://github.com/odoo/odoo/blob/817186b7b896c9a415bd947baf189bf7f1bde321/addons/sale_stock/models/sale_order_line.py#L80-L81 However, when you are not delivering in 1 step, the only delivery move linked to the SOL will be the move which destination is the customer location. To be more precise, confirming the SO in a delivery in two steps a stock move from the Output to the customer will be created and linked to the SOL. During the action confirm of this move a procurement will be run to generate a move from stock to the Output but the SOL will not be referenced anymore so that the SOL will not be linked to it. ### Note: The behavior is different in saas-17.2 where each of the delivering move is linked to the SOL so that the probably need to be adapted. opw-3981935 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177389 Forward-Port-Of: odoo/odoo#176756
Before this commit: Functions where treated as object by the deepMerge utils, causing it to merge function properties. After this commit: Functions are now treated as values (This commit is a backport of [03f7b5f](https://github.com/odoo/odoo/commit/03f7b5f4f79b31c373b0f5a57a7bcced1e5a26b0) from 17.4 to 17.2) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178156
Original PR description
Before this commit: Functions where treated as object by the deepMerge utils, causing it to merge function properties. After this commit: Functions are now treated as values (This commit is a backport of [03f7b5f](https://github.com/odoo/odoo/commit/03f7b5f4f79b31c373b0f5a57a7bcced1e5a26b0) from 17.4 to 17.2) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178156
This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285 Forward-Port-Of: odoo/enterprise#68675 Forward-Port-Of: odoo/enterprise#63481
Original PR description
This will add rules for the payroll in Alabama, Nevada, Washington and Colorado. Task: 3923285 Forward-Port-Of: odoo/enterprise#68675 Forward-Port-Of: odoo/enterprise#63481
We noticed that in production, eTIMS regularly fails to respond within the timeout of 30s when we send an invoice. Since this happens fairly often, this PR aims to improve the error message so that the user knows there is nothing they can do except wait for a bit and then retry. We also increase the timeout to 45s, on the off chance that this might improve things somewhat. taskid: none Forward-Port-Of: odoo/enterprise#69099 Forward-Port-Of: odoo/enterprise#69049
Original PR description
We noticed that in production, eTIMS regularly fails to respond within the timeout of 30s when we send an invoice. Since this happens fairly often, this PR aims to improve the error message so that the user knows there is nothing they can do except wait for a bit and then retry. We also increase the timeout to 45s, on the off chance that this might improve things somewhat. taskid: none Forward-Port-Of: odoo/enterprise#69099 Forward-Port-Of: odoo/enterprise#69049
### Before this PR: ->If we create a product that isn't a service > open the helpdesk ticket form view -> type the name of the product you created from the SOL field and click create -> a new SOL is generated for this product and is successfully set on the ticket ### After this PR: A new SOL is generated only for service products, it should only be allowed for services products, it will throw validation error that isn't service task-3972359 Forward-Port-Of: odoo/enterprise#69349
Original PR description
### Before this PR: ->If we create a product that isn't a service > open the helpdesk ticket form view -> type the name of the product you created from the SOL field and click create -> a new SOL is generated for this product and is successfully set on the ticket ### After this PR: A new SOL is generated only for service products, it should only be allowed for services products, it will throw validation error that isn't service task-3972359 Forward-Port-Of: odoo/enterprise#69349 Forward-Port-Of: odoo/enterprise#66463
### Steps to reproduce: - Install the module "l10n_ec" and switch to Ecuadorian company - Go to Accounting > Configuration > Ecuadorian SRI > Digital Certificates SRI - When uploading a p12 file with the country name "Ecuador" and not "EC" - An error pops up but does not tell the right reason ### Cause: The cryptography library only accepts country names in the form of 2 character country code, so it raises an error. If an error occurs during the loading of the file, the error message w
Original PR description
### Steps to reproduce: - Install the module "l10n_ec" and switch to Ecuadorian company - Go to Accounting > Configuration > Ecuadorian SRI > Digital Certificates SRI - When uploading a p12 file with the country name "Ecuador" and not "EC" - An error pops up but does not tell the right reason ### Cause: The cryptography library only accepts country names in the form of 2 character country code, so it raises an error. If an error occurs during the loading of the file, the error message will always be "Error loading certificate %s, check that password is correct and file type is p12". ### Solution: As we cannot display the error messages of external libraries (here the cryptography library), this commit adds the reason "The country name is not a 2 character country code." in the error message. opw-4116914 Forward-Port-Of: odoo/enterprise#69194 Forward-Port-Of: odoo/enterprise#68633
Before this commit, the section transaction without statement didn't count the reconciled entries, and so the balance of the account was wrong. To fix that we putted a new custom engine function that will trigger the _bank_reconciliation_report_custom_engine_common with False for the "from_statement" and False for the "unreconciled" variables. With that the query will get all the transaction reconciled or not that are not from a statement. There was also a problem if the reconcile rate was
Original PR description
Before this commit, the section transaction without statement didn't count the reconciled entries, and so the balance of the account was wrong. To fix that we putted a new custom engine function that will trigger the _bank_reconciliation_report_custom_engine_common with False for the "from_statement" and False for the "unreconciled" variables. With that the query will get all the transaction reconciled or not that are not from a statement. There was also a problem if the reconcile rate was 0, which didn't when having only unreconciled entries but now that we can have that, it needed to be modified. task: 4110491 Forward-Port-Of: odoo/enterprise#68594
Steps to reproduce 1. Click on the retweet button. 2. select the Quote tweet button. 3. error occurs (if debug is ON). 4. Throws an error when clicking the 'Post' button. Technical Reason: Clicking on a quote causes an error because of props validation. Additionally, the route for the post is not set properly. After this commit: Clicking on a 'quote tweet' works without any errors. Posting will work as expected. Task-4072916 Forward-Port-Of: odoo/enterprise#67941
Original PR description
Steps to reproduce 1. Click on the retweet button. 2. select the Quote tweet button. 3. error occurs (if debug is ON). 4. Throws an error when clicking the 'Post' button. Technical Reason: Clicking on a quote causes an error because of props validation. Additionally, the route for the post is not set properly. After this commit: Clicking on a 'quote tweet' works without any errors. Posting will work as expected. Task-4072916 Forward-Port-Of: odoo/enterprise#67941