Monday, September 2, 2024
7 changes
1 change
Resolved issues and error corrections
This fix prevents Odoo's web utilities from mistakenly combining details attached to functions when merging data. It makes internal data handling more predictable and reduces the risk of subtle interface issues in the web client.
Original PR description
Before this commit: Functions where treated as object by the deepMerge utils, causing it to merge function properties. After this commit: Functions are now treated as values (This commit is a backport of [03f7b5f](https://github.com/odoo/odoo/commit/03f7b5f4f79b31c373b0f5a57a7bcced1e5a26b0) from 17.4 to 17.2) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
4 changes
Resolved issues and error corrections
Planning schedules now better reflect employee contract status when showing available and unavailable working periods. This helps planners see more accurate availability around draft, active, expired, or cancelled contracts, reducing scheduling mistakes.
Original PR description
In this commit we have made some changes regarding how contracts affect the planning schedule and added some test cases in HOOT. task:3815229
2 changes
Resolved issues and error corrections
This fix resolves a timing issue that occurred when users left a spreadsheet, where thumbnail saving and data snapshots were happening simultaneously and causing unpredictable errors. The fix ensures these operations happen in the correct sequence, making spreadsheet sessions more stable and reliable.
Original PR description
Steps to reproduce (in odoo) - Open a spreadsheet - do something such that there's a least one revisions - leave the spreadsheet => non-deterministic concurrent update because we save the thumbnail and we snapshot at the same time. I'm able to reproduce more when my laptop power setting is on "performance" compared to "balanced" Task: 4080148
The Partner Ledger partner filter now excludes contact-only partner records, so users see only relevant accounting partners. This reduces confusion when selecting partners for accounting reports and helps avoid misleading report filters.
Original PR description
Steps to reproduce: - Go to Partner Ledger report - Open partner filtering dropdown list Current behaviour: - Show all partners include contact partners Expected behaviour: - Should not show contact partners Explanation: Based on the discussion on discord, https://discord.com/channels/678381219515465750/1099994955830796348/1268492839575093291 We should not display contact partners filtering for accounting report.
Payroll batches now return to the confirmed state when payslips are regenerated for the same employees after being set back to draft. Users with batch accounting enabled also get easier access to the related journal entry, reducing confusion and extra navigation.
Original PR description
-steps to reproduce: create a batch, generate the payslips, set the batch back to draft, regenerate the payslips (with the same employees). -what is the bug: the state of the batch is not set to 'confirmed' after the second generation of payslips. -expected behaviour: the batch should be in confirmed state. -fix: if regenerating with the same employees, nothing is actually done, it should at least set the batch in confirmed state. Also add a button to get to the journal entry if the setting 'Batch Account Move Lines' is enabled. Task: 3975654
This fix makes the Philippine tax reporting logic return accounting entries in a consistent order. It prevents occasional test failures caused by unpredictable ordering, helping keep the module stable without changing user-facing behavior.
Original PR description
Since the moves query didn't specify the ordering, sometimes unit test will failed since the order of the moves are different. x-origin-commit: f25f362
This fix resolves a critical issue in the French FEC file import process where importing files containing multiple partners with identical names but different reference codes would cause the import to fail. Previously, the system would skip creating duplicate-named partners and then fail when trying to link accounting entries to the missing partner records. Now the import correctly creates all partners regardless of name duplication, ensuring all accounting data is properly linked.
Original PR description
Steps to reproduce: - Have a FEC file (see ticket) - Import it on a brand new db Issue: Crash. We try to create account move line with an xml id that does not exist because we didn't create the partner associated to the correct ref The second issue is that we will link the move to the wrong customer since the second one is not created Cause: The first issue is caused because we bypass the creation of the second partner with the same name "PARTNER 01" but different ref "PARTNER02" `ValueError: External ID not found in the system: l10n_fr_fec_import.89_partner_PARTNER02` The reason is, when creating the move line, we assign the `partner_id` with an xml_id based on the partner_ref https://github.com/odoo/enterprise/blob/ae3820059f6ff46b0dbcd64eabb2aae5caa98e18/l10n_fr_fec_import/wizard/import_wizard.py#L474-L490 Which of course does not exist. opw-3932234