Saturday, November 25, 2023
21 changes · 17.0
Resolved issues and error corrections
This fixes a crash in the Accounting invoice analysis pivot report when users collapse a column group and then expand it by month. The report now uses the correct date grouping, so business users can analyze invoices by month without interruption.
Original PR description
Accounting > Reporting > Invoice Analysis Open Pivot View Collapse column group, expand by Date>Month StopInteration traceback will raise line: column = self._read_group_postprocess_aggregate(spec, next(column_iterator)) The error is caused by a missing interval attribute on the group by pivot view default search. This will make the view call `read_group` with a wrong groupby list ['invoice_date', 'invoice_date:month'], that will cause the error raise opw-3603433 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where module loading errors could make the web test suite appear blank instead of showing the problem. This helps teams diagnose test failures faster and keeps automated quality checks clearer.
Original PR description
Since the module loader rewrite, it now reports errors directly in the DOM. The error alert also has the class "modal" so that in case a tour comes accross a page with module loading errors, it will only look for elements inside it and fail. But in the QUnit test suite, modals are invisible by default, causing the page to be blank in those cases. This commit adds a css rule to make sure that this error alert is shown, and updates the code that was previously used to report these errors in the qunit suite to instead simply check for errors reported by the module loader.
The spreadsheet component was updated to a newer version with fixes that make copying, pasting, formula handling, and row removal more reliable. It also includes performance improvements for calculations and lookups, helping large spreadsheets feel faster and reducing user-facing errors.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7346d0af9 [REL] 17.0.4 https://github.com/odoo/o-spreadsheet/commit/661e290f4 [FIX] sheet: remove zombie code…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/7346d0af9 [REL] 17.0.4 https://github.com/odoo/o-spreadsheet/commit/661e290f4 [FIX] sheet: remove zombie code https://github.com/odoo/o-spreadsheet/commit/7362fc105 [FIX] sheet: remove rows faster https://github.com/odoo/o-spreadsheet/commit/dcaa1ab0c [FIX] tokenizer: faster current char lookup https://github.com/odoo/o-spreadsheet/commit/0448b26f5 [FIX] tokenize: replace special chars faster https://github.com/odoo/o-spreadsheet/commit/88a57c6be [FIX] icons: use correct comment syntax in xml files https://github.com/odoo/o-spreadsheet/commit/cf8194df2 [FIX] clipboard: fix array formula copy https://github.com/odoo/o-spreadsheet/commit/ca24d7e8c [FIX] evaluation: faster range matrix https://github.com/odoo/o-spreadsheet/commit/a13ff80b3 [FIX] clipboard: traceback on paste from copy after deleting that sheet https://github.com/odoo/o-spreadsheet/commit/eaa0dca12 [FIX] evaluation: cache range references values Task: 3588401 https://github.com/odoo/o-spreadsheet/commit/cdeb716c3 [REF] evaluation: group compilation parameters https://github.com/odoo/o-spreadsheet/commit/943a7e7f8 [FIX] lookup: cache string normalization Task: 3588401 https://github.com/odoo/o-spreadsheet/commit/0330db03c [FIX] cells,borders: cancel useless commands Task: 3603259 https://github.com/odoo/o-spreadsheet/commit/38d77fe89 [FIX] cells: faster getter to get cell Task: 3588401 https://github.com/odoo/o-spreadsheet/commit/15bdafc80 [FIX] model: don't flatten command result
This fix prevents mail conversations from repeatedly loading older messages when a chat is reopened or unfolded. It also ensures inbox previews show the true latest message, improving reliability for users navigating recent and older conversations.
Original PR description
The issue is that "load older" was called every time the thread was made visible, in particular after chat window unfold. The load more button will naturally be visible when first loading a thread, it only makes sense to check its final visibility and not intermediate steps. But there was a bug where the loading mechanism was relying on the initial "load older" to fetch messages, because the messaging menu preview was incorrectly setting the thread as already loaded, when it just fetched the last message. Moreover, the "last message" displayed in the preview was not correctly computed, and it could end up being the last "currently fetched" message and not the last of all messages (when jumping in the past), and it could also be a non-persistent message. runbot-35533
Downloading a preview of an invoice that has not yet been confirmed no longer triggers an error. The system now only allows PDF download handling when the invoice is posted, improving reliability for users working with draft invoices.
Original PR description
Steps to reproduce: ------------------- - create an invoice without confirm it; - go to the preview and download it; Issue: ------ A traceback appears. Cause: ------ We try to get `ids` field of a non "record" object (not the root cause). The root cause is that we don't create an attachment if the invoice is not posted. And to post an invoice, we must add line before confirm it. Solution: --------- Make sure you are in the case of an invoice that is `posted` to download a pdf. sentry-4612532780
This update helps Belgian users choose the correct Peppol identification code by showing a warning that Belgium should use 0208. It also ensures only customer invoices, credit notes, and receipts are marked as Peppol ready, making batch sending more reliable and reducing accidental selections.
Original PR description
## [FIX] account_peppol: add a warning for Belgium Users need a helpful message for selecting the right EAS and Endpoint numbers. In Belgium it should always be 0208 according to BOSA, so we can display a warning message advising them to select that code for Belgian partners. ## [FIX] account_peppol: fix peppol ready We should only mark account moves as "Peppol ready" if it's a customer invoice/customer credit note. These are also the only types of account moves we should display when a user wants to filter by "peppol ready" as this means they want to easily select all and send them via peppol in batch. This commit limits "Peppol Ready" to `out_invoice`, `out_refund`, `out_receipt`. task-3603416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents event website pages from showing an error when a visitor's browser does not support service workers. It keeps the experience stable for affected visitors instead of displaying a technical crash dialog.
Original PR description
PR [1] removed the legacy error handler that swallowed promise rejection errors with anything else than an error (namely, the "legacyRejectPromiseHandler"). As a consequence, promise rejections done as "control flow" now lead to error dialogs being displayed. In particular, it happened on the website (with website_event_track installed), if the browser doesn't support service workers. This commit simply leaves the promise pending if the feature is unavailable. [1] https://github.com/odoo/odoo/pull/137702 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where changes to a bank journal payment method could be lost when another payment method was removed at the same time. This helps accounting users avoid rework and keeps payment configuration changes reliable.
Original PR description
When users edit a outbound/inbound payment method line of their bank journal and in the same time remove another payment method line, the edited line changes for their initial state (without the…
When users edit a outbound/inbound payment method line of their bank journal and in the same time remove another payment method line, the edited line changes for their initial state (without the change). It was caused by a complicated way to know which payment method line are available for this journal. This non stored compute field is recompute for each change made on the inbound/outbound payment method line. It means that the function deal with origin record instead of record itself. During the search for this fix, we found out that everything work fine if we remove the column_invisible on this computed field. In that case, we had not so many calls to the compute function to get the values. It's obviously not a solution and that's why after some investigations, we decide to use the _origin id when we get the outbound/inbound_payment_method_line in the _compute_available_payment_method_ids function. Thanks to @h4818 for his help during the process. opw-3597536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures datetime range fields correctly understand when they are required. It prevents unnecessary extra date inputs from appearing and avoids validation issues in debug mode, improving form reliability for users.
Original PR description
Previously, the datetime field read the value for required directly in the attrs when extracting its props when available. This resulted in 2 separate bugs: - in debug mode, props validation of the…
Previously, the datetime field read the value for required directly in the attrs when extracting its props when available. This resulted in 2 separate bugs: - in debug mode, props validation of the datetime picker would fail, as it expects to receive a boolean for the `range` prop. This was caused by the fact that required was the raw attribute (a string) instead of the boolean and ended up being propagated to the `range` prop - outside of debug mode, the value for required did not cause a crash but any value for required that was not empty would be interpreted as truthy, causing the field to always be display itself as though it is required. In non-range mode, this is invisible, but in range mode, it would always show the second datetime input and the arrow between the beginning and end date, even with required being 0/False, or a python expression that may evaluate to false This commit fixes that by instead reading the value for required from the dynamic infos provided to `extractProps`, which will always be a boolean and contain the value of the evaluated expression when appropriate.
This update fixes a technical issue in the Planning module where an outdated translation function was replaced with the current standard. This ensures the module continues to work properly with the latest system updates and maintains compatibility with the current codebase.
Original PR description
In this commit we fix _lt with _t. Let's see more informations on https://github.com/odoo/odoo/pull/124157
Fixed a visual bug in the timesheet timer where selecting a project or task caused unwanted extra height to appear on mobile devices. The issue was caused by an oversized arrow button (1.3em) that was pushing content down. The fix reduces the button size through a new stylesheet to maintain consistent layout when making selections.
Original PR description
**Steps:** - Open timesheet - Switch to mobile view - Start the timer - Select a Project / Task from dropdown - (Appears in all the views) **Issue:** - When a project/task is selected, extra height appears beneath it **Cause:** - The extra height is caused due to the arrow button which has a size of 1.3em **Fix:** - Making a new scss file for this instead of changing in base files and adding style to reduce the size of the button. **Task:** 3387850 Forward-Port-Of: odoo/enterprise#43428
This fix ensures that the WhatsApp category appears in the mobile version of the Discuss app's bottom navigation bar, matching the desktop experience. Previously, users could see WhatsApp conversations on desktop but the category was missing from mobile navigation, making it harder to access WhatsApp messages on phones and tablets.
Original PR description
WhatsApp category was shown in Discuss app sidebar in desktop, but was not visible in the bottom navbar in mobile. Part of Task-3525542 opw-3580979
This update corrects how fuel type information is stored and displayed for company vehicles in the Belgian payroll system. The fix ensures that fuel type selections are handled properly without storing unnecessary data in the database, maintaining compliance with system policies while preserving the ability to show fuel types for new vehicles.
Original PR description
https://github.com/odoo/enterprise/pull/47717 fixed the display of the fuel type for a new car, as it was not being shown. However, the change from that PR was not respecting stable policy. This commit fixes this by changing the selection values from a static list to a lambda function that returns that list This makes the selection values not be stored in the database. Forward-Port-Of: odoo/enterprise#51297
A display issue in the field service portal task view has been corrected where the "Time & Material" section was appearing in the wrong location. The fix updates the underlying code to ensure this section displays in the correct position above the Timesheets section, improving the user experience when viewing task details.
Original PR description
In field service's portal task view, a display error would occur with the "Time & Material" section ; it would get displayed next to the "Timesheets" section which is wrong, as it should be displayed on top of it. The issue is that with the rework of portal's front in 17.0, the xpath expression that supposedly selects the "Timesheets" section now selects the "Timesheets" navigation menu, and makes the "Time & Material" section display right on top of it. To fix this, the xpath expression was changed to select the right element. task-3609165
This fix resolves an import error that occurred when Odoo Enterprise was installed as a package. A missing initialization file was preventing the bank statement import module from loading correctly. This ensures the bank statement import functionality works reliably in packaged installations.
Original PR description
When enterprise is installed as a package, importing this odoo.addons.account_avatax will raise an ImportError due to this missing file. @moduon MT-1075 Forward-Port-Of: odoo/enterprise#48669
This fix corrects how Odoo generates SEPA payment files to comply with banking standards. The ChrgBr (Charge Bearer) tag is now placed at the payment level instead of the transaction level, following official SEPA specifications. This resolves issues where some banks were rejecting payment files due to incorrect formatting.
Original PR description
In the SEPA specification: "It is recommended that this element [ChrgBr] be specified at ‘Payment Information’ level." In odoo the ChrgBr was set at transaction level leading to some bank refusing the SEPA file. To follow the specification recommendation, ChrgBr is moved at the payment level. opw-3479639 Forward-Port-Of: odoo/enterprise#51376
This fix resolves an error that occurred when printing invoices in the Accounting module with Documents enabled. The issue happened because documents were being created multiple times concurrently, causing a validation error. The fix ensures documents are created immediately when attachments are created, rather than when they're loaded in the chat, preventing duplicate creation attempts.
Original PR description
Steps to reproduce: - Install Accounting and Documents - Go to Documents settings - Activate "Accounting" option (Workspace: Finance) and add a journal to synchronize (Journal: Customer Invoices -…
Steps to reproduce: - Install Accounting and Documents - Go to Documents settings - Activate "Accounting" option (Workspace: Finance) and add a journal to synchronize (Journal: Customer Invoices - Workspace: Finance) - Go to Accounting and create an invoice - Click on Print button and select "Invoices" => The following Validation Error can be raised: "The operation cannot be completed: This attachment is already a document" (This issue depends on the speed of the platform and doesn't always happen) Cause: When printing the invoice, an attachment is created, but no document is created in Documents immediately (as configured in Documents settings). Once the attachment created, it is loaded in the chatter and several calls are made to "register_as_main_attachment" method of the attachment. This method is triggering a write on the related record (i.e. the invoice), which tries to create a document (in Documents) from the attachment. When trying to create the document, it first checks if a document already exists for that attachment. But in some cases, there can be 2 concurrent calls where the first one has not finished creating the document when the second one checks if a document already exists. It then tries to create a second document for the attachment and triggers the SQL unique constraint. Solution: The creation of the document should not depend on the loading of the attachment in the chatter. It should be created when the attachment is created. So, when the first attachment of an account move is created, the related document will also be created. opw-3464593 Forward-Port-Of: odoo/enterprise#51114
This update reverts a previous change to how reported dates and hours are calculated in planning templates. The previous fix was causing unintended behavior changes in the stable version. A more comprehensive solution will be developed separately to properly handle shift template generation when users save shifts as templates.
Original PR description
This reverts commit 145fdbc because the fix alters the behavior in planning template which is not really allowed in stable. A another fix will be done to correctly compute the shift template generated when the user saves a shift as template. Forward-Port-Of: #50933
This fix ensures that spreadsheet record names are properly displayed as text strings when users access shared spreadsheets. Previously, in certain cases where a record didn't have a defined name, the system would return an empty value instead of a text string, causing display issues in the spreadsheet interface. This update corrects how the system retrieves and formats record names to ensure consistent, reliable display for all users.
Original PR description
When fetching the record data from the server via `join_spreadsheet_session`, we rely on the field `display_name` while expecting it to be a string. This will however not be the case since [1] (i.e. if `_rec_name=""` then `display_name=False`). The client components are expecting a string, we therefore fix `join_spreadsheet_session` accordingly. [1] https://github.com/odoo/odoo-security/commit/c68fb4a494acc38b97678ed2a1fe18dbf8f3fa9d Task: 3562167 Forward-Port-Of: odoo/enterprise#51296
This fix resolves a display problem in the timesheet grid where long task titles would expand across the entire screen, making it impossible to see the timesheet data. The solution adds a maximum width constraint to task titles so they properly truncate with ellipsis, allowing users to view both the task name and timesheet information simultaneously.
Original PR description
This commit fix a UI issue due to unset max-width on the o_grid_row_title.
HOW TO REPRODUCE:
- Go in project
- Create a task with a very long name
- Go in timesheet
- Record a tisheet line linked to the created task
ISSUE:
- The title takes all the screen and we cannot see the timesheets.
FIX:
- Put a maximun width for the row titles in order to trigger the
text-truncate
taskid:3539337
Forward-Port-Of: odoo/enterprise#51390Fixed an error handling issue in the Shiprocket delivery integration where the system was not properly managing error responses from the shipping provider. This fix ensures that when the Shiprocket API returns an invalid payload response, the system now correctly handles and reports the error instead of failing silently, improving reliability of shipping operations.
Original PR description
When `payload` response is false, need to handle error. opw-3604932 Forward-Port-Of: odoo/enterprise#51261