Daily updates from Odoo
Thursday, July 18, 2024
12 changes · 17.0
Resolved issues and error corrections
The Saskatchewan tax report now includes the missing “Total before Sales” line. This helps Canadian businesses produce a more complete and accurate tax report for Saskatchewan filings.
Original PR description
Saskatchewan tax report was missing a line for `Total before Sales` opw-3955926
List views no longer show separator entries as optional fields when configuring displayed columns. This removes confusing choices that have no data value and prevents a related browser console warning.
Original PR description
Since https://github.com/odoo/odoo/issues/113974, Properties fields can contain separator (virtual `<group>`)
information inside its value. But in the view list, these separator can be selected in the optional fields. It doesn't make sense because there no value associated.
Also it avoids a warning in the JS console ("Missing widget: separator
for field of type separator").
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prTimesheets now link analytic accounts to the correct custom analytic plan instead of always using the default Projects plan. This helps ensure accounting reports show timesheet costs under the right plan when companies use customized analytic structures.
Original PR description
Steps to reproduce: ------------------- 1. Create a new analytic plan and set it as the default analytic plan in Project settings (it must be different from the 'Projects' plan) 2. Create again a new…
Steps to reproduce:
-------------------
1. Create a new analytic plan and set it as the default analytic plan in Project settings (it must be different from the 'Projects' plan)
2. Create again a new analytic plan and set its parent to the one you have created in step 1.
3. Create a new analytic account linked to the plan you have just created in step 2.
4. Create a new project and a new task
5. Link the analytic account you have created in step 3. to the task
6. Create a new timesheet linked to the task
7. In Accounting > Analytic Items, the analytic account of the timesheet will not be reported in the plan you created in step 2.
Fix:
-------------------
The 'Projects' plan (the default one) represents the 'account_id' field of analytic.account.line, other plans have names with the following format: 'x_plan{plan.id}_id' (they are fields created on the fly).
When creating a timesheet we were always setting its account.analytic.account to the 'account_id' field by default and ignoring the other plans.
The fix we propose is to look at the top-level plan of the account.analytic.account of the timesheet being created or modified, and link it to the plan it belongs to.
Note that we keep the 'account_id' ('Projects' plan) updated even if the account does not belong to this plan because this field is used in other parts of the code.
Linked PR: https://github.com/odoo/odoo/pull/139225
task-3820916
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix corrects a guided tour step for the Field Service Management worksheet feature. Previously, the tour would advance without requiring users to fill in the worksheet name field as intended. The fix ensures the tour properly waits for user input before proceeding to the next step.
Original PR description
Steps to reproduce: - Start the tour and continue till the worksheet step - Click on worksheet stat button in the tour - Click on the worksheet name field Issue: - The tour continues. - An input fields needs to be inputted with something before moving on. Reason: - Incorrect configuration of trigger for this step Fix: - Re-target the trigger on input field and fix the run function task-3709542
This fix corrects how the system determines the acquisition date for fixed assets created from invoices. Previously, the accounting date was incorrectly used instead of the invoice date. Now the system properly uses the invoice date when available, ensuring assets are recorded with the correct acquisition date for financial reporting purposes.
Original PR description
The accounting date is used as acquisition date instead of
bill date.
Steps:
2 flows leads to the bug:
1) - Create and confirm a bill with different accoutning and bill dates
- Open a new asset form and click on "select related purchases"
button
- Select the bill
-> The acquisition is set as the accounting date instead of the bill
date
2) - Set the expense account to create an asset
- Create and confirm a bill with line using the expense account
- An asset should be created, open it
-> Same as before
Cause:
In the `_compute_acquisition_date`, we use the field `date` from
`account.move.line` which is a related field to the `date` field of
`account_move`
Fix:
In the compute, we get the `invoice_date` field from the related move
of each `original_move_line_ids` then fallback to `date` if it is not
set (case of journal entries)
opw-4000259
Forward-Port-Of: odoo/enterprise#66831
Forward-Port-Of: odoo/enterprise#65769POS staff can now settle customer dues directly from the point of sale system without requiring accounting permissions. The system has been updated to show accurate due amounts in real-time, including dues settled in the current session, making it easier for POS users to manage customer payments.
Original PR description
Previously, only users with accounting rights could see the `total_due` from the POS and therefore only they could settle dues from the POS. Basic POS users should be able to settle dues. This commit allows them to do so without granting them unnecessary rights, by creating an exception in the `get_total_due` method for users in `group_pos_user`. opw-[3976254](https://www.odoo.com/odoo/project.task/3976254?cids=1)
This fix resolves an issue where tax report lines were showing zero values when users switched to a translated language. The problem occurred because tax tag names were being translated, but the report formulas that reference these tags were not. The fix ensures that tax tags are always matched using the base English language to maintain consistency between report formulas and tag names.
Original PR description
To reproduce the issue: 1) Make an invoice using a tax impacting some tag 2) Add a tanslation to that tag 3) Switch the user language to the one you added a translation for 4) Open the tax report: the line the tag is linked to has a value of 0 ===> It should contain the value you added in 1) l10n_multilang makes the 'name' field of account.account.tag translatable. Because of that, it is important to always check the tags matching a report expression's formula using en_US as the language, to make sure the formula of the report expression matches the tag name (since that expression's formula is not translatable). community: https://github.com/odoo/odoo/pull/170041 Forward-Port-Of: odoo/enterprise#65030
Fixed a critical issue where subscription invoices with negative amounts (credit notes) could incorrectly charge customers instead of refunding them. The system now blocks automatic payments for negative amounts and flags these invoices for manual review, preventing unintended charges while maintaining data integrity.
Original PR description
Before, when the subscription cron create recurring invoices, it might create a credit note in case some already invoiced non recurring product had his ordered quantity set back to zero. The payment transaction created for this credit note will take the absolute total without taking into account the type of the entry process. This leads to a transaction charging the amount to the client instead of refunding him. As we don't want to allow automatic refund because it could lead to catastrophe if a bug occurs, we decide to prevent the payment request if the amount is negative. In that case, we keep the draft invoice and keep the "payment_exception" flag to avoid running the subscription invoice cron again on that contract. opw-3874964
This update improves how the balance sheet test handles database operations by reducing the number of temporary savepoints created during testing. Previously, the system created a new savepoint for each test iteration, which could exceed database limits and cause performance issues. Now it creates a single savepoint and reuses it, making tests run more efficiently.
Original PR description
Instead of calling `env.cr.savepoint()` in a loop, which will create a savepoint at every iteration, we should create a single savepoint and rollback to it at the end of every subtest. In Postgres, the number of sub-transactions that may exist in active transactions has a hard limit of 64 before sub-transactions are stored on disk. It's therefore best practice to limit the number of savepoints we create. See also https://github.com/odoo/odoo/pull/167236 Forward-Port-Of: odoo/enterprise#66322
This fix ensures the eTims button only appears on vendor bills when the company is based in Kenya. Previously, the button was showing for all countries, which could confuse users in other regions. This improves the user experience by hiding irrelevant features based on the company's location.
Original PR description
…bill
This fix prevents Web Studio from crashing when opening invoices that have empty group attributes in their configuration. The issue occurred when certain modules set empty group values, which the system couldn't process correctly. The fix adds a simple check to skip empty group values, allowing users to open and edit invoices in Web Studio without errors.
Original PR description
Steps to reproduce ================== - Install account_accountant,l10n_fr_invoice_addr,web_studio,website_sale - Go to invoices - Open studio ``` enterprise/web_studio/models/ir_ui_view.py:103 in…
Steps to reproduce
==================
- Install account_accountant,l10n_fr_invoice_addr,web_studio,website_sale
- Go to invoices
- Open studio
```
enterprise/web_studio/models/ir_ui_view.py:103 in _postprocess_access_rights
100 │ │ │ for node in tree.xpath('//*[@groups]'):
101 │ │ │ │ node_groups[node] = node.get('groups')
❱ 103 │ │ │ │ if not self.user_has_groups(node.get('groups')):
odoo/odoo/models.py:1550 in user_has_groups
❱ 1550 │ │ │ if group_ext_id[0] == '!':
1551 │ │ │ │ not_has_groups.append(group_ext_id[1:])
IndexError: string index out of range
```
Cause of the issue
==================
The l10n_fr_invoice_addr sets an [empty group] attribute on a node. When opening studio, user_has_groups is called with the groups attribute value. In this case, it's an empty string and it fails.
Solution
========
Since an empty group is [allowed] by the ORM, we simply check that the value is not empty before calling user_has_groups
---
[empty group]: https://github.com/odoo/odoo/blob/00a78373f87c84dfa8ffa97ca255cf01368cd423/addons/l10n_fr_invoice_addr/models/account_move.py#L17
[allowed]: https://github.com/odoo/odoo/blob/a913272136182e6f4b1e28337686dd14616ea0ca/odoo/addons/base/tests/test_views.py#L2791
opw-4046078
Forward-Port-Of: odoo/enterprise#66595Previously, when employees viewed a stock picking in the barcode system, they were automatically assigned as the responsible person, even if they only looked at it without making any changes. This fix ensures users are only assigned as responsible when they actually perform an action like validating or editing a line, not when simply viewing the picking.
Original PR description
Problem --- When a stock picking is clicked from the barcode view, its responsible is always automatically assigned to the current user. Fix --- assign current user only if they change anything (validate, edit a line, etc) but not if they just look. opw-3878484