Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eyal application to employee #48386

wants to merge 3 commits into
base: 13.0


Copy link

pinkasey commented Mar 25, 2020

Description of the issue/feature this PR addresses:
When converting an application to an employee, it is reasonable to expect that all custom fields that exist on both - will be copied from the applicant to the newly created employee

Current behavior before PR:
a hard-coded set of fields are copied from the applicant to the new employee (see create_employee_from_applicant()).
custom fields are not populated.

Desired behavior after PR is merged:
When the same field is defined on both applicant and employee - it should be copied from applicant to the new employee

I confirm I have signed the CLA and read the PR guidelines at

@robodoo robodoo added the seen 🙂 label Mar 25, 2020
@C3POdoo C3POdoo added CLA HR labels Mar 25, 2020

This comment has been minimized.

Copy link

pinkasey commented Mar 25, 2020

I wasn't sure if this should go to 13 or master -
I think the risk here is low (only affect the button "Create Employee"), and the value is much higher than the risk.

If you disagree, I can rebase to master and open a new pull-request.


This comment has been minimized.

Copy link

mart-e commented Mar 30, 2020


Sorry but I don't think it's a good idea. You are making the assumption that all the custom fields of hr.applicant must be copied on the hr.employee record.
Either we apply this logic to all fields (custom or not), either we do it case by case.

I would tend for the second case for safety. For instance, we have a field active on hr.applicant and we do not want to copy it when creating an hr.employee record. There is certainly other similar examples with your custom fields. Either I would say that we create a _prepare_... method that builds the dict and custom code can customize this.

But maybe @tivisse disagree with me and has another idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.