Tuesday, April 2, 2024
35 changes
1 change
Resolved issues and error corrections
This change removes a duplicate Inventory page path that could cause errors when users refreshed the page or shared a link. It also adds an extra check to prevent similar duplicate paths from being created in the future, improving navigation reliability.
Original PR description
Since [1], a duplicate path `inventory` was introduced, this leads to errors when reloading the page, or when a URL is shared. Normally, duplicated path should be impossible due to the unique SQL constraint, added in [2]. But, the tables ir_act_window, ir_act_report_xml, ir_act_url, ir_act_server and ir_act_client inherit from table ir_actions (see base_data.sql). And a big limitation of the postgresql inheritance feature is that unique indexes only apply to the single tables, and not across all the tables, for more information see [3]. This commit, removes the duplicated path, and add a python api constraint, to check the uniqueness of the path. [1] https://github.com/odoo/odoo/commit/814d2dc6ac5c06403ae5d2133d572a6b01edc1c0 [2] https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f [3] https://www.postgresql.org/docs/14/ddl-inherit.html#DDL-INHERIT-CAVEATS
3 changes
Enhancements to existing features
Users can now include the overdue amount in customer follow-up messages, rather than only the total amount due. This helps keep reminders accurate when specific invoices are excluded from a follow-up report.
Original PR description
Have a customer with multiple invoices in need of action (i.e. first remainder email) in followup reports Exclude an invoice. The amount in the message will not change upon refresh because it is the total amount due of the partner and there is no way to encode just the overdue opw-2419553
21 changes
New functionality added to Odoo
Odoo now supports Mauritius-specific accounting requirements with a new localization package. This includes a complete chart of accounts, tax configurations, fiscal positions, and customized invoice settings tailored for Mauritius businesses. Companies operating in Mauritius can now use Odoo with locally compliant accounting practices.
Original PR description
Adds Mauritius localization, includes:
- Chart of accounts
- Taxes
- Fiscal positions
- Default settings, including invoice customization.
task-3631730Discuss now includes breadcrumbs, making it easier for users to move back through previous pages or conversation areas. This improves day-to-day navigation and helps users stay oriented while working in messaging.
Original PR description
This commit adds breadcrumbs to Discuss page, so that users can easily browse backwards. Community PR: https://github.com/odoo/odoo/pull/153802 Task-3734245
Resolved issues and error corrections
This fixes the subscription renewal flow for the 'Send & try to charge' option. If an automatic payment attempt fails, the invoice is still created and sent manually so customers and staff do not lose track of the renewal charge.
Original PR description
Create a subscription model with 'Create invoice' option set to 'Send & try to charge'. Create a subscription product based on the model From Sale generate a sale order with such product, save and confirm. On renew, if the payment is not successfull the invoice will not be generated. Fixing by creating and sending the invoice manually in case the payment fails opw-2199358
Enhancements to existing features
The National Social Security Fund (NSSF) contribution rates for Kenya have been updated to 7,000 KES and 36,000 KES, effective February 1, 2024. This change ensures payroll calculations comply with the latest regulatory requirements from Kenya's social security authority.
Original PR description
The rates of the nssf have been updated to 7000Ksh and 36000Ksh to reflect the changes the changes that start to be active from 1st February 2024. The computation of the nssf doesn't change. task-3827016
This update improves the Point of Sale system to display clear, readable error messages when users encounter issues while creating or editing customer information. Previously, errors were not shown to users, making it difficult to understand what went wrong. Now, detailed error information from the backend is displayed, helping users quickly identify and resolve problems.
Original PR description
Currently, point of sale does not show a readable error for user in the edition of the partners, this change shows the error from the backend to give more information about the causes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the online store's product search functionality by adding customization hooks that allow developers to easily extend search capabilities to additional product fields beyond the standard name and product code. This makes it simpler for businesses to tailor product discovery to their specific needs without complex technical workarounds.
Original PR description
Description of the issue/feature this PR addresses: In case we want to search on other fields than name or default_code, or eventually on the descriptions, we need to reverse the domain that is built using AND and OR operators from osv.expression which is something we would prefer to avoid anytime. By adding hooks to add custom domains, it allows to search on whatever extra fields we would like to search on. Current behavior before PR: Impossible to search efficiently on specific fields Desired behavior after PR is merged: Easy to extend the domain to search efficiently on specific fields --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147865
This update makes the editor's formatting specifications inheritable, allowing developers to extend and customize the editor with new formatting options more easily. This improvement enhances the flexibility of the web editor for custom implementations and extensions.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: formatsSpecs object isn't heritable, which prevents developers from adding new options to the editor --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158703
This update enhances the user experience on websites with slower internet connections by adding visual feedback (loading effect) when buttons are clicked during the initial page load. Instead of buttons appearing unresponsive, users now see a loading indicator and their click is processed once the page fully loads. This particularly benefits users in regions with poor connectivity while maintaining fast page load times for users with good connections.
Original PR description
Odoo implements its own lazy-loading mechanism for the biggest JS bundles that are loaded on the frontend. This mechanism allows the page to appear to the user very fast, at the downside of having…
Odoo implements its own lazy-loading mechanism for the biggest JS bundles that are loaded on the frontend. This mechanism allows the page to appear to the user very fast, at the downside of having some interactive elements (such as buttons) have no effect during the lazy loading. In general, this is not a problem since: - Standard links and buttons work, only those with custom effects (a modal, a custom JS behavior, etc) have no effect. - The full loading should not take long anyway. - After the pages have been visited, everything should be in cache. However, in some cases (countries with poor internet connections), the experience can be confusing. Without lazy loading, they would have a page that appears as a blank white page for a few seconds. With our custom lazy loading, they get the website very fast... but some buttons appear buggy (no effect) for a few seconds. The long term plan is to review our lazy loading: - Should it be less delayed than it currently is? (at the time, this was the minimum delay that made Google give us good page scoring but it may not be as impacting as before) - Should some of the lazy-loaded JS should actually not be? - Should the assets be split differently? - Could we be able to remove some code that weighs too much? - ...? Meanwhile, this commit improves the behavior this way: during lazy loading, any click on a button is now ignored but a loading effect is displayed. Once the JS is fully loaded, the click is then re-played on the previously clicked button, hopefully triggering its effect. In any case, this cannot be worse than what we have before... except for: - **The reasonable risk we take merging this in stable (we considered merging in a more recent version but it is needed for some specific projects and many websites would benefit from this improvement).** - Any custom code that added behavior on buttons to be available during lazy loading... will just wait for lazy loading with a loading effect too now. This should be a good compromise as, again, that lazy loading is cached and should not take too long anyway. Note that this replaces the previous o_wait_lazy_js class behavior (it has now no effect). Overall: - This should not impact (neither improve nor worsen) most websites that are currently experienced from good internet connections. - This should be a big improvement for most websites that are currently experienced from bad internet connections. Related to task-3770362 Forward-Port-Of: odoo/odoo#159572 Forward-Port-Of: odoo/odoo#158661
Resolved issues and error corrections
This fix adds account 1611 (Crediti per ritenute subite) to the Italian Balance Sheet report. This account, which tracks withholding tax credits, was being created by the system but wasn't appearing on the Balance Sheet, causing incomplete financial reporting. The fix ensures all relevant accounts are now properly displayed in the Balance Sheet.
Original PR description
Account 1611 Crediti per ritenute subite (appoggio) which is created by the l10n_it_edi_withholding module was not referenced in the Balance Sheet. We fix this now. taskid: 3060790 Forward-Port-Of: odoo/enterprise#59148
This fix resolves an issue where views embedded in Knowledge articles fail to load with an access error. The problem occurred when importing views from other modules like Documents because the Knowledge module was overriding the search model needed to retrieve data. The solution restructures the Knowledge search model to work alongside other modules' search models, allowing embedded views to function correctly.
Original PR description
**Step to reproduce:** - Install `Knowledge` and `Documents` modules (for test purpose) - Go to Documents app - Click on Action button -> Knowledge -> Insert view in article - Select any article…
**Step to reproduce:**
- Install `Knowledge` and `Documents` modules (for test purpose)
- Go to Documents app
- Click on Action button -> Knowledge -> Insert view in article
- Select any article
**Issue:**
View is not loaded correctly in the article.
Error message: Something went wrong! The view does not exist or you
are not allowed to access to it.
**Cause:**
In the imported view, we try to retrieve the selected Folders, but this last one need the search model to retrieve the data.
https://github.com/odoo/enterprise/blob/11daa694d4ca51939c2b458bced8ab9d48030ef8/documents/static/src/views/documents_controller_mixin.xml#L5
The method called to retrieve the folders (`getSelectedFolder`) is set on the documents search model (`DocumentsSearchModel`), however, the search model set in the embedded_view is the knowledge search model (`KnowledgeSearchModel`).
**Solution:**
Change the `KnowledgeSearchModel` class into a mixin so it can extend the (potentially) custom search model defined for any embedded view during the mounting process (default to the generic search model), instead of overwriting it.
opw-3752927
Forward-Port-Of: odoo/enterprise#59758This fix ensures that when a job offer is generated with a specific job and department, those details are correctly transferred to the new employment contract. Previously, the contract was not using the job and department information from the offer, which could result in incorrect contract details. Now the system prioritizes the offer information over the contract template defaults.
Original PR description
Since when we generate an offer, we can provide a specific job and department, that will be set on the user and used in the pdf contract signed. We should also get this job and departement correctly set on the new contract which is not the case for now. So we first choose to use the info comming from the offer before the one from the contract template.
This fix resolves a bug where vendor bill totals (Untaxed Amount, Taxes, and Total) were incorrectly displayed as $0 when manually editing invoice line prices after adding a product. The issue occurred for users without the Units of Measure feature enabled. The fix reorders form fields to ensure proper calculation of invoice totals.
Original PR description
Steps to reproduce: - Install Invoicing - Create a product with $0 cost (e.g. Product X) - Create a vendor bill: * Vendor: [any] * Invoice Lines: - Product: [none] - Label: [anything] - Price: [any]…
Steps to reproduce:
- Install Invoicing
- Create a product with $0 cost (e.g. Product X)
- Create a vendor bill:
* Vendor: [any]
* Invoice Lines:
- Product: [none]
- Label: [anything]
- Price: [any]
- Taxes: [any]
=> The displayed "Untaxed Amount", "Taxes" and "Total" are correct
- Save the vendor bill
- Edit the invoice line of the bill
- Add Product X => "Untaxed Amount", "Taxes" and "Total" are correctly set to 0 as expected
- Change Price to 100 manually
Issue:
"Untaxed Amount", "Taxes" and "Total" stay at $0.
Upon save, "Untaxed Amount" is correctly set to $100, but "Taxes" stays at $0.
If "Units of Measure" option is activated in the Settings (available with Sales, Purchase or Inventory app), the user will be in "uom.group_uom" and the issue will not happen.
Cause:
When the user isn't in "uom.group_uom" group, "product_uom_id" field is declared after "price_unit" field in the view.
Due to that, adding a product in the invoice line and changing the price to $100, will first set "price_unit" to $100 and then set "product_uom_id" that will trigger "_compute_price_unit" method where "price_unit" is recomputed to $0 (its cost).
Solution:
Move "product_uom_id" field before "price_unit" field in the view as it is the case when the user is in "uom.group_uom" group.
opw-3750740
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents the Google Calendar sync from accidentally removing video call locations that were set in Odoo meetings. Previously, when syncing calendar events from Google, the system would clear any existing Odoo video call information. Now, local video call details are preserved and no longer overwritten during the synchronization process.
Original PR description
The `videocall_location` was accidentally unset when synch from Google, which is not expected ### Step to reproduce 1. From from calendar view of calendar.event, click to open the form view 2. click `Add Odoo meeting` to set discuss videocall location 3. save to create new calendar.event record 4. wait for synch to be done 5. recheck the field `videocall_location` to find its value False ### After this PR The discuss videocall location is no longer overriden with False --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157939
This fix resolves an error that occurred when users tried to create a location record by clicking on a date in the Calendar view while using the homeworking feature. The issue was caused by incorrect use of the calendar API, which has been corrected to use the proper record creation method. Users can now successfully set locations in the calendar without encountering errors.
Original PR description
Versions -------- - 17.0 - saas-17.1 Steps ----- 1. Have `calendar` and `hr_homeworking` installed; 2. go to Calendar; 3. try to set a location by clicking on a date column. Issue ----- Odoo Client Error. Cause ----- The `onDayRender` function calls `onDateClick` to create a record, passing an `info` object lacking the `jsEvent` attribute. Solution -------- Use `this.props.createRecord` instead. opw-3815617
This fix corrects how invoices are downloaded from the customer portal. Previously, downloading an invoice could unintentionally trigger additional processes (like CFDI document generation in Mexico) and show a Print button even when documents weren't ready. Now, downloads only retrieve the invoice file without triggering extra workflows, and the Print button is removed from the portal view to prevent confusion.
Original PR description
Steps to reproduce: - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Product: [any…
Steps to reproduce: - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Product: [any product with UNSPSC Category set] - Confirm the invoice - Go to the portal preview of the invoice - Download the invoice from portal Issue: 1) On the invoice, the CFDI document has been generated and processed without notice. Downloading an invoice from portal should only download the invoice. 2) There are 2 buttons on the portal: "Download" and "Print". The "Print" allows to print the invoice, even if it has not been generated and sent yet. Cause: When downloading an invoice from portal, we are going through the "Send & Print" wizard (without displaying it) with only "Download" option checked. However, some localization (e.g. MX) may add specific options that are checked by default (e.g. CFDI), which triggers the corresponding flow. Solution: 1) Make sure that all options of "Send & Print" wizard are deactivated, except "Download". Download existing invoice documents or generate a Pro Forma document when downloading invoice from portal. 2) Remove "Print" button from portal view. opw-3821371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug that occurred when users sorted a list of records and then tried to delete an item. The system was not properly loading all required field information for records that needed to be moved between pages after deletion, causing the application to crash. Now the system ensures all necessary data is loaded before attempting to delete records.
Original PR description
In some cases, sorting a sub-view list and then deleting one of its rows can cause a traceback. This commit corrects this situation. Here's a way to reproduce the error: - Install `sale_management` -…
In some cases, sorting a sub-view list and then deleting one of its rows can cause a traceback.
This commit corrects this situation.
Here's a way to reproduce the error:
- Install `sale_management`
- Open a quotation
- Put enough elements to have two pages
- Modify the view via debug mode and change the list view limit from "200" to "2".
- Add 4 elements
- Sort with `product_uom_qty` field
- Attempt to delete the second element (i.e. the last element on the first page)
When deleting this line, a traceback is raised
Let's say we have 4 records with the following data
Page 1 (`1 - 2 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 1 | Table | 6 |
| 2 | Lamp | 1 |
Page 2 (`3 - 4 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 3 | Chair | 4 |
| 4 | Board | 3 |
In this case we have two cached elements: the two elements visible on
the first page.
In the cache we have two complete records, by complete we mean a record
containing all the fields, for example:
```js
{
"1": {
id: "datapoint_4",
...
data: {
sequence: 10,
name: "Table",
product_uom_qty: 6,
display_type: false
...
}
},
"2": {
id: "datapoint_11",
...
data: {
sequence: 10,
name: "Lamp",
product_uom_qty: 1,
display_type: false
...
}
}
}
```
After sorting by quantity, we end up with
Page 1 (`1 - 2 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 2 | Lamp | 1 |
| 4 | Board | 3 |
Page 2 (`3 - 4 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 3 | Chair | 4 |
| 1 | Table | 6 |
It also changes at cache level, since we sorted via the `product_uom_qty`
field, we had to go and read the records on the next page (despite the
fact that they weren't displayed).
But as we only need the quantity information, we only fetch this field
from the records on the following pages.
In terms of cache, we have something like this
```js
{
"1": {
id: "datapoint_45",
...
data: {
sequence: 10,
name: "Lamp",
product_uom_qty: 1,
display_type: false
...
}
},
"3": {
id: "datapoint_16",
...
data: {
sequence: 10,
name: "Board",
product_uom_qty: 3,
display_type: false
...
}
},
"4": {
id: "datapoint_32",
...
data: {
sequence: 10,
name: "Table",
product_uom_qty: 6,
display_type: false
...
}
},
"2": { //Chair
id: "datapoint_1",
...
data: {
sequence: 10,
product_uom_qty: 4,
}
}
}
```
We therefore have one new incomplete record in the cache
The problem will occur when we try to delete a record from the first page,
if we delete `Board`, to have this
Page 1 (`1 - 2 / 3`):
| ID | Product | Quantity |
|----|---------|----------|
| 2 | Lamp | 1 |
| 3 | Chair | 4 |
Page 2 (`3 - 3 / 3`):
| ID | Product | Quantity |
|----|---------|----------|
| 1 | Table | 6 |
So we'll have to move the table that was on page 2 to page 1 (in our
case `Table`), except that when we render the list we'll have to compute
the required/readonly/invisible elements, and if we have a field that
has a readonly with the condition `not display_type` in our view, this
will cause a traceback because in the cache we only have this
```js
"4": { //Chair
id: "datapoint_32",
...
data: {
sequence: 10,
product_uom_qty: 4,
}
},
```
`display_type` is definitely not in the data because we considered this
cached record to be complete.
This commit modifies the `StaticList._applyCommands` function to create
datapoints for all records that are not **entirely** loaded via `StaticList._getResIdsToLoad`.
https://github.com/odoo/odoo/blob/00898aef4dbeb469e0cec7eaea387de2755c6426/addons/web/static/src/model/relational_model/static_list.js#L898-L912
opw-3771077This fix ensures that when an order is refunded in the Point of Sale system, the refund payment method and rounding matches the original order exactly. Previously, refunds were being incorrectly rounded even when the original order used multiple payment methods with different rounding rules, causing discrepancies between the original order total and the refund amount.
Original PR description
Current behavior: When you refund an order that was paid with bank and so not rounded, the refund is rounded wich result in a difference between the original order and the refund. This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund. Steps to reproduce: - Setup a rounding method with a precision of 5.0 - Create a product with a price of 138.0 - Open the POS and add the product to the order - Pay the order with 2 payments, one bank of 55 and one cash that will be rounded to 80. - Validate the order - Go in the backend and refund the order - The refund will be rounded to 135.0 opw-3701574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159129 Forward-Port-Of: odoo/odoo#155619
This fix improves the Point of Sale experience by displaying error messages when data fails to load, instead of leaving the system stuck on a loading screen. Users will now see what went wrong and can take appropriate action, rather than being confused by an unresponsive interface.
Original PR description
Before this commit, if there was an error, the PoS stays on the loading page which was confusing for the user. owp-3834647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves a system error that occurred in the HR module when an employee had no contracts. The error happened because the system tried to compare a false value with a date, which isn't allowed. The fix adds a check to prevent this comparison from occurring when contract data is missing.
Original PR description
### Before This PR if there the new_hire_field is False(in case of hr_contract for example if there are not contracts), an error appear. ### After THIS PR This Commit will check that the field is not false so the error is not raised --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that when job applicants retake a survey multiple times, all survey responses are properly linked to the applicant's record. Previously, only the first survey response was connected to the applicant, making it impossible to view subsequent attempts. Now all survey retakes will be correctly associated with the applicant, allowing hiring teams to review the latest feedback.
Original PR description
Description of the issue/feature this PR addresses: module: hr_recruitment_survey Current behavior before PR: when retaking the survey, the survey input not map with the applicant id, so if you retake 5 time, only the 1st survey has value of applicant_id Desired behavior after PR is merged: all survey retakes have the same applicant id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where a horizontal scrollbar would unexpectedly appear when a background video and animated elements are used together on a webpage. The problem occurred due to timing issues when the video was loading. The fix ensures the video dimensions are properly recalculated after the video finishes loading, eliminating the scrollbar issue.
Original PR description
When a background video and an animation coming from the left or the right are on a page at the same time, there sometimes is a horizontal scrollbar that appears for no reason. It can happen at any…
When a background video and an animation coming from the left or the right are on a page at the same time, there sometimes is a horizontal scrollbar that appears for no reason. It can happen at any screen size but more frequently near 1000px and below. This issue seems to happen on Chrome only. It seems to be a race condition between the calls to the `_adjustIframe` function in the `backgroundVideo` public widget. Indeed, this function is called when the video is added in the DOM and each time the screen is resized. When an animation is played, it triggers a resize of the window when it is over, which therefore calls `_adjustIframe`. When the animation comes from the right/left of the screen, the animated element is translated from outside the page; the page width is therefore bigger but its overflow is prevented. When the video is loaded, the loading placeholder is removed. Depending on the time it takes to it to fully load, if the animation ends before it, the iframe is adjusted before the placeholder removal, leaving the iframe wrongly adjusted when it is finally removed. Note that it is hypothetical, as everything refreshes when inspecting the DOM, making the scrollbar disappear. But this proves that no element is really overflowing, so it seems to be a value refreshing issue. This commit adds a call to `_adjustIframe` when the video has loaded, to make sure its dimensions are recomputed/refreshed, preventing the scrollbar to appear. Steps to reproduce: - Drop a "Text-Image" snippet. - Set a background video to it. - Add the "Fade In-Right" animation to the image column. - Save and then resize down the screen to 1000px or below. - Refresh. => When the video is loaded, a horizontal scrollbar may appear. If not, refresh until it does. opw-3487117 Forward-Port-Of: odoo/odoo#159193
This fix resolves a system error that occurred when users tried to change the end date while creating a work entry for a newly hired employee who doesn't yet have a contract assigned. The system now handles this scenario gracefully by providing a default value instead of crashing.
Original PR description
This traceback arises when the user changes the date with a new employee of no contract while creating a new Work Entry. To reproduce this issue: 1) Install `hr_work_entry_contract` 2) Open `payroll`…
This traceback arises when the user changes the date with a new employee of no contract
while creating a new Work Entry.
To reproduce this issue:
1) Install `hr_work_entry_contract`
2) Open `payroll` and create a new `Work Entry`
3) Select `Work Entry Type` as `Unpaid` and create a new employee
4) Now try to change the `end date`
Error:-
```
KeyError: False
File "odoo/http.py", line 2252, in __call__
response = request._serve_db()
File "odoo/http.py", line 1828, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1848, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1826, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1833, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2058, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1074, in onchange
todo = [
File "addons/web/models/models.py", line 1077, in <listcomp>
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1190, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6669, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 1138, in __get__
self.recompute(record)
File "odoo/fields.py", line 1353, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1326, in apply_except_missing
func(records)
File "odoo/fields.py", line 1375, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4982, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 102, in determine
return needle(*args)
File "addons/hr_work_entry/models/hr_work_entry.py", line 84, in _compute_duration
durations = self._get_duration_batch()
File "home/odoo/src/enterprise/saas-17.1/hr_work_entry_contract_planning/models/hr_work_entry.py", line 46, in _get_duration_batch
res.update(super(HrWorkEntry, super_we)._get_duration_batch())
File "addons/hr_work_entry_contract/models/hr_work_entry.py", line 119, in _get_duration_batch
result[work_entry.id] = mapped_contract_data[(date_start, date_stop)][calendar][employee.id]['hours']
```
On the `_get_duration_batch` method, when the user creates a new employee without a contract,
the calendar remains an empty recordset.
which leads to the traceback from the below lines.
https://github.com/odoo/odoo/blob/a277faa2ffab7559fcbad95fcc1e8fd6a26d756b/addons/hr_work_entry_contract/models/hr_work_entry.py#L110-L112
After applying this commit will resolve the issue by making the code more robust
and gives the default value for `work_entry.id`.
sentry-5095168051
Forward-Port-Of: odoo/odoo#159276The Point of Sale numpad was occasionally triggering events when it shouldn't, causing unexpected behavior. This fix adds a validation check to ensure the numpad only processes events when it's properly initialized and ready to receive input. This improves the reliability and user experience of the checkout process.
Original PR description
The numpad in the PoS was sometimes handling events when it was not supposed to, leading to unexpected behavior. This was due to the fact we did not check if there was a buffer holder for the numpad before triggering the event handler. The check is now done by adding a check in the _onKeyboardInput method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159619