Tuesday, July 16, 2024
10 changes · 17.0
Resolved issues and error corrections
The product data population tool now avoids duplicate barcode patterns when it is run multiple times in the same database. This helps teams generate test or demo data repeatedly without the process failing on product records.
Original PR description
You can't run the `populate` odoo-bin command more than once if `product.product` is part of the models to be populated. This is because it will always generate a kind of fixed barcode pattern in the…
You can't run the `populate` odoo-bin command more than once if `product.product` is part of the models to be populated. This is because it will always generate a kind of fixed barcode pattern in the form of `BARCODE-PP-{counter}`.
This commit simply performs a quick raw SQL check to ensure no previous populate run was done, and if it was it simply retrieves the barcode of the last product created through a previous populate command. If that barcode exists, is then used as prefix itself.
Running the populate command 4 times in a row will produce the following results:
```
select id,default_code, barcode from product_product order by id desc;
id | default_code | barcode
-----+--------------+----------------------------
639 | PP-150 | BARCODE-PP-150-150-150-150
638 | PP-149 | BARCODE-PP-150-150-150-149
...
```
Another option would have been to use a fully randomized string, but avoiding randomness is preferable, especially when considering the case of running the populate command only once.
Note that the `product.product` model is the only problematic one when
running back to back `populate` on all models used by accounting:
- account.move
- account.journal
- account.bank.statement
- account.bank.statement.line
- account.payment
- account.reconcile.model
- account.reconcile.model.line
- res.company
- res.partner
- res.partner.industry
- product.product
- product.category
- ...probably more through `_populate_dependencies`...
task-3821088Fixed an issue where increasing product quantities in the website cart could show distracting extra decimal digits. This keeps the cart clearer for shoppers and reduces confusion during checkout.
Original PR description
To reproduce the bug: 1. On Runbot, set the decimal accuracy of "Product Unit of Measure" to 5. 2. Go to the website and add a product to the cart. 3. Go to the cart and click on the "+" button. Some decimals may appear due to issues related to floating-point numbers. This issue is being addressed and will be fixed in the future (see: https://github.com/odoo/odoo/pull/152709). In the meantime, we can apply a fix on the frontend. opw-3990565
This fixes an issue where changing the organizer while creating a calendar event could be lost after adding that organizer as an attendee. Users can now set the intended organizer before saving, avoiding incorrect ownership of newly created meetings.
Original PR description
### Steps to reproduce: - Install Calendar module - Create a new event - Change the organzier to Marc Demo and then add him as attendee - Save the event ### Current behavior before PR: When changing…
### Steps to reproduce: - Install Calendar module - Create a new event - Change the organzier to Marc Demo and then add him as attendee - Save the event ### Current behavior before PR: When changing the organizer of an event that you are creating and then add a new attendee and save the event the organizer will not be saved and will be back to the default user. This is happening because when getting the changed values to use it in the create operation it will check if the organizer field is readonly https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/model/relational_model/record.js#L592:L597 It will be true and it is readonly because of the computed field in the calendar.event 'user_can_edit' where when it checks who can edit the event before creating it the 'partner_ids' will be found as 'NewId' not yet 'res.partner' https://github.com/odoo/odoo/blob/17.0/addons/calendar/models/calendar_event.py#L296 ### Desired behavior after PR is merged: We can change the organizer of the event before assign the attendees or creating the event. As we are now checking the ids itself not the whole object of the partner_ids opw-3908333
Opening a record from a list no longer triggers validation messages when nothing has been changed. This reduces distracting notifications and makes routine record viewing smoother for users.
Original PR description
Before this commit, opening a record from the list view triggered field validity checks, resulting in unnecessary notifications. This commit optimizes the process by bypassing the _checkValidity function when no changes to the record have been made. opw-3987849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Self-order purchases are now always created under the dedicated self-order user instead of whichever staff session happens to be active. This prevents orders from being linked to the wrong employee account and keeps kiosk or public self-order activity consistent.
Original PR description
Before this commit, the self order was created with the user of the current session. This is not the expected behavior, as the self order is always accessed by a public user. This commit fixes this by always using the self user for the self order.
This fixes the default account settings used in the French localization for suspense and deferred entries. Businesses using the French chart of accounts will get the expected suspense accounts and the proper deferred expense and revenue accounts by default, reducing manual corrections and accounting setup errors.
Original PR description
Accounts 471000 to 475000 can be used as suspense accounts. 471000, 472000 & 473000 have been chosen since they're the 1st ones Expected deferred accounts: - Expense: 486000 - Revenue: 487000 task-383985
Point of Sale-related accounting entries in India now update their state information when POS sessions change. This helps keep tax and localization data accurate for sales processed through POS sessions.
Original PR description
Enhanced the `_compute_l10n_in_state_id` method in the `AccountMove` model by adding a dependency on the `l10n_in_pos_session_ids` field. This ensures that the state computation is triggered when POS sessions are updated, improving the accuracy of state determination for moves related to POS sessions.
This update prevents an access error when calculating the total amount due for a contact if the user cannot view related parent company records. It helps users complete follow-up and payment review tasks without being blocked by permissions they do not control.
Original PR description
When computing the total due for a contact, the current user might not have read access to the aml's parent companies. Before this commit, this would generate an access error opw-3970447
This update fixes an issue where job positions were not sorting alphabetically when clicking the sort header in the Contracts view. The referral module was interfering with the standard sorting behavior. Now employees can properly sort job positions in alphabetical order when managing contracts.
Original PR description
Necessary modules: hr_contract, hr_referral Steps to reproduce: - Employees > Employees > Contracts - Click header to sort by job position What happens: Job positions are not sorted by alphabetical order What was done: Make sure referral does not override the ordering rules of hr_job, so the alphabetical sorting is kept. opw-4037409
This update fixes an issue with how stock movements are ordered when reporting to Kenya's eTIMS tax system. By making the ordering consistent and predictable, the system now works reliably without random test failures, ensuring accurate and stable tax compliance reporting.
Original PR description
When we search for the stock moves to report to eTIMS, we need to ensure that the ordering is deterministic so that tests don't randomly fail. runbot-71136