Wednesday, August 28, 2024
9 changes · 17.0
Enhancements to existing features
This update addresses frequent timeout issues when submitting invoices to Kenya's eTIMS system. The system timeout has been increased from 30 seconds to 45 seconds to give the service more time to respond, and error messages have been improved to clearly inform users that they should simply wait and retry rather than taking other action.
Original PR description
We noticed that in production, eTIMS regularly fails to respond within the timeout of 30s when we send an invoice. Since this happens fairly often, this PR aims to improve the error message so that the user knows there is nothing they can do except wait for a bit and then retry. We also increase the timeout to 45s, on the off chance that this might improve things somewhat. taskid: none
Unit tests have been added to validate the Indian asset depreciation feature, ensuring the calculations and functionality work correctly. This improves the reliability and quality of the Indian localization module by catching potential issues early through automated testing.
Original PR description
[IMP] l10n_in_asset: add unit tests to indian asset depreciation This is about adding test to the new indian asset depreciation feature https://github.com/odoo/enterprise/pull/67225/commits/23591bb39500018afb3c4dab1c33c665c5f3a064 task-id#3909619 original-pr: https://github.com/odoo/enterprise/pull/67225
Event registration emails and SMS messages are now sent in batches instead of one at a time, making the notification system faster and more efficient. This improvement allows the system to process multiple communications together, reducing overall processing time and server load when events receive many registrations.
Original PR description
Mail or sms sending on "after registration" is currently done sequentially. With this commit it is now batched in order to benefit from optimizations done in various mail and sms stack. Sending is grouped by scheduler, allowing to globally group by template (mail or sms). Task-3084943
Resolved issues and error corrections
This fix resolves an issue where companies with names longer than 64 characters or contacts with state/city names longer than 128 characters could not generate Renewal Request files for the Argentine government. The system now properly handles these longer field values, allowing users to successfully download their Renewal Request documents without errors.
Original PR description
**Version**: 17, master **Description of the issue/feature this PR addresses**: It is necessary to restrict the fields lenght that are used to create Renewal Request to argentinean goverment. For…
**Version**: 17, master **Description of the issue/feature this PR addresses**: It is necessary to restrict the fields lenght that are used to create Renewal Request to argentinean goverment. For example: It is received an error and not downloaded "Renewal Request" file if the company name lenght has more than 64 characters or if the company has a Contact with state name or city name lenght more than 128 characters. **Video showing how to replicate the error**: https://drive.google.com/file/d/1JB39Njjfpf9nJExyixaBLSvcL19Ig49X/view **Steps to reproduce**: 1) Log in with admin on runbot odoo enterprise 17 instance and install l10n_ar_edi (Argentinean Electronic Invoicing) module. 2) Take position on company "Responsable Inscripto". 3) Change company name to a name with lenght more than 64 characters. 4) Go to "Accounting / Configuration / Settings" and click on "Generate Renewal Request" on "Argentinean Localization" section. It will be received this message: _"Internal Server Error The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application."_ **Current behavior before PR**: It is received an error and not downloaded "Renewal Request" file if the company name lenght has more than 64 characters or if the company has a Contact with state name or city name lenght more than 128 characters. **Desired behavior after PR is merged**: It is downloaded "Renewal Request" file if the company name lenght has more than 64 characters or if the company has a Contact with state name or city name lenght more than 128 characters. _Ticket Adhoc side_: 78650 _Task latam_: 1246
Fixed an issue that prevented users from creating custom menus for Marketing Automation using the Studio tool. The problem occurred when the system tried to process empty domain fields, causing the application to crash. This fix ensures users can now successfully add new menus to the Marketing Automation module without errors.
Original PR description
Steps:
- Install `marketing_automation` and `web_studio`
- Open Marketing Automation and studio
- Click "Edit Menu"
- Click "New Menu"
- Set a name
- Set Existing Model
- Select "Marketing Activity"
- Confirm
- Try to use this new menu
- Traceback
This is because a compute is triggered in marketing_activity and we use `literal_eval` on domain fields unsetted.
`literal_eval` works only with string https://docs.python.org/3/library/ast.html#ast.literal_eval
opw-4115586
Forward-Port-Of: odoo/enterprise#68920This fix resolves a system error that occurred when creating purchase orders with products in companies outside of Kenya. The issue happened because the system was trying to look up Kenya-specific company information that didn't exist for other companies. Now the system properly handles purchase orders regardless of which company is being used.
Original PR description
Currently, a traceback occurs when the user creates a PO with a product from a company other than 'KE'. To reproduce this issue: 1) Install `l10n_ke_edi_oscu_stock` 2) Switch to a company other than…
Currently, a traceback occurs when the user creates a PO with a product from a company other than 'KE'. To reproduce this issue: 1) Install `l10n_ke_edi_oscu_stock` 2) Switch to a company other than `KE` 3) Create a PO with a product > `Confirm Order` 4) Click on `Receive Products` > `Validate` and get back to PO through breadcrumb 5) Click on the `Create Bill` Error:- ``` ValueError: Compute method failed to assign purchase.order.line(19, ).display_name ``` The above error occurs because of a computing method in which a filter is used to access the `KE` company record. But when the user is not in `KE` company it returns None. Here, the `display_name` is a readonly and non-stored field. Which leads to the above traceback. https://github.com/odoo/enterprise/blob/7a9157e059fd70831eb3174863a797abdb99ad53/l10n_ke_edi_oscu_stock/models/purchase.py#L71-L73 After applying this commit, We can resolve the above issue by giving the POl name when it is not `KE` company. sentry-5726618591
This fix resolves an internal error that occurred when customers scanned QR codes on POS receipts in Ecuador. The issue was caused by conflicting template code that prevented the ticket validation page from loading correctly. This fix ensures customers can successfully access their receipt information via QR code.
Original PR description
Steps to reproduce:
- Install `l10n_{ar,pe}_pos` and `l10n_ec_edi_pos`
- Enable "Use QR Code on ticket"
- Make an order and validate it inside the POS
- Open in an incognito window the link given by the QR Code
Issues:
Internal error, the cause is the multiple else that are added to the `get_info_div` block.
This problem is blocking #175591 and #175593
related community PR: https://github.com/odoo/odoo/pull/176746This update fixes a test in the Peru stock reports module that was failing unpredictably due to inconsistent data ordering. By standardizing the order of data processing, the test now runs reliably every time, improving the stability of our quality assurance process.
Original PR description
Trying the test from l10n_pe_reports_stock, it failed locally, but somehow we are lucky it did not fail on runbot. The problem is that the order is not fixed and by fixing the order we avoid the indeterministic failing.
Fixed a bug in the quality control module that was causing shop floor tests to fail when certain modules weren't installed together. The issue was in how lot IDs were being assigned during quality checks, which has now been corrected to ensure tests run reliably regardless of module configuration.
Original PR description
test_shop_floor fails with only mrp_workorder installed. With quality_mrp (as in runbot), test succeeds. Origin is in _compute_lot_line_id which set lot_id even when no qty_done.