Daily updates from Odoo
Wednesday, November 15, 2023
16 changes · 17.0
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