Search
Navigate
Branch
Friday, September 15, 2023
19 changes
New functionality added to Odoo
Payroll teams now get a dashboard warning when employees have bank accounts that are not yet trusted. They can also mark those accounts as trusted through an action, helping reduce payment errors before SEPA payroll files are created.
Original PR description
…sted bank accounts task - 3284174
Enhancements to existing features
Tax reports will now open using the previous tax period instead of always defaulting to the previous calendar month. This better supports businesses whose tax reporting cycles are monthly, quarterly, or follow another schedule.
Original PR description
Currently the tax report always opens the previous month by default. Since tax periods are not always months, it makes much more sense to open the previous "tax period" (whatever length it has) when opening the tax report. In order to allow that, this commit introduces the calculation and selection of tax periods on reports. The rest of the functionality is done in the related community commit. [task-3481913](https://www.odoo.com/web#id=3481913&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Related to https://github.com/odoo/odoo/pull/133715
Resolved issues and error corrections
This fix prevents an error from appearing when users open the Timesheet list view in developer mode. It aligns the Timesheet list view configuration with the expected format, improving reliability for teams reviewing timesheet entries.
Original PR description
- 1 Issue
ListRenderer pros type is array/list and timesheet_grid inside pros type
is object, both mismatch so i think this issue is raised.
- 2 Fix:
We have replaced object with list type in list renderer pros.
Step to reproduce:
- Install Timesheet
- Turn on developer mode
- Go to timesheet
- Click on listview
task- 3507986Code cleanup and technical improvements
The spreadsheet editing component was internally renamed from RecordsSelector to TagsSelector to better match its purpose. This is a technical cleanup that should not change how users work, but it makes future maintenance easier.
Miscellaneous changes
Avatax returned positive tax amounts for records with a single line with a negative quantity. The Avalara documentation specifies that the quantity field should always be positive, even when it's a return or refund [1]. The sign is determined by 'amount'. Changing the larger, overarching test_*_odoo_invoice tests to include negative quantities was considered but doing so doesn't catch this bug. Those tests ensure Odoo does the right thing with the Avatax responses. That works correctly. In
Original PR description
Avatax returned positive tax amounts for records with a single line with a negative quantity. The Avalara documentation specifies that the quantity field should always be positive, even when it's a…
Avatax returned positive tax amounts for records with a single line with a negative quantity. The Avalara documentation specifies that the quantity field should always be positive, even when it's a return or refund [1]. The sign is determined by 'amount'. Changing the larger, overarching test_*_odoo_invoice tests to include negative quantities was considered but doing so doesn't catch this bug. Those tests ensure Odoo does the right thing with the Avatax responses. That works correctly. Instead the issue lies in the request we send to Avatax. A simple test was added to ensure only positive quantities are sent. [1] "This quantity value should always be a positive value representing the quantity of product that changed hands, even when handling returns or refunds." https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/CreateTransaction/ PS. Before this patch another incorrect behavior occurred on sale.order. The amounts on a line with a negative quantity would flip between positive and negative after each button_update_avatax(). This happened because account_avatax_sale sets price_subtotal on the line from the Avatax response. Since we send price_subtotal as 'amount' to Avatax it would alternate between positive and negative because we also sent the negative quantity. It's not necessary to set price_subtotal (US only has price-excluded taxes and we don't do it on account.move), but because it doesn't cause any immediate issues it wasn't changed. opw-3431324 Forward-Port-Of: odoo/enterprise#47441 Forward-Port-Of: odoo/enterprise#45095
Barcode users can now see product images during stock move operations and inventory adjustments, helping them identify items more quickly and accurately. Selecting an image opens a fullscreen preview, and product references and names are separated for easier reading.
Original PR description
With this commit ================ - Product Image appears for all the stock move operations and inventory adjustment. - Onclicking the Image it shows up in fullscreen. - Product Reference and Name are displayed on two separate lines. Task ID : 3329820
Gantt schedule views can now load a limited number of groups at first, reducing wait times on large schedules. Rental Schedule uses this new limit so users can start working sooner instead of waiting for all records to load.
Original PR description
Some gantt views (notable exemple perf-wise is Rental > Schedule, but it's not the only one) can take some time to load, since they try to load everything. By adding a pager to the gantt view that only loads the "XX" first groups, we can make the performance issue less of an issue by allowing devs to control the amount of records shown. The limit is set via the optional arch root attribute "groups_limit". We set a limit of 20 on the view Rental > Schedule. Task ID: 3054548
Event organizers can now generate and use QR codes for attendee access without relying on traditional barcodes. This makes event check-in more flexible and easier to manage with common scanning tools.
Original PR description
This PR allows organizers to use QR codes without needing a barcode. task-3411827
This update corrects syntax mistakes in Web Studio page templates that could cause errors in certain screens. It also supports better automated checks so similar template issues are caught earlier, improving reliability for users.
Original PR description
New test from community catches syntax mistakes of qweb files. This PR fixes those issues. https://github.com/odoo/odoo/pull/128445
Performance test benchmarks were adjusted to match recent underlying platform changes. This keeps internal test checks accurate and helps avoid false failures in development workflows, with no expected impact on end users.
Original PR description
This commit modifies the query count of some performance tests to cope with changes made in https://github.com/odoo/odoo/pull/131355 task-3442819
Switching between bank reconciliation cards no longer triggers duplicate background requests. This reduces unnecessary processing and should make the reconciliation view feel more responsive and reliable for accounting users.
Original PR description
Since the new relational model https://github.com/odoo/odoo/pull/114024, in the kanban reconciliation view, when the card is switched, two similar "web_search_read" RPCs are executed. Why: Because two renderings are caused, one because of the update applied to the record datapoint and the second when the newState is applied to the kanban view. Solution: Customise the Relational Model to have a custom update for "todo_command". The changes will be applied when the newState is applied so that there is only one rendering.
The event barcode setup now updates registration barcodes in one batch instead of many separate database calls. This reduces installation time and database overhead, especially when the database is hosted separately, while focusing barcode generation on current and future events.
Original PR description
## Description During the installation of the module `event_barcode`, we have an override of `_init_column` for the `barcode`. We were using the psycopg's `executemany` which is just a syntactical…
## Description During the installation of the module `event_barcode`, we have an override of `_init_column` for the `barcode`. We were using the psycopg's `executemany` which is just a syntactical sugar for a loop over an `execute`. So we trigger 1 query (which incurs a network cost when deployed and the database is not on the same machine) per row, currently we have 27 queries (for demo data). ## Solution We can use SQL syntax: ```sql UPDATE ... SET ... FROM (VALUES ...) WHERE ... ``` which does 1 update for all rows in one go. ## Implementation details We could implement this query directly with a simple execute, but it requires a lot of manual construction with the help of `sql. Composed`, because of necessity to insert manually `sql.Literal` used for the tuples of the `VALUES`. Psycopg2 exposes a function called `execute_values` which is just for this case and makes to code way more legible. We also generate barcodes only for registrations linked to event that are ongoing or in the future, to improve the speed of the UPDATE itself (we update less rows). ## Reference task-3430406
The Belgian fleet expense calculation now shows rates as percentages instead of decimals. This prevents misleading values such as 0.5 appearing where 50 should be shown, helping users apply the correct disallowed expense rate.
Original PR description
Currently the rate is incorrectly computed (0.5 instead of 50)
Forward-Port-Of: odoo/enterprise#47468
Original PR description
Forward-Port-Of: odoo/enterprise#47468
Remove useless padding from 'o_content' that broke warnings padding. Forward-Port-Of: odoo/enterprise#47341
Original PR description
Remove useless padding from 'o_content' that broke warnings padding. Forward-Port-Of: odoo/enterprise#47341
Part of task-3101400 Forward-Port-Of: odoo/enterprise#47378
Original PR description
Part of task-3101400 Forward-Port-Of: odoo/enterprise#47378
Fetching transactions using bank sync can be confusing since users can't tell which transactions were fetched and which transactions were manually created by themselves. This commits makes the fetched transactions get posted by Odoobot. Task ID: 3336907 Forward-Port-Of: odoo/enterprise#47091
Original PR description
Fetching transactions using bank sync can be confusing since users can't tell which transactions were fetched and which transactions were manually created by themselves. This commits makes the fetched transactions get posted by Odoobot. Task ID: 3336907 Forward-Port-Of: odoo/enterprise#47091
To reproduce: Create a bill with transporting tax for Deco Addict Create a second one but with Azure Interior Go on tax report, select PND53, export PND53 => The row number are not in the right order. We should order the row number with the right order, and then use this row number to order the lines Linked to runbot error 24628 Forward-Port-Of: odoo/enterprise#47209
Original PR description
To reproduce: Create a bill with transporting tax for Deco Addict Create a second one but with Azure Interior Go on tax report, select PND53, export PND53 => The row number are not in the right order. We should order the row number with the right order, and then use this row number to order the lines Linked to runbot error 24628 Forward-Port-Of: odoo/enterprise#47209
After PR https://github.com/odoo/enterprise/pull/44274 we create a separate move for exchange difference but it was not set to the right date. It needs to be the maximum date of involved lines in reconviliation. Forward-Port-Of: odoo/enterprise#47397 Forward-Port-Of: odoo/enterprise#47354
Original PR description
After PR https://github.com/odoo/enterprise/pull/44274 we create a separate move for exchange difference but it was not set to the right date. It needs to be the maximum date of involved lines in reconviliation. Forward-Port-Of: odoo/enterprise#47397 Forward-Port-Of: odoo/enterprise#47354