Daily updates from Odoo
Navigate
Branch
Wednesday, November 15, 2023
35 changes
18 changes
Enhancements to existing features
The Documents preview area has been reorganized so action buttons are easier to understand and no longer crowd document details. The trash action now appears beside the document name, while archived documents show restore and delete actions above the preview to keep titles readable.
Original PR description
Improve the document preview layout by setting the inspector buttons above the document preview to separate them from the document fields. Move the trash button next to the document name for understanding purpose. When a document is archived the restore and trash buttons are displayed above the preview to leave the document name some space. Task-3566683
Resolved issues and error corrections
This update resolves a reporting export issue in Accounting, restores employee/resource avatars for Planning users without HR access, and modernizes the Twitter social media autocomplete component. These changes reduce user-facing errors and improve reliability without introducing major workflow changes.
Code cleanup and technical improvements
This update standardizes how units of measure are named across purchasing, stock, manufacturing, repair, delivery, and related workflows. It is mainly an internal cleanup that improves consistency for future maintenance, with little expected direct impact on day-to-day users.
Original PR description
task 2648449 renaming product_uom and product_uom_id into uom_id community: https://github.com/odoo/odoo/pull/104166
This draft update cleans up and simplifies the styling used in the HR Referral app. It should make the interface easier to maintain while preserving the existing user experience for referral dashboards and views.
Miscellaneous changes
The Depreciation Schedule report was not well computed when closing an asset with non-depreciable value. Steps: - Create an asset with acquisition date on the first day of last month - 10,000$ value, 8,000€ non-depreciable, 12 Months straight - Confirm, and dispose the asset - Post the disposal move - Go to Depreciation Schedule -> Values are not correct opw-3550938 Forward-Port-Of: odoo/enterprise#50626 Forward-Port-Of: odoo/enterprise#49723
Original PR description
The Depreciation Schedule report was not well computed when closing an asset with non-depreciable value. Steps: - Create an asset with acquisition date on the first day of last month - 10,000$ value, 8,000€ non-depreciable, 12 Months straight - Confirm, and dispose the asset - Post the disposal move - Go to Depreciation Schedule -> Values are not correct opw-3550938 Forward-Port-Of: odoo/enterprise#50626 Forward-Port-Of: odoo/enterprise#49723
If a user does not have `snailmail_account_followup` and uses server action `action_manually_process_automatic_followups` to process followup reports then the user will face error. steps to produce: - Install `Accounting`. - Uninstall `snailmail_account_followup`. - Accounting > Customers > Follow-up Reports > select a follow up report with status `in_need_of_action` and run the server action `Process Automatic Follow-ups`. Error: ``` AttributeError: 'account_followup.followup.line'
Original PR description
If a user does not have `snailmail_account_followup` and uses server action `action_manually_process_automatic_followups` to process followup reports then the user will face error. steps to produce:…
If a user does not have `snailmail_account_followup` and uses server action `action_manually_process_automatic_followups` to process followup reports then the user will face error.
steps to produce:
- Install `Accounting`.
- Uninstall `snailmail_account_followup`.
- Accounting > Customers > Follow-up Reports > select a follow up report with status `in_need_of_action` and run the server action `Process Automatic Follow-ups`.
Error:
```
AttributeError: 'account_followup.followup.line' object has no attribute 'send_letter'
File "odoo/tools/safe_eval.py", line 365, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(630,)", line 2, in <module>
File "home/odoo/src/enterprise/saas-16.4/account_followup/models/res_partner.py", line 586, in action_manually_process_automatic_followups
if followup_line.send_letter and not any(self.env['snailmail.letter']._is_valid_address(to_send_partner)
ValueError: <class 'AttributeError'>: "'account_followup.followup.line' object has no attribute 'send_letter'" while evaluating
'if records:\n action = records.action_manually_process_automatic_followups()'
File "odoo/http.py", line 2138, in __call__
response = request._serve_db()
File "odoo/http.py", line 1714, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1741, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1942, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 717, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/action.py", line 46, in run
result = action.run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 688, in run
res = runner(run_self, eval_context=eval_context)
File "odoo/addons/base/models/ir_actions.py", line 558, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 379, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
Our commit moves the snailmail address validity check to an override in the snailmail_account_followup module.
sentry-4522827500
Forward-Port-Of: odoo/enterprise#48835The "social reason" tag in the VAT export should be a company name. Forward-Port-Of: odoo/enterprise#50638
Original PR description
The "social reason" tag in the VAT export should be a company name. Forward-Port-Of: odoo/enterprise#50638
Before this commit, SerializationFailure could happen when the invoice are sent to the customers. It would trigger the following traceback: ```py File "/home/odoo/src/enterprise/saas-16.4/sale_subscription/models/sale_order.py", line 1859, in _process_invoices_to_send subscription.validate_and_send_invoice(invoice) File "/home/odoo/src/enterprise/saas-16.4/sale_subscription/models/sale_order.py", line 1875, in validate_and_send_invoice self.env.cr.commit() File "/home/odoo/s
Original PR description
Before this commit, SerializationFailure could happen when the invoice are sent to the customers. It would trigger the following traceback: ```py File…
Before this commit, SerializationFailure could happen when the invoice are sent to the customers. It would trigger the following traceback:
```py
File "/home/odoo/src/enterprise/saas-16.4/sale_subscription/models/sale_order.py", line 1859, in _process_invoices_to_send
subscription.validate_and_send_invoice(invoice)
File "/home/odoo/src/enterprise/saas-16.4/sale_subscription/models/sale_order.py", line 1875, in validate_and_send_invoice
self.env.cr.commit()
File "/home/odoo/src/odoo/saas-16.4/odoo/sql_db.py", line 450, in commit
self.flush()
File "/home/odoo/src/odoo/saas-16.4/odoo/sql_db.py", line 136, in flush
self.transaction.flush()
File "/home/odoo/src/odoo/saas-16.4/odoo/api.py", line 851, in flush
env_to_flush.flush_all()
File "/home/odoo/src/odoo/saas-16.4/odoo/api.py", line 713, in flush_all
self[model_name].flush_model()
File "/home/odoo/src/odoo/saas-16.4/odoo/models.py", line 5918, in flush_model
self._flush(fnames)
File "/home/odoo/src/odoo/saas-16.4/odoo/models.py", line 5991, in _flush
process(model, id_vals)
File "/home/odoo/src/odoo/saas-16.4/odoo/models.py", line 5941, in process
model.browse(ids)._write(vals)
File "/home/odoo/src/odoo/saas-16.4/odoo/models.py", line 4176, in _write
cr.execute(query, params + [sub_ids])
File "/home/odoo/src/odoo/saas-16.4/odoo/sql_db.py", line 321, in execute
res = self._obj.execute(query, params)
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update
```
Forward-Port-Of: odoo/enterprise#50612
Forward-Port-Of: odoo/enterprise#50269When scanning a package on a batch picking, we receive "The operation cannot be completed: Error, a partner cannot follow twice the same object." This happened because the user is defined for all pickings in the batch and the _setUser function calls the rpc method to update the user before configuring the cached data, causing the second (async) iteration to reselect the first picking because the cached data is not yet updated. Forward-Port-Of: odoo/enterprise#50532
Original PR description
When scanning a package on a batch picking, we receive "The operation cannot be completed: Error, a partner cannot follow twice the same object." This happened because the user is defined for all pickings in the batch and the _setUser function calls the rpc method to update the user before configuring the cached data, causing the second (async) iteration to reselect the first picking because the cached data is not yet updated. Forward-Port-Of: odoo/enterprise#50532
Two many2one to ir.attachment were added on table that can have a lot of record in there respective table. The deletion of ir_attachment need to check the new foreign constraints on those table which can take a lot of time. It can block the autovacuum since _gc_lost_attachments can timeout To speed up the delete, btree indexes neet to be added on many2one that point to ir_attachment Forward-Port-Of: odoo/enterprise#50573
Original PR description
Two many2one to ir.attachment were added on table that can have a lot of record in there respective table. The deletion of ir_attachment need to check the new foreign constraints on those table which can take a lot of time. It can block the autovacuum since _gc_lost_attachments can timeout To speed up the delete, btree indexes neet to be added on many2one that point to ir_attachment Forward-Port-Of: odoo/enterprise#50573
Problem: The user is unable to export or post closing entries due to a traceback that warnings is of None type. The method, _dynamic_check_lines, tries to assign an item to warnings which is a dict. However, since warnings was not initiliazed, it throws a traceback. Solution: Initialize warnings as an empty dict when it hits the failed_control condition This will unblock the user from exporting the tax report or posting the closing entry for the tax report. Steps to reproduce on Runbot(
Original PR description
Problem: The user is unable to export or post closing entries due to a traceback that warnings is of None type. The method, _dynamic_check_lines, tries to assign an item to warnings which is a dict. However, since warnings was not initiliazed, it throws a traceback. Solution: Initialize warnings as an empty dict when it hits the failed_control condition This will unblock the user from exporting the tax report or posting the closing entry for the tax report. Steps to reproduce on Runbot(ALL): Switch to BE Company CoA Enable "0% EU S" purchase tax Create a vendor bill using this tax Try to post Tax Closing Entry for the period which includes the created vendor bill Receive technical error OR Try to export the Tax Report opw-3560681 Forward-Port-Of: odoo/enterprise#49887
Prior to this commit, there was a white gap on the right side in the frontend view. This was due to a missing class enabling the column size to be set correctly on large screens. To fix that, this commit introduces this missing class. task-3592631 Forward-Port-Of: odoo/enterprise#50511
Original PR description
Prior to this commit, there was a white gap on the right side in the frontend view. This was due to a missing class enabling the column size to be set correctly on large screens. To fix that, this commit introduces this missing class. task-3592631 Forward-Port-Of: odoo/enterprise#50511
This is a legal requirement for Mexico, the PDF must be a printed representation of the CFDI and the fiscal regime is a data that is present on the XML of the payment  opw #3515408 Forward-Port-Of: odoo/enterprise#50619 Forward-Port-Of: odoo/enterprise#47685
Original PR description
This is a legal requirement for Mexico, the PDF must be a printed representation of the CFDI and the fiscal regime is a data that is present on the XML of the payment  opw #3515408 Forward-Port-Of: odoo/enterprise#50619 Forward-Port-Of: odoo/enterprise#47685
Before this commit, in helpdesk homepage, the daily target inputs in the 'My Performance' area were reasonably functional in focused state, but in dark mode, they exhibited an undesirable box-shadow/inset effect. This commit addresses the issue by applying a 'form-control' class to the inputs and removing any superfluous classes, thereby enhancing the visual consistency and aesthetic. <table> <tr> <td>Before</td> <td> After</td> <tr> <td> <img alt="before" src="https://github.com/od
Original PR description
Before this commit, in helpdesk homepage, the daily target inputs in the 'My Performance' area were reasonably functional in focused state, but in dark mode, they exhibited an undesirable box-shadow/inset effect. This commit addresses the issue by applying a 'form-control' class to the inputs and removing any superfluous classes, thereby enhancing the visual consistency and aesthetic. <table> <tr> <td>Before</td> <td> After</td> <tr> <td> <img alt="before" src="https://github.com/odoo/enterprise/assets/80678921/fef930e2-06d3-4932-ac91-726f6fddd132"> </td> <td><img alt="after" src="https://github.com/odoo/enterprise/assets/80678921/16321474-0070-4987-9e35-c4b963f8dc6f"> </td> </table> task-3593349 Forward-Port-Of: odoo/enterprise#50536
The recruitment settings were using the iap_buy_more_credits widget, even tho there is no hard dependency between IAP and Recruitment. The widget has been moved to the enterprise module `hr_recruitment_extract`. Closes odoo/odoo#114747 Forward-Port-Of: odoo/enterprise#49576 Forward-Port-Of: odoo/enterprise#37959
Original PR description
The recruitment settings were using the iap_buy_more_credits widget, even tho there is no hard dependency between IAP and Recruitment. The widget has been moved to the enterprise module `hr_recruitment_extract`. Closes odoo/odoo#114747 Forward-Port-Of: odoo/enterprise#49576 Forward-Port-Of: odoo/enterprise#37959
Issue: ====== When you cancel repeat with type `until` for a `planning slot` it will not get saved after saving the form. Steps to reproduce the error: ============================= - Install planning - Go to planning create a new slot from the Gantt (default) view. - Add resource , choose date as a period of 2 days for example (doesn't matter), select repeat, change forever to until and select the date for some day in next month for example and save it. - Click on the created slot and
Original PR description
Issue: ====== When you cancel repeat with type `until` for a `planning slot` it will not get saved after saving the form. Steps to reproduce the error: ============================= - Install…
Issue: ====== When you cancel repeat with type `until` for a `planning slot` it will not get saved after saving the form. Steps to reproduce the error: ============================= - Install planning - Go to planning create a new slot from the Gantt (default) view. - Add resource , choose date as a period of 2 days for example (doesn't matter), select repeat, change forever to until and select the date for some day in next month for example and save it. - Click on the created slot and unselect repeat and click save. - Click again on the slot , it will show that repeat is still selected. Origin of the issue: ==================== The reason behind this issue is that _compute_repeat_until is called when changing repeat value and thus changing the values of `slot.repeat_until` to False and then in the save `inverse_repeat` is called and it will not match all the conditions in the second if : The condition on `repeat_until` will be False. Solution: ========= I removed the `repeat_until` from the conditions to be checked. opw-3550191 Forward-Port-Of: odoo/enterprise#48969
Step to reproduce: - Order two same combo products in pos_restaurent - Only one product will appear on the kitchen display Previously the _get_order_changes method was computing the orderline changes based on a key composed of the product id, the full product name and the note. This was done considering the fact that the merge orderline was working. Combo products are not handled by the merge orderline. Because of this, if 2 orderlines of combo product were the same, only the last orderline
Original PR description
Step to reproduce: - Order two same combo products in pos_restaurent - Only one product will appear on the kitchen display Previously the _get_order_changes method was computing the orderline changes based on a key composed of the product id, the full product name and the note. This was done considering the fact that the merge orderline was working. Combo products are not handled by the merge orderline. Because of this, if 2 orderlines of combo product were the same, only the last orderline would be taken into account. To prevent this, this commit changes the key to the uuid which is a unique identifier to an orderline. Forward-Port-Of: odoo/enterprise#49893
Since changes have been made in default tax settings, incoming emails with invoices for l10n-cl are not configuring the tax correctly. This ensures that the default tax is being added correctly. This PR is a revision of #49332 wich did not work since method `_get_withholding_taxes()` returns a set, and the default_purchase_tax cannot be added that way. Besides, as the default tax is the main one, we put it first in the sequence of taxes. Forward-Port-Of: odoo/enterprise#49651
Original PR description
Since changes have been made in default tax settings, incoming emails with invoices for l10n-cl are not configuring the tax correctly. This ensures that the default tax is being added correctly. This PR is a revision of #49332 wich did not work since method `_get_withholding_taxes()` returns a set, and the default_purchase_tax cannot be added that way. Besides, as the default tax is the main one, we put it first in the sequence of taxes. Forward-Port-Of: odoo/enterprise#49651
17 changes
Security fixes and vulnerability patches
This fix closes a security gap where users with only interviewer permissions could view applicants they referred but weren't assigned to interview. After this update, users will only see applicants in the recruitment app if they are the assigned interviewer or the job position's interviewer, preventing unauthorized access to candidate information.
Original PR description
Steps to reproduce: - Have a user that have the interviewer rights but not higher ones - Set the user as the referrer of an applicant but not as the interviewer and not as the job position…
Steps to reproduce: - Have a user that have the interviewer rights but not higher ones - Set the user as the referrer of an applicant but not as the interviewer and not as the job position interviewer - As this user go to the recruitment app - You can see the applicant and you can open it Expected behavior: in that situation the user should not be able to see the applicant or access it in any way in the recruitment app. Explanation: The user was able to see the applicant because the my referral view is based on the hr.applicant model and thus the user has access to the record in both apps. But the problem should be fixed in the recruitment app because the user should still be able to see the applicant in the referral app. after this fix: You'll not be able to see the applicant in the recruitment app if you are not the interviewer of the applicant or the interviewer of the job position if you only have the interviewer rights. You'll also get an access error if you try to access the applicant directly by URL. task-3457405
Resolved issues and error corrections
Fixed an issue where the fuel type wasn't displaying when employees selected a new car model in their contract. The system now correctly shows fuel type information whether a car is selected from existing inventory or as a new car model. This ensures accurate vehicle information is always visible in employee contracts.
Original PR description
https://github.com/odoo/enterprise/pull/34883 started showing the fuel type of the car_id in the form view of hr_contract. However, when selecting new cars, the car_id won't be set. Instead we'll set the new_car_model_id field and the fuel type won't be shown. This commit changes the fuel_type field in hr_contract to be a computed field that will either take the fuel_type from car_id or from new_car_model_id. task-3515936 Forward-Port-Of: odoo/enterprise#47717
This fix resolves an error that occurred when scanning packages during batch picking operations. The issue was caused by a timing problem where user information was being updated before the system's internal data was properly refreshed, causing the system to incorrectly reprocess the same picking. This fix ensures the data is updated in the correct order, allowing batch picking operations to complete successfully.
Original PR description
When scanning a package on a batch picking, we receive "The operation cannot be completed: Error, a partner cannot follow twice the same object." This happened because the user is defined for all pickings in the batch and the _setUser function calls the rpc method to update the user before configuring the cached data, causing the second (async) iteration to reselect the first picking because the cached data is not yet updated.
This fix resolves a technical error that prevented users in Belgium from exporting tax reports or posting tax closing entries. The issue occurred when certain tax conditions were met, causing the system to crash. By properly initializing the warnings system, users can now successfully complete these critical tax reporting tasks without encountering errors.
Original PR description
Problem: The user is unable to export or post closing entries due to a traceback that warnings is of None type. The method, _dynamic_check_lines, tries to assign an item to warnings which is a dict. However, since warnings was not initiliazed, it throws a traceback. Solution: Initialize warnings as an empty dict when it hits the failed_control condition This will unblock the user from exporting the tax report or posting the closing entry for the tax report. Steps to reproduce on Runbot(ALL): Switch to BE Company CoA Enable "0% EU S" purchase tax Create a vendor bill using this tax Try to post Tax Closing Entry for the period which includes the created vendor bill Receive technical error OR Try to export the Tax Report opw-3560681 Forward-Port-Of: odoo/enterprise#49887
A white gap that appeared on the right side of the room booking interface has been fixed. The issue was caused by a missing CSS class that controls how the layout adapts to larger screens. Adding this class ensures the interface displays properly without unwanted spacing.
Original PR description
Prior to this commit, there was a white gap on the right side in the frontend view. This was due to a missing class enabling the column size to be set correctly on large screens. To fix that, this commit introduces this missing class. task-3592631
This update reorganizes how the recruitment module handles credit purchasing functionality. The credit widget has been moved to the specialized recruitment extraction module where it's actually used, removing an unnecessary dependency. This improves the system's organization and makes the code cleaner without affecting how recruitment features work.
Original PR description
The recruitment settings were using the iap_buy_more_credits widget, even tho there is no hard dependency between IAP and Recruitment. The widget has been moved to the enterprise module `hr_recruitment_extract`. Closes odoo/odoo#114747 Forward-Port-Of: odoo/enterprise#49576 Forward-Port-Of: odoo/enterprise#37959
This update adds the fiscal regime field to payment PDF documents in Mexico, which is a legal requirement for CFDI (electronic invoice) compliance. The fiscal regime data was already present in the XML but was missing from the printed PDF representation, and this fix ensures the PDF now matches the complete legal requirements.
Original PR description
This is a legal requirement for Mexico, the PDF must be a printed representation of the CFDI and the fiscal regime is a data that is present on the XML of the payment  opw #3515408 Forward-Port-Of: odoo/enterprise#50619 Forward-Port-Of: odoo/enterprise#47685
This update resolves a technical issue that was causing invoice sending to fail when customers received their subscription invoices. The fix improves the robustness of the invoice sending process by addressing database concurrency issues, ensuring invoices are sent reliably without interruption.
Original PR description
Before this commit, SerializationFailure could happen when the invoice are sent to the customers. It would trigger the following traceback: ```py File…
Before this commit, SerializationFailure could happen when the invoice are sent to the customers. It would trigger the following traceback:
```py
File "/home/odoo/src/enterprise/saas-16.4/sale_subscription/models/sale_order.py", line 1859, in _process_invoices_to_send
subscription.validate_and_send_invoice(invoice)
File "/home/odoo/src/enterprise/saas-16.4/sale_subscription/models/sale_order.py", line 1875, in validate_and_send_invoice
self.env.cr.commit()
File "/home/odoo/src/odoo/saas-16.4/odoo/sql_db.py", line 450, in commit
self.flush()
File "/home/odoo/src/odoo/saas-16.4/odoo/sql_db.py", line 136, in flush
self.transaction.flush()
File "/home/odoo/src/odoo/saas-16.4/odoo/api.py", line 851, in flush
env_to_flush.flush_all()
File "/home/odoo/src/odoo/saas-16.4/odoo/api.py", line 713, in flush_all
self[model_name].flush_model()
File "/home/odoo/src/odoo/saas-16.4/odoo/models.py", line 5918, in flush_model
self._flush(fnames)
File "/home/odoo/src/odoo/saas-16.4/odoo/models.py", line 5991, in _flush
process(model, id_vals)
File "/home/odoo/src/odoo/saas-16.4/odoo/models.py", line 5941, in process
model.browse(ids)._write(vals)
File "/home/odoo/src/odoo/saas-16.4/odoo/models.py", line 4176, in _write
cr.execute(query, params + [sub_ids])
File "/home/odoo/src/odoo/saas-16.4/odoo/sql_db.py", line 321, in execute
res = self._obj.execute(query, params)
psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update
```
Forward-Port-Of: odoo/enterprise#50269This fix improves the user experience when working with embedded views in knowledge article templates. The toolbar that appears next to embedded content is now easier to click and visually appears properly connected to the content, rather than floating above it. This makes the interface more intuitive and responsive for users creating or editing knowledge articles.
Original PR description
This commit slightly adapts the template data to add a br element after the hr separator, which is necessary to be able to easily click on the embed view toolbar that appears right next to it. In addition, we modify the toolbar styling to make it appear "connected" to its embed view rather than floating a few pixels above it.
This fix corrects incorrect calculations in the Depreciation Schedule report when an asset with non-depreciable value is disposed. The report now accurately displays depreciation values and adjustments for closed assets, ensuring financial reporting accuracy.
Original PR description
The Depreciation Schedule report was not well computed when closing an asset with non-depreciable value. Steps: - Create an asset with acquisition date on the first day of last month - 10,000$ value, 8,000€ non-depreciable, 12 Months straight - Confirm, and dispose the asset - Post the disposal move - Go to Depreciation Schedule -> Values are not correct opw-3550938 Forward-Port-Of: odoo/enterprise#50626 Forward-Port-Of: odoo/enterprise#49723
This fix resolves a crash that occurred when users tried to process automatic follow-up reports without having the snailmail module installed. The system was attempting to access snailmail-specific features that weren't available, causing the process to fail. The fix properly handles this scenario by moving the snailmail validation logic to where it belongs, ensuring the follow-up process works correctly regardless of whether snailmail is installed.
Original PR description
If a user does not have `snailmail_account_followup` and uses server action `action_manually_process_automatic_followups` to process followup reports then the user will face error. steps to produce:…
If a user does not have `snailmail_account_followup` and uses server action `action_manually_process_automatic_followups` to process followup reports then the user will face error.
steps to produce:
- Install `Accounting`.
- Uninstall `snailmail_account_followup`.
- Accounting > Customers > Follow-up Reports > select a follow up report with status `in_need_of_action` and run the server action `Process Automatic Follow-ups`.
Error:
```
AttributeError: 'account_followup.followup.line' object has no attribute 'send_letter'
File "odoo/tools/safe_eval.py", line 365, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(630,)", line 2, in <module>
File "home/odoo/src/enterprise/saas-16.4/account_followup/models/res_partner.py", line 586, in action_manually_process_automatic_followups
if followup_line.send_letter and not any(self.env['snailmail.letter']._is_valid_address(to_send_partner)
ValueError: <class 'AttributeError'>: "'account_followup.followup.line' object has no attribute 'send_letter'" while evaluating
'if records:\n action = records.action_manually_process_automatic_followups()'
File "odoo/http.py", line 2138, in __call__
response = request._serve_db()
File "odoo/http.py", line 1714, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1741, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1942, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 717, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/action.py", line 46, in run
result = action.run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 688, in run
res = runner(run_self, eval_context=eval_context)
File "odoo/addons/base/models/ir_actions.py", line 558, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 379, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
Our commit moves the snailmail address validity check to an override in the snailmail_account_followup module.
sentry-4522827500
Forward-Port-Of: odoo/enterprise#48835This update corrects the "social reason" field in the French VAT export to properly display the company name. The fix ensures that VAT reports sent to French tax authorities contain the correct company information, improving compliance and reducing potential reporting errors.
Original PR description
The "social reason" tag in the VAT export should be a company name. Forward-Port-Of: odoo/enterprise#50638
This fix resolves an issue where barcode scanning would incorrectly retrieve the wrong lot when multiple products share the same lot name. The system now properly filters lots by product ID when processing GS1 barcode scans, ensuring the correct lot is populated during delivery order operations.
Original PR description
Steps to reproduce: 1. Enable GS1 Barcode nomenclature 2. Create 2 products, P1 and P2 both tracked by lots. 3. Add barcode for P2 here is the barcode: 05711544001952 4. Create two lots. You MUST…
Steps to reproduce:
1. Enable GS1 Barcode nomenclature
2. Create 2 products, P1 and P2 both tracked by lots.
3. Add barcode for P2 here is the barcode: 05711544001952
4. Create two lots. You MUST create a lot for P1 before lot P2.
5. These two lots must have the same name. I'm using "304" as the name
6. Go to barcode and delivery order
7. Scan this barcode:
This is for the location
odoo.__DEBUG__.services['web.core'].bus.trigger('barcode_scanned', "WH-STOCK", $(".o_web_client")[0])
This is for the product, expiration date, lot number
odoo.__DEBUG__.services['web.core'].bus.trigger('barcode_scanned', "01057115440019521524071010304", $(".o_web_client")[0])
Bug:
Based on the GS1 Nomenclature, you're scanning the product, expiration, and lot number.
This scan will go through but you will not see the lot number get populated. This is because Odoo is pulling the other lot with the same name. (P1).
Fix:
apply filter (by product id) on the lots
opw-3387326
Forward-Port-Of: odoo/enterprise#50333
Forward-Port-Of: odoo/enterprise#47734This update speeds up the deletion of attachments in the system by adding database indexes to improve lookup performance. Previously, deleting attachments could take a long time and interfere with system maintenance tasks. This fix ensures the system runs more smoothly without performance disruptions.
Original PR description
Two many2one to ir.attachment were added on table that can have a lot of record in there respective table. The deletion of ir_attachment need to check the new foreign constraints on those table which can take a lot of time. It can block the autovacuum since _gc_lost_attachments can timeout To speed up the delete, btree indexes neet to be added on many2one that point to ir_attachment Forward-Port-Of: odoo/enterprise#50573
This fix resolves an error that occurred when users tried to select a resource from the roles configuration menu in the Planning module. The issue was caused by missing selection values in a field definition, which has now been corrected to allow users to properly assign resources to roles without encountering errors.
Original PR description
Steps ===== - Install module planning - Go to menu Configuration > Roles - Click on the resource column of a given role - In the opened dropdown, click on a resource Issue ===== A traceback appears when the resource is clicked. Cause ===== The field resource_type is needed for the widget many2many_avatar_resource and is therefore added as a relatedFields. However, for field of type 'selection' the selection's values have to be added in the field info since the change of the relational model (see odoo/odoo#114024). Fix === Selection values are added in the field description.
This fix resolves a technical error that occurred when uploading AFIB certificates in the Argentinean localization settings. The system was incorrectly processing the certificate file, causing the upload to fail. Users can now successfully update their AFIB certificates without encountering errors.
Original PR description
Settings>Accounting>Argentinean Localization Change AFIB Certificate Save Issue: Traceback will raise because we input the file size to the b64decode instead of the content opw-3589877
This fix resolves an issue where cancelling a recurring planning slot with an "until" date would not save properly. Users would uncheck the repeat option, save the form, but the repeat setting would still appear as active when reopening the slot. The fix adjusts the logic that handles saving repeat settings to correctly process cancellations.
Original PR description
Issue: ====== When you cancel repeat with type `until` for a `planning slot` it will not get saved after saving the form. Steps to reproduce the error: ============================= - Install…
Issue: ====== When you cancel repeat with type `until` for a `planning slot` it will not get saved after saving the form. Steps to reproduce the error: ============================= - Install planning - Go to planning create a new slot from the Gantt (default) view. - Add resource , choose date as a period of 2 days for example (doesn't matter), select repeat, change forever to until and select the date for some day in next month for example and save it. - Click on the created slot and unselect repeat and click save. - Click again on the slot , it will show that repeat is still selected. Origin of the issue: ==================== The reason behind this issue is that _compute_repeat_until is called when changing repeat value and thus changing the values of `slot.repeat_until` to False and then in the save `inverse_repeat` is called and it will not match all the conditions in the second if : The condition on `repeat_until` will be False. Solution: ========= I removed the `repeat_until` from the conditions to be checked. opw-3550191 Forward-Port-Of: odoo/enterprise#48969