Daily updates from Odoo
Tuesday, March 4, 2025
5 changes · master
New functionality added to Odoo
Indian payroll now includes an ESIC report in the reporting section. Employees with an ESIC number on their profile are included, and the report also provides a separate sheet explaining related information and reason codes.
Original PR description
In this PR, the ESIC report has been added to the report section. If the employee has an ESIC number on their profile, it will be included in the ESIC report. There is another sheet in the report which contains the information and reason code. Task-4212727
Enhancements to existing features
Payroll users can now populate Individual Accounts reports without automatically generating PDFs for every eligible employee. They can choose specific employees or generate/post all relevant PDFs from the available report actions, giving teams more control and reducing unnecessary document creation.
Original PR description
Problem ---------- When you click on populate in "Individual Accounts" report, it trigger the pdf generation automatically for all eligible employees Objective ---------- We want to let the user decide if he wants to generate all the pdfs or if he wants to select which of them should be generated. Solution ---------- - The populate button not trigger the generate pdf action. - In Employee declaration view, the "Generate PDF(s)" button is always visible. - If the user select some of the employees, the button will trigger the pdf generation only for them. Else, if the user does not select anyone, all pdfs are generated. task-4161348
Recruitment teams now use a clearer signature request flow for applicants, with the applicant's email filled in by default instead of the current user's email. Users can also send signature requests to multiple applicants from the list view, reducing manual work and avoiding duplicate wizard options.
Original PR description
Problem ---------- - In an application form view, There are 2 Signature Request wizard accessible from the cogwheel menu. We have to use only the wizard from sign. And not our custom one in…
Problem ---------- - In an application form view, There are 2 Signature Request wizard accessible from the cogwheel menu. We have to use only the wizard from sign. And not our custom one in hr_recruitment_sign. - Change this sign wizard to replace the user mail with the applicant mail. - In case of selection of multiple application in list view. We have to be able to send signature request to all of them with a new wizard in the action cogwheel menu. This wizard must be the same as the sign request for employee one. Objective ---------- - Remove our sign request wizard in the cogwheel menu of applicant form view. - Adapt the sign wizard to display the applicant email by default. - Add the multiple sign request wizard in the cogwheel menu of list view. Solution ---------- For the multiple sign request : I use the previous customized wizard in hr_recruitment_sign (replaced by the sign one). Just adapt it to be usable with multiple records. So now the "signature request" action available in the cogmenu is display only in list view for multiple sign requests. Finally, for the sign request wizard in form view. To make it custom for the hr_applicant model. I needed to adapt and override the context of the cogmenu item to add the default signer and the active model. And adapt and override the sign_send_request to change the default signer. task-4260572
Appointment events are being simplified so each booking can link directly to its resource instead of relying on separate booking lines. This should make resource changes and calendar/grouped view editing easier for teams managing appointments.
Original PR description
Prior to this, each event had an o2m relation with booking lines. This made validation easy but also makes some tasks such as modifying the resources used and editing grouped views more cumbersome. We remove the booking lines and replace them with a direct m2o relation between events and appointment resources. task-338900
Deleting recurring shifts now consistently shows a confirmation dialog in list, kanban, and calendar views, matching the existing behavior in the form view. This helps users choose how to handle recurring shifts and reduces the risk of accidentally deleting the wrong planning entries.
Original PR description
[IMP] planning: improve recurring shifts deletion Before this commit: - Deleting recurring shifts from the form view would display a dialog with options for handling the deletion of recurring shifts. However, this behavior was inconsistent in the list, kanban and calendar views, where deleting a recurring shift would delete the shift without showing any dialog. After this commit: - List view: when some shifts are recurring, the modal is displayed - Kanban and Calendar view: when the shift is recurring, the modal is displayed. task-4149099