Friday, September 20, 2024
15 changes · 17.0
Resolved issues and error corrections
Fixes an issue where favorite star icons could show the wrong state after saving records affected by automation rules. Users will now see the favorite status update consistently when toggling it, reducing confusion in apps such as Project.
Original PR description
The issue: When setting an automation rule to trigger 'On Save' onto a model with the boolean_favorite widget (i.e. project), the display will not update the icon properly when attempting to toggle it. This is due to base_automation populating the old_values which will attempt to read is_favorite, triggering a recomputation before favorite_user_ids is updated. The Fix: Retrigger the update without saving. This will force is_favorite to recompute again with the updated favorite_user_ids value and the display will stay consistent with the status of the widget. OPW: 4106799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix removes an unnecessary rounding step when calculating expense unit prices. It helps ensure expense amounts are displayed consistently and accurately, reducing confusion during expense review and reimbursement.
Original PR description
During the forward-port of c940d3f fix about the price_unit display, the changes introduced by the refactoring in 68fbdc9 weren't taken into consideration. task-3749434 This completes the fix by removing the price_unit rounding entirely in the compute method 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
Installing Indian withholding tax no longer fails when an Indian company has branch companies. The setup now loads taxes only for the main company, avoiding errors for branches that already use the parent company's chart of accounts.
Original PR description
- Install `l10n_in` - create a branch for the Indian company - install `l10n_in_withholding` - traceback If there an Indian company has a branch, installing `l10n_in_withholding` raises an RPC error on the branch company, because the TDS group is not set on it. Since branches use the COA of the parent company, we don't need to load further. Task [link](https://www.odoo.com/odoo/project/967/tasks/4143223) task-4143223
This change prevents a timesheet access rule from incorrectly blocking analytic account branch tests when only the timesheet grid app is installed. It helps keep automated checks reliable and avoids configuration-specific access errors.
Original PR description
Steps to reproduce: - install only `timesheet_grid` - run `test_analytic_account_branches` Issue: An access error is raised Cause: https://github.com/odoo/odoo/blob/8029b467dacaf9e34b21db52b148a2963efb29e4/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L44 So the analytic line should have a project_id set. Solution: Unlkink the groupe if existing runbot-97783
This fixes when the Viettel e-invoice XML section is shown on invoice forms. Users should now see the correct page when working with replacement invoice information, avoiding confusion or missing details.
Original PR description
* PROPBLEM: In form view we try to use m2o.field_name which is 'l10n_vn_edi_replacement_origin_id.l10n_vn_edi_invoice_number', odoo doesn't support that so it will not work at least in form view * SOLUTION: this commit make the invisible condition more simpler and create a non-store field to fix the issue 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
When a SendCloud contract has no available rates, adding it to a sales order no longer triggers a disruptive popup. Users now see the same message in a red banner, keeping the workflow clearer and less interruptive.
Original PR description
In this PR ================== Some contracts in SendCloud do not have rates. This caused an annoying popup when adding it to the Sales Order. After this PR, the red banner is displayed with the same message instead of the annoying popup when adding it to the Sales Order. Enterprise PR: https://github.com/odoo/enterprise/pull/66976 TaskId: 4012182
This update adds a missing validation rule to the batch payment system to prevent payment method changes that could violate business constraints. While the standard interface already prevents this issue, the fix ensures the constraint is enforced even when records are created or modified through custom views or direct code, protecting data integrity.
Original PR description
payment_method_id is readonly in account.batch.payment's form view when there is at least one payment on the batch. So, it cannot easily be changed in standard in order to break the constraint. It could however happen in custom views or when generating records directly from the code. Forward-Port-Of: odoo/enterprise#70230
Miscellaneous changes
Versions -------- - 16.0+ Steps ----- 1. Try to import a malformed OFX file into a bank journal; 2. close traceback; 3. try to import a valid OFX or CSV file. Issue ----- Same traceback as first upload. Cause ----- There's no error handling on the RPC call. If the file is successfully imported, the `attachmentIdsToProcess` gets clear, but if there's an error, the bad file remains in the queue until leaving the view. Solution -------- Put the RPC call in a `try` block, and
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Try to import a malformed OFX file into a bank journal; 2. close traceback; 3. try to import a valid OFX or CSV file. Issue ----- Same traceback as first upload. Cause ----- There's no error handling on the RPC call. If the file is successfully imported, the `attachmentIdsToProcess` gets clear, but if there's an error, the bad file remains in the queue until leaving the view. Solution -------- Put the RPC call in a `try` block, and clear the `attachmentIdsToProcess` in `finally` to ensure this happens regardless of outcome. opw-4113740 Forward-Port-Of: odoo/odoo#180845
Before this commit: ========== - An issue existed with the quantity of reward products where there were more reward products applied than configured in the backend. - Rewards were being applied even when loyalty points were insufficient for the redemption of loyalty rewards. - In a loyalty program configuration with a reward point mode per order, loyalty points were consistently decreasing. - We were not showing a balance of loyalty points for the customers. After this commit:
Original PR description
Before this commit: ========== - An issue existed with the quantity of reward products where there were more reward products applied than configured in the backend. - Rewards were being applied even when loyalty points were insufficient for the redemption of loyalty rewards. - In a loyalty program configuration with a reward point mode per order, loyalty points were consistently decreasing. - We were not showing a balance of loyalty points for the customers. After this commit: ========== - The quantity of the applied reward product will now match the configuration set in the backend. - Reward products will not be applied if the customer's loyalty points are insufficient for the specific reward product. - Loyalty points will be computed correctly in the case of the reward point mode per order. - We will show a balance of loyalty points for the customers. task-4126886 Forward-Port-Of: odoo/odoo#178901
Updated imports for `zeep.wsse` components to explicitly import modules. This change is required because zeep 4.2.0 introduced an `__all__` declaration in `zeep.wsse`: ``` __all__ = [ "Compose", "BinarySignature", "MemorySignature", "Signature", "UsernameToken", ] ``` The __all__ prevents using wildcard imports for all wsse submodules as we did before. Steps to Reproduce: - Install the l10n_nl_reports_sbr module. - Navigate to Accounting > Report > Tax Rep
Original PR description
Updated imports for `zeep.wsse` components to explicitly import modules.
This change is required because zeep 4.2.0 introduced an `__all__` declaration in `zeep.wsse`:
```
__all__ = [
"Compose",
"BinarySignature",
"MemorySignature",
"Signature",
"UsernameToken",
]
```
The __all__ prevents using wildcard imports for all wsse submodules as we did before.
Steps to Reproduce:
- Install the l10n_nl_reports_sbr module.
- Navigate to Accounting > Report > Tax Report.
- Select XBRL from the dropdown menu on the PDF button in the top left corner.
- Attempt to send the document.
- An error will occur:
```
Copy code
File "/home/odoo/src/enterprise/saas-17.4/l10n_nl_reports_sbr/wizard/l10n_nl_reports_sbr_tax_report_wizard.py", line 168, in __init__
wsse.signature.MemorySignature.__init__(
^^^^^^^^^^^^^^
AttributeError: module 'odoo.tools.zeep.wsse' has no attribute 'signature'
````
opw-4181876
Forward-Port-Of: odoo/odoo#180857### Steps to reproduce the issue: 1. Create a Customer Invoice with two product lines 2. Give a negative price to one of those lines, the total must remain positive 3. Add distinct analytic accounts to each line's analytic_distribution 4. Add a payment term with applicable early discount 5. Confirm and Register Payment 6. Go to the Journal Entry related to the Invoice 7. Check the Invert Tags (developer mode), one of them is set to True, which should not be the case ### Explanation:
Original PR description
### Steps to reproduce the issue: 1. Create a Customer Invoice with two product lines 2. Give a negative price to one of those lines, the total must remain positive 3. Add distinct analytic accounts…
### Steps to reproduce the issue: 1. Create a Customer Invoice with two product lines 2. Give a negative price to one of those lines, the total must remain positive 3. Add distinct analytic accounts to each line's analytic_distribution 4. Add a payment term with applicable early discount 5. Confirm and Register Payment 6. Go to the Journal Entry related to the Invoice 7. Check the Invert Tags (developer mode), one of them is set to True, which should not be the case ### Explanation: In the current situation, `_compute_is_refund` and `_compute_tax_tag_invert` will assign a value to `tax_tag_invert` depending on the `account.move.line.balance`. Because of the distinct analytic accounts, the negative line is separated from the others and because of the logic behind the computes, `tax_tag_invert` is set to the opposite value. ### Fix reasoning: While `account.payment` are restricted to `account.move` with the same direction, `account.bank.statement.line` are not. In the current case, the affected lines all have `tax_ids` values. Thanks to this, we can use `account.tax.type_tax_use` independently of the line's balance to differentiate in and out transactions and assign `tax_tag_invert` consistently. We must also consider the case where `account.bank.statement.line`. To target the Early Payment Discount lines, we will separate them from the other values using `display_type`. opw-3989174 Forward-Port-Of: odoo/odoo#170499
In `test_base_on_rule_currency_is_converted` we create a rate for a testing currency and check that is applied, but we don't specify its name/date, so under certain conditions it will considered as applying only tomorrow and the test will fail. runbot-97969 Forward-Port-Of: odoo/odoo#180287
Original PR description
In `test_base_on_rule_currency_is_converted` we create a rate for a testing currency and check that is applied, but we don't specify its name/date, so under certain conditions it will considered as applying only tomorrow and the test will fail. runbot-97969 Forward-Port-Of: odoo/odoo#180287
Steps to reproduce: - Time off > Configuration > Time off types > New - Set 'Requires Allocation' to 'No Limit' - Takes leaves of this type - Set 'Requires Allocation' to 'Yes' - Approvals > Allocations > New > Select your time off type - Edit validity period to start after the leaves you took - Confirm > Click on the newly created allocation - Displays -X remaining out of Y The allocations try to cover leaves taken before the requirement was changed, when we'd expect leaves taken und
Original PR description
Steps to reproduce: - Time off > Configuration > Time off types > New - Set 'Requires Allocation' to 'No Limit' - Takes leaves of this type - Set 'Requires Allocation' to 'Yes' - Approvals >…
Steps to reproduce: - Time off > Configuration > Time off types > New - Set 'Requires Allocation' to 'No Limit' - Takes leaves of this type - Set 'Requires Allocation' to 'Yes' - Approvals > Allocations > New > Select your time off type - Edit validity period to start after the leaves you took - Confirm > Click on the newly created allocation - Displays -X remaining out of Y The allocations try to cover leaves taken before the requirement was changed, when we'd expect leaves taken under No Limit mode not to require any. This is problematic because it can happen with past leaves as well, which we cannot get rid of on production databases. Since Odoo does not track which allocation requirement mode leave are taken under nor the date and content of edits to that parameter, we cannot tell apart leaves of the same type when distributing allocated days. Tracking either would certainly require edits to the model which rules out stable versions, so instead the edits to allocation requirement should be restricted in favor of creating new time off types when we want to switch that parameter. opw-3919886 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180566
Steps - install `stock` - create a delivery for 2 products > *Mark as Todo* > *Validate* - make a return, a `ListRenderer` for the return moves opens - click the last field (quantity) of the last record in the list - press `tab` * => Traceback: `Uncaught Promise > futureRecord is undefined` Cause --- This specific view is `editable='top' create='0'`, but the return moves have been generated on the fly, so their `isNew` property is true. But, we check `isNew` to decide if a rec
Original PR description
Steps - install `stock` - create a delivery for 2 products > *Mark as Todo* > *Validate* - make a return, a `ListRenderer` for the return moves opens - click the last field (quantity) of the last record in the list - press `tab` * => Traceback: `Uncaught Promise > futureRecord is undefined` Cause --- This specific view is `editable='top' create='0'`, but the return moves have been generated on the fly, so their `isNew` property is true. But, we check `isNew` to decide if a record has just been created in the list, and what element is the last. This leads to a false negative where we don't detect that we're on the last record. Note --- `.isNew` is still needed because we can run into problems with the pager or if we start with a grouped list view. opw-4108845 Forward-Port-Of: odoo/odoo#180690
Avoid sending more emails than necessary at events We want to make sure that in all mails sent from the calendar event, the recipients are only the ones we want and avoid sending them to 'indirect' followers. Examples use case: - Subtype Notes with Default checked. - Several Attendees set (including several users). - Each invitation email must be sent only to the corresponding attendee, no one else. - Each event reminder email must reach only the corresponding attendee, no one else.
Original PR description
Avoid sending more emails than necessary at events We want to make sure that in all mails sent from the calendar event, the recipients are only the ones we want and avoid sending them to 'indirect' followers. Examples use case: - Subtype Notes with Default checked. - Several Attendees set (including several users). - Each invitation email must be sent only to the corresponding attendee, no one else. - Each event reminder email must reach only the corresponding attendee, no one else. Example use case in runbot v16 **before** this change.  Example use case **after** this change.  @Tecnativa TT50302 Ping @pedrobaeza and @carlosdauden --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174494