Monday, February 10, 2025
29 changes · saas-18.1
Resolved issues and error corrections
Loyalty and promotion settings can now be saved even if the default Services product category was deleted. This prevents an unexpected setup error and keeps sales configuration workflows running smoothly.
Original PR description
Currently, an exception is generated when a user tries to find the 'Services' product category after it has been deleted. Steps to reproduce: 1. Install the sale_management module. 2. Navigate to…
Currently, an exception is generated when a user tries to find the 'Services' product category after it has been deleted. Steps to reproduce: 1. Install the sale_management module. 2. Navigate to Sales -> Configuration -> Product Categories. 3. Delete the 'Services' category. 4. Go to Sales Settings. 5. Enable 'Promotions, Loyalty & Gift Cards'. 6. Click Save -> An error occurs. Error: ```ParseError while parsing /home/odoo/src/odoo/saas-18.1/addons/loyalty/data/loyalty _data.xml:4, somewhere inside ``` This issue[1] occurs because when the system tries to reference the missing 'Services' product category, it results in a ParseError due to a missing required record. [1] - https://github.com/odoo/odoo/blob/4d9984d0b5f5a856104d11261fecd27ddc2e5466/addons/loyalty/data/loyalty_data.xml#L4-L11 This fix resolves the issue by providing a False value when the 'Services' product category is missing. sentry-6243406444 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects when scheduled background jobs stop after reaching the 10-second limit. It helps prevent jobs from running longer than intended, improving system reliability without changing user-facing workflows.
Original PR description
Fix condition for odoo/odoo#195807. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Example of steps: - Install `web_studio` - Open any view editor with `web_studio` - Try to edit a field required condition - Pick a char field - Add `starts_with` or `ends_with` operator - Traceback The solution is to remove these two operators from expression_editor as this is not a python expression, `starts_with` and `ends_with` are interpreted as `=ilike`, but there is no way to translate it easily to a python expression like for `=`, `>=`, etc.. opw
Original PR description
Example of steps:
- Install `web_studio`
- Open any view editor with `web_studio`
- Try to edit a field required condition
- Pick a char field
- Add `starts_with` or `ends_with` operator
- Traceback
The solution is to remove these two operators from expression_editor as
this is not a python expression,
`starts_with` and `ends_with` are interpreted as `=ilike`, but there is
no way to translate it easily to a python expression like for `=`, `>=`, etc..
opw-4551688
Forward-Port-Of: odoo/odoo#197121Before this commit, when the login screen was left idle using an employee login, the screensaver would appear as expected. However, upon user interaction (e.g., moving the mouse), the system would update the previous screen to the screen saver. This causing issues during login where the screensaver would be displayed. opw-4494087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196472
Original PR description
Before this commit, when the login screen was left idle using an employee login, the screensaver would appear as expected. However, upon user interaction (e.g., moving the mouse), the system would update the previous screen to the screen saver. This causing issues during login where the screensaver would be displayed. opw-4494087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196472
Since the function message_post on mail thread has been built to be called on exactly one record and the function write on employee is for multiple records, we need to call it for each employee we are writing on. It has been introduced in: https://github.com/odoo/odoo/pull/143217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196257
Original PR description
Since the function message_post on mail thread has been built to be called on exactly one record and the function write on employee is for multiple records, we need to call it for each employee we are writing on. It has been introduced in: https://github.com/odoo/odoo/pull/143217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196257
Repro steps: - Add `Tax String` to `Product Page Extra Fields` for one of your websites - Add taxes from a company that isn't linked to that website for one of your products - Open that product's product page in eCommerce - You get an access error The issue is that we try to read the taxes for all companies when opening the product page. Instead, we should only read the taxes for the current company. opw-4435721 Forward-Port-Of: odoo/odoo#197044 Forward-Port-Of: odoo/odoo#194881
Original PR description
Repro steps: - Add `Tax String` to `Product Page Extra Fields` for one of your websites - Add taxes from a company that isn't linked to that website for one of your products - Open that product's product page in eCommerce - You get an access error The issue is that we try to read the taxes for all companies when opening the product page. Instead, we should only read the taxes for the current company. opw-4435721 Forward-Port-Of: odoo/odoo#197044 Forward-Port-Of: odoo/odoo#194881
Scenario: - install hr_recruitment but not documents (to have the right view) - go to Employee > Configuration > Recruitment | Job Positions - choose a job positions with documents and click on Documents - click on Applicant column on one of the rows => traceback shown: OwlError: Invalid props for component 'FormController': 'resId' is not a number or boolean at Object.validateProps Reason: In saas-17.2 with a7586fdb4123481fd8794ef99fdc372e95de7459 merged in february 2024, m
Original PR description
Scenario: - install hr_recruitment but not documents (to have the right view) - go to Employee > Configuration > Recruitment | Job Positions - choose a job positions with documents and click on…
Scenario: - install hr_recruitment but not documents (to have the right view) - go to Employee > Configuration > Recruitment | Job Positions - choose a job positions with documents and click on Documents - click on Applicant column on one of the rows => traceback shown: OwlError: Invalid props for component 'FormController': 'resId' is not a number or boolean at Object.validateProps Reason: In saas-17.2 with a7586fdb4123481fd8794ef99fdc372e95de7459 merged in february 2024, many2one_reference was changed from a simple integer to either 0 if unset, or a object containing resId and displayName keys. Fix: Get the id with .resId and this should not happen, but test if the record is set with "if(res_id && ...)" in case res_id was 0. Note: without the fix, the added test fails by opening the view if res_id was 0, and if not the next click would fail with: OwlError: Invalid props for component 'FormController': 'resId' is not a number or boolean opw-4384139 PR note: the test could be run without mails models, but then we would need to mock a lot of models for services (like `mail.ChatHub`) or a method like `prepareRegistry` [from studio](https://github.com/odoo/enterprise/blob/f5b7b53963829b351446e9b6f71e00f21291bc58/web_studio/static/tests/view_editor_tests_utils.js#L123-L153) that would remove all unnecessary services for the test. Forward-Port-Of: odoo/odoo#191510
Before this commit, the credit note's tax lines were causing an issue during reconciliation because they were reconciled with both the invoice and with the cash basis entry. Reproduce: * Enable cash basis accounting. * On the tax that will be used, set: Tax Exigibility: Based on Payment. * Allow reconciliation on the associated account. * Add a product without tax and save. * Then, add a tax. * Try to create and post a credit note for this invoice Forward-Port-Of: odoo/odoo#196933 Forw
Original PR description
Before this commit, the credit note's tax lines were causing an issue during reconciliation because they were reconciled with both the invoice and with the cash basis entry. Reproduce: * Enable cash basis accounting. * On the tax that will be used, set: Tax Exigibility: Based on Payment. * Allow reconciliation on the associated account. * Add a product without tax and save. * Then, add a tax. * Try to create and post a credit note for this invoice Forward-Port-Of: odoo/odoo#196933 Forward-Port-Of: odoo/odoo#192586
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#192240
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192240
With the introduction of Invoicing Enterprise (access to bank recon etc) a new user group was created "Invoicing & Banks" (`group_account_basic`) This group should also be able to access the customer statement / partner ledger (from the partner smart button) Task-4465208 Forward-Port-Of: odoo/odoo#196936
Original PR description
With the introduction of Invoicing Enterprise (access to bank recon etc) a new user group was created "Invoicing & Banks" (`group_account_basic`) This group should also be able to access the customer statement / partner ledger (from the partner smart button) Task-4465208 Forward-Port-Of: odoo/odoo#196936
Revert changes from [commit] due to `m.facebook.com` using 'X-Frame-Options' header set to 'deny', which prevented iframe embedding across domains. META has now fixed this issue, so this PR restores the snippet's visibility on mobile devices. [commit]: https://github.com/odoo/odoo/commit/588f910da03d6284a57c2fab8fd042ef3169666f task-4507102 Forward-Port-Of: odoo/odoo#196108 Forward-Port-Of: odoo/odoo#194843
Original PR description
Revert changes from [commit] due to `m.facebook.com` using 'X-Frame-Options' header set to 'deny', which prevented iframe embedding across domains. META has now fixed this issue, so this PR restores the snippet's visibility on mobile devices. [commit]: https://github.com/odoo/odoo/commit/588f910da03d6284a57c2fab8fd042ef3169666f task-4507102 Forward-Port-Of: odoo/odoo#196108 Forward-Port-Of: odoo/odoo#194843
**Current behavior:** As of now, whenever a journal is set to "Hash on Post", the user is granted the secured group rights. This allows the user to see the lock icon in the status bar, the extra default filters in the list views of Journal Entries and Journal Items, and access to the Secure Entries wizard. However, if only entries from journals with "Hash on Post" are secured, these features are not necessary. The user trusts Odoo to hash any and all entries that are posted in that specific
Original PR description
**Current behavior:** As of now, whenever a journal is set to "Hash on Post", the user is granted the secured group rights. This allows the user to see the lock icon in the status bar, the extra…
**Current behavior:** As of now, whenever a journal is set to "Hash on Post", the user is granted the secured group rights. This allows the user to see the lock icon in the status bar, the extra default filters in the list views of Journal Entries and Journal Items, and access to the Secure Entries wizard. However, if only entries from journals with "Hash on Post" are secured, these features are not necessary. The user trusts Odoo to hash any and all entries that are posted in that specific journal. **Expected behavior:** When "Hash on Post" is active, the user does not need any additional user group. However, if even one entry is secured and does not belong to a journal with the "hash on post" feature, the user will then need access to the new features, such as the lock icon, default filters, and the Secure Entries wizard. **Approach:** This commit removes the calls to _activate_group_account_secured() when setting a journal to "Hash on Post". It also removes it from the Secure Entries wizard. Instead, we add the key 'journal_restrict_mode' to the chains_to_hash, which indicates the value of the journal's restrict_mode_hash_table field. If at least one chain with moves does not have 'journal_restrict_mode', only then we call _activate_group_account_secured() from _hash_moves(). This will only happen when the Secure Entries wizard is used, hashing entries from all journals. task-4348380 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196748
[IMP] account - imported line shouldn't change tax Foward-port https://github.com/odoo/odoo/pull/193483 messed up and removed important code of https://github.com/odoo/odoo/pull/172787. This commit adds it back. task-4547597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196801
Original PR description
[IMP] account - imported line shouldn't change tax Foward-port https://github.com/odoo/odoo/pull/193483 messed up and removed important code of https://github.com/odoo/odoo/pull/172787. This commit adds it back. task-4547597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196801
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform. Authentication: the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFa
Original PR description
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all…
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform.
This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform.
Authentication:
the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFactura PR](https://github.com/odoo/odoo/pull/144061)
eTransport flow:
- Add the necessary eTransport data to a delivery
- send the eTransport document to ANAF
- the document gets processed by ANAF
- Fetch the status of the document:
- which can result in an error, in which case the flow starts again from the beginning with the corrected data
- or in a success
task-id: 3810735
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#196201
Forward-Port-Of: odoo/odoo#170080GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#78778 Forward-Port-Of: odoo/enterprise#77423
Original PR description
GroupingCategory and GroupingCode nodes have changed from optional to mandatory in SAF-T V1.3. For the category, we use RF-1167 for now as it's the most common value. task-4374014 Forward-Port-Of: odoo/enterprise#78778 Forward-Port-Of: odoo/enterprise#77423
During sharepocalypse, we injected the ListView.Selection component from the control panel directly instead of using t-slots. This made our list view component limited to the features we want to support in the kanban view, so fewer than what the webclient supports. This commit restores the List View features on the list view. Task-4544692 Forward-Port-Of: odoo/enterprise#78417
Original PR description
During sharepocalypse, we injected the ListView.Selection component from the control panel directly instead of using t-slots. This made our list view component limited to the features we want to support in the kanban view, so fewer than what the webclient supports. This commit restores the List View features on the list view. Task-4544692 Forward-Port-Of: odoo/enterprise#78417
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further versions like 18.0. The changes made in that particular view in 18.0 will not be loaded and will cause errors since its inherited view's will not be compatible enough. For ex: If we make changes in a "Purchase Order"(i.e; purchase.report_purchaseorder) report then after saving the changes the n
Original PR description
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further…
Issue: ------ When making changes in version 17.0 using studio the correspondent standard view's noupdate becomes 'True' as per the logic implemented. But when we migrate the database to the further versions like 18.0. The changes made in that particular view in 18.0 will not be loaded and will cause errors since its inherited view's will not be compatible enough. For ex: If we make changes in a "Purchase Order"(i.e; purchase.report_purchaseorder) report then after saving the changes the noupdate of that report view which is "purchase.report_purchaseorder_document" will be updated to 'true'. And the action record i.e; "purchase.action_report_purchase_order" noupdate will be updated to 'true'.   If the customer makes changes using studio then those changes will be recorded in the studio view and there is no point of making the standard view's noupdate to 'true'. Solution: ----------- Remove redundant code to overcome updating noupdate to 'true'. Steps to reproduce: ------------------------ 1. Create a database in version 17.0. 2. Make changes in any report using studio and save. 3. Migrate the database and try opening that report. 4. You'll encounter issues due to incompatibilty of views. Since, the changes made in the standard will not be loaded because it's noupdate is true. REF PRS: Enterprise PR: 1.https://github.com/odoo/enterprise/commit/2ae63d9a43ba973d905232105201d88e423a8245#diff-cf8f46a54f86279b4d773f0d39b23d22f046eb6d33a39c851f2a86dcd2b5b202R463 Forward-Port-Of: odoo/enterprise#78582
Before this commit: when triggering a followup reports on parent company, followup levels on both parent company and branches were triggered, meaning duplicated datas could be sent to customers. After this commit: Now only the followup on the current company is triggered, ignoring all the branches. task-4393081 Forward-Port-Of: odoo/enterprise#78238 Forward-Port-Of: odoo/enterprise#75572
Original PR description
Before this commit: when triggering a followup reports on parent company, followup levels on both parent company and branches were triggered, meaning duplicated datas could be sent to customers. After this commit: Now only the followup on the current company is triggered, ignoring all the branches. task-4393081 Forward-Port-Of: odoo/enterprise#78238 Forward-Port-Of: odoo/enterprise#75572
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view. This request actually reach the server even if Chrome is already closed and the test is cleaning itself (rollbacking the changes made in the database), resulting into a "release savepoint" mismatch on an already aborted transaction (example build's error [1]). This commit is kind of
Original PR description
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view. This request actually reach the server even if Chrome is already closed and the test is cleaning itself (rollbacking the changes made in the database), resulting into a "release savepoint" mismatch on an already aborted transaction (example build's error [1]). This commit is kind of a follow-up of a previous PR [2] where a last step allowing for the spreadsheet to unload was added and adding one more to actually wait to be back on the Document app. [1] https://runbot.odoo.com/runbot/build/74602509 [2] https://github.com/odoo/enterprise/pull/51795 Forward-Port-Of: odoo/enterprise#78896 Forward-Port-Of: odoo/enterprise#78797
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view (cf. save). This request actually reach the server even if Chrome is already closed and results into a SQl constraint error. Indeed, the (very basic) form views created for those tours are based on the "res.partner" model and only display the "name" field. This field isn't marked as "
Original PR description
During testing of the "new" Chrome's headless mode (by default since version 128), a concurrency issue arise at the end of those tours: a last request to the server is actually sent during the unload of the view (cf. save). This request actually reach the server even if Chrome is already closed and results into a SQl constraint error. Indeed, the (very basic) form views created for those tours are based on the "res.partner" model and only display the "name" field. This field isn't marked as "required" neither in the model, nor the view BUT has a SQL constraint attached to it... which makes it implicitly "required". This commit fixes it by properly marking them as such in the arch to let the client-side validation prevent the ultimate "save" request made during the unload. Forward-Port-Of: odoo/enterprise#78903 Forward-Port-Of: odoo/enterprise#78810
Versions -------- - 17.0+ Steps ----- 1. Use Belgian localization; 2. create an invoice for a Belgian customer; 3. pay the invoice using SEPA Direct Debit; 4. go to Accounting / Bank; 5. create a bank statement matching the SDD mandate details; 6. go to payment transactions linked to the invoice. Issue ----- The transaction is still pending, and the SDD Mandate hasn't been confirmed. Cause ----- When matching transactions to bank statement lines, it checks whether `tx.refer
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Belgian localization; 2. create an invoice for a Belgian customer; 3. pay the invoice using SEPA Direct Debit; 4. go to Accounting / Bank; 5. create a bank statement matching the SDD mandate details; 6. go to payment transactions linked to the invoice. Issue ----- The transaction is still pending, and the SDD Mandate hasn't been confirmed. Cause ----- When matching transactions to bank statement lines, it checks whether `tx.reference == line.payment_ref`. The `tx.reference` is based on the invoice name, whereas `payment_ref` depends on localization, with Belgian payment request being structured as `+++000/0000/12345+++`. Solution -------- When creating a SDD mandate transactions, display `tx.reference` as payment communication. opw-4380832 Forward-Port-Of: odoo/enterprise#78787 Forward-Port-Of: odoo/enterprise#78413
It is possible for a user to empty the value for `l10n_au_medicare_reduction` from an employee's form. Since this field is used in the computation of `l10n_au_tax_treatment_code`, doing so will trigger an error: ``` File "/home/odoo/src/enterprise/18.0/l10n_au_hr_payroll/models/hr_employee.py", line 347, in _compute_l10n_au_tax_treatment_code code += rec.l10n_au_medicare_reduction # Sixth Character TypeError: can only concatenate str (not "bool") to str ``` This error can also happe
Original PR description
It is possible for a user to empty the value for `l10n_au_medicare_reduction` from an employee's form. Since this field is used in the computation of `l10n_au_tax_treatment_code`, doing so will trigger an error:
```
File "/home/odoo/src/enterprise/18.0/l10n_au_hr_payroll/models/hr_employee.py", line 347, in _compute_l10n_au_tax_treatment_code
code += rec.l10n_au_medicare_reduction # Sixth Character
TypeError: can only concatenate str (not "bool") to str
```
This error can also happen during upgrades, when employee records are created before the module `l10n_au_hr_payroll` is loaded.
Forward-Port-Of: odoo/enterprise#78834[task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78734
Original PR description
[task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78734
With the introduction of Invoicing Enterprise (access to bank recon etc) a new user group was created "Invoicing & Banks" (`group_account_basic`) This group should also be able to access the customer statement / partner ledger (from the partner smart button) Task-4465208 Forward-Port-Of: odoo/enterprise#78807
Original PR description
With the introduction of Invoicing Enterprise (access to bank recon etc) a new user group was created "Invoicing & Banks" (`group_account_basic`) This group should also be able to access the customer statement / partner ledger (from the partner smart button) Task-4465208 Forward-Port-Of: odoo/enterprise#78807
In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#78730 Forward-Port-Of: odoo/enterprise#75035
Original PR description
In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#78730 Forward-Port-Of: odoo/enterprise#75035
Bug introduced by this commit: https://github.com/odoo/enterprise/commit/4b312d56e7fa01ab4e8f534a1e62ef59e1421f77 Steps to reproduce the bug: - Create a storable product “P1” - Create two different MOs: - First MO: 1 unit of P1 - Second MO: 2 units of P1 - Confirm and mark them as done - Go to the manufacturing list view - Select both MOs - Print Cost Analysis Problem: The mo_qty is 2 units instead of 3; only the quantity of the last MO is taken into account. This is beca
Original PR description
Bug introduced by this commit: https://github.com/odoo/enterprise/commit/4b312d56e7fa01ab4e8f534a1e62ef59e1421f77
Steps to reproduce the bug:
- Create a storable product “P1”
- Create two different MOs:
- First MO: 1 unit of P1
- Second MO: 2 units of P1
- Confirm and mark them as done
- Go to the manufacturing list view
- Select both MOs
- Print Cost Analysis
Problem:
The mo_qty is 2 units instead of 3;
only the quantity of the last MO is taken into account. This is because, to calculate the total quantity of all MOs, we use a variable mo_qty, but it is initialized twice, once before the loop and again within the MO loop, so for each MO, the counter is reset to 0.
opw-4529333
Forward-Port-Of: odoo/enterprise#78731TaskID: 4558836 Forward-Port-Of: odoo/enterprise#78840
Original PR description
TaskID: 4558836 Forward-Port-Of: odoo/enterprise#78840
Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip mo
Original PR description
Steps to Reproduce: - create a helpdesk ticket from the website form without attachments. - creation message in the chatter is missing. Cause: - subtype_id for helpdesk ticket messages was explicitly set in the bridge module's insert_attachment method. When no attachments were present, this prevented the _creation_subtype logic in the helpdesk.ticket model from executing, resulting in the missing creation message. Solution: - Added a condition in the insert_attachment method to skip modifying messages when no attachments are present. It ensures that the default _creation_subtype logic handles subtype assignment, maintaining consistent and accurate creation message logging in the chatter. task-4397661 Forward-Port-Of: odoo/enterprise#78777 Forward-Port-Of: odoo/enterprise#76111
When the user claims the document and there is no valid token Odoo tries to re-generate the token, and instead of recalling to try to claim the document the code is wrongly calling the method to accept the document This logic was added in this https://github.com/odoo/enterprise/commit/3e906a93b91b5f66a4da850acc2b5ff2f43dd267 but for reason when the methods for accept/claim were merged into one method (_l10n_cl_action_response) -- Adhoc Ticket 86396 Forward-Port-Of: odoo/enterprise#782
Original PR description
When the user claims the document and there is no valid token Odoo tries to re-generate the token, and instead of recalling to try to claim the document the code is wrongly calling the method to accept the document This logic was added in this https://github.com/odoo/enterprise/commit/3e906a93b91b5f66a4da850acc2b5ff2f43dd267 but for reason when the methods for accept/claim were merged into one method (_l10n_cl_action_response) -- Adhoc Ticket 86396 Forward-Port-Of: odoo/enterprise#78248