Thursday, April 18, 2024
44 changes · 17.0
Enhancements to existing features
The VAT listing report now displays a warning at the top showing customers with significant turnover (over 250€) who were excluded from the report due to missing information like country or VAT number. Users can directly view and edit these customers from the warning to complete their records and ensure accurate reporting.
Original PR description
In the VAT listing report, a customer might have a turnover of more than 250€ but wasn't added in the report due to missing information such as country or a VAT number. This commit adds a warning with those customers on top of the report with a link to view and edit them. task-3249107
This improvement adds visibility of appointment slot availability directly in the calendar gantt view. Previously, users couldn't see whether appointments fell within valid time periods defined by appointment slots. The update displays both available and unavailable time slots, making it clearer when appointments can be scheduled.
Original PR description
Appointment slots are not reflected in the gantt view so there are no indications of whether an appointment is within a valid time period with regards to the appointment-defined time intervals. This commit adds slot intervals in gantt availabilities display and attempts to have more common ground between slots and gantt. task-3813567
This update adds new tax configurations for Brazilian service-related transactions to support upcoming service tax calculation and electronic document interchange (EDI) features. The changes expand the tax template data to enable more accurate tax handling for service operations in Brazil.
Original PR description
These will be used in the new service tax calculation and EDI modules. task-3660574
Resolved issues and error corrections
This update fixes two issues with the comments panel in the Knowledge module. First, it prevents an unnecessary popover from appearing when replying to comments in small windows. Second, it corrects a styling problem that was causing comments to display as empty boxes in the panel on smaller screens. These fixes ensure the comments panel works properly regardless of window size.
Original PR description
# FIX] knowledge: remove useless popover This commit fixes an issue where the popover would open inside the comments panel when replying to a comment with a small enough window, even though in this situation it's not useful at all. Now when the panel is open and we have a small window, the popover will not open when replying to a comment. # [FIX] knowledge: show panel's comments in small windows This commit fixes an issue with the comments panel when using it with a small window. Before, when you opened the panel when in a small enough window, the comments aren't properly displayed meaning that you only have empty boxes inside the panel. This was caused by a styling issue inside of the template that applied a wrong style to the comment boxes inside panel, which is not necessary inside it. Now, we modified the inline style in the template so that it is not applied inside the panel, showing back those comments in all circumstances. task-3786282
The subscription tour feature in Odoo was broken due to recent technical updates. This fix restores the guided tour functionality by updating it to work with the latest system changes, ensuring users can properly navigate the subscription setup process.
Original PR description
Before this commit, subscription tour didn't work due to technical changes. This commit aims to fix the tour, by adapting to the new changes. Task: 3679337
A bug in the subscription invoicing automation was preventing the system from properly batching subscriptions for processing. The fix corrects how batch sizes are calculated, ensuring that subscriptions are now properly grouped together during automated invoice generation. This improves the efficiency and reliability of recurring subscription billing.
Original PR description
Within #45236 the sale subscription batching method was rewritten to allow invoices to be consolidated during the cron. However, batch_size was adjusted that caused the code to never actually batch. Because `batch_size` was reassigned to `batch_size + 1` before the search call, the batch check: `need_cron_trigger = len(all_subscriptions) > batch_size` Will always fail as `all_subscription` will never be a larger recordset than `batch_size`. Solution: Don't re-write batch_size and instead do `batch_size and batch_size + 1` in the search directly. opw-3846540
This fix resolves a technical error that occurred when completing field service projects involving serial-numbered items with multi-step delivery routes. The issue happened when marking a project as done after creating multiple shipments for the same product, and has been corrected to ensure smooth project completion in these scenarios.
Original PR description
Steps to reproduce: In field service, have a project on which you have to sell 3 of item A. Item a is tracked by serial number and the delivery route is in 2 steps. From stock to output and from output to customer. On the sale order make sure you have 3 separate lines of 1 quantity of product A separated or not by sections. Confirm this one. This will create two pickings. One picking linked to a global stock move for 3 units from stock to output. A second picking linked to 3 stock moves each linked to a sale line id. Prioritise the first one by starring it. Now go back to the project and mark is as done. OPW-3792527 Forward-Port-Of: odoo/enterprise#59163
This fix corrects two issues in the Spanish Model 347 tax report. First, customer receipts are now properly included in the report when they exceed the €3,005.06 threshold. Second, the report now correctly counts invoices even after payments have been registered against them, preventing transactions from being incorrectly excluded due to payment cancellations.
Original PR description
Currently, receipts are not accounted for in the model 347 report (issue 1). The same happens for invoices for which a payment has been registered (issue 2). ### Setup * install `l10n_es_reports` *…
Currently, receipts are not accounted for in the model 347 report (issue 1). The same happens for invoices for which a payment has been registered (issue 2). ### Setup * install `l10n_es_reports` * switch to a Spanish company ### Steps to reproduce issue 1 * with a new partner, create and confirm a customer receipt for more than €3005.06 (threshold for appearing in the report) * open the model 347 tax report We would expect the new partner to be listed in the report, but they aren't. ### Steps to reproduce issue 2 * with a new partner, create and confirm an invoice for more than €3005.06 * if you open the model 347 report, you will see the new partner listed there * go back to that invoice and register a payment for it. * open the model 347 report again We expect the new partner to still be listed, but they are not. ### Cause issue 1: receipts are missing in the corresponding domains. issue 2: all account moves are used to calculate the threshold. This means that, for example, invoices and payments can cancel each other out in the calculation. opw-3816370 Forward-Port-Of: odoo/enterprise#60353 Forward-Port-Of: odoo/enterprise#59343
This fix resolves an error that occurred when generating Mexican tax documents (CFDI) for invoices where the delivery address differs from the customer address. The issue was caused by a missing method that was renamed during a previous update. The fix restores the proper handling of delivery address information in external trade invoices.
Original PR description
**Steps to reproduce:** - Install Contacts, Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to company form and configure its address (*) - Create…
**Steps to reproduce:** - Install Contacts, Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to company form and configure its address (*) - Create a US customer (e.g. Foreign Customer) (*) - In Accounting settings: * activate "Customer Addresses" * use Mexican Bank for automatic currency rates (*) - Configure a product for external trade (e.g. Office Chair) (*) - Create an invoice: (*) * Customer: Foreign Customer * Delivery Address: [different than customer] (e.g. Deco Addict) * Product: Office Chair * Incoterm: EX WORKS * External Trade: Definitive - Confirm the invoice - Generate CFDI via "Send & Print" button (*) https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade **Issue:** A traceback is raised because an inexisting method (i.e. `_get_customer_cfdi_values`) is called. **Cause:** The missing method has been renamed from "_l10n_mx_edi_get_customer_cfdi_values" to "_get_customer_cfdi_values" during a refactoring, but the original method has been deleted without implementing the new one. **Solution:** "_l10n_mx_edi_get_customer_cfdi_values" method was used to generate the data for the delivery address without altering the existing CFDI values. These data were used to populate the external trade data of the CFDI. "_add_customer_cfdi_values" method is similar to removed "_l10n_mx_edi_get_customer_cfdi_values" method, except that it also updates "receptor" in the CFDI. It is used with a copy of the cfdi values to compute the values for the delivery address. opw-3849153
This fix resolves an issue where users couldn't create website forms in Studio when a route with the same URL already existed (such as /event). The system now properly checks for existing routes before creating new forms, allowing users to successfully add forms to their websites without conflicts.
Original PR description
Currently, it's not possible to create a form on `event.event` because website_studio doesn't check whether `/event` already exists. Steps: - Install `website_studio` and `website_event` - Open `Events` - Open `Studio` - Click on `Website` tab - Try to add a new form by clicking on `New Form` - Studio doesn't create a new form because it points to /event which already exists (created by `website_event`). This commit verifies that the route doesn't exist before creating it. Pages are served as a fallback when Python routing (`@route`) doesn't match and there is no attachment matching that url. For simplicity and performance, we only check that our new page doesn't collide with an `@route` controller, because we assume that attachments url won't collide. see `website/models/ir_http.py` `Http::_serve_fallback` opw-3778543 Forward-Port-Of: odoo/enterprise#60226 Forward-Port-Of: odoo/enterprise#58504
This fix resolves an error that occurred when validating point-of-sale orders in Chile when the associated account document didn't have a barcode. The system now properly handles cases where barcodes are missing, allowing orders to be validated successfully without interruption.
Original PR description
Prior to this commit, an error would occur when validating an order if the account move associated with a journal (where 'l10n_latam_use_documents' is set to false) did not have the 'l10n_cl_sii_barcode'. This commit prevents this error by adding appropriate handling for cases where the barcode is missing. opw-3870174
Fixed a bug where automatic payment reminders were using the wrong email template. When processing automatic follow-ups for overdue invoices, the system was incorrectly selecting the template from a later follow-up level instead of the appropriate one. This fix ensures customers receive the correct reminder message based on their invoice's age.
Original PR description
When sending an automatic followup, the wrong template is set. This is because of a typo when getting the followup line from the options. Steps: - Have 2 followup levels, 15 and 30 days with 2 different templates and automatic reminder - Have a customer with an invoice overdue by +15 days, and go to his followup report - In the action menu, select "Process Automatic Follow-ups" -> The template used is the one from the 2nd followup level instead of the one from the 1st level. opw-3858013
This update improves security and user experience in the Appointment module by hiding buttons that users don't have permission to access. Managers can now see the "Add a Leave" button while other users see a simplified "Share Appointment Link" button instead of the previous dropdown menu. This prevents system crashes and provides a cleaner interface based on user permissions.
Original PR description
- Ensure that only managers can see the "Add a Leave" button to prevent crashes caused by unauthorized user groups attempting to access it. - Replace the "Share Availability" and dropdown button with "Share Appointment Link" which will work the same as the dropdown was working but will not contain the "Select Dates" and "Any time" options for user groups without permission to access the "appointment.type" record. - Now the buttons creating the custom appointment and the any-time appointment are hidden for the user who lacks access so we can clean some access checks and sudo from the controller as "group_appointment_user" already have rights to create the appointment types. Forward-Port-Of: odoo/enterprise#57794
Portal users can now create recurring tasks when confirming subscription orders, just like regular users. Previously, the system incorrectly required portal users to have special permissions they don't have, preventing recurring tasks from being created. Now the system checks if recurring tasks are enabled in settings instead, ensuring consistent task behavior regardless of who confirms the order.
Original PR description
Steps to reproduce: ------------------- - create a product with: - recurring - prepaid - create task on order - in the settings, enable "Recurring Tasks" - add "Use Recurring Tasks" to the current user - create a sale order with a recurring plan and the recurring product - confirm the sale order --> the created task is recurring - duplicate the sale order - validate it with a portal user Issue: ------ The task created is not recurring. The two tasks should be recurrent because the sale order is the same. The user who confirms the sale order must not affect the status of the task. Cause: ------ We check that the user belongs to the `group_project_recurring_tasks` group, which will never be the case for a portal user. Solution: --------- Authorise the creation of the recurring task if the setting is activated. opw-3823250
This fix improves how Web Studio stores references to action buttons in form views. Previously, buttons used database-specific IDs that could change when exporting configurations between systems. Now they use permanent identifiers (xml_id) that remain consistent across different databases, making it safer to share and export form customizations.
Original PR description
In a form view, add a stat button in the button box. Before this commit, the button contained the action's id. It worked on a single DB but when exporting, the id might have changed. After this commit, we put the xml_id of the action instead, which is set when studio=1 is in the context. opw-3824053 Forward-Port-Of: odoo/enterprise#60730 Forward-Port-Of: odoo/enterprise#60298
Users encountered an error when trying to uninstall the IoT feature for Point of Sale. This fix corrects a technical compatibility issue that was introduced during a code update, ensuring the uninstall process now works smoothly without errors.
Original PR description
Currently, an exception is generated when the user tries to uninstall IoT for PoS. Error: `TypeError: uninstall_hook() missing 1 required positional argument: 'registry'` This is because the commit https://github.com/odoo/enterprise/commit/6b10cc80ea2441b5b2ab86aab52abbf7084d4319 added the uninstall hook at 15, and the uninstall hook requires two arguments in 15.0. But from saas-16.3 uninstall hook require only one argument as 'env'; it is not changed with commit [1]'s forwarded port. This commit will fix this issue by providing the argumnet 'env' that is required in the uninstall hook. sentry-5167509820 Forward-Port-Of: odoo/enterprise#60392
This fix resolves a memory issue that occurred when exporting XAF reports for companies with partners having thousands of bank account numbers. The previous query was duplicating data for each bank account, causing excessive memory usage. The update optimizes the database query to prevent this duplication and improve system performance.
Original PR description
…tprint With this [commit](https://github.com/odoo/enterprise/commit/8638ccc9cc26b997caee852e266b7ecc6f7c632a), we introduced a performance issue for databases with partners having lots (several thousands) bank account numbers. Due to the GROUP BY clause, the query was duplicating each move line for each partner's bank account number, which quickly saturated the server's memory. We eliminated the problem by selecting from `res_partner` instead of `account_move_line`. Forward-Port-Of: odoo/enterprise#60875 Forward-Port-Of: odoo/enterprise#60851
This fix resolves a crash that occurred in the Timesheets app when a user's employee link was removed. The app now handles this scenario gracefully by loading the timesheet grid normally and hiding the performance leaderboard when no billable target data is available for the user.
Original PR description
Before this commit, when the user goes to Timesheets app, he could get a traceback because the JS code does manage the case `get_billable_time_target` method could return an empty when no employee is…
Before this commit, when the user goes to Timesheets app, he could get a traceback because the JS code does manage the case `get_billable_time_target` method could return an empty when no employee is linked to the current user. This commit fixes the issue by managing that case and hide the leaderboard as we should expect since the billable target is not found for that current user. Steps to reproduce the issue ============================ 1. Create a new employee 2. Link that employee to a new user 3. Remove the user to the employee (unset Linked user field) 4. Log in as that new user 5. Go to timesheets app Current Behavior ================ A traceback is occured because the rpc called returned an empty list instead of a list containing at least one object to get the billable target for the current user. Expected Behavior ================= The grid view of Timesheets app should be loaded as expected and the leaderboard should not be displayed since no data is found to get the billable target for that current user. opw-3862635 opw-3866805 opw-3864353
Fixed a bug in the Partner Ledger report that caused the application to crash when users clicked "Unfold All" if some partners were archived. The issue occurred when the groupby_prefix feature was enabled. This fix ensures the report correctly handles both active and archived partners, preventing errors and improving the user experience.
Original PR description
When activating the groupby_prefix parameter for the Partner Ledger, a Traceback can happen if clicking on Unfold All and some of the partners are archived. That's because the search on res.partner in `_custom_unfold_all_batch_data_generator` injects the active ir.rule whereas the search in `_query_partners` does not. To fix that, pass `active_test=False` to the context. To reproduce: - Install `account_reports` and `contacts` with demo data - Archive Azure Interior - Set the parameter `account_reports.partner_ledger. groupby_prefix_groups_threshold` to 2 - Go to Partner Ledger - Click on Unfold All - A Traceback is raised Also changes the search domain operator from `ilike` to `=ilike`. Ticket link: [odoo/task#3703069](https://www.odoo.com/web#model=project.task&id=3703069) opw-3703069 Forward-Port-Of: odoo/enterprise#57727
The Sign module was experiencing a crash during asset compilation due to a missing stylesheet dependency. This fix updates the module configuration to properly include the required stylesheet file, resolving the asset computation failure and ensuring the Sign module loads correctly.
Original PR description
This commit addresses a computed asset failure caused by the inclusion of 'web.editor.frontend.scss' in the 'sign' module manifest since [1] (OWL conversion). A scss variable added in 'fontawesome_overriden.scss' by a related community PR is used in 'web.editor.frontend.scss', leading to a crash during asset computation. This file is now added in the manifest. Related community PR: - https://github.com/odoo/odoo/pull/161770 opw-3747848 [1]:https://github.com/odoo/enterprise/commit/5fa63a2f284fe93acc0c4d8dc12ee47646703247 Forward-Port-Of: odoo/enterprise#60894
This fix resolves an issue where canceling a confirmed subscription order would incorrectly set the subscription to a draft state, causing system errors. The update now properly cleans up the subscription state when orders are canceled and correctly restores it if the canceled order is moved back to quotation status.
Original PR description
Before this commit, when a confirmed order was canceled, a draft quote subscription_state was set. It would trigger the constraint `sale_subscription_state_coherence` or _constraint_canceled_subscription depnding the version. THis commits ensure to clean the subscription_state of canceled subscription and it set it back to the correct value if the canceled order is set back to quotation.
This update fixes how notes are formatted in Peru electronic invoicing documents to comply with official UBL standards. Notes are now automatically cleaned to contain only letters, numbers, and spaces, and limited to 200 characters maximum. This ensures Peru invoices are properly validated by tax authorities.
Original PR description
This commit fixes the note handling in the UBL tags for the l10n_pe_edi module by ensuring notes contain only alphanumeric characters and spaces, conforming to UBL specifications. This change: - Removes all non-alphanumeric characters except spaces. - Ensures notes are truncated to a maximum of 200 characters. Legal Reference: https://cpe.sunat.gob.pe/sites/default/files/inline-files/AjustesValidacionesCPEv20240205_.xlsx 
This fix resolves a problem where article blocks in the Knowledge module were being incorrectly marked as modified and triggering unnecessary database saves. The issue was caused by improper encoding of special characters in article properties, which led to mismatches between the displayed content and the stored value. The fix ensures proper encoding of article block properties to prevent false dirty state detection.
Original PR description
# Introduction: `JSON.stringify` was used to serialize the properties for the `/article` command instead of the classical `encodeDataBehaviorProps` which also uses `encodeURIComponent` above the…
# Introduction: `JSON.stringify` was used to serialize the properties for the `/article` command instead of the classical `encodeDataBehaviorProps` which also uses `encodeURIComponent` above the `JSON.stringify`, to avoid having some special characters as an attribute value. # The issue: `html_field.js:getEditingValue` is recovering the current value in the DOM using `innerHTML` which converts some characters from tag attributes to HTML entities, i.e.: `"` for `"`. `mail.py:html_normalize` is using `lxml.html.tostring` is receiving such a string with HTML entities, and is returning a string without HTML entities. The database value (without HTML entities) is later given to the `html_field` as a prop and is used as a comparison reference (`updateValue`) with the current value in edition (that is still being converted to have HTML entities). Since both values are different, the field is considered as dirty and in need of being saved, which will trigger a write, even though the normalized value is the same. # Fix: Using `encodeDataBehaviorProps` to serialize props as the Behavior anchor attribute (like for any other Behavior) will prevent the use of characters that are being converted to HTML entities. In order to update existing `/article` blocks, the behavior will overwrite its `data-behavior-props` attribute when it is mounted in edit mode. task-3853291 Forward-Port-Of: odoo/enterprise#60775 Forward-Port-Of: odoo/enterprise#60177
A bug in the account reports module was causing warning messages to be ignored when processing custom engine reports. The system was always using empty warnings instead of the actual warnings provided. This fix ensures that warning information is properly passed through and displayed to users, improving the accuracy of report feedback.
Original PR description
For the custom engine report, _compute_formula_batch_with_engine_custom always uses None for the warnings in the function custom_engine_function, even if a good warnings argument is sent. Now it correctly use the warnings instead of None Forward-Port-Of: odoo/enterprise#60929
This update fixes an issue where uploaded PDF header and footer files were not being properly saved with their correct file names in the sales settings. The fix allows the header and footer file name fields to be editable, ensuring that when users upload new PDF files for quotes, the system correctly records and uses the updated file names.
Original PR description
Steps: - Install sale apps. - Upload a header file from settings with xyz.pdf for example. Issue: - Header/Footer file is not updated according to uploaded file name. Cause: - Header/Footer file name in setting is related and readonly is should not be readonly in order to update header file name. Fix: - Make settings header/footer file not readonly to set proper updated file names. task-3620555