Wednesday, October 2, 2024
18 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
6 changes
Enhancements to existing features
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
10 changes
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.
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
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
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)
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