Friday, August 30, 2024
6 changes
1 change
Resolved issues and error corrections
This fixes an error that occurred when users selected and duplicated several calendar events at once from the list view. The change restores the expected duplication workflow, helping teams manage repeated meetings or events without interruption.
Original PR description
Versions: ------------- saas-17.2 Steps to Reproduce: ---------------------------- 1. Go to the Calendar app. 2. Switch to list view. 3. Select multiple events. 4. Attempt to duplicate the selected events. Issue: -------- An error occurs when trying to duplicate multiple events. Cause: ---------- After a recent update, the `copy` method now processes records in batches, calling the `create` method with multiple records at once. Previously, this was done one by one. This change causes issues because the `default_get` method, used during creation, now encounters multiple records in `self`, leading to a singleton error. Solution: ------------ Instead of using `self.default_get()` with multiple records, we now use `self.env['calendar.event'].default_get()`. This ensures that the default values are set correctly without causing the singleton error. Task-4098739
2 changes
Resolved issues and error corrections
This change restores Brazilian tax records that had been removed in a previous update. The rollback prevents unexpected issues for Brazilian localization users while the team reassesses the correct approach for Brazil-specific tax handling.
Original PR description
[FIX] l10n_br_avatax: reset the tax record for brazil This is a revert for the changes that has been done in this commit https://github.com/odoo/enterprise/pull/68310/commits/5a2cfe938f6e13a9cd7394e3ce7685b25a31e7f8 Reason: It cause un-expected effect to brazil as they stay need all the removed taxes. So, We decided to roll the change back and investigate in the brazil case again to define what we need to do. task-id#4127128 odoo-pr: https://github.com/odoo/odoo/pull/177727
3 changes
Resolved issues and error corrections
This fix corrects the bank reconciliation report to properly count both reconciled and unreconciled transactions that are not from a bank statement. Previously, the report was excluding reconciled entries, which caused incorrect account balances. The fix also addresses an issue with reconciliation rate calculations when there are no reconciled entries.
Original PR description
Before this commit, the section transaction without statement didn't count the reconciled entries, and so the balance of the account was wrong. To fix that we putted a new custom engine function that will trigger the _bank_reconciliation_report_custom_engine_common with False for the "from_statement" and False for the "unreconciled" variables. With that the query will get all the transaction reconciled or not that are not from a statement. There was also a problem if the reconcile rate was 0, which didn't when having only unreconciled entries but now that we can have that, it needed to be modified. task: 4110491
Updating a partner bank account from the Employees bank account view now applies it to the related employees for that partner. The selection list is also limited to partners linked to employees in the selected companies, reducing mistakes and keeping payroll banking details consistent.
Original PR description
With this commit, when a user will a partner bank account from the view (Employees > Employees > Bank Accounts) this bank account will be set on its partner's employees. Also on this view; only partners linked to at least one employee (in selected companies) will be selectable. task-4076834
This fix ensures that when follow-up emails are sent automatically by the system, the designated follow-up responsible person is credited as the message author instead of the system bot. This means that when customers reply to automatic follow-up emails, the responsible person will be properly notified, matching the behavior of manually-sent follow-ups.
Original PR description
Have a partner in need of action with the followup level configured to Send an Email, with 'Automatic' enabled Case 1: - Send the followup manually - Reply to the follouwp mail - Message will be posted as log note but the system link the message with the previous one[1], where user is the author and will be automatically notified Case 2: - Wait for the cron to send followup automatically - Reply to the followup mail - Message will be posted as log note but since OdooBot is the author of the previous message no user will receive any notification With this commit we make use of the followup responsible when sending followup email automatically before defaulting to OdooBot [1] https://github.com/odoo/odoo/blob/fe4b2a6d08a450b281e7ac0676afd51a88dd6008/addons/mail/models/mail_thread.py#L1182 opw-4000835 Forward-Port-Of: odoo/enterprise#67391
This fix ensures that when users duplicate a pricelist, all recurring price rules and rental rules are now properly copied to the new pricelist. Previously, these special pricing rules were not being duplicated, which meant users had to manually recreate them in the duplicated pricelist.
Original PR description
Before this commit, when user duplicate pricelist then recurring price rule are not duplicated in new pricelist. After this commit, recurring price rule will be copied to new pricelist when user will duplicate pricelist. task-4035473