[6.0.1] HR-Recruitment: bug applicant becoming employee: wrong data
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Addons (MOVED TO GITHUB) |
Fix Released
|
Low
|
OpenERP R&D Addons Team 3 |
Bug Description
Hello,
In hr_recruitment, I see the following bug, when applicant is hired, an employee record is created but it is created with wrong data.
Please follow these steps:
- Create an applicant (hr.applicant)
- Put in field "Subject" (name): "My application" (a value that seems logical if the application comes from fetchmail)
- Put in field "Applicant's name" (partner_name): "John Doe"
- Create a partner for john doe with an address so you can store John Doe's address
- Change the state to "In progress" then to "hired", what should create an employee record in "hr.employee".
You should see the following bugs:
1. In the tab history of applicant, you can read that the states' names have not the same description ("in progress" becomes "Open" and "Hired" becomes "Closed"), which is not very good from a user standpoint
2. Access to the employee that has been created in employee list (he.employee)
- The name of the employee created is the field "subject" of hr.applicant -> in this case the employee's name is "My application". This field should show instead the content of field "Applicant's name" (hr.applicant-
- The home address of employee in hr.employee remains empty, and I think it could content automatically the contact address of the partner that has been created for the applicant, showed in hr.applicant-
Regards,
Bernard
Related branches
- Mustufa Rangwala (Open ERP) (community): Approve
- Rohan Nayani(Open ERP) (community): Needs Resubmitting
-
Diff: 27 lines (+9/-1)1 file modifiedhr_recruitment/hr_recruitment.py (+9/-1)
Changed in openobject-addons: | |
milestone: | none → 6.1 |
Changed in openobject-addons: | |
status: | Confirmed → In Progress |
Changed in openobject-addons: | |
status: | Fix Committed → Fix Released |
Hello Bernard,
I am confirming this issue only for the issue number 2.
Regarding your issue no 1 for history object status we are considering generalize status because this object is used for number of other object also like crm so we can not consider this issue for implementation.
Thanks