Tuesday, November 5, 2024
20 changes · 17.0
New functionality added to Odoo
This update introduces a new report for Slovenian localization, specifically the 'EC Sales List'. The previous version had a bug that caused crashes due to outdated tax filter selections. This fix ensures the report functions correctly and accurately displays EC sales data for Slovenian users.
Original PR description
This commit will add the ec sales list report for Slovenian localisation Community PR: odoo/odoo#166559 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247
Resolved issues and error corrections
The Attendance kiosk screens now display correctly on smaller devices, including the welcome and PIN entry screens. This helps employees use check-in kiosks more reliably on compact monitors or tablets.
Original PR description
This commits fixes the display of the kiosk mode for smaller resolutions (welcome screen, PIN code screen). opw-4264565
Code cleanup and technical improvements
This change updates repository configuration for bundled third-party add-ons and adds a script to check repository status. It appears to be an internal maintenance change that helps developers manage the Odoo environment rather than changing day-to-day business workflows.
Original PR description
Miscellaneous changes
Steps to reproduce: - Install Project and sale_timesheet - Create a project with Timesheet option enabled - Go to that project's setting and allocate hours - Gear Icon > Duplicate The duplicated project has 0 allocated hours, this is odd since sale_timesheet forces that field to copy=False despite every other module allowing it (Even Timesheet). Additionally, copied tasks still have their allocated hours no matter what so it is strange to remove them from the project itself. opw-428495
Original PR description
Steps to reproduce: - Install Project and sale_timesheet - Create a project with Timesheet option enabled - Go to that project's setting and allocate hours - Gear Icon > Duplicate The duplicated project has 0 allocated hours, this is odd since sale_timesheet forces that field to copy=False despite every other module allowing it (Even Timesheet). Additionally, copied tasks still have their allocated hours no matter what so it is strange to remove them from the project itself. opw-4284950 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185890
This fix prevents a user's online status from briefly showing as offline when one of multiple open browser sessions disconnects or reloads. It makes the Discuss experience smoother and avoids confusing status flickers for users working across multiple windows or devices.
Original PR description
When a user disconnects from a device, the server assumes he is disconnected until another device/browser says otherwise. However, this can lead to small flickers. This PR fixes the issue by debouncing the update of the im status field of the persona model. This way, there is no flickering. Steps to reproduce the issue: - Open two browser windows with mitchell admin in the discuss app (incognito + regular windows). - Go to the chat with your self, where the im status can be seen. - Reload one tab several times: you can sometimes see a flicker from online to offline. task-4236550
This fix makes the maintenance calendar test wait until the monthly calendar view is fully ready before trying to move an event. It prevents false test failures caused by timing issues, helping keep quality checks stable without changing user-facing behavior.
Original PR description
During `test_drag_and_drop_event_in_calendar`, an error occurs due to the target not being found in drag and drop steps. When the test is performed on the same week as the event, there is a likely chance for the drag and drop steps to be triggered before the rendering of the Monthly Calendar view. When we are changing from weekly to monthly view, we will wait for the latter to be rendered before calling the next steps. runbot-error-105708 runbot-error-105709
Users can now clear email or SMS delivery failure alerts even after the related record has been deleted. This prevents stale failure notifications from remaining in the messaging menu and reduces confusion for users managing communications.
Original PR description
When a failure occurs when sending an email or a sms, it is displayed in the messaging menu. Before this PR, it could not be removed after a record was deleted. Steps to reproduce: - Send a message on a record, add a recipient with an incorrect email. - A red enveloppe is displayed next to the message and a notification is added in the messaging menu. - Delete this record. - Try to mark this failure as read. - Nothing happens. This occurs because the message deletion is only notified to the recipients, not the author. This PR fixes the issue. opw-4272165
This fix prevents scheduled time off accrual calculations from accidentally discarding pending changes to existing allocations. It helps ensure employee leave balances remain accurate when future leave is considered during automated processing.
Original PR description
Before this commit, when the accrual cron was running and there was a leave in the future to account for, it would calculate the number of days by processing a fake allocation and invalidating it afterwards. However, the cache invalidation was too aggressive and would also invalidate any changes that were made to existing accrual allocations that were not yet flushed. This commit fixes this behavior by invalidating the recordset so as to only invalidate the fake allocations. opw-4200067
This fixes an issue where export options such as XLSX could become hidden behind the report header and fail to open. Users can now reliably use report action buttons from accounting reports, including Trial Balance comparisons.
Original PR description
Steps to reproduce: - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Select "Last Month" as data filter - Select "Previous Month: 9" as comparison filter - Click on dropdown button next to PDF button - Click on a button that is displayed in front of the header of the report (e.g. XLSX) Issue: The action is not triggered. Once the button has been clicked, the dropdown menu disappears behind the header of the report. opw-4265087
This fix adjusts the test setup for Indian GSTR point-of-sale reports so automated checks behave more reliably. It helps reduce false test failures during development and maintenance, with no expected change for end users.
Original PR description
…cter inheritance
This update fixes an issue where the 'Last Evaluation' button in the employee module incorrectly displayed the current date instead of the last appraisal date. Now, the button accurately shows the date of the most recent completed appraisal or indicates an ongoing appraisal if one exists, ensuring accurate appraisal tracking.
Original PR description
The issue: When accessing the record of any employee in the employee module, we have the smart button "Last evaluation", and that button is considering the current date instead of the evaluation date of the most recent evaluation. How to reproduce the issue: -In the app employee on any employee, clic on the Request Appraisal button. -Confirm the appraisal. -Go back on the employee page. Explanation: The behavior of this smartbutton was changed in 17.2 (https://github.com/odoo/enterprise/commit/ab01d6cbb4e2add8b6736f92c036a537bea57005). After this fix for version 17.0, the behavior will be as follows: -If there is an ongoing appraisal, the smartbutton display "Ongoing Appraisal" with the number of ongoing appraisals. -If there is no ongoing appraisal, the smart button will display the date of the most recent completed appraisal, which corresponds to the date when that last appraisal was completed. opw-4180982
This update corrects a small bug in the way the system compares financial amounts within the asset management module. The previous logic incorrectly used '1' as the threshold for comparison, leading to inaccurate calculations. This fix ensures that amount comparisons are accurate, improving the reliability of asset tracking.
Original PR description
To check that an amount is greater than another one, compare_amounts need to be bigger than 0 not 1 Forward-Port-Of: odoo/enterprise#73159
This update fixes a bug preventing filter options in the Partner Ledger report (Kontoudtog) from being translated into Danish. The fix ensures that all report labels, including filter selections, are correctly localized for international users. This improves the user experience for Danish-speaking customers.
Original PR description
The problem: In the accounting reports, filter options were not being translated. Steps to reproduce: Install and change to the Danish language. Navigate to Accounting > Reporting > Partner ledger (Kontoudtog) Activate the filter "Only Show Unreconciled Entries" (Vis kun ikke udlignede posteringer) Generate the PDF report. Why it was happening: The array `extra_options` was built dynamically by concatenating raw python strings to it. Those raw strings will not be translated. The fix: Now, we create local variables for each string, using the syntax `<t t-set="label_raw_string">Raw String</t>` which makes the string label_raw_string translatable, then we append it to `extra_options`. opw-4213562
This update resolves a technical issue that prevented users from correctly calculating payslips when adding new worked days to draft payslips. The fix ensures that the system properly recomputes payslip amounts when editing, preventing a traceback error. This ensures accurate payroll processing for all employees.
Original PR description
Steps --- * Create a payslip for an Employee with a contract (e.g. Anita Oliver) (*Payroll > Payslips > All Payslips > New*) * From the *Edit Payslip Lines* action, try to add a new worked day line (first list) with a non 0 amount * *Validate Edition* => Traceback Cause --- When saving new worked days lines, we try to recompute the amount of the *Basic Salary* payslip line, but if the payslip is still a **draft** it was never computed, and so the action we are calling does not exist. task-4191349 Forward-Port-Of: odoo/enterprise#71373
This update resolves an issue where the preparation display showed all orders, even after closing and reopening the session, leading to potential performance problems. Now, the display only shows currently active orders, improving the system's responsiveness and stability.
Original PR description
Before this commit, if a user didn't remove the prepared orders from the preparation display, all orders would be displayed even after closing and opening a new session. This could cause rendering issues due to the large number of orders. opw-4295258
This update fixes a potential issue where POS order tax information wasn't consistently matched, leading to inaccuracies in GST reports. By sorting tax IDs before comparison, the system now ensures accurate matching regardless of the original order, improving report reliability.
Original PR description
Before this PR: - POS order lines were matched without sorting `tax_ids`, which could cause mismatches when the tax IDs were in a different order between `details_pos_line` and `account_move_line`. After this PR: - POS order lines are matched by comparing `tax_ids` in sorted order, ensuring consistent matching regardless of the order of tax IDs.
This update fixes an error in the Pakistani Profit and Loss report that incorrectly displayed 'Other Income' as a negative value. The fix ensures that 'Other Income' is correctly added to the 'Gross Profit' section, accurately reflecting the company's financial performance. This resolves a discrepancy between the PK-specific report and the standard Profit & Loss report.
Original PR description
**Steps to reproduce:** - Install l10n_pk_reports - Switch to a Pakistani company (e.g. PK Company) - Create a Journal entry crediting an account of "Other Income" type (e.g. 3112003 Misc Income) - Post the journal entry - Go to "Accounting / Reporting / Statement Reports / Profit and Loss" - Select "Profit and Loss (PK)" report **Issue:** The created journal entry is negative in the "Other Income" section and its value is subtracted from "Gross Profit" section, reducing "Profit of the Year" section, which is not correct. On the other hand, if the normal "Profit and Loss" report is selected, the created journal entry is positive and its value is added to "Gross Profit" section, increasing "Net Profit" section, which is correct. opw-4185212 Forward-Port-Of: odoo/enterprise#72378
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
Since #138471, each time `create_or_update_sequences_and_picking_types` is called, the related sequences will be updated to their default values. This means that if a user changed the sequence_code of a standard picking type, whenever that method is called (which can happen at the update of a warehouse), it will erase their settings. Rather than that, if the picking type already exist, we use its sequence_code instead of the default one. Related to: opw-4245938 opw-4264520 --- I conf
Original PR description
Since #138471, each time `create_or_update_sequences_and_picking_types` is called, the related sequences will be updated to their default values. This means that if a user changed the sequence_code of a standard picking type, whenever that method is called (which can happen at the update of a warehouse), it will erase their settings. Rather than that, if the picking type already exist, we use its sequence_code instead of the default one. Related to: opw-4245938 opw-4264520 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185966
The test was failing in winter because of the offset is -005 and not -004. The test is mainly there to check that a non migrated tz will behave as the replacement tz. Making the expected offset dynamic solve the issue. Runbot error: 105674 Forward-Port-Of: odoo/odoo#186108
Original PR description
The test was failing in winter because of the offset is -005 and not -004. The test is mainly there to check that a non migrated tz will behave as the replacement tz. Making the expected offset dynamic solve the issue. Runbot error: 105674 Forward-Port-Of: odoo/odoo#186108
* line._origin can be empty recordset so when line._origin.name it will return False then we compare it to result of inner function get_name which will be wrong because '\n'.join(values) will return empty string '' because line is empty so values is empty also . This commit correctly set the correct return value for inner function which introduce in [1]. This will allow custom module can recompute the label by different api.depends [1]: https://github.com/odoo/odoo/pull/182136/commits/2dee06
Original PR description
* line._origin can be empty recordset so when line._origin.name it will return False then we compare it to result of inner function get_name which will be wrong because '\n'.join(values) will return empty string '' because line is empty so values is empty also . This commit correctly set the correct return value for inner function which introduce in [1]. This will allow custom module can recompute the label by different api.depends [1]: https://github.com/odoo/odoo/pull/182136/commits/2dee061cb022e15c60539b987a87f8225cdc4881 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#183891