Tuesday, October 8, 2024
22 changes
4 changes
New functionality added to Odoo
This draft proof of concept adds support for setting a default grouping in Gantt timeline views. It could help users open planning screens with the most relevant organization already applied, reducing manual setup when reviewing schedules.
Enhancements to existing features
This update improves compatibility with newer OpenSSL and PyOpenSSL versions used for secure certificate handling. It helps electronic invoicing and related localization services continue working reliably across supported environments.
Original PR description
The OpenSSL API X509_get_notBefore got renamed to X509_getm_notBefore in OpenSSL v.1.0.0a. PyOpenSSL v19.0.0 calls the old name, PyOpenSSL v20.0.0 calls the new one. The related community PR also contains a small refactor of the _monkeypatches.py to allow simple import and creation of possible new monkeypatches and to put order onto the ones that are already in odoo.tools.misc Community PR: https://github.com/odoo/odoo/pull/95524
10 changes
Enhancements to existing features
List views now handle selected records more cleanly on small screens by grouping selection actions into one menu and showing the selection count as a floating notice. This reduces horizontal scrolling and keeps more records visible on mobile devices.
Original PR description
Ths List view allows to select one or multiple records. While doing so, an indicator is displayed, showing how much records are selected and providing actions to perform on them. On regular computer's screen, the central part of the ControlPanel is used to display this indicator and its related buttons, hiding the SearchBar. On smaller screens, all those visual elements take a lot of space, easily triggering an horizontal scrolling and taking an additional line in the ControlPanel, which push the records a bit down on the screen. This commit reuses the CogMenu paradigm to group all the actions/buttons in a single element. To avoid the records being pushed down, the selection indicator is transformed into a floating "Toast" as an overlay to the Navbar (similar to what was previously done to the Pager). task-3336242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
8 changes
Enhancements to existing features
This update fixes how accounting reports are formatted when exported to Excel files. The changes improve the layout by moving account codes to a more logical position in the spreadsheet and fixing indentation issues that previously limited reports to three levels. Users will now see cleaner, better-organized Excel exports with proper indentation support for complex report structures.
Original PR description
### [FIX] account_report: fix indentation in xlsx export Currently the indentation of XLSX export of reports was sometimes broken. The current implementation only supported up to three levels of indentation in the export as well. This fix supports a virtually infinite number of indentation levels and fixes the indentation in the XLSX exports. ### [I18N] account_reports: update terms ### [IMP] account_reports: move account code column to the right in xlsx Currently, when exporting an accounting report as XLSX file, we add a column for the account codes on the very left of the sheet. This looks a bit weird and is not the most important information to have as a first column. In this commit, we move the column to the right so the name of the line will be first, followed by the account code (if applicable). We also add a column name for the account codes. task-3986483
The Approvals app is easier to use with keyboards and screen readers. Menus, report printing, view buttons, selection states, and page landmarks now provide clearer accessibility cues, helping more users navigate the app confidently.
Original PR description
Improved accessibility for keyboard navigation and screen readers
- Added aria-labels:
- 'Actions menu' to action menu cog item
- Dynamic aria-label 'Print report: {report_name}' to print menu entry
- {view_name view} to view mode buttons
- Converted state_selection to use CheckBoxItem instead of DropdownItem:
- Improves audio narration to announce checked items properly.
- Updated main container landmarks:
- Used `<main>` node instead of `<div>` in views layout.
Task: 3603393
community:-https://github.com/odoo/odoo/pull/168878The Knowledge app now loads some interface parts only when they are needed. This should reduce initial loading work and make Knowledge feel faster, especially for users opening pages with complex views or navigation.
Original PR description
locs (js, xml, scss): ... Total lazy loaded locs: ? Task ID: `3546321`
The accounting secure entries wizard now alerts users when securing entries may also lock older-dated records outside the selected date. The warning includes a review action so users can inspect those affected entries before proceeding, improving visibility and reducing surprises in accounting workflows.
Original PR description
Consider the Secure Entries wizard. There it can happen that entries that are past the selected date are secured. This is possible since the hash chain corresponds to the sequence prefix, ordered by…
Consider the Secure Entries wizard.
There it can happen that entries that are past the selected date are secured. This is possible since the hash chain corresponds to the sequence prefix, ordered by sequence number.
Currently the user is not warned in case this happened.
This commit introduces a warning containing an action to show all moves that are past the selected date.
To generate the warning on runbot
1. Ensure there are no invoices with prefix INV/2020
(There should not be any on the runbot)
2. Create an invoice with (accounting) date 2020/01/02 (2 Jan 2020)
It should have name INV/2020/0001
3. Create an invoice with (accounting) date 2020/01/01 (1 Jan 2020)
It should have name INV/2020/0002
4. Activate debug mode (to see the wizard)
5. Go to Accounting (app) -> Accounting (menu) -> Secure Entries Wizard
6. Select 2020/01/01 as date (to include INV/2020/0002 but not INV/2020/0001)
7. The warning should show up
Clicking "Review" leads to a list view that includes INV/2020/0001 .
(INV/2020/002 has a higher sequence number but lower accounting date than INV/2020/0001).Resolved issues and error corrections
The stock operations board no longer allows cards to be dragged and dropped in grouped views. This helps prevent accidental changes that could cause operational issues in multi-warehouse setups.
Original PR description
In a multi-warehouse environment, dragging and dropping operations card by mistake in "group by" view can lead to many issues. Therefore, this PR disables this feature. task-4207673 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue that prevented users from closing Point of Sale sessions. It improves day-to-day store operations by ensuring session closing works correctly while handling administrator-level checks appropriately.
Original PR description
Before this commit: ==================== - The user cannot able to close the session. After this commit: ==================== - Able to close the session. - Check the logged-in user ID with the `SUPERUSER_ID` for the userError. task-4239959 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Switching a Point of Sale payment method away from a terminal integration now clears the terminal-specific fields. This prevents hidden or outdated terminal settings from blocking users when they save payment method changes.
Original PR description
[FIX] point_of_sale: ensure values are cleared when switching away from terminal payment method Problem: After a terminal provider is selected in "Integrate with" option, if the user change "Integration" option away from 'Terminal', the fields from terminal are still visible and getting validate. This makes record's changes cannot be saved if the fields are empty or do not pass validations. Steps to Reproduce: 1. Install Point of Sale app. 2. Go to Configuration > Settings. Enable any "Payment Terminals". 3. Go to Configuration > Payment Methods. Click new or edit a record. 4. Select a journal 5. Select an "Integration" option "Terminal" 6. Select a terminal in "Integrate with" option 7. Switch an "Integration" option to None 8. Observe that the added fields does not disappear and is still getting validate when you save the record. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Paid restaurant orders no longer keep a table marked as booked, so staff can quickly see which tables are truly available. The update also improves product setup visibility by showing tracking information in the Point of Sale product form.
Original PR description
## Commit 1 After paying an order in a table, the table isn't rendered to be "emtpy". In this change, we make sure that the order that makes a table "booked" is based on the table's active order that is not paid. There is already a getter for that which is the `.orders`. And since the `getOrder` method isn't used, we are also removing it in this change. ## Commit 2 Before: <img width="663" alt="Screenshot 2024-10-01 at 15 17 28" src="https://github.com/user-attachments/assets/cb7af694-cbc9-46d5-a219-048cfd6a1895"> After: <img width="665" alt="Screenshot 2024-10-01 at 15 16 07" src="https://github.com/user-attachments/assets/29bf899c-9f92-4bd7-b4e2-ec98ffcce24a">
Deleting certain accounting records could fail when they were still referenced by saved default settings. This update corrects that cleanup logic so users can remove affected records without encountering a system error.
Original PR description
To reproduce: - Setup 2 companies. Company 1 should use the generic CoA. - Go to Accounting -> Configuration -> Chart of Accounts - Open the account 110400 Cost of Production in Company 1. - In the 'Mapping' tab, add a code for the account in Company 2. - Change the account's `company_ids` to remove Company 1 and put Company 2 instead. - Open the Chart of Accounts list view with Company 2, and try to delete the account. - A traceback appears: `psycopg2.ProgrammingError: can't adapt type 'ir.model.fields'` Diagnosis: - `ir.default.field_id` is already a recordset, so we shouldn't do `self.env['ir.default'].browse(default.field_id)` in `BaseModel.unlink()`. taskid: none
This update aligns Enterprise tests with a fix in Odoo Community so recorded payments fully update invoices without requiring bank reconciliation. It helps ensure invoices show the correct remaining amount and payment status when users record payments in Community edition.
Original PR description
This commits only adapts tests based on the change of code of the related community PR. Message of the community PR: In Odoo Community, bank reconciliation is not available. For that reason, when recording a Payment, this should be enough to fully recognize the payment of the invoice, as there is no second "reconciliation step". In this case, we always want a "behind-the-scene" entry to be created to compute the amount_residual and the status of the invoice accordingly. After the Payments rework, the problem is that by default, no Outstanding account is set up on basic Payment Methods, not triggering any entry and messing up the computation of the invoice status. On top of that, the user can't even configure accounts on journals, as this is only possible in Enterprise edition. Outstanding accounts have also been re-instantiated as they are actually necessary in community edition. task-4224553
This update standardizes Mexican electronic invoicing on global rounding and fixes a rounding issue when combining multiple invoices into one global invoice. It helps ensure invoice totals and tax amounts match expected legal reporting values, reducing small discrepancies in Mexican CFDI documents.
Original PR description
[IMP] l10n_mx_edi: Remove support of round_per_line Now the round globally is fully working and since we enforced the round_globally in Mexico, let's force all Mexican users to use the round…
[IMP] l10n_mx_edi: Remove support of round_per_line Now the round globally is fully working and since we enforced the round_globally in Mexico, let's force all Mexican users to use the round globally. [FIX] l10n_mx_edi: Fix global invoice taxes aggregator with round globally When the global invoice is made on multiple invoices, aggregating rounded values lead to rounding issues. That's the case for "Subtotal" in the test case added in this commit: Suppose 5 invoices having a single invoice line with 16% price included tax. The unit price are: 2803.0, 1842.0, 2798.0, 3225.0, 3371.0. 2803 + 1842 + 2798 + 3225 + 3371 = 14039 14039 / 1.16 = 12102.586206897 ≃ 12102.59 Before this commit, when aggregating each 'Subtotal' of CFDI file, one per invoice: 2416.38 + 1587.93 + 2412.07 + 2780.17 + 2906.03 = 12102.58 [IMP] l10n_mx_edi: Cleanup dead code When introducing the dispatching on the negative lines long time ago, we added a config parameter to disable it. Now, it doesn't make any sense to disable it and the config parameter is gone so the method always returns True. Let's remove it.
This fix ensures that when a receipt is processed through the barcode app and part of a product fails a quality check, both the accepted and failed quantities are received correctly. The failed quantity is moved to the chosen failure location instead of incorrectly creating a backorder, improving inventory accuracy and warehouse workflow reliability.
Original PR description
Steps to reproduce: - Create a QP (quantity and pass/fail, also define a failure location) on a product on receipt picking type. - Create a receipt order with any quantity of this product. - Open the picking from the barcode app. - Open the quality wizard. - Fail the check. - From the second wizard, set a partial quantity and a failure location. - Confirm the wizard. - Validate the transfer. Current behavior: Only the passed quantity is added to the stock, and a backorder is created with the failed quantity. Expected behavior: The whole quantity should be added to the stock with each line moved to its corresponding location.
The demo data for Argentina's reporting module has been updated to remove real partner information and replace it with fictional data. This improvement protects actual customer privacy while maintaining the ability to test and demonstrate the system's functionality.
Original PR description
This task was created to modify the demo data for Argentina, to avoid using real partner information. latam-task-1239 adhoc-task-41734 Forward-Port-Of: odoo/enterprise#71230
The system now correctly identifies late bills in GST Return-2B reports by comparing the bill date against the return period start date, rather than using an inaccurate comparison method. This ensures businesses get accurate reporting of late vendor invoices, which is important for GST compliance and financial accuracy.
Original PR description
Previous behavior: - Late bills were determined by comparing `supprd` with the `return period`, which led to inaccuracies. New behavior: - Late bills are now identified by checking if the `bill date` is earlier than the `return period start date`, ensuring more precise classification of late bills. OPW: 4210068 Forward-Port-Of: odoo/enterprise#70225
Resolved issues and error corrections
This fix resolves a system error that occurred when invoice consolidation was enabled and multiple users were assigned to subscription invoices simultaneously. The issue caused the billing process to crash with a technical error. By disabling the automatic user assignment notification during consolidation, the system now handles these scenarios correctly without interruption.
Original PR description
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed: ``py File…
Before this commit, when the invoice consolidation option was activated and several user_id were set on subscription invoicing at the same time, a traceback was observed:
``py
File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 276, in create
thread._message_auto_subscribe(create_values, followers_existing_policy='update')
File "/home/arj/PycharmProjects/worktree/17.0/odoo/addons/mail/models/mail_thread.py", line 4138, in _message_auto_subscribe
res = self._message_auto_subscribe_followers(updated_values, def_ids)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/17.0/enterprise/sale_subscription/models/account_move.py", line 76, in _message_auto_subscribe_followers
if salesperson and user_id == salesperson.id and user_id != self.env.user.id:
^^^^^^^^^^^^^^
File "/home/arj/PycharmProjects/worktree/17.0/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: res.users(56, 60)
```This update corrects how quarterly tax declaration fields are submitted to Spanish tax authorities (AEAT). Previously, new fields introduced for Q4 2024 and later were left empty, but the tax authority's submission system now requires these fields to be filled with zero values instead. This ensures tax reports are properly accepted by the AEAT system.
Original PR description
According to the documentation of the new Modelo 303 BOE export, the new fields that will be used for the declarations starting in 10/2024 or Q4/2024 "can only be completed from periods 10 and 4Q of 2024 and subsequent years". As such, we left the fields "empty" using the space character (like in other places). However, now that the new AEAT submission page is ready, it seems they expect us to fill the new fields with zeroes instead of leaving them empty. This commit fixes that. [opw-4222842](https://www.odoo.com/odoo/all-tasks/4222842) Forward-Port-Of: odoo/enterprise#71379
This fix corrects how product demand quantities are displayed in the Master Production Schedule (MPS). Previously, when products used different units of measurement (like dozens), the system was not properly converting the quantities, causing demand to appear incorrectly (showing 1 unit instead of 12). This fix ensures quantities are always shown in the product's correct unit of measurement.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: Unit - Create a transfer for one dozen of P1: - Mark it as "To Do" - Go to the MPS: - Add the product “P1” - In the filter, add “Actual Demand” Problem: The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1. opw-4199710 Forward-Port-Of: odoo/enterprise#71216
This update improves how product information appears in Ecuador electronic invoices by prioritizing the line item name in the description field. Companies that include detailed product information in invoice line labels will now see this information properly displayed in the XML format used for electronic document submission, providing better clarity and detail in official invoices.
Original PR description
- In order to have more detail of the product used in the invoice, many companies place information in the label of the invoice line, we prioritize the name field to be displayed in the description tag of the xml.
This fix corrects an issue where Amazon orders containing multiple items were incorrectly creating separate shipping lines for each item, even when no per-item shipping cost was defined. Now shipping is properly consolidated, preventing duplicate and incorrect charges on customer orders.
Original PR description
If an Amazon order has more than one item it was creating for each item an own shipping line even if it had not even a shipping price defined per item line. Info: @wt-io-it