Wednesday, January 4, 2023
6 changes · master
Enhancements to existing features
Users now see an empty loading screen immediately when changing apps, rather than waiting on the previous view. This makes navigation feel more responsive, especially on mobile and from the home menu.
Original PR description
The goal is to provide a better feedback to the user, especially in mobile mode/home menu. Task 2900847 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
Email templates are now easier to find and edit from the settings area, with clearer template lists and forms. Users also get guidance for updating related email header and footer views, while digest emails better match company branding colors.
Original PR description
Allow our users to modify mail template more easily; * make the list accessible from the settings * give them a link to update relevant views to update header/footer * make the list and form of templates more readable taskID 2944770
The French localization content has been converted to follow Odoo's standard translation process: source localization terms are kept in English and translated into French through translation files. This improves consistency and makes future updates easier to manage across French and Canadian French deployments.
Original PR description
The French localisation was written in french which was wrong, all the localisation have to be written in english and then translated back to the native language thanks to PO files. Thanks to this PR, all the french localisation has been translated. Task-id: 3112366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Managers can now filter employee lists to show everyone who reports under them, including indirect reports through the management chain. This makes it easier to review teams beyond direct reports and supports more accurate people management views.
Original PR description
Before this commit, in the search view, it is not possible to filter the employees to only have those ones who is a subordinate of the current user. That is, if Pierre is the current employee/user and he is the manager of Paul and Paul is the manager of Jacques. Pierre could want to see his subordinates in his view of so Paul and Jacques instead of just Paul. This commit adds a new boolean field called `is_subordinate` in `hr.employee` and `hr.employee.public` models. This field will be True if the employee is a subordinate of the current user. task-3061362
The timesheet team filter now shows only employees the current user directly manages or approves, reducing unrelated entries. Timesheet approvers with broad access can also validate timesheets for employees who have no assigned manager or approver, helping prevent approval bottlenecks.
Original PR description
Before this commit, the "My Team" filter is showing all the users that are part of a project from wich the user is manager or timesheets of employees for which he is the responsible. Also, a user who has the "User: All Timesheet" access right set, should be able to validate timesheet of other users that do not have a timesheet approver and a parent set. This commit updates the filter condition to only see the timesheets linked an employee for which the current user is his timesheet manager or his manager. It also changes the validation process for the Timesheets approver, he can now validate the timesheets linked to an employee for which the current is the manager or the timesheet approver or that employee has no manager and no timesheet approver. task-3061362 Co-authored-by: Xavier Bol <xbo@odoo.com>
Resolved issues and error corrections
PDF reports now handle page headers and footers correctly when printing batches that include right-to-left languages such as Arabic alongside left-to-right languages. This prevents corrupted or unreadable documents in large batch prints, improving reliability for sales, purchasing, and stock-related paperwork.
Original PR description
When selecting at least 10 SO with RTL language on the customer, the printing behavior (the PDF produced) is inconsistent. By inconsistent, we mean some pages are completely filled with buggy headers…
When selecting at least 10 SO with RTL language on the customer, the printing behavior (the PDF produced) is inconsistent. By inconsistent, we mean some pages are completely filled with buggy headers making the whole PDF corrupted (on a business point of view). Step to reproduce the issue: The customer/vendor on the PO, SO, RFQ has language set to Arabic The user creating the document has language set to English (US) Printing out 10+ documents The resulting PDF document is inconsistent and contains headers issues (as previously stated). Solution: The problem is that the headers/footers doesn't take into account the language of the company (RTL or not). In fact, all the headers/footers of a batch print are contained into a single HTML file (apparently, at the time, wkhtmltopdf did not support multiple headers/footers). A Javascript script is used to select the appropriate header/footer for each page of the PDF. The issue is that the CSS file used for these headers/footers is always a LTR CSS file. Moreover, with this design, it is impossible to combine headers/footers in RTL and LTR into a single PDF file with multiple pages. The complete solution would be to create a single header/footer file per page in the PDF report (wkhtmltopdf now supports this), that way we can specify the language (RTL or LTR) for each of the page and have the perfect behavior. However, this change cannot be applied into a stable version (requires changes in signature of methods, etc.), consequently, the full solution will only be kept for master. Enterprise PR: https://github.com/odoo/enterprise/pull/26289 Original PR on stable version: https://github.com/odoo/odoo/pull/88883 opw-2734671