Wednesday, November 8, 2023
16 changes · 17.0
Enhancements to existing features
The website editor now better respects protected areas when users type, paste, use keyboard actions, or apply editing commands. This helps dynamic widgets stay intact and reduces the risk of accidental changes to content that should remain controlled by the system.
Original PR description
In order to be able to create dynamic widgets to the editor, this commit reinforce the concept of data-oe-protected by preventing the default behavior for _applyRawCommand, on paste, on input and on keydown. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Closing the ChatGPT prompt dialog now immediately clears the loading state, even if a response is still pending. This prevents lingering overlays and avoids errors caused by callbacks running after the dialog has been closed.
Original PR description
Before this commit, when the ChatGPT prompt dialog was closed while waiting for a response, the "loading" overlay would be present until such response was complete. Moreover, in certain occasions, the rpc callback, called after the component was destroyed, could lead to a traceback due to reading a property of a no longer existing reference to the prompt input element (namely, in the `_unfreezeInput` method). This commit improves the user experience by unfreezing the UI on dialog close, even if a response is pending, and prevents the rpc callbacks from running after the component is destroyed. task-3586380
Invoices are no longer left stuck in the Peppol sending queue when the required XML file is not generated, making the send process clearer and easier to recover. Demo companies eligible for Peppol now include bank details, reducing setup errors when testing electronic invoicing.
Original PR description
### [FIX] account_peppol: peppol_move_state One flow wasn't considered in the PR that added a ready state: - A user unchecks BIS3 XML generation and sending via Peppol in the send & print wizard -…
### [FIX] account_peppol: peppol_move_state One flow wasn't considered in the PR that added a ready state: - A user unchecks BIS3 XML generation and sending via Peppol in the send & print wizard - `peppol_move_state` is set to `ready`, even though it's not possible to send it without the XML file, so it queues forever This commit adds a `skipped` state. If the XML file is not generated, the `peppol_move_state` is changed to `skipped` and the user needs to manually regenerate attachments to send the invoice via Peppol. Also, the BIS3 checkbox shouldn't be deselected automatically when peppol checkbox is deselected. ### [FIX] l10n_*: add partner bank demo data When trying to send a demo peppol invoice, a user gets an error about the missing recipient bank. The user then needs to set the invoice back to draft, create the bank, and save changes, before being able to send the invoice via Peppol. To make the demo process smoother, this commit adds a `res.partner.bank` record for every demo company that is eligible for peppol. However, it can be useful in general, so these are added in the community l10n modules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Amounts to Settle view now handles grouping by due or payment date without errors. Due date filtering is more accurate, and items are ordered to make reconciliation easier for accounting users.
Original PR description
Reproduce: * Accounting > Vendor > Amounts to Settle * Group By: Due Date (any) There is an error because `payment_date` is not stored. We also allow more operators in `_search_payment_date` because the `read_group` will use `<=` and `>=` to open the groups. We still transform `=` to `<=` to enable the quick search.
This fix resolves an access rights error that occurred when portal users tried to create or confirm sales orders with internal users as customers while using the UPS delivery module. The system now properly handles user permission checks, allowing the order creation process to complete successfully without blocking on restricted user record updates.
Original PR description
Steps to reproduce: - Install the delivery_ups module - Log in as Marc Demo - Create a SO and set Mitchell Admin as Customer - Try to save or confirm the order The user will get an access rights error because he's not able to update `res.users` records. This commit makes sure the update done in the inverse of the `partner_ups_carrier_account` is done in sudo, not triggering unexpected access errors. task-3519499 Forward-Port-Of: odoo/enterprise#48093
The split tools dialog in the Documents module was displaying incorrectly and taking up half the window due to improper positioning. This fix adjusts the dialog positioning from relative to fixed, ensuring it displays properly and doesn't obstruct the user's view of the document.
Original PR description
Before this commit, the position of the dialog of the split tools was incorect, leading to the dialog taking half of the window. Solution : forcing the dialog to be fixed and not relative.
This update improves the security and compatibility of bank account synchronization by ensuring the customer's IP address is included when making direct connections to financial institutions. Many banks and payment providers now require this information for compliance and fraud prevention purposes, making this change necessary for continued reliable service.
Original PR description
More and more provider/institutions requires that we pass along the psu(customer) IP address when making direct calls (when the user is behind the screen and clicking on the button). So this commit performs exactly that. Forward-Port-Of: odoo/enterprise#47600
This fix corrects an issue where the closing entry button was incorrectly filtering entries as "posted" when multiple companies had tax units enabled. Since these entries are in draft status, the filter has been removed to show all relevant entries. This ensures users can properly view and manage closing entries across multiple companies.
Original PR description
When having tax unit enabled with more than one company, clicking on the button for the closing entry will redirect to a tree view where the "posted" filter is put by default. But in this cas we don't want it since all the moves are in draft. This commit will remove the 'search_default_posted' from the context when having multiple moves. task: 3580453 Forward-Port-Of: odoo/enterprise#50362 Forward-Port-Of: odoo/enterprise#50048
This fix resolves a technical error that occurred when users tried to divide employee shifts using the cutting tool in the Planning module. The issue prevented the shift division feature from working properly, and this update restores that functionality so employees can manage their schedules more flexibly.
Original PR description
Steps: - Open Employee - Create an employee with standard 40 hours/week working hours - Open planning - Create a shift for that employee for multiple days - Search for that employee - Try dividing the shift through cutting tool Issue: - When we divide the shift through cutting tool TypeError occurs. Cause: - Missing optional chaining operator in the variables unavailability_at_start and unavailability_at_stop which didn't execute the find method and throws the TypeError. Fix: - Add the optional chaining operator in the variables unavailability_at_start and unavailability_at_stop. task-3576698 Forward-Port-Of: odoo/enterprise#49889
Fixed an issue where a rejection wizard would unnecessarily appear when manually matching a single bank transaction to a payment within a batch. This improvement streamlines the reconciliation process for banks that create one transaction per payment in a batch, reducing unnecessary steps and improving user experience.
Original PR description
…for one payment If a transaction is manually matched with one payment that is inside a batch, the rejection wizard should not appear. This is useful for the case of banks making one transaction per payment inside a batch. task-3547187 Forward-Port-Of: odoo/enterprise#50302 Forward-Port-Of: odoo/enterprise#49418
This update fixes an issue where users couldn't modify filters on the tax report when accessing it through a dashboard shortcut. The fix simplifies how the system handles report options by changing the ignore_session setting from a three-value option to a simple on/off toggle. Now users can make filter changes that actually stick, regardless of how they access the report.
Original PR description
[REF] account_reports: ignore session boolean (backport of 2ff76e8 , needed to solve a bug) Account reports save options into the session so users don't lose them when reloading the page.To prevent…
[REF] account_reports: ignore session boolean (backport of 2ff76e8 , needed to solve a bug) Account reports save options into the session so users don't lose them when reloading the page.To prevent some reports to use those session options we used the 'ignore_session' variable. The 'ignore_session' could have 3 values: - 'read' to prevent the reading of session options - 'write' to prevent the writing of session options - 'both' to prevent reading and writing of session options The thing is that there is not real usage for those 3 cases. In practice, the session options are completely ignored (read and write) or never ignored. The distinction between 'read' and 'write' is then useless. This all means that we can simplify that variable by making it a boolean instead. closes #46128 ========================================================== [FIX] account_reports: allow assigning values to filters of the tax report when coming from the dashboard shortcut The tax report can be opened from the dashboard, using a shortcut link displayed for each closing move to post. When opened this way, trying to modify a filter on the report never worked. This happened because the dashboard link uses ignore_session in its related action. With this key, the options are never restored from the session. Since 16.4 and the introduction of sections, the session is however always used to reload the options after any filter assignation. Because of that, loadReportOptions always returned the original options of the report, and modifying a filter manually never had any effect. When coming from the menu item, ignore_session was not used, and the bug didn't occur. We solve that by changing the meaning of ignore_session and simplifying it: it will now forbid reading options from the session when the report is opened, and nothing more. This means that when opening a report with ignore_session=True, changing some filters, and then opening it again from another action without ignore_session, the options will still be restored. We consider it overall clearer for the user anyway: we always restore the options of the last time the report was opened within the current http session, ignoring the path followed by the user. Forward-Port-Of: odoo/enterprise#50385
This fix resolves an issue where filtering for archived analytic accounts and partners in General Ledger and Partner Ledger reports was not working correctly. When users selected archived accounts from the search results, the filter was ignored and the displayed data remained unchanged. This update ensures that archived account filters are now properly applied to the reports.
Original PR description
Steps to reproduce: - Activate "Analytic Accounting" in Accounting settings - Create an invoice with an analytic account (e.g. Administrative) - Archive the used analytic account (i.e. Administrative) - Go "Accounting / Reporting / Audit Reports / General Ledger" - Click on "Analytic" button - When selecting Accounts, click on "Search More..." - Filter "Archived" accounts - Select an archived account (e.g. Administrative) => The filter is selected but it is not taken into account. The displayed data stay unchanged. There is the same issue with partner filter in "Partner Ledger" report. opw-3514165 Forward-Port-Of: odoo/enterprise#50308 Forward-Port-Of: odoo/enterprise#49856
The system now intelligently decides which dialog to show when users click on the planning calendar. If there are existing shifts to plan, it displays the planning dialog; otherwise, it opens a form to create a new shift. This eliminates unnecessary dialog popups and streamlines the shift planning workflow.
Original PR description
Before this commit, when the user clicks on a gantt cell to plan a shift, a plan dialog is displayed even if there is nothing to plan. That behavior could be annoying for the user if he just wants to plan a new shift each time he clicks on a gantt cell. This commit checks if there is at least one shift to plan, if yes then the plan dialog will be displayed otherwise the form view dialog will be displayed to create a new shift to plan.
This fix resolves an issue where the planning view would crash when displaying employee avatars in certain database configurations without demo data. The system now gracefully handles missing progress bar information by using an alternative data source, ensuring the planning view displays correctly for all users.
Original PR description
On some db without demo data and in particular configuration, the changes introduced in https://github.com/odoo/enterprise/pull/49333 create a problematic situation where no progress bar info is available for a row with an employee. This commit avoids such traceback by falling back on the relation used for employee_id field if no info is available in the progress bar on the model used. Forward-Port-Of: odoo/enterprise#50215 Forward-Port-Of: odoo/enterprise#50169
This update removes an unwanted dependency that was accidentally created between the Luxembourg payroll and reports modules. The fix restores the correct module structure by reverting changes that incorrectly linked these two modules together, ensuring they operate independently as intended.
Original PR description
This PR [1] introduced unwanted dependency between l10n_lu_reports and l10n_lu_hr_payroll. In this commit we remove it. The PR [1] was attempt to undo error made in PR [2] [1] - https://github.com/odoo/enterprise/pull/49991 [2] - https://github.com/odoo/enterprise/pull/45720 Forward-Port-Of: odoo/enterprise#50381
This fix resolves an issue where financial reports (Balance Sheet and Profit & Loss) exported as XML files for Luxembourg were showing empty declarations with only dates populated. The underlying report generation logic was updated to correctly retrieve and display financial data in the exported files.
Original PR description
- Install l10n_lu_reports - Export a BS or P&L as an XML file - The declarations are empty, only the dates are added The way the lines are retrieved has been changed during the reportalypse. This commit adjusts report generation accordingly. opw-3421063 Forward-Port-Of: odoo/enterprise#50435 Forward-Port-Of: odoo/enterprise#50172