Navigate
Branch
Wednesday, October 2, 2024
25 changes
2 changes
Miscellaneous changes
In #167973 (merged in 17.0+), we enabled the audit trail by default when loading the German localization. TSB requested that we indicate this explicitly in the manifest. task-none Forward-Port-Of: odoo/odoo#182295
Original PR description
In #167973 (merged in 17.0+), we enabled the audit trail by default when loading the German localization. TSB requested that we indicate this explicitly in the manifest. task-none Forward-Port-Of: odoo/odoo#182295
This issue occurs only in frontend debug (which I initially missed but odony caught), the problem is that the `InputConfirmationDialog` used for the creation dialog has a required `onInput` callback in its props but none is provided by the "new api key" button case. Props are (I assume) only validated in debug mode, so that's the only situation in which the error appears... and blocks users. While `onInput` seems like a useful hooks for input validation and stuff, it doesn't seem necessary to
Original PR description
This issue occurs only in frontend debug (which I initially missed but odony caught), the problem is that the `InputConfirmationDialog` used for the creation dialog has a required `onInput` callback in its props but none is provided by the "new api key" button case. Props are (I assume) only validated in debug mode, so that's the only situation in which the error appears... and blocks users. While `onInput` seems like a useful hooks for input validation and stuff, it doesn't seem necessary to mandate it, and the code specifically checks if it's unchecked (and ignores it in that case). OPW-4194305 Forward-Port-Of: odoo/odoo#182285
7 changes
Enhancements to existing features
This draft change removes unnecessary frontend asset files from field service-related modules to reduce what the browser needs to load. The expected business benefit is a faster, smoother user experience, especially for field service users working in the web interface.
Original PR description
Specification: This PR aims to remove unnecessary files populated in asset frontend to optimize the load time. task-4146922
14 changes
Security fixes and vulnerability patches
User-created filters are now handled more safely when accessed through the experimental JSON route. The route is also turned off by default in production unless enabled in configuration or when demo data is installed, reducing risk from unfinished functionality.
Original PR description
Static parsing for ir_filter, and add a configuration switch to enable/disable the route, as it is experimental
2 changes
Resolved issues and error corrections
A specialized product catalog view designed for field service management was incorrectly appearing when selecting products on sales orders in mobile view. This fix ensures the catalog view is only used in its intended location, preventing confusion and ensuring the correct product selection interface appears in sales orders.
Original PR description
For all 17.0 databases of a specific partner (strangely it couldn't be reproduced on runbot), the fsm catalog view was used to select product on sale order lines in mobile view. This commit ensures that this custom view will only be used for the specific action using it and won't appear in other places. opw-4196351
This update adjusts an internal timesheet test to match a recent change in how employee company information is handled. It helps keep automated checks reliable without changing day-to-day user workflows.
Original PR description
task-4149953
Miscellaneous changes
We forgot to add the field. We'll go for a model method in this fix, this can be cleaned to a field in master. Task-4216195 Forward-Port-Of: odoo/enterprise#71191
Original PR description
We forgot to add the field. We'll go for a model method in this fix, this can be cleaned to a field in master. Task-4216195 Forward-Port-Of: odoo/enterprise#71191
The tour `spreadsheet_dashboard_document_add_document_to_dashboard_group` was never actually run because the python method wasn't prefixed by `test_`. The toru was also broken since we allowed to create a dashboard based on a new spreadsheet. Task: [4199036](https://www.odoo.com/web#id=4199036&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#71198 Forward-Port-Of: odoo/enterprise#70355
Original PR description
The tour `spreadsheet_dashboard_document_add_document_to_dashboard_group` was never actually run because the python method wasn't prefixed by `test_`. The toru was also broken since we allowed to create a dashboard based on a new spreadsheet. Task: [4199036](https://www.odoo.com/web#id=4199036&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#71198 Forward-Port-Of: odoo/enterprise#70355
This PR addresses a styling issue in the kiosk mode of Frontdesk. Before this pr, the landing page would not fill the height of the window causing the whole user experience to be strange. task-4213241 Forward-Port-Of: odoo/enterprise#70926
Original PR description
This PR addresses a styling issue in the kiosk mode of Frontdesk. Before this pr, the landing page would not fill the height of the window causing the whole user experience to be strange. task-4213241 Forward-Port-Of: odoo/enterprise#70926
Forward-Port-Of: odoo/enterprise#71238 Forward-Port-Of: odoo/enterprise#70302
Original PR description
Forward-Port-Of: odoo/enterprise#71238 Forward-Port-Of: odoo/enterprise#70302
Adds the possibility to synchronize exchange rates using the API provided by the Bank Of Thailand (BOT). Rates are synchronized using yesterday as a date, as they do not provide rates for the current day. Task id # 3724438 Forward-Port-Of: odoo/enterprise#67767
Original PR description
Adds the possibility to synchronize exchange rates using the API provided by the Bank Of Thailand (BOT). Rates are synchronized using yesterday as a date, as they do not provide rates for the current day. Task id # 3724438 Forward-Port-Of: odoo/enterprise#67767
Enhancements to existing features
Odoo now avoids relying on a deprecated dependency-checking library during normal startup and setup checks. This reduces warning noise and future compatibility risk while keeping advanced dependency checks available only when needed.
Original PR description
This is a followup pr to #174951 This pr is a combined work from @sbidoul who proposed an alternative to pkg_ressource using packaging, removing dependency on pkg_ressource (witch is excellent)…
This is a followup pr to #174951 This pr is a combined work from @sbidoul who proposed an alternative to pkg_ressource using packaging, removing dependency on pkg_ressource (witch is excellent) Unfortunately, we don't want to add a requirement on packaging since it is not needed to run odoo by default. It should be only useful when defining a "complex" external dependency (with version or markers) This pr proposes to replace` packaging.Requirement` by a simple replacement, that would work for basic external_dependencies. (no version or marker) Note that another change was made to the original proposal to continue to support module name dependency (ex: PIL instead of Pillow, the distribution package name) but will log a warning in this case instead of the previous info. Still to discuss if we need to keep it. Note that a first version (see 4e9e5924f7254b470397b61573b7c634c654d61c) was trying to combine both logic in `check_python_external_dependency` but some code needed to be duplicated and a version proposing a similar api to Requirements allows a smaller change to the original pr.
Resolved issues and error corrections
This change fixes an installation failure in the self-order point of sale module when a company already has a chart of accounts and demo data is not installed. It prevents the setup from depending on sample restaurant data, making the module install reliably for real business databases.
Original PR description
If the company has a CoA, it's currently not possible to install the module without the demo data. When loading the data of the module, it will lead to https://github.com/odoo/odoo/blob/3ad46fc7bbb7511efeb9e4861d9795844feec878/addons/pos_self_order/data/kiosk_demo_data.xml#L3-L5 https://github.com/odoo/odoo/blob/9511bacc89cc23ce162f93af4682a4806c45dfda/addons/pos_self_order/models/pos_config.py#L344-L352 Since the company has a CoA, we execute the `ref` but they target demo data, cf how they are loaded: https://github.com/odoo/odoo/blob/0bc90e7d74bd0792b9af7464256ba8770d894a25/addons/pos_restaurant/data/demo_data.xml#L4 https://github.com/odoo/odoo/blob/b9f9dbb7a1cd7d8812658c68daca89191c28eda7/addons/pos_restaurant/models/pos_config.py#L107-L111 https://github.com/odoo/odoo/blob/e2f08d58ff024228c3f472b35fd4aef7e60bdde4/addons/pos_restaurant/data/scenarios/restaurant_data.xml#L9-L12 Hence `ValueError: External ID not found in the system: pos_restaurant.food` OPW-4226855
Payment records now show as reconciled when they have been paid without a separate journal entry, which helps batch payments report the correct completion status. Payments that fail check printing no longer show a misleading sent indicator, and draft payments are prevented from being marked paid when they still need validation.
Original PR description
The matched state of the payment should be marked as reconciled when the payment is paid in the case there is no journal entry for the payment. Otherwise keep the states depending on the reconciliation.
The lunch dashboard layout now displays correctly on tablets and mobile phones. This makes it easier for users to browse and order lunch from smaller screens without visual or navigation issues.
Original PR description
This PR fixes layout issues in the lunch dashboard on tablet and mobile. task-4218941 | Before | After | |--------|--------| |  |  | |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix suppresses an unnecessary warning that appeared when loading push notification functionality on newer Ubuntu environments. It keeps system logs cleaner and avoids distracting messages without changing the user-facing behavior.
Original PR description
On google-auth import, setuptools will emit a warning in ubuntu noble when importing pkg_resources. This was not visible before the previous commits because another import of pkg_resources was made before enabling the warnings. The pkg_resources import is removed in google-auth >= 1.23.0 but the noble version is 1.5.1 (as it was in jammy)
Bank reconciliation and batch payment flows now work correctly when payments do not have journal entries. This prevents reconciliation errors and ensures batch payment amounts keep the right sign, while preserving existing stable-version behavior.
Original PR description
Since the entries are optional for payments [^1], the bank reconciliation widget was not working anymore because it was relying heavily on the fact that there are journal entries created. This commit introduces support for payments without entries by: * looking at payments instead of journal entries when relevant * not unfolding the batch payments anymore, cancelling/rejecting payments can be done through the batch payment form view * removing the payment rejection wizard, same reason [^1]: https://github.com/odoo/odoo/commit/01b87f1230beac0568f4e3b1b76e547909506892
Miscellaneous changes
**Current behavior:** With a non-standard-costing, stored product appears in a purchase order with a discount and requiring a currency exchange, the price unit may be calculated in an inaccurate fashion. **Expected behavior:** The price_unit should be accurate. **Steps to reproduce:** 1. Enable another currency, set an exchange rate on it that is very small (like < 0.01) 2. Enable automatic valuation, create a product with both average costing method and real time valuation on its ca
Original PR description
**Current behavior:** With a non-standard-costing, stored product appears in a purchase order with a discount and requiring a currency exchange, the price unit may be calculated in an inaccurate…
**Current behavior:** With a non-standard-costing, stored product appears in a purchase order with a discount and requiring a currency exchange, the price unit may be calculated in an inaccurate fashion. **Expected behavior:** The price_unit should be accurate. **Steps to reproduce:** 1. Enable another currency, set an exchange rate on it that is very small (like < 0.01) 2. Enable automatic valuation, create a product with both average costing method and real time valuation on its category, give it some initial cost e.g., 500 3. Create a new purchase order, add a line like: - product_id: from step 2 - quantity: 13 - discount: 1% 4. Set the currency on the purchase order to be the one from step 1, so it is different from the active company's 5. Confirm the purchase order and validate the receipt, look at the SVL generated and note its remaining value 6. Create a bill for the purchase order, post the invoice, then look at the SVL's remaining value again -> it changed **Cause of the issue:** The price unit being converted between currencies and rounded causes some discrepancy with the final value, also the calculation for gross price unit on AML model is somewhat primitive. **Fix:** Stop rounding base and update the formula used when calculating gross price unit. opw-4103167 Forward-Port-Of: odoo/odoo#181866 Forward-Port-Of: odoo/odoo#181527
Steps to reproduce: - Download payroll and Time off - Time Off > Configuration > Time off types - In Paid and unpaid type, set 'Take Time Off in' to Hours - Employees > Pick one > Time off - Click calendar day and create 2 leaves: -- Paid type, Custom hours from 8:00 to 9:00 -- Unpaid type, Custom hours from 9:00 o 10:00 - Time off > Management > Time off - Approve and validate both leaves - The employee needs to have a running contract so if needed -- Payroll > Contracts > Contra
Original PR description
Steps to reproduce: - Download payroll and Time off - Time Off > Configuration > Time off types - In Paid and unpaid type, set 'Take Time Off in' to Hours - Employees > Pick one > Time off - Click…
Steps to reproduce: - Download payroll and Time off - Time Off > Configuration > Time off types - In Paid and unpaid type, set 'Take Time Off in' to Hours - Employees > Pick one > Time off - Click calendar day and create 2 leaves: -- Paid type, Custom hours from 8:00 to 9:00 -- Unpaid type, Custom hours from 9:00 o 10:00 - Time off > Management > Time off - Approve and validate both leaves - The employee needs to have a running contract so if needed -- Payroll > Contracts > Contracts > New - Payroll > Regenerate work entries for your employee - Leaves are generated as a single block of type 'Generic time off' The leaves are merged. The Interval class sorts its entries' boundaries in such a way that it will see the start of an entry before the stop of the previous one if the start/stop time are the same. Its counterpart WorkIntervals does not merge overlapping entries. i.e with entries 8:00-9:00 and 9:00-10:00 Intervals will interpret as: 8:00 start, 9:00 start, 9:00 stop, 10:00 stop => Merged entries. And WorkIntervals as: 8:00 start, 9:00 stop, 9:00 start, 10:00 stop => No merged entries. This happens regardless of the content of the merged resources, in this case two different types of leaves which should not be treated the same by nature (Paid/Unpaid). When going though the leaves, we currently loop over the associated work intervals, this is part of the reason several leaves are processed as a single interval. The only reason we need the attendance interval is because some work entry types can take precedence over leaves (For instance a long term medical disability must supercede a public holiday). In the interest of avoiding a change in the return type of the method '_get_interval_leave_work_entry_type' we instead rebuild the intervals with the bounds of the leave and the work entry type of the attendance. opw-4193334 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182273
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 Forward-Port-Of: odoo/odoo#179676
Original PR description
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 Forward-Port-Of: odoo/odoo#179676
Before this commit, using the 'Search more' button to load products with variants from the server resulted in a duplicate key error. This issue arose from creating new product objects upon loading from the server, where using a Set did not prevent duplicates. This commit resolves the problem by employing a Map, keyed by product ID, to ensure uniqueness. opw-4211407 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182321
Original PR description
Before this commit, using the 'Search more' button to load products with variants from the server resulted in a duplicate key error. This issue arose from creating new product objects upon loading from the server, where using a Set did not prevent duplicates. This commit resolves the problem by employing a Map, keyed by product ID, to ensure uniqueness. opw-4211407 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182321
This issue occurs only in frontend debug (which I initially missed but odony caught), the problem is that the `InputConfirmationDialog` used for the creation dialog has a required `onInput` callback in its props but none is provided by the "new api key" button case. Props are (I assume) only validated in debug mode, so that's the only situation in which the error appears... and blocks users. While `onInput` seems like a useful hooks for input validation and stuff, it doesn't seem necessary to
Original PR description
This issue occurs only in frontend debug (which I initially missed but odony caught), the problem is that the `InputConfirmationDialog` used for the creation dialog has a required `onInput` callback in its props but none is provided by the "new api key" button case. Props are (I assume) only validated in debug mode, so that's the only situation in which the error appears... and blocks users. While `onInput` seems like a useful hooks for input validation and stuff, it doesn't seem necessary to mandate it, and the code specifically checks if it's unchecked (and ignores it in that case). OPW-4194305 Forward-Port-Of: odoo/odoo#182285
In #167973 (merged in 17.0+), we enabled the audit trail by default when loading the German localization. TSB requested that we indicate this explicitly in the manifest. task-none Forward-Port-Of: odoo/odoo#182295
Original PR description
In #167973 (merged in 17.0+), we enabled the audit trail by default when loading the German localization. TSB requested that we indicate this explicitly in the manifest. task-none Forward-Port-Of: odoo/odoo#182295
## Steps to reproduce: 1. Create a new batch picking (in the Inventory app) 2. Set an operation type and save 3. Open the batch picking in the barcode application ## Before this commit: Because the batch picking has an operation type, Odoo will try to load it from the cache, but since the batch picking is empty, the backend did not send any `stock.picking.type`. ## After this commit: Load the `stock.picking.type` in the frontend cache. opw-4175883 Forward-Port-Of: odoo/enterprise#
Original PR description
## Steps to reproduce: 1. Create a new batch picking (in the Inventory app) 2. Set an operation type and save 3. Open the batch picking in the barcode application ## Before this commit: Because the batch picking has an operation type, Odoo will try to load it from the cache, but since the batch picking is empty, the backend did not send any `stock.picking.type`. ## After this commit: Load the `stock.picking.type` in the frontend cache. opw-4175883 Forward-Port-Of: odoo/enterprise#70400
This fix resolves a problem where empty batch pickings could not be opened in the barcode application. The issue occurred because the system tried to load operation type information from cache but the backend didn't send the necessary data for empty batches. The fix ensures the operation type information is properly loaded in the frontend cache, allowing users to successfully open and work with empty batch pickings.
Original PR description
## Steps to reproduce: 1. Create a new batch picking (in the Inventory app) 2. Set an operation type and save 3. Open the batch picking in the barcode application ## Before this commit: Because the batch picking has an operation type, Odoo will try to load it from the cache, but since the batch picking is empty, the backend did not send any `stock.picking.type`. ## After this commit: Load the `stock.picking.type` in the frontend cache. opw-4175883 Forward-Port-Of: odoo/enterprise#70400