Monday, January 13, 2025
55 changes · saas-18.1
Resolved issues and error corrections
The checkout helper now points to the updated script location after a previous update left it referencing an old path. This helps keep IoT box setup and maintenance processes running reliably without manual correction.
Original PR description
Forward-porting [this PR](https://github.com/odoo/odoo/pull/191928) resulted in setting path for checkout script to old path. The path is now set to the new location (in `iot_box_image` module).
Keyboard navigation in dropdown menus now clearly shows the currently selected option again. This restores expected behavior for users who rely on arrow keys, improving usability and accessibility when choosing records.
Original PR description
- Previously, navigating through dropdown options using the keyboard's up and down arrow keys would highlight the selected value in the dropdown. However, this functionality was inadvertently removed in this commit https://github.com/odoo/odoo/commit/6d77fb2d823688fcdd3085cd15c7a28771e783b6, resulting in the selected record not being visible during keyboard navigation. - This fix restores the original behavior, ensuring that the selected option is properly highlighted and visible when navigating with the keyboard. Task-4402580 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where selecting a Point of Sale preset by name could fail if no customer was linked. This prevents an unexpected error during checkout setup and keeps the sales flow uninterrupted.
Original PR description
Since https://github.com/odoo/odoo/pull/192154, selecting a preset indentified by name without a partner raise a traceback as we try to access the name of the partner which is undefined. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The web test timeout has been reduced now that the underlying browser-related slowdown has been fixed. This helps failed or unhealthy builds stop sooner, making regressions such as memory problems visible more quickly without affecting end users.
Original PR description
This timeout has been recently increased [1] because builds sometimes reached it. It was indicating that something was wrong, but until we figured it out, the correct thing to do was to increase it. PR [2] just fixed the underlying issue, which was coming from the update to from chrome 123 to chrome 126 on runbots. Indeed, as of chrome 124, the instruction to force a garbage collect after each test had to be slightly adapted. Now that this is done, this suite generally lasts 20-22 minutes, so we can safely decrease the timeout to 30 minutes, which allows us to kill the test earlier when something's wrong, and which will indicate regressions (like memory leaks) faster. [1] odoo/odoo#191456 [2] odoo/odoo#193332 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
Selecting a document record in mobile view no longer triggers an error after reloading the page. This improves reliability for users managing documents on phones or narrow screens.
Original PR description
**Steps to reproduce:** Switch to mobile view Reload the page Select any record Traceback occurs **Technical:** After commit https://github.com/odoo/odoo/commit/ef3656e3468ba6dab207c8df65d12fbb75ae4c77, the 'isPageSelected' condition was removed for the ALL button in the "web.list.selection" template. As a result, the first two conditions will be true, and the system will then check for model.root.isRecordCountTrustable. However, at that point, the model is not available. Previously, the false value of isPageSelected would prevent the check for the model from occurring. **After this commit:** The user will not encounter any traceback when selecting a record in mobile view. Task-4402442
Miscellaneous changes
Previously, settling a sale.order from the POS of a Belgian company would auto check the invoice option before paying. Steps to reproduce: ------------------- * Install `l10n_be_pos_cert` * Switch to the Beligian company * Crete a quotation in **Sale** app * Add any partner and any product, remove all taxes for the product line * Save * Open pos shop * Settle the order * Go to the payment screen > Observation: The invoice button is already selected. Why the fix: ------------ T
Original PR description
Previously, settling a sale.order from the POS of a Belgian company would auto check the invoice option before paying. Steps to reproduce: ------------------- * Install `l10n_be_pos_cert` * Switch to…
Previously, settling a sale.order from the POS of a Belgian company would auto check the invoice option before paying. Steps to reproduce: ------------------- * Install `l10n_be_pos_cert` * Switch to the Beligian company * Crete a quotation in **Sale** app * Add any partner and any product, remove all taxes for the product line * Save * Open pos shop * Settle the order * Go to the payment screen > Observation: The invoice button is already selected. Why the fix: ------------ This invoice option was auto selected since this commit: https://github.com/odoo/odoo/commit/c760fbb1bd2e7725b5e759198684a07060612033 The following commit https://github.com/odoo/odoo/commit/3a5e22218708b4b6c9aedfa965d9f3c279edbd46 updates the previous one as the invoice enforcement is only needed when we have intracom taxes on the SO. Thus when no intracom taxes apply we can still decide wether or not to invoice. We fallback on the default behavior which is to have the invoice button un-selected. opw-4334095 Forward-Port-Of: odoo/odoo#193286 Forward-Port-Of: odoo/odoo#188400
Some modules (i.e., Appointment) uses calendar.event, but they don't want to create an activity every time a user books a meeting. This PR indroduce a helper function, which return a list of models, in which we don't want to create activities. Task-4243603 Forward-Port-Of: odoo/odoo#184272
Original PR description
Some modules (i.e., Appointment) uses calendar.event, but they don't want to create an activity every time a user books a meeting. This PR indroduce a helper function, which return a list of models, in which we don't want to create activities. Task-4243603 Forward-Port-Of: odoo/odoo#184272
- `point_of_sale`: when creating cash payment methods, we now use the default cash account if it exists. - `l10n_be_pos_restaurant`: filter taxes to create to avoid recreating same tax in sub company 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#193275
Original PR description
- `point_of_sale`: when creating cash payment methods, we now use the default cash account if it exists. - `l10n_be_pos_restaurant`: filter taxes to create to avoid recreating same tax in sub company 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#193275
Currently, the extractor looking for terms to translate in spreadsheet files was specifically looking for files ending in "_spreadsheet.json". However, since this version there were new spreadsheets added that ended in "_spreadsheet.osheet.json". The translation extractor couldn't find these and the terms were never extracted, resulting in missing translations. This commit searches for both filename patterns to export the terms. We also make sure that file references are only extracted onc
Original PR description
Currently, the extractor looking for terms to translate in spreadsheet files was specifically looking for files ending in "_spreadsheet.json". However, since this version there were new spreadsheets added that ended in "_spreadsheet.osheet.json". The translation extractor couldn't find these and the terms were never extracted, resulting in missing translations. This commit searches for both filename patterns to export the terms. We also make sure that file references are only extracted once per term per file. Related to https://github.com/odoo/enterprise/pull/75605 Forward-Port-Of: odoo/odoo#193054 Forward-Port-Of: odoo/odoo#190598
Before this commit, it was possible to load pricelists that were not available in the PoS. opw-4423566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191560
Original PR description
Before this commit, it was possible to load pricelists that were not available in the PoS. opw-4423566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191560
opw-4409456 Forward-Port-Of: odoo/odoo#192863
Original PR description
opw-4409456 Forward-Port-Of: odoo/odoo#192863
In the Tasks' and Tasks Analysis' chart and pivot views, some default measures were not translatable after [this commit]. We make them translatable again here so they can be localized. [this commit]: https://github.com/odoo/odoo/commit/e82567f9d5842bd95fe01ba3b9f54a65437e313f [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#193058
Original PR description
In the Tasks' and Tasks Analysis' chart and pivot views, some default measures were not translatable after [this commit]. We make them translatable again here so they can be localized. [this commit]: https://github.com/odoo/odoo/commit/e82567f9d5842bd95fe01ba3b9f54a65437e313f [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#193058
The demo data for `mass_mailing_crm` is currently not viewable nor editable before being sent. Steps to reproduce ----- 1. Open Email Marketing > Select the campaign titled "We want to hear from you !" 2. In the form view, a template picker is displayed instead of the existing contents Cause ----- The demo data is using `body_html` instead of `body_arch`, the latter of which is displayed in the form view before the campaign is sent. Since `body_arch = False`, the template picker is di
Original PR description
The demo data for `mass_mailing_crm` is currently not viewable nor editable before being sent. Steps to reproduce ----- 1. Open Email Marketing > Select the campaign titled "We want to hear from you !" 2. In the form view, a template picker is displayed instead of the existing contents Cause ----- The demo data is using `body_html` instead of `body_arch`, the latter of which is displayed in the form view before the campaign is sent. Since `body_arch = False`, the template picker is displayed instead. Solution ----- Use the `body_arch` field instead, `body_html` will be rendered when running the Test or Send actions. opw-4440786 Forward-Port-Of: odoo/odoo#193274
In this commit, in order to simplify the tours API, we remove the saveAs attribute from the tour object definition. This attribute does not bring anything in the sense that it just allows not to create in the registry a tour that could already exist and to save it under another name to have access to it from tour_service. To avoid the error of creating a key that already exists in the registry, simply remove it before adding it again. This is only used in the website module for the homepa
Original PR description
In this commit, in order to simplify the tours API, we remove the saveAs attribute from the tour object definition. This attribute does not bring anything in the sense that it just allows not to create in the registry a tour that could already exist and to save it under another name to have access to it from tour_service. To avoid the error of creating a key that already exists in the registry, simply remove it before adding it again. This is only used in the website module for the homepage tour. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193065
Before this commit, if you made a product available in PoS but set it to not be available in self order, it would still appear in the kiosk or mobile menu with an "out of stock" tag, which is confusing and not the expected behavior. opw-4200540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188663
Original PR description
Before this commit, if you made a product available in PoS but set it to not be available in self order, it would still appear in the kiosk or mobile menu with an "out of stock" tag, which is confusing and not the expected behavior. opw-4200540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188663
When creating a repair order, and paying it with a POS order, the product from the repair order would be consumed twice, once when creating the repair order, and once when validating the POS order. So we end up with 2 stock moves for the same product. Steps to reproduce: ------------------- * Create a repair order for any product * Add product A to the part list * Start and end the repair (at this point one stock move is created) * Create a quotation for the repair order * Open PoS and
Original PR description
When creating a repair order, and paying it with a POS order, the product from the repair order would be consumed twice, once when creating the repair order, and once when validating the POS order. So we end up with 2 stock moves for the same product. Steps to reproduce: ------------------- * Create a repair order for any product * Add product A to the part list * Start and end the repair (at this point one stock move is created) * Create a quotation for the repair order * Open PoS and settle the quotation * Validate the PoS order, and check the stock moves for the product A > Observation: You can see one more stock move for the product A coming from the PoS order Why the fix: ------------ We make a similar fix as this one https://github.com/odoo/odoo/pull/186812 to prevent the creation of stock moves when the product is coming from a repair order. opw-4351266 Forward-Port-Of: odoo/odoo#192753
Scenario: create a server action that updates a properties Result: traceback error is raised Issue: server action does not handle updating record properties Fix: ignore the error in _stringify_path method, so the more legible ValidationError from _traverse_path is raised instead. Note: without the fix, the added test failed with "KeyError: 'discussion_color_code'", with the fix it doesn't fail (and there is a "ValidationError: 'The path to the field to update contains a non-relation
Original PR description
Scenario: create a server action that updates a properties
Result: traceback error is raised
Issue: server action does not handle updating record properties Fix: ignore the error in _stringify_path method, so the more legible
ValidationError from _traverse_path is raised instead.
Note: without the fix, the added test failed with "KeyError: 'discussion_color_code'", with the fix it doesn't fail (and there is a "ValidationError: 'The path to the field to update contains a non-relational field (attributes) that is not the last field in …'").
opw-4339633
Forward-Port-Of: odoo/odoo#192483**Steps to reproduce:** - Install l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice with "Simplified Invoice Partner (ES)" as customer - Confirm the invoice - Process the invoice with "TicketBAI (ES)" service **Issue:** The generated XML has 2 regime keys (02 and 52) for <ClaveRegimenIvaOpTrascendencia> that are not compatible with each other. From the documentation, regime key "52" (for simplified invoices) can only be associated with regime key "51"
Original PR description
**Steps to reproduce:** - Install l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice with "Simplified Invoice Partner (ES)" as customer - Confirm the invoice - Process the invoice with "TicketBAI (ES)" service **Issue:** The generated XML has 2 regime keys (02 and 52) for <ClaveRegimenIvaOpTrascendencia> that are not compatible with each other. From the documentation, regime key "52" (for simplified invoices) can only be associated with regime key "51", which is not supported for the moment. **Solution:** If the "Simplified Invoice Partner" is used, only the regime key "52" is used. opw-4332052 opw-4355424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192825 Forward-Port-Of: odoo/odoo#192448
Currently, there's no way to know what are the valid/expected values for the "type" argument of ODOO.ACCOUNT.GROUP. It makes it almost impossible to use if you are not technical and you can't go and check the code. The valid inputs are the *technical* value of the selection field `account_type`. I had to copy-paste and hard-code the selection field option. This is clearly not ideal (not a single source of truth), but the current auto-complete system is synchronous. I can't make a server
Original PR description
Currently, there's no way to know what are the valid/expected values for the "type" argument of ODOO.ACCOUNT.GROUP. It makes it almost impossible to use if you are not technical and you can't go and check the code. The valid inputs are the *technical* value of the selection field `account_type`. I had to copy-paste and hard-code the selection field option. This is clearly not ideal (not a single source of truth), but the current auto-complete system is synchronous. I can't make a server call to fetch all the options. Besides, the UX is better if the auto-complete shows up instantly rather than having to wait for a network round-trip. Task: 4465573 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#193167
If the user adds a product to a PO generated for a sold and subcontrated service, the picking will be a receipt and the related SO will not be updated To reproduce the issue: 1. Create a service S: - Add a new vendor V - Subcontracted Service: True 2. Create a product P: - Vendor V - Routes: Dropship 3. Create and confirm a SO with 1 x S 4. Add 1 x P to the PO 5. Confirm the PO - Error 01: it generates a receipt while a dropship is expected 6. Process the receipt
Original PR description
If the user adds a product to a PO generated for a sold and subcontrated service, the picking will be a receipt and the related SO will not be updated To reproduce the issue: 1. Create a service S: -…
If the user adds a product to a PO generated for a sold and subcontrated service, the picking will be a receipt and the related SO will not be updated To reproduce the issue: 1. Create a service S: - Add a new vendor V - Subcontracted Service: True 2. Create a product P: - Vendor V - Routes: Dropship 3. Create and confirm a SO with 1 x S 4. Add 1 x P to the PO 5. Confirm the PO - Error 01: it generates a receipt while a dropship is expected 6. Process the receipt - Error 02: the SO does not change while a new SOL for P1 is expected If the initial SO had P, it would work correctly. The user could even add a second dropshipped product before confirming the PO, the picking would be a dropship and there would be some new SOL for the dropship products. When confirming a SO, the process that generates the PO depends on the SOL. If at least one of them is a product, the stock rule mechanism will always handle the situation since it is called before the `super`: https://github.com/odoo/odoo/blob/899878f8e4d61de6b7bb6e4799a3e97e8d9f4434/addons/sale_stock/models/sale_order.py#L176-L178 while, service side, we generate the PO after `super` https://github.com/odoo/odoo/blob/706431510110a005618a2acaf6566f2bb61d5114/addons/sale_purchase/models/sale_order.py#L20-L24 And, good news, everything works correctly when the PO is created by the stock rules. However, when creating a PO for a sold service, we have few mistakes. First, we don't provide any operation type: https://github.com/odoo/odoo/blob/238a41e35280256382f6509182b9e900fb4f7aba/addons/sale_purchase/models/sale_order_line.py#L131-L141 We therefore use the default one, a receipt: https://github.com/odoo/odoo/blob/f9381a0611207e0fec6b957aef3b160437ecbafb/addons/purchase_stock/models/purchase_order.py#L23 We don't provide any destination address either, as explicitly said by the comment: "False since only supported in stock". All this could make sense as long as we don't add any product. If we do, we will then have an issue with the picking: error 01. The PO has been created to subcontract a service to a customer. It's a dropship-like situation. We should therefore anticipate the situation and set some correct values in case we add some products. Then, when processing the picking, we update the related SO in some conditions: https://github.com/odoo/odoo/blob/84d2c884300f090103b917b8911d82dbeac9279e/addons/sale_stock/models/stock.py#L119-L130 Fixing error 01 solves a part of the conditions: we now have a correct destination location. However, we still don't have any SO linked to the picking. This info actually comes from the group: https://github.com/odoo/odoo/blob/84d2c884300f090103b917b8911d82dbeac9279e/addons/sale_stock/models/stock.py#L87-L90 However, when confirming the PO, it leads to the picking creation. To do so, we directly create the missing group but we don't provide any value for `sale_id`: https://github.com/odoo/odoo/blob/f9381a0611207e0fec6b957aef3b160437ecbafb/addons/purchase_stock/models/purchase_order.py#L259-L264 OPW-4332074 Forward-Port-Of: odoo/odoo#192375
It is impossible to close a session when there is a combined payment amount with a negative value. Steps to reproduce: - Create a new bank payment method and assign as payment method of a pos.config. - Open a session. - Sell with negative amount (e.g. negative quantity) and pay using the new payment method. - [ISSUE] Try to close the session and you will get an error. When a payment amount is negative, we invert the destination and outstanding accounts. Prior to creation of the `accoun
Original PR description
It is impossible to close a session when there is a combined payment amount with a negative value. Steps to reproduce: - Create a new bank payment method and assign as payment method of a pos.config. - Open a session. - Sell with negative amount (e.g. negative quantity) and pay using the new payment method. - [ISSUE] Try to close the session and you will get an error. When a payment amount is negative, we invert the destination and outstanding accounts. Prior to creation of the `account.payment` record, it's possible that an outstanding account is missing. This value can be missing but will be automatically assigned during the creation of the `account.payment` record. So instead of inverting the accounts before creating the `account.payment` record, we now invert them after the creation. OPW: 4317320 Forward-Port-Of: odoo/odoo#192328
Current behavior before PR: In channel it was not possible to mention internal users which are non-members of channel. Desired behavior after PR is merged: now it is possible to mention internal users who has access to the channel task-4100364 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176758
Original PR description
Current behavior before PR: In channel it was not possible to mention internal users which are non-members of channel. Desired behavior after PR is merged: now it is possible to mention internal users who has access to the channel task-4100364 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176758
I encountered an error when upgrading the database. This error is because the `fname` does not exist in `self._fields` after the field has been removed in the code. Here is all the traceback : ``` Traceback (most recent call last): File "/home/do/my_projects/odoo-17/odoo17/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/do/my_projects/odoo-17/odoo17/odo
Original PR description
I encountered an error when upgrading the database. This error is because the `fname` does not exist in `self._fields` after the field has been removed in the code. Here is all the traceback : ```…
I encountered an error when upgrading the database.
This error is because the `fname` does not exist in `self._fields` after the field has been removed in the code.
Here is all the traceback :
```
Traceback (most recent call last):
File "/home/do/my_projects/odoo-17/odoo17/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/do/my_projects/odoo-17/odoo17/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/do/my_projects/odoo-17/odoo17/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/do/my_projects/odoo-17/odoo17/odoo/modules/loading.py", line 536, in load_modules
env['ir.model.data']._process_end(processed_modules)
File "/home/do/my_projects/odoo-17/OpenUpgrade/openupgrade_framework/odoo_patch/odoo/addons/base/models/ir_model.py", line 77, in _process_end
return IrModelData._process_end._original_method(self, modules)
File "/home/do/my_projects/odoo-17/odoo17/odoo/addons/base/models/ir_model.py", line 2558, in _process_end
self._process_end_unlink_record(record)
File "/home/do/my_projects/odoo-17/odoo17/odoo/addons/base/models/ir_model.py", line 2487, in _process_end_unlink_record
record.unlink()
File "/home/do/my_projects/odoo-17/odoo17/addons/mail/models/ir_model_fields.py", line 52, in unlink
'sequence': self.env[field.model_id.model]._mail_track_get_field_sequence(field.name),
File "/home/do/my_projects/odoo-17/odoo17/addons/mail/models/models.py", line 181, in _mail_track_get_field_sequence
if isinstance(fname, IrModelFields):
KeyError: 'date_process'
```
close: https://github.com/odoo/odoo/issues/172891
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#172881The question_selection steps of the chatbot suffer from several issues. In [1], a fix was made to make the chatbot work with answers containing ampersands, but this fix broke other special characters such as "'". This step also does not handle well answers containing a subset of words, such as "X"/"not X". This occurs because the client code tries to guess which answer was selected after posting the answer. This PR updates the flow to save the answer when the message is posted. As a resul
Original PR description
The question_selection steps of the chatbot suffer from several issues. In [1], a fix was made to make the chatbot work with answers containing ampersands, but this fix broke other special characters such as "'". This step also does not handle well answers containing a subset of words, such as "X"/"not X". This occurs because the client code tries to guess which answer was selected after posting the answer. This PR updates the flow to save the answer when the message is posted. As a result, there is no need to guess which answer was selected anymore, and all these issues are fixed. [1]: https://github.com/odoo/odoo/pull/189313 opw-4369966,4436567. Forward-Port-Of: odoo/odoo#192076
We improve the image reliability by: - Improving handlers cleanup (we only removed os-specific handlers but downloaded all), - Forcing Odoo service to restart after checkout, even if an error occurred. Task: 4433461 Forward-Port-Of: odoo/odoo#191928
Original PR description
We improve the image reliability by: - Improving handlers cleanup (we only removed os-specific handlers but downloaded all), - Forcing Odoo service to restart after checkout, even if an error occurred. Task: 4433461 Forward-Port-Of: odoo/odoo#191928
The label of the "Task" field in the wizard that opens when you "Add a line" to "My Timesheets" was not exportable for translation after [this commit] and thus never translated in the UI. This commit fixes that. <img width="851" alt="image" src="https://github.com/user-attachments/assets/5477ab35-7f84-402e-8d62-1dd8d8edd8ca" /> [this commit]: https://github.com/odoo/odoo/commit/e82567f9d5842bd95fe01ba3b9f54a65437e313f [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Fo
Original PR description
The label of the "Task" field in the wizard that opens when you "Add a line" to "My Timesheets" was not exportable for translation after [this commit] and thus never translated in the UI. This commit fixes that. <img width="851" alt="image" src="https://github.com/user-attachments/assets/5477ab35-7f84-402e-8d62-1dd8d8edd8ca" /> [this commit]: https://github.com/odoo/odoo/commit/e82567f9d5842bd95fe01ba3b9f54a65437e313f [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#193108
Step to reproduce * open the reconcilation widget and toggle the list view * multi edit bank statement lines and assign them a new bank statement with name 'BLABLA 1' * click save and see how Odoo just didn't keep your name at all The reason is that the module account_bank_statement_extract forces the recomputation of the name when the statement's date changes which happens at the creation (and triggers our bug) but also when the OCR fills that value (in which case we still want that).
Original PR description
Step to reproduce * open the reconcilation widget and toggle the list view * multi edit bank statement lines and assign them a new bank statement with name 'BLABLA 1' * click save and see how Odoo…
Step to reproduce * open the reconcilation widget and toggle the list view * multi edit bank statement lines and assign them a new bank statement with name 'BLABLA 1' * click save and see how Odoo just didn't keep your name at all The reason is that the module account_bank_statement_extract forces the recomputation of the name when the statement's date changes which happens at the creation (and triggers our bug) but also when the OCR fills that value (in which case we still want that). So to fix that, * the default name of the statement line now check if the statement date is falsy, to avoid having a default name as 'BNK1 Statement False', and fallback on the create_date * when filling the OCR values, we check if the statement still has the same structure, we can assume it wasn't manually changed and we can safely replace the default name ticket-4424021 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#192759
Steps: - Login as Mitchell Admin - Create 8 user (B, C, D, E, F, G, H, I) to reach search limit - Rename Mitchell Admin to Admin Mitchell to be the first result - Open a user dropdown (employee form) Actual result: - Admin Mitchell appears twice Expected result: - Admin Mitchell appears at first position - Admin Mitchell appears only once opw-4430590 Forward-Port-Of: odoo/odoo#192075
Original PR description
Steps: - Login as Mitchell Admin - Create 8 user (B, C, D, E, F, G, H, I) to reach search limit - Rename Mitchell Admin to Admin Mitchell to be the first result - Open a user dropdown (employee form) Actual result: - Admin Mitchell appears twice Expected result: - Admin Mitchell appears at first position - Admin Mitchell appears only once opw-4430590 Forward-Port-Of: odoo/odoo#192075
Issue ----- Read-only fields appear in the export menu when the "I want to update data (import-compatible export)" checkbox is active. Cause ----- The `readonly` key is missing from the field dictionnary leading to all fields being considered as not read-only. https://github.com/odoo/odoo/blob/a546e2e5a87c311bef054ca4a6909e63d70c91fd/addons/web/controllers/export.py#L389-L390 Issue from 2b87effeb461acddf327884dd72c00ee22a4c9aa since only some attributes of the fields are fetched. opw-
Original PR description
Issue ----- Read-only fields appear in the export menu when the "I want to update data (import-compatible export)" checkbox is active. Cause ----- The `readonly` key is missing from the field dictionnary leading to all fields being considered as not read-only. https://github.com/odoo/odoo/blob/a546e2e5a87c311bef054ca4a6909e63d70c91fd/addons/web/controllers/export.py#L389-L390 Issue from 2b87effeb461acddf327884dd72c00ee22a4c9aa since only some attributes of the fields are fetched. opw-4446090 Forward-Port-Of: odoo/odoo#192486
Previously, when refunding a product with a serial number, the serial number was not being properly set in the refund order. This caused issues in inventory management as the POS transfer was not automatically validated. After this commit, the serial number of the refunded product is correctly assigned in the refund order and the POS transfer is automatically validated. opw-4387411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of
Original PR description
Previously, when refunding a product with a serial number, the serial number was not being properly set in the refund order. This caused issues in inventory management as the POS transfer was not automatically validated. After this commit, the serial number of the refunded product is correctly assigned in the refund order and the POS transfer is automatically validated. opw-4387411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192497 Forward-Port-Of: odoo/odoo#191147
In this commit, we prefer to use selector in trigger instead of use native in run function. This is better to ensure trigger is in DOM when the run is activated. The findTrigger method in tour engine is based on MutationObserver while run function in a step definition is launched once the trigger has been found. This is why it can cause the following error during the tour. runbot-error-id~106439 Description of the issue/feature this PR addresses: Current behavior before PR: Desired
Original PR description
In this commit, we prefer to use selector in trigger instead of use native in run function. This is better to ensure trigger is in DOM when the run is activated. The findTrigger method in tour engine is based on MutationObserver while run function in a step definition is launched once the trigger has been found. This is why it can cause the following error during the tour. runbot-error-id~106439 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#193183
This fixes the indeterminate test failures where the Test Product isn't found in the product list. Related: https://github.com/odoo/enterprise/pull/76894 Forward-Port-Of: odoo/odoo#193123
Original PR description
This fixes the indeterminate test failures where the Test Product isn't found in the product list. Related: https://github.com/odoo/enterprise/pull/76894 Forward-Port-Of: odoo/odoo#193123
**Steps to Reproduce:** - Install data_recycle module. - Navigate to Configuration → Rules and create any rule for the data_recycle. **Issue:** - The selected option for the notify_frequency_period field is not displayed correctly due to a fixed width class (w-25) assigned to its parent div element.  **Solution:** - Updated the width class from w-25 to w-50 to ensure proper display of the select
Original PR description
**Steps to Reproduce:** - Install data_recycle module. - Navigate to Configuration → Rules and create any rule for the data_recycle. **Issue:** - The selected option for the notify_frequency_period field is not displayed correctly due to a fixed width class (w-25) assigned to its parent div element.  **Solution:** - Updated the width class from w-25 to w-50 to ensure proper display of the selected option.  opw-4414071 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192851 Forward-Port-Of: odoo/odoo#191639
Steps: === - Open a POS shop. - Create an order, select a customer, and validate it. Issue: === - The generated receipt did not include customer name and phone details. Cause: === - Customer details were not being passed correctly to the receipt template. Fix: === - Updated the function for setting customer details to correctly include in the receipt. Task- 4431623 Forward-Port-Of: odoo/odoo#193084 Forward-Port-Of: odoo/odoo#191972
Original PR description
Steps: === - Open a POS shop. - Create an order, select a customer, and validate it. Issue: === - The generated receipt did not include customer name and phone details. Cause: === - Customer details were not being passed correctly to the receipt template. Fix: === - Updated the function for setting customer details to correctly include in the receipt. Task- 4431623 Forward-Port-Of: odoo/odoo#193084 Forward-Port-Of: odoo/odoo#191972
Steps: - Enable the self-invoicing option from Configuration → Settings → Bills & Receipts. - Open the POS system. - Create an order and validate it. - Scan the QR code for self-invoicing displayed on the receipt. - The QR code opens the portal. Issue: - A traceback error appears when opening the page. Cause: - A problem in the `account_peppol` module was causing it to search for an element on the page that wasn’t available. Fix: - Included a condition such that If the element i
Original PR description
Steps: - Enable the self-invoicing option from Configuration → Settings → Bills & Receipts. - Open the POS system. - Create an order and validate it. - Scan the QR code for self-invoicing displayed on the receipt. - The QR code opens the portal. Issue: - A traceback error appears when opening the page. Cause: - A problem in the `account_peppol` module was causing it to search for an element on the page that wasn’t available. Fix: - Included a condition such that If the element isn’t found, it skips the step and assigns a null value to the variable, resolving the error. Task: 4438885 Forward-Port-Of: odoo/odoo#192701
This commit adds a "X" next to "Turn on notifications" to quickly dismiss the suggestion to enable push notifications. Note that this keeps the push permission to "Ask", as it cannot be changed programmatically. So if the user wants to change the push permissions, it should be manually changed to "Allow" or "Denied" from browser settings or should clear the local storage content in order to display "Turn on notifications" in messaging menu again. Task-4446924 Before  After  Forward-Port-Of: odoo/odoo#192336
Forward-Port-Of: odoo/enterprise#76595
Original PR description
Forward-Port-Of: odoo/enterprise#76595
Issue: in the current version is not posible to add bills or remove them when the asset is already running or closed, and the current error message shown to the user is "It is not possible to delete an item that is linked to a posted entry." Solution: Since this behavior will be upgraded in master we show a more specific error message to the user for stable versions. opw-3369633 Forward-Port-Of: odoo/enterprise#76765 Forward-Port-Of: odoo/enterprise#71561
Original PR description
Issue: in the current version is not posible to add bills or remove them when the asset is already running or closed, and the current error message shown to the user is "It is not possible to delete an item that is linked to a posted entry." Solution: Since this behavior will be upgraded in master we show a more specific error message to the user for stable versions. opw-3369633 Forward-Port-Of: odoo/enterprise#76765 Forward-Port-Of: odoo/enterprise#71561
1) Action button on Appointment Type kanban view only appear on hover, it should be always visible. 2) When a user books a meeting, Odoo creates an activity, which is unnecessary for calendar event linked with appointment type. This PR exclude appointment model in valid_activity_model_ids using helper function, so we won't get any activity on appointment type. (See community commit.) 3) The 'Connect Google' button with info and warning it's too vague for users. Add new warning when ther
Original PR description
1) Action button on Appointment Type kanban view only appear on hover, it should be always visible. 2) When a user books a meeting, Odoo creates an activity, which is unnecessary for calendar event…
1) Action button on Appointment Type kanban view only appear on hover, it should be always visible. 2) When a user books a meeting, Odoo creates an activity, which is unnecessary for calendar event linked with appointment type. This PR exclude appointment model in valid_activity_model_ids using helper function, so we won't get any activity on appointment type. (See community commit.) 3) The 'Connect Google' button with info and warning it's too vague for users. Add new warning when there are no creds but Google Calendar is Installed. Show old warning + info if creds are found but not synced. 4) The translation icon is badly positioned, it should be inside the field. 5) On Appointment Resource Create, Make Timezone field invisible if there is no resource_id. 6) When creating a booking in POS, the admin is always set as an attendee, becuase default for `default_partner_ids` was set to current user on create, which is not correct. 7) Change booked_mail_template_id field's name to 'Booking Email', as it may contain mail for appointment event which yet to be confirmed. Task-4243603 Forward-Port-Of: odoo/enterprise#72274
The related community commit fixed the issue where we forgot to extract terms from spreadsheet files ending in "_dashboard.osheet.json" and were file references were added multiple times in the .pot files. This commit re-exports all spreadsheet pot files again using the fixed code. Related to https://github.com/odoo/odoo/pull/190598 Forward-Port-Of: odoo/enterprise#76820 Forward-Port-Of: odoo/enterprise#75605
Original PR description
The related community commit fixed the issue where we forgot to extract terms from spreadsheet files ending in "_dashboard.osheet.json" and were file references were added multiple times in the .pot files. This commit re-exports all spreadsheet pot files again using the fixed code. Related to https://github.com/odoo/odoo/pull/190598 Forward-Port-Of: odoo/enterprise#76820 Forward-Port-Of: odoo/enterprise#75605
Since 18.0[^1], the ending balance is done by summing the values fetched instead of querying the database again. While this is a great performance gain, it also means that we can't get other values like the balance. Note that the Trial Balance has been refactored in 18.1[^2], so a simple fix is enough. opw-4435450 [^1]: e598fcb48b5e4f0126406a4008f175a88528ba85 [^2]: a7e1ec20e07efc39bca44d3ae613a54770175273 Forward-Port-Of: odoo/enterprise#76535
Original PR description
Since 18.0[^1], the ending balance is done by summing the values fetched instead of querying the database again. While this is a great performance gain, it also means that we can't get other values like the balance. Note that the Trial Balance has been refactored in 18.1[^2], so a simple fix is enough. opw-4435450 [^1]: e598fcb48b5e4f0126406a4008f175a88528ba85 [^2]: a7e1ec20e07efc39bca44d3ae613a54770175273 Forward-Port-Of: odoo/enterprise#76535
This commit fixes an issue with an icon in dark mode and some UX on mobile. The `All changes saved` icon inside the topbar wasn't really visible in dark mode. To fix this, an invert filter is applied to the img when Odoo is in dark mode. This way instead of black the icon is white. In mobile, there is no possibility to create articles below a specific route, because the buttons are invisible. To fix, this we rendered the buttons always visible when the user is on mobile. task-4377610 Forw
Original PR description
This commit fixes an issue with an icon in dark mode and some UX on mobile. The `All changes saved` icon inside the topbar wasn't really visible in dark mode. To fix this, an invert filter is applied to the img when Odoo is in dark mode. This way instead of black the icon is white. In mobile, there is no possibility to create articles below a specific route, because the buttons are invisible. To fix, this we rendered the buttons always visible when the user is on mobile. task-4377610 Forward-Port-Of: odoo/enterprise#76946 Forward-Port-Of: odoo/enterprise#75180
This allows to customize the ability to generate a task and/or project per sale.order.line instead of per order only. Forward-Port-Of: odoo/enterprise#75643
Original PR description
This allows to customize the ability to generate a task and/or project per sale.order.line instead of per order only. Forward-Port-Of: odoo/enterprise#75643
Steps to reproduce: 1. remove the owner of a document. 2. add tags to that document. 3. hovering on it will move other documents slightly. Technical Reason: Before hover, the elements are set to display: 'none', which triggers layout recalculations and reflows in the browser when the elements are added or removed from the rendering tree on hover. After this commit: No layout shifting to documents on hover. Task-4442559 Forward-Port-Of: odoo/enterprise#76507
Original PR description
Steps to reproduce: 1. remove the owner of a document. 2. add tags to that document. 3. hovering on it will move other documents slightly. Technical Reason: Before hover, the elements are set to display: 'none', which triggers layout recalculations and reflows in the browser when the elements are added or removed from the rendering tree on hover. After this commit: No layout shifting to documents on hover. Task-4442559 Forward-Port-Of: odoo/enterprise#76507
Currently our translation extraction mechanism for Javascript does not support `_t()` calls that are inside template strings. Because of that a bunch of placeholders were not exported for translation. This commit fixed that by rewriting the code without nesting `_t()` calls in template strings. [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#76829
Original PR description
Currently our translation extraction mechanism for Javascript does not support `_t()` calls that are inside template strings. Because of that a bunch of placeholders were not exported for translation. This commit fixed that by rewriting the code without nesting `_t()` calls in template strings. [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#76829
Backport of a00faee178b94e455a670fb59a3c77c3827b3b49 Forward-Port-Of: odoo/enterprise#76769 Forward-Port-Of: odoo/enterprise#76541
Original PR description
Backport of a00faee178b94e455a670fb59a3c77c3827b3b49 Forward-Port-Of: odoo/enterprise#76769 Forward-Port-Of: odoo/enterprise#76541
To reproduce the issue: 1) Create a vendor bill for 100€, with a tax of 15% 2) In the grouped generic tax reports, the base will be 100 and the tax 15 3) Create an expense of 200€, with the same tax, paid by the company. Fully validate it and post the entry. ====> The grouped generic tax reports now should display 300 of base, and 45 of tax. It does only show 200 of base, though. This happens because when post-processing the results of the query ran by the report, we do this https://github
Original PR description
To reproduce the issue: 1) Create a vendor bill for 100€, with a tax of 15% 2) In the grouped generic tax reports, the base will be 100 and the tax 15 3) Create an expense of 200€, with the same tax,…
To reproduce the issue: 1) Create a vendor bill for 100€, with a tax of 15% 2) In the grouped generic tax reports, the base will be 100 and the tax 15 3) Create an expense of 200€, with the same tax, paid by the company. Fully validate it and post the entry. ====> The grouped generic tax reports now should display 300 of base, and 45 of tax. It does only show 200 of base, though. This happens because when post-processing the results of the query ran by the report, we do this https://github.com/odoo/enterprise/blame/16.0/account_reports/models/account_generic_tax_report.py#L406 , so we essentially don't add the base amounts of the tax lines whose identification key has already been treated. This is important for taxes with multiple tax repartition lines. In our case, a line is generated by the query for both the invoice and the expense entry. This is because the query groups on display_type: the expense line has display_type = 'product', while the invoice has 'tax'. This grouping was introduced here https://github.com/odoo/enterprise/commit/67f841ee36cb5a8ef95ae3dd3859239a4d10b99d to avoid counting the base amounts of the cash rounding lines as additional base amounts. We fix this by slightly tweaking the query, in order for rounding lines to be considered as having a base amount of 0. opw-3890736 Forward-Port-Of: odoo/enterprise#76929 Forward-Port-Of: odoo/enterprise#76536
Forward-Port-Of: odoo/enterprise#75397
Original PR description
Forward-Port-Of: odoo/enterprise#75397
…nsaction list view Step to reproduce * open the reconcilation widget and toggle the list view * multi edit bank statement lines and assign them a new bank statement with name 'BLABLA 1' * click save and see how Odoo just didn't keep your name at all The reason is that the module account_bank_statement_extract forces the recomputation of the name when the statement's date changes which happens at the creation (and triggers our bug) but also when the OCR fil> So to fix that, * the de
Original PR description
…nsaction list view Step to reproduce * open the reconcilation widget and toggle the list view * multi edit bank statement lines and assign them a new bank statement with name 'BLABLA 1' * click save and see how Odoo just didn't keep your name at all The reason is that the module account_bank_statement_extract forces the recomputation of the name when the statement's date changes which happens at the creation (and triggers our bug) but also when the OCR fil> So to fix that, * the default name of the statement line now check if the statement date is falsy, to avoid having a default name as 'BNK1 Statement False', and fallback on the create_date. Same for the journal_code since journal_id isn't required. * when filling the OCR values, we assume it wasn't manually changed (why whould it be?) and we replace the default name since we now know the real date ticket-4424021 Forward-Port-Of: odoo/enterprise#76656
Steps to reproduce ================== - Create multiple companies - In the current user settings, select a default company that is not the first one - Use another company - logout - login => The previously used company is kept Cause of the issue ================== The cids cookie was not invalidated because super was not called opw-4426742 Forward-Port-Of: odoo/enterprise#76800 Forward-Port-Of: odoo/enterprise#76716
Original PR description
Steps to reproduce ================== - Create multiple companies - In the current user settings, select a default company that is not the first one - Use another company - logout - login => The previously used company is kept Cause of the issue ================== The cids cookie was not invalidated because super was not called opw-4426742 Forward-Port-Of: odoo/enterprise#76800 Forward-Port-Of: odoo/enterprise#76716
This commit ensures the asynchronous fetching cron is activated or deactivated only when necessary. Previously, the cron was executed every 5 minutes to check for online accounts to fetch transactions, even when none were present, leading to useless call to the cron. With this update, a toggle function is introduced, which is triggered whenever a journal or an online account is created, modified, or removed. Before deactivating the cron, the function verifies that no journals with an online
Original PR description
This commit ensures the asynchronous fetching cron is activated or deactivated only when necessary. Previously, the cron was executed every 5 minutes to check for online accounts to fetch transactions, even when none were present, leading to useless call to the cron. With this update, a toggle function is introduced, which is triggered whenever a journal or an online account is created, modified, or removed. Before deactivating the cron, the function verifies that no journals with an online account are currently in the fetching process, preventing unnecessary execution. no task id Forward-Port-Of: odoo/enterprise#76843
Before this commit, it could happen that the partner associated to the current company was not automatically loaded at the start of the POS session. Since this parter is required for proper operation of l10n_it_pos, it could lead to unexpected errors. After this commit, the partner is explicitly force-loaded at the start of the POS session to ensure proper operation. opw-4394672 Linked community PR: https://github.com/odoo/odoo/pull/193196 Forward-Port-Of: odoo/enterprise#76517
Original PR description
Before this commit, it could happen that the partner associated to the current company was not automatically loaded at the start of the POS session. Since this parter is required for proper operation of l10n_it_pos, it could lead to unexpected errors. After this commit, the partner is explicitly force-loaded at the start of the POS session to ensure proper operation. opw-4394672 Linked community PR: https://github.com/odoo/odoo/pull/193196 Forward-Port-Of: odoo/enterprise#76517
**Steps to Reproduce:** - Install data_cleaning and data_merge modules. - Navigate to Configuration → Rules and create any rule for the above models. **Issue:** - The selected option for the notify_frequency_period field is not displayed correctly due to a fixed width class (w-25) assigned to its parent div element.  **Solution:** - Updated the width class from w-25 to w-50 to ensure proper disp
Original PR description
**Steps to Reproduce:** - Install data_cleaning and data_merge modules. - Navigate to Configuration → Rules and create any rule for the above models. **Issue:** - The selected option for the notify_frequency_period field is not displayed correctly due to a fixed width class (w-25) assigned to its parent div element.  **Solution:** - Updated the width class from w-25 to w-50 to ensure proper display of the selected option.  opw-4414071 Forward-Port-Of: odoo/enterprise#76684 Forward-Port-Of: odoo/enterprise#76122
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery creations handled in _post_invoice_hook are all done at the end of the last batch, without any commit. If the database has a lot of invoices to generate (ex: ~200), it would take a few minutes before the delivery creations to start. This is enough time for the CRON "payment: post-process transaction
Original PR description
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery…
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery creations handled in _post_invoice_hook are all done at the end of the last batch, without any commit. If the database has a lot of invoices to generate (ex: ~200), it would take a few minutes before the delivery creations to start. This is enough time for the CRON "payment: post-process transactions" to start and handle all the invoices & payments created by "_create_recurring_invoice". The 2 CRON were then likely to create SerializationFailure due to a concurrent update. With this commit, each batch creates its own deliveries before triggering the next batch. If the delivery creations do fail: - The error is caught as to not prevent the next batch from being triggered. - An exception activity is created on the subscription to notify the customer about the error. - A contextual action is available to manually trigger the delivery. OPW-4319019 --- When the delivery creation failed, you can easily spot it on the list view thanks to the activity warning:  --- ## Example log ``` 2024-11-14 07:48:53,757 96554 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (30.353s). 2024-11-14 07:58:26,142 96886 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 07:58:57,145 96886 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (31.003s). 2024-11-14 08:05:51,910 97204 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:06:46,734 97204 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (54.823s). 2024-11-14 08:06:53,143 97262 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:07:46,207 97262 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (53.064s). 2024-11-14 08:07:55,496 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:08:30,928 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 08:08:44,957 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (49.461s). 2024-11-14 08:08:50,945 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:09:18,543 97300 ERROR customer-database odoo.addons.base.models.ir_cron: Call from cron Sale Subscription: generate recurring invoices and payments for server action #705 failed in Job #10 2024-11-14 08:15:52,854 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (441.926s). 2024-11-14 08:18:31,161 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 08:21:16,823 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (165.662s). 2024-11-14 08:28:31,865 99066 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. ``` - At the beginning: `payment: post-process transactions` take ~30 secs - Then, `Sale Subscription: generate recurring invoices and payments` runs a few times (as expected). - `payment: post-process transactions` re-runs, and it takes 441.926. During this time, `Sale Subscription: generate recurring invoices and payments` starts and failed. --- ## A few points of information/discussion: - The SerializationFailure is systematic on the customer database, who has ~200 subscriptions invoiced each day. - The added action "Subscription: Generate delivery" is optional, I am amenable to remove it from this PR, but we would just block the customer with undelivered stock. - In master, it would be better to automatically detect the deliveries not done and re-generate each day. However, I was unable to find a proper way to do it without adding a field or changing the behavior of an existing one. - I originally wanted to create to add a button to the form view like "Create Delivery", however, like above I was unable to properly detect undelivered subscriptions. - The exception activity does not directly notify the users via discuss, do you think I should add the option? - I did not (yet) created tests for this error. To properly do so, I would need to reproduce a SerializationFailure which I'm unsure of how to do without doing commits. I could simply fake it by overwriting the `_action_launch_stock_rule` to raise an Error... TBD Forward-Port-Of: odoo/enterprise#75618 Forward-Port-Of: odoo/enterprise#73911
Currently, a traceback occurs if the user installs an inventory module, When the accounting module was installed, there was no state_id in the company. To reproduce this issue: 1) Install `Accounting` and remove the state from the company 2) Update a Fiscal Position record with Foreign Tax and Federal State 3) Now install the inventory module Error:- ``` TypeError: sequence item 0: expected str instance, bool found ``` Here, State_id is not a required field in the company, So,
Original PR description
Currently, a traceback occurs if the user installs an inventory module, When the accounting module was installed, there was no state_id in the company. To reproduce this issue: 1) Install…
Currently, a traceback occurs if the user installs an inventory module, When the accounting module was installed, there was no state_id in the company. To reproduce this issue: 1) Install `Accounting` and remove the state from the company 2) Update a Fiscal Position record with Foreign Tax and Federal State 3) Now install the inventory module Error:- ``` TypeError: sequence item 0: expected str instance, bool found ``` Here, State_id is not a required field in the company, So, the user can remove it. When there is no `state_id` and a fiscal position record has a Foreign Tax. We get a traceback from the below lines. https://github.com/odoo/enterprise/blob/1c6f0273e76b6dfb89ef65eb359e620b9c4c5759/account_reports/models/res_company.py#L216-L219 This is because we have a `vat_fpos_with_state_count` value due to foreign vat in fiscal position, but we don't have a state_id in the company. So the `state_codes` value will be a list of bool, which leads to the above traceback. We can resolve this issue by making the code more robust. sentry-6203209197 Forward-Port-Of: odoo/enterprise#76784