Friday, November 17, 2023
11 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
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
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 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
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