Daily updates from Odoo
Thursday, July 18, 2024
6 changes
1 change
Resolved issues and error corrections
Point of Sale records now keep linked information when saved or transferred, even if some related data was not loaded in the session. This helps prevent missing customer, order, or other linked details in certain Point of Sale workflows.
Original PR description
Before this commit, serializing a record would omit x2many and many2one fields if their related models were not loaded into the PoS. opw-3998097 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
5 changes
Resolved issues and error corrections
Timesheets 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 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 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