Friday, November 17, 2023
16 changes · 17.0
Resolved issues and error corrections
This change prevents deleted personal stages in the Todo app from reappearing in the Kanban view after another stage is removed. It keeps the screen consistent with the database, avoiding confusing “ghost” columns and errors until the page is refreshed.
Original PR description
This commit's purpose is to fix the re apparition of personnal stage on the todo app when personnal stages are deleted one after the other. Step to reproduce: -login as Marc demo -open todo -delete…
This commit's purpose is to fix the re apparition of personnal stage on the todo app when personnal stages are deleted one after the other. Step to reproduce: -login as Marc demo -open todo -delete any personnal stage without any todo in it -delete any personnal stage with at least one todo in it The personnal stage deleted first is now present again in the kanban view. Note that it is only a frontend bug. The record has been correctly removed from the db, and any action with it will trigger a cache miss exception and reloading the view completly will removed those ghost stages definitly. Source of the problem: The problem is that the deletion is only reloading the view completly when a record with child data is removed. More precisly, the _deleteGroup function of the dynamic list triggers an rpc call to update the config of the component only when a record with child data is deleted, and that data need to be switched to another record, while when it is an empty record, the record is simply removed from the group field of the list. The issue is that there is thus a mismatch between the group in the list.config.groups and the list.group. And when the config is updated, only the list.config.groups is used to update the config, meaning it potentially still contains element that were already deleted. Solution: Doing a check up on the list.group to ensure that any deleted element is also removed from the config when an update is triggered. Note: I dont why Mitchel admin did not trigger the bug. Code wise, it should happends no matter the access right of the connectedd user. Version affected: master task - 3553101 https://www.odoo.com/web#id=3553101&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form 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
Switching away from a company while viewing a record that is only available in that company now redirects users to a usable list view instead of showing an access error and blank screen. This keeps the app usable and reduces confusion for users working across multiple companies.
Original PR description
…Error while switching companies 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
This fixes how the system builds file paths when loading base module resources. It helps prevent incorrect path resolution in edge cases, improving reliability without changing user-facing workflows.
Original PR description
`os.path.join(..., <absolute>)` returns `<absolute>` path
The media selection window has been simplified to make loading and browsing images or files clearer. Users still get a scroll shortcut, while the load more option stays in the normal content flow, reducing confusion and improving maintainability.
Original PR description
In commit [1], the media dialog has been improved in order to have a better UX when using it. However, its code is quite complex and could be simplified. This commit modifies again the UX of the media dialog to only consider the addition of the "scroll button" and leaves the "Load more" button after the attachments without making it fixed. The scroll button still disappears once the load more button appears in the modal. This commit also addresses the remaining review comments that were not resolved, as it was merged in a rush. [1]: https://github.com/odoo/odoo/commit/d1c7e371491b06176c2f5a432dccdc87b7002296 task-3580707
Fixed a bug in the account reconciliation system where payment labels were not being matched correctly. The system was comparing sanitized payment information instead of the original values, which could cause valid payments to fail matching. This fix ensures that single-word payment labels are now matched against the complete original payment information, improving the accuracy of automatic payment reconciliation.
Original PR description
When the payment label is a single word, we try to match the full value and not only the alphanumeric values. However, the matching was made on the token that was already sanitized using the [0-9a-zA-Z\s] regex. Instead, let's match the full value. X-original-commit: bccc0ae0e896d58b54debae9483b8744d2b59ddc Forward-Port-Of: odoo/enterprise#49842
This update corrects how unaffected earnings are calculated in Luxembourg Balance Sheet reports. The fix ensures that profit or loss figures are now properly linked to the Profit and Loss report, with current year earnings showing the latest profit/loss and prior year earnings correctly adjusted for any distributions. This improves the accuracy of financial reporting for Luxembourg entities.
Original PR description
This commit rewrites the Balance Sheet lines 'V. Profit or loss brought forward' and 'VI. Profit or loss for the financial year' using a cross-report formula from the Profit and Loss report. The formulae are written such that: - the line 'VI. Profit and loss for the financial year' is the line '18. Profit and Loss for the financial year' from the Profit and Loss report, for the current financial year. - the line 'V. Profit or loss brought forward' is the line 18 from the Profit and Loss report, for past financial years, minus any amounts taken out of the 14 accounts. Task: 3060790 Forward-Port-Of: odoo/enterprise#42353
This update corrects how tax amounts are calculated for partial payments in Mexican invoices. Previously, the system calculated taxes line-by-line and then reduced them by the payment percentage, which could cause rounding errors and validation failures. The fix now sums all line amounts first, then applies the payment percentage, ensuring tax calculations meet Mexican tax authority requirements.
Original PR description
To pass validation by the PAC, the tax amounts reported for each invoice line need to fulfil the following conditions: - The total tax amount must be equal to the sum of the tax amounts reported for…
To pass validation by the PAC, the tax amounts reported for each invoice line need to fulfil the following conditions: - The total tax amount must be equal to the sum of the tax amounts reported for each invoice line. - The tax amount reported for each line must be equal to (tax rate * base amount), rounded either up or down. The system currently compute tax base and import from the move line, and then, in case of partial payment, these amounts are scaled down using the percentage of amount already paid (computed as payment amount over total amount). This process have 2 issues: 1) The tax amount computed this way may not be the same as computing it from the base amount *after* taking into account the percentage paid 2) The base value reduced by the payment percentage is saved and then summed up (for each line) to get the payment amount. Due to rounding imprecision adding up, the result may be off a few cents difference that will make the payment validation fail. It is best to sum the line values and then apply the payment percentage. opw-3537164 Forward-Port-Of: odoo/enterprise#50118
This update fixes automated tests in the accounting and bank statement modules that were failing because they relied on demo data. The tests have been updated to work independently, ensuring the system can be tested properly even when demo data is not installed. This improves the reliability of the testing process.
Original PR description
We want the tests to be able to run even without demo data. These use a res_partner/res_partner_bank defined in demo data. The account_asset test was forgotten during the fw-port of https://github.com/odoo/enterprise/commit/d8e5b62dfadffb6b81e61fce73053fa806fc2c6c Runbot error: 26966, 26308, 26986 Forward-Port-Of: odoo/enterprise#50512 Forward-Port-Of: odoo/enterprise#49851
Fixed a bug in the timesheet timer feature where starting and stopping a timer on a task with a future date would incorrectly add time to the existing entry instead of creating a new entry for today. The fix ensures that new timer entries are properly created regardless of whether the task date is in the past or future, maintaining consistent behavior across all scenarios.
Original PR description
**Steps:** - Install Timesheets - In Kanban View > create a new project and task with a future date - Start the timer and stop - A new entry with today's date won't be made. **Issue:** - If we have a kanban card with an older date and we start and stop the timer, a new kanban entry will be made with today's date. But if the kanban card has a future date, it will not create a new entry rather it will add the time in the same one. **Cause:** - Due to the condition given in the action_timer_start function, it will make a new entry only when the date is older. **Fix:** - Giving the proper condition in action_timer_start so that a new entry is created even when we have a future date. **Task**: 3429428 Forward-Port-Of: odoo/enterprise#50628 Forward-Port-Of: odoo/enterprise#44682
This update improves how the system handles situations when incoming customer emails with XML attachments cannot be matched to existing invoices in the database. Instead of treating these cases as critical errors, the system now logs them as warnings, reducing unnecessary alert noise while still tracking the issue for investigation.
Original PR description
While retrieving emails from incoming customers, this issue will only be triggered when the emails contain attachments of the .xml file type. Subsequently, a data matching process is carried out between the email content and the searched database. If no matching data or IDs are found, an error is thrown. Traceback: ``` Move not found with partner: 672, name: FAC 016714, l10n_latam_document_type: 1, company_id: 1 ``` This commit will change logger error to logger warning. sentry- 4305483242 Forward-Port-Of: odoo/enterprise#44248
This fix corrects how hours and dates are calculated when saving a planning schedule as a template. Previously, the template would show an incorrect number of days because regular working hours were being miscounted. Now templates will accurately reflect the actual duration and hours of the original planning schedule.
Original PR description
In planning dashboard create a new planning Set any start date and an end date after 2 days Check "Save as Template" Save Check the creted template (Configuration>Shift Templates) Issues: Template name will have a greater days count because normal hours are counted as working hours opw-3475656 Forward-Port-Of: odoo/enterprise#50782 Forward-Port-Of: odoo/enterprise#46538
The POS Preparation Display module was showing incorrect product attributes to kitchen staff. This fix corrects the data source used to display product details, ensuring that the right attribute information (like size, color, or customizations) appears on preparation screens. This improves order accuracy and reduces confusion in the kitchen.
Original PR description
Before this commit, the 'pos_preparation_display' module mistakenly used 'product.template.attribute.value' instead of the correct 'product.template.attribute.value' for displaying product attributes. This resulted in incorrect attribute values being shown in the preparation display. This commit corrects the reference to ensure that the accurate attribute values are displayed. opw-3599554
The appointment calendar event names have been reorganized to show the attendee's name first, followed by the service type. This ensures that important information remains visible on smaller displays like POS terminals, instead of being cut off. For example, "Marc Demo - Tennis Court Booking" now displays clearly instead of truncating to "Tennis Court wi...".
Original PR description
Currently, when booking an appointment, let's say for a tennis court, the calendar.event name will be setup as follows: "Tennis Court with Marc Demo". Which is not very practical for smaller display, as we will have only the first part of the name remaining: "Tennis Court wi...". The goal of this commit is to modify it to the following format: "Marc Demo - Tennis Court Booking". That way we keep the most important information first, which is the name of the attendee. This is especially important for the POS Restaurant display. Task-3599241
The appointment module's email parser has been improved to better handle complex email inputs with multiple email addresses. This fix updates the corresponding tests to reflect the enhanced email detection capability, ensuring the system can now correctly process unusual multi-email formats that previously may have been missed.
Original PR description
We now find more emails when input is a strange multi-emails like input. See community PR for more details. Task-3572208
This update corrects a test case in the barcode scanning module to properly handle procurement groups. The test was creating multiple inventory moves with conflicting procurement group settings in the same picking operation, which is not a valid business scenario. This fix ensures the test accurately reflects how the system should work.
Original PR description
Following https://github.com/odoo/odoo/pull/138623, creating 2 moves with different procurement group in the same picking makes no sens opw-3470090 Forward-Port-Of: odoo/enterprise#50821
Fixed a bug that caused an error when users tried to interact with sign items in templates that are locked for editing (templates with existing sign requests). The system was attempting to enable drag and resize functionality even when the template was read-only, causing the application to crash. This fix prevents these interactions from being registered on non-editable templates.
Original PR description
Issue: ====== When you have a sign template which has a sign request it shouldn't be editable, but accessing it and trying to drag some of sign items will raise an error because of `helperLines` is undefined. Steps to reproduce the issue: ============================= - Install sign - Go to sign and click on a templte which already have a sign request (in demo data : default it's real_estate_listing_agreement) - Try to drag or resize some sign elements. Origin of the issue: ==================== The reason behind the error is that helperLines is only defined in `renderSignItems` which requires `this.allowEdit` to be true which is not the case , but enableCustom will register the resize and drag events in the sign item even if it's not editable. opw-3579341 Forward-Port-Of: odoo/enterprise#50633