Tuesday, June 25, 2024
9 changes · 17.0
Resolved issues and error corrections
This fix resolves an issue where branch users could not see contacts assigned to their parent company. The change updates access rules to allow branches to view and access partner records from the parent company, improving data visibility and usability across multi-branch organizations.
Original PR description
This PR changes an enterprise test that failed with a community PR. Linked community PR: https://github.com/odoo/odoo/pull/166965 ### Steps to reproduce: - Create a company and a branch - Create a contact and assign him to the company created - Switch to the branch and go to the Contact app - You can't see the contact created ### Cause: A rule does not allow branches to see partners from the parent company. ### Solution: Change the rule to make partners accessible to branches. This solution implies changing access rules defined in base to use the 'parent_of' operator. By changing it, I removed a performance improvement introduced so I needed to change performance tests counting queries to make them pass. opw-3927295
Fixed an error that occurred when users without Point of Sale (PoS) access tried to create invoices for sales containing recurring products. This ensures that users can properly invoice recurring product sales regardless of their PoS permissions, improving the workflow for teams that use subscriptions but not the PoS system.
Original PR description
When creating an invoice for a sales containing a recurring product, if the user doesn't have access to PoS you will have an access errorr Steps to reproduce: ------------------- * Remove PoS right from Marc Demo * Create a recurring product * Connect as Marc Demo * Create a sale with the recurring product * Try to invoice the sale > Observation: You get an access error opw-4010753
Fixed an issue where subscription orders could not be closed properly due to unreliable invoice detection. The system now uses multiple verification methods to confirm invoices exist before allowing a subscription to close, ensuring that subscriptions with invoices are correctly identified even when internal data structures change.
Original PR description
https://github.com/odoo/enterprise/commit/f510c4098cc4696dec3fbc7d6cd3164c6fb1d6bd prevented to close a subscription if there was no invoice. Unfortulately, sale_order.order_line.invoice_lines.move_id is not always a reliabable way to check for invoices. Sme flows could replaces all the sale.order.line and therefore the link to the invoices would be lost. In that case, for subscription orders, using the subscription_id field on the account.move.line is more reliable. We use both values to be sure.
Fixed a bug where timesheet timers started in list or kanban views were not properly recording the time spent. The issue was caused by missing function calls and incorrect state tracking that prevented the timer data from being saved to the server. Now when employees start a timer, set a project and task, and stop the timer, the hours will be correctly recorded.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to Timesheets; 2. open list or kanban or list view; 3. click the START button to start a timer; 4. set a project & task; 5. stop timer. Issue ----- A…
Versions -------- - 17.0+ Steps ----- 1. Go to Timesheets; 2. open list or kanban or list view; 3. click the START button to start a timer; 4. set a project & task; 5. stop timer. Issue ----- A record is added but hours spent remains 00:00, regardless of how much time has passed. Cause ----- 1. No timer was created on the server, because the `_setProjectTask` function that's responsible for it isn't being called when selecting a project or task. 2. From `_setProjectTask`, the `onWillUpdateProps` hook wasn't getting triggered, because it's calling `load()` on `propsList` instead of `propsList.model`. 3. In `onWillUpdateProps`, the value of `timesheet.resId` wasn't getting updated because `resId` has a getter returning `config.resId`, but no setter modifying `config`. Solution -------- 1. Add a `onRecordChanged` hook. 2. Replace `propsList.load()` with `propsList.model.load()`. 3. Modify state tracking to supplant the need for changing `resId`. opw-3735463
This update fixes how the bank reconciliation feature displays on mobile devices. Previously, the layout was difficult to read on smaller screens due to narrow element widths and display issues. The fix ensures that reconciliation data is now readable and usable on mobile phones and tablets, improving the experience for users who need to manage bank reconciliations on the go.
Original PR description
This PR fixes the mobile responsiveness inside the reconciliation in `account_accountant`. The width of the elements was too small and the `overflow` value broke the layout on mobile view. The point…
This PR fixes the mobile responsiveness inside the reconciliation in `account_accountant`. The width of the elements was too small and the `overflow` value broke the layout on mobile view. The point is to make the data at least readable on mobile, but this could be improved in the near future (eg. less data shown to user, displayed another way like a list-group, etc). If barcode is installed, the buttons are half-hidden under the control-panel. This is fixed in this [Enterprise/#63271](https://github.com/odoo/enterprise/pull/63271). task-3358275 Related to task-3326263 | Before | After | |--------|--------| | <img width="408" alt="Screenshot 2024-05-27 at 14 19 32" src="https://github.com/odoo/enterprise/assets/108661430/56ac88f0-22e4-498c-a5f2-ea9ef9316a80"> | <img width="407" alt="Screenshot 2024-05-27 at 14 31 49" src="https://github.com/odoo/enterprise/assets/108661430/be2bdb9a-c1de-4280-bf07-2d5257d74c3d"> | | | <img width="408" alt="Screenshot 2024-05-27 at 14 32 00" src="https://github.com/odoo/enterprise/assets/108661430/fecb7a25-04c3-48d0-a555-67c2a4aa45d4"> | Forward-Port-Of: odoo/enterprise#45256
This fix addresses an issue where Brazilian mobile phone numbers were not being formatted correctly in WhatsApp messaging. Due to Brazil's 2016 phone number format changes (which added a digit to mobile numbers), the system's phone number formatting wasn't applying the necessary adjustments. The fix ensures that phone numbers are properly formatted and validated when using WhatsApp in Brazil.
Original PR description
Current behaviour: --- Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil. (Adding a 9 to mobile phone numbers) Cause of the issue: --- Phonenumbers metadata were patched to add 9 in mobile numbers, however, when E164 is selected, phone numbers aren't formatted, thus patched metadata not being applied. See format_number in phonenumbers "Early exit for E164 case" Fix: --- See community commit Adding extra tests in test_whatsapp opw-3861847
This fix corrects how tax identification numbers (NIF) are displayed in Spanish VAT reports. Previously, NIF numbers were only shown for Spanish partners or those without a country assigned. The update now properly displays NIF information for non-EU partners as required by Spanish tax authority specifications, ensuring accurate VAT record reporting.
Original PR description
### Issue: The VAT lines in tax reports do not populate correctly. ### Steps to reproduce: - Activate l10n_es module - Go to Accounting > Reporting > Statement Reports > Tax Report - Select a 'Generic Tax Report' and click on 'VAT Record Books (XLSX)' - In the report, only Spain and partners without countries have a NIF number ### Cause: A line of code is only populating the NIF field in the report if the partner has no country or if the country is Spain. In addition, other lines related to the NIF are not populated as they should. ### Solution: Add conditions to populate the NIF lines as the specs demands it. Specs: https://sede.agenciatributaria.gob.es/static_files/AEAT/LSI.xlsx (second point) opw-3918623
This update corrects a typo in the Swiss payroll system's LAAC1 compensation condition logic. The fix ensures that compensation calculations for Swiss employees are processed correctly according to the proper business rules, preventing potential payroll calculation errors.
Fixed an issue where planning timesheets in non-English languages would cause an error. The system was failing to correctly parse dates when the user's language didn't match the server's locale (for example, showing "15 Mag 2024" in Italian). This fix ensures dates are properly formatted and parsed regardless of the user's language setting.
Original PR description
## Before this PR If you have a different language than the locale of the server and you try to generate a timesheet on "Planning" for a period that has already timesheet , an error pops out because strptime can't parse the day in language : for example returns "15 Mag 2024" (in italian) and strptime fails To replicate: - Change to a language other than English - Plan a period for a employee - Try to plan a period that overlaps the same period - Error appear ### After this PR: i correctly pass the correct lang to the function so it is formatted on the same format than the locale of the server Forward-Port-Of: odoo/enterprise#62526