OFBiz › OFBiz - Dev

[jira] Created: (OFBIZ-2205) Implemented recruitment in HR module

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

47 messages Options

123

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688229#action_12688229 ]

Ashish Vijaywargiya commented on OFBIZ-2205:
--------------------------------------------

Hello Abhinav,

The updated patch looks lot better from the initial one.
Yesterday I have spent some time in reviewing the content of your patch & Here are few more comments
(I am sure you will not feel bad to see my comments again :-) ):

1) JobRequisition lookup should be improved. It is hard to remember the exact jobRequisitionId so we should include other fields from JobRequisition entity.
Instead of "Begins With" we should prefer "Contains" for searching. Change this everywhere in the patch.

2) EditApprovalStatus form should be improved to use the StatusValidChange. For ex: Internal Job Posting status can't be changed from "Rejected" to "Approved".
Please ask question if it is confusing. You can search existing patterns to understand the concept.

3) I think we should get rid of else part from all the service implementation except Create Job Requisition.
The reason is that we are not explicitly passing the applicationId from the html form.

+ <if-empty field="parameters.applicationId">
+ <make-next-seq-id value-field="newEntity" seq-field-name="applicationId"/>
+ <else>
+ <set from-field="parameters.applicationId" field="newEntity.applicationId"/>
+ </else>
+ </if-empty>

This case will not be applied on *Type entity based service implementation like InterviewType & JobPostingType.

4) For changing the behaviour(optional="true" to optional="false" & vice versa) of any field in the service definition we should use the <override> tag.
Change all the attribute tag into <override> tag and do the same for other service definition.

+ <service name="updateJobRequisition" engine="simple" default-entity-name="JobRequisition"
+ location="org/ofbiz/humanres/HumanResServices.xml" invoke="updateJobRequisition" auth="true">
+ <description>Update Job Requisition</description>
+ <permission-service service-name="humanResManagerPermission" main-action="UPDATE"/>
+ <auto-attributes mode="IN" include="pk" optional="false"/>
+ <auto-attributes mode="IN" include="nonpk" optional="true"/>
+ <attribute name="noOfResources" mode="IN" type="java.lang.Long" optional="false"/>
+ <attribute name="durationMonths" mode="IN" type="java.lang.Long" optional="false"/>
+ <attribute name="location" mode="IN" type="String" optional="false"/>
+ </service>
+

5) Do you know the purpose of default-map attribute in form tag ?
+ <form name="AddJobPostingType" type="single" target="createJobPostingType" default-map-name="jobPostingType"
Please explain & if its not clear then let me know I will help you.

6) The following line should be changed to use the new pattern (see revision 756025 for more details) :
+ <field name="deleteLink" title="${uiLabelMap.CommonDelete}" widget-style="buttontext">
+ <hyperlink target="deleteInterviewType?interviewTypeId=${interviewTypeId}" description="${uiLabelMap.CommonDelete}" also-hidden="false"/>
+ </field>
Please try to find the reason of this change and if you are unable to find the reason then please let us know.

7) Do you know the purpose of default-field-type="hidden" in the following line ?
+ <auto-fields-service service-name="updateJobPostingType" default-field-type="hidden"/>
Please explain & if its not clear then let me know I will help you.

8) You need not to fetch the "userLogin" object from session attribute in the groovy files.
It is implicitly available.
+userLogin = session.getAttribute("userLogin");

9) We should change the groovy file name from "LoginHR.groovy" to something more verbose.
Like ApproverPermissionCheck.groovy or ValidateApproverPermission.groovy or IdentifyApproverPermission.groovy.

10) There is no need to add prefix or suffix as "genericValue". Just write the name of entity following camelcase pattern.
For example : genericValueUserLoginSecurityGroup can be changed to userLoginSecurityGroup.
This is again best practice and code can be reviewed in existing applications.
For fetching list you need to add only "s" as suffix after the name of entity following camelcase pattern.
For example : UserLoginSecurityGroupList can be changed into userLoginSecurityGroups
Although userLoginSecurityGroupList is also good to keep (Change "U" to "u").

General Note : Initially I was thinking to do all these changes but I thought it would be difficult for you to review the changes.
I hope my comments will help you to overcome from such issues in future.

--
Ashish Vijaywargiya

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688619#action_12688619 ]

Ashish Vijaywargiya commented on OFBIZ-2205:
--------------------------------------------

Hello Abhinav,

Please take a look at the ongoing discussion on creating View entity using another View entity.
Here is the link to see the discussion.
http://www.nabble.com/One-view-entity-member-of-another-view-entity-to22657407.html

Specially notice the David's reply in that thread. (For your reference pasting the contents here)
------------
Is it feasible? That depends on the constraints you're working with.

It does usually work and can be done, but also often results in asking
the database to do more than your code really needs it to do (ie
including things in the joins that you don't need, significantly
slowing performance). The same is true of poorly defined view-entities
with normal (non-view) member entities, but there is more of a
tendency for that with views of views.

-David
----------------------

So now we can say that we should avoid the use of View that uses another View entity for data preparation.
We should find the alternate approach for doing the same thing instead of using ApproverAndCandidate, InterviweeAndInterviewer, PersonAndEmployeeAction view entities to solve our purpose.

--
Ashish Vijaywargiya

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689476#action_12689476 ]

Abhinav Vaid commented on OFBIZ-2205:
-------------------------------------

Hello Ashish

Thanks for your comments.

We are happy to answer questions that you asked :

1) Purpose of default map in forms :
It tells the form, what default map is to be used. If you have anything in addition to it, please share with us.

2) Purpose of default-field-type="hidden" in auto-fields :
It is used to select only the fields required for our target service from the input map. If we get our data from a map other than the default, we specify it with map-name="otherMap". If you have anything in addition to it, please share with us.

3) Removal of else part from all the service implementation except Create Job Requisition:
You have told us to get rid of the else part of all the service implementation except job requisition. In job requisition also we are not explicitly passing the job requisition id. So it would be better if we remove the else part from its implementation as well.

4) Instead of "Begins With" we should prefer "Contains" for searching:
You asked to use "Contains" as the default option instead of "Begins With". To accomplish this we will have to make changes in framework file i.e "HtmlFormRenderer.java". And, the same will be reflected everywhere in the OFBiz. We suggest it is better to use "Contains" as the default option because "Contains" covers "begins with". What do you suggest?

Regards
Abhinav Vaid
iLabs, Larsen & Toubro Infotech Ltd.
Mumbai.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694066#action_12694066 ]

Ashish Vijaywargiya commented on OFBIZ-2205:
--------------------------------------------

Hello Abhinav,

I hope you are doing good.

Thanks for your comments.
Here are my updated comments on your comments.

1) Purpose of default map in forms :
It tells the form, what default map is to be used. If you have anything in addition to it, please share with us.

Comment :
Yes you are right.
In our forms (i.e AddInterviewType, AddJobPostingType etc) we don't need to pass this as we are dealing with single map. (We can say case of Edit / Update)
I guess it was copy - paste issue :-).
The default-map come into picture when you are dealing with more then one "map" in the form.
For example RequirementForms.xml line # 104:
<form name="EditRequirement" type="single" target="updateRequirement" title="" default-map-name="requirement"

In this form definition "requirement" is the default map and two fields are being handled by the use of "parameters" map.
Please let me know if it is not clear.

2) Purpose of default-field-type="hidden" in auto-fields :
It is used to select only the fields required for our target service from the input map. If we get our data from a map other than the default, we specify it with map-name="otherMap". If you have anything in addition to it, please share with us.

Comment :
Yes you are right.
I think we can safely remove the use of default-field-type="hidden" from the AddJobPostingType & AddInterviewType form definition.
After searching its use in OFBiz source code I found that its been used extensively in lookup form and <auto-field-entity> tag except Humanres component.
It looks like that it improves the performance of search but can't say about it as I haven't had a chance to see this on bulky data.

I would like to say thanks to Pranay Pandey for discussing this point with me. As I haven't used this feature too much in past.

3) Removal of else part from all the service implementation except Create Job Requisition:
You have told us to get rid of the else part of all the service implementation except job requisition. In job requisition also we are not explicitly passing the job requisition id. So it would be better if we remove the else part from its implementation as well.

Comment :
Yes you are right. Please discard my comment on that. Actually the exclusion of "Type" entities was there in my mind(wrote the same thing in last of that comment) while completing that sentence. My mistake, apologies for that.

4) Instead of "Begins With" we should prefer "Contains" for searching:
You asked to use "Contains" as the default option instead of "Begins With". To accomplish this we will have to make changes in framework file i.e "HtmlFormRenderer.java". And, the same will be reflected everywhere in the OFBiz. We suggest it is better to use "Contains" as the default option because "Contains" covers "begins with". What do you suggest?

Comment :
No need to do any changes in the framework files. This has been discussed on the mailing list (as I remembered ... I can be wrong here) and its been decided to go with Begins_With default option. If you want to explicitly override the default behavior you can do so by the help of following line.

<field name="paymentId"><text-find default-option="contains" ignore-case="true"/></field>
For reference : https://localhost:8443/accounting/control/findPayments

Here are few best practices :

a) For the fields that are auto generated like Primary Key, in such case we should go with the lookup in the find screens. For Ex: It won't make any sense to search thousands of records by "Numbers". But if the Primary key is passed explicitly and the tables don't have too much records then we should use "Begins_With" option.

b) For the fields having "Type" entity reference we should provide the Combo box for the selection on the search / find screen.

c) For the fields that are referencing Name, Comments, Description & Notes, we should prefer the "Contains" default option.

I hope you can do the needful from my comments now on the use of default option for find screens.

Will wait for the updated patch :-).
Thanks Abhinav for your excellent work.

--
Ashish Vijaywargiya

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694952#action_12694952 ]

Abhinav Vaid commented on OFBIZ-2205:
-------------------------------------

Hi Ashish,

Thanks for all your comments and appreciation.

With respect to comment dated 24th March 09 it was suggested to use different approach for doing the same things instead of using ApproverAndCandidate, InterviweeAndInterviewer, PersonAndEmployeeActions view entities to solve our purpose, as they were created from two view-entities.

I would like to elaborate on the purpose of these view entities. As we are providing login functionality, so user (admin, employee and approver) can view the names of all the applying parties as well as their approver's. So for displaying their names in the search result, we had to create these view entities.

We have created one view entity (ApproverAndCandidate) from two view entities (CandidateAndPerson and ApproverAndPerson) as in our entity "EmploymentApp" we have two fields i.e. "applyingPartyId" and "approverId" which are both partyId's.
So for fetching first and last names of "applyingPartyId" we had to create one view (CandidateAndPerson) that will first fetch names for "applyingPartyId" from Person table and then another view (ApproverAndPerson) that will fetch names for "approverId" from the same Person table.

This is the reason why we had to create another view from these two views.

We understand your concern and here we suggest three Approaches that can be followed: -

Approach 1:
We can make both "approverId" and "applyingPartyId" as hyperlinks. They can be redirected to ViewProfile page. In this case all the view entities can be ignored and if anybody is interested in their details then he can click on the partyId and the same will be redirected to party detail page where he can see the first name and last name of the party.

Approach 2:
We display either approverId's first and last names or applyingPartyId's first and last names. In this case we will not require the third view entity that is created from two veiw entities.

Approach 3:
We display names of both approver and applying party. In this case we will require all the view entities that have created in our patch.

Kindly suggest us which approach to follow and also if there are some other alternative approaches for the same.

Regards
Abhinav Vaid
iLabs, L & T Infotech Ltd.
Mumbai.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696007#action_12696007 ]

Ashish Vijaywargiya commented on OFBIZ-2205:
--------------------------------------------

Hello Abhinav,

Let's go with the Approach 1:

For displaying the First Name and Last Name you can use the following code snippet. It will also provide you the link to navigate to the Profile page of the party.

<field name="partyId" widget-style="buttontext">
<display-entity entity-name="PartyNameView" description="${firstName} ${middleName} ${lastName} ${groupName}">
<sub-hyperlink target="/partymgr/control/viewprofile" target-type="inter-app" description="${partyId}" link-style="buttontext">
<parameter param-name="partyId" from-field="partyId"/>
</sub-hyperlink>
</display-entity>
</field>

If you want to see the contents on the GUI then take a look at the following link. And in this link add one record and see the "Party Id" column in the resultant screen in the bottom.

https://localhost:8443/workeffort/control/ListWorkEffortPartyAssigns?workEffortId=DEFAULT_ROUTING

--
Ashish Vijaywargiya

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Updated: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Abhinav Vaid updated OFBIZ-2205:
--------------------------------

Attachment: HR_Recruitment.patch

Hi Ashish

As per your suggestions we have made the changes and updated the patch. We are uploading the updated patch.

Kindly review and revert if any further changes are required.

Regards
Abhinav Vaid
iLabs, L&T Infotech Ltd.
Mumbai.

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700034#action_12700034 ]

Ashish Vijaywargiya commented on OFBIZ-2205:
--------------------------------------------

Hello Abhinav,

Thanks for your continue work on this.
I will review your patch on this weekend and will share my thoughts / comments.

Sorry for being little late but I was bit busy in last week so didn't get a chance to review your patch.

--
Ashish

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701460#action_12701460 ]

Abhinav Vaid commented on OFBIZ-2205:
-------------------------------------

Hi Ashish

Thanks for your appreciation.
Did you get any chance to look into the patch?
Hope to hear from you soon.

Regards
Abhinav Vaid
iLabs, L & T Infotech Ltd.
Mumbai.

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701470#action_12701470 ]

Ashish Vijaywargiya commented on OFBIZ-2205:
--------------------------------------------

Hello Abhinav,

Sorry, I didn't get a chance to review your patch on Sunday.
Will do it today after reaching to home in the evening.

Thanks for the reminder ... although it is there in my queue (and my notes remind me each day to review your patch :-) ).

--
Ashish

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Updated: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ashish Vijaywargiya updated OFBIZ-2205:
---------------------------------------

Attachment: HR_Recruitment.patch

Hello Abhinav,

Sorry, I was not able to come back on your patch early.
I have fixed few issues :

1) Changed <sequenced-id to <sequenced-id.
2) Removed the spaces present in the Id fields.(Job Interview was used for interviewTypeId, I changed it to JOB_INTERVW)
3) Removed the demoemployee record. As DemoEmployee was already exists OOTB. So I used that one in UserLogin entity.
4) Changed demoapprover to DemoApprover
5) Removed partyQualTypeId="PARTYQUAL_DEGREE" instead of this I have used existing type i.e "DEGREE".

Now I am done with your patch and improved it on above comments.
Will wait for other comments for a day or so then will commit your code if we don't see any comment from others.

Thanks !

--
Ashish Vijaywargiya

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703134#action_12703134 ]

Jacopo Cappellato commented on OFBIZ-2205:
------------------------------------------

Abhinav, Ashish,

thanks for your work and review, they are both very appreciated.

I would like to add mine comments after reviewing the data model part of this patch:

1) instead of "approverId" I would suggest "approverPartyId"; also, wouldn't be better to define the fk to the Party entity (instead of the Person entity)?
2) InterviewInformation:
2a) woudn't be better to name it just "Interview" or even better "JobInterview"? (but if we choose "JobInterview" then we shoudl add the job prefix to some of its fields for consistency)
2b) should gradeSecured, result be associated to the Enumeration entity (and renamed to gradeSecuredEnumId etc..)?
2c) intervieweeId and interviewerId should be intervieweePartyId and interviewerPartyId and associated to the Party entity (not Person entity)
3) Exam: I think we can use the Enumeration entity instead of a new entity; or at least we should rename it as "ExamType"
4) what is the purpose of the JobPostingType entity? sorry, I can't understand it from the context (in general, what is a "job posting"?)
5) EmployeeAction: I am not 100% sure about the meaning of this entity but maybe instead of it we could use the EmplPosition and EmplPositionFulfillment entities (I suspect that they model the same exact data)

Cheers,

Jacopo

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703137#action_12703137 ]

Ashish Vijaywargiya commented on OFBIZ-2205:
--------------------------------------------

Hello Jacopo,

Thanks for your comment on this.
I agree on all of them.

Hello Abhinav,

Can you please take the recent patch uploaded by me and start working on Jacopo's comment ?
Please ask question if you need help so that we all could discuss the things on the mailing list.

Thanks !

--
Ashish Vijaywargiya

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706388#action_12706388 ]

Ashish Vijaywargiya commented on OFBIZ-2205:
--------------------------------------------

Hello Abhinav,

Are you working on the points suggested by Jacopo ?

Didn't see any response from since long so was curious to know how is it going ?

--
Ashish

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706869#action_12706869 ]

Abhinav Vaid commented on OFBIZ-2205:
-------------------------------------

Hello Ashish,

We are now working on the 5th point related to "EmployeeAction" entity and fixed other comments as suggested by Jacopo dated 27/Apr/09.
We will upload the patch in few days.

Thanks & Regards
Abhinav Vaid
iLabs, L & T Infotech Ltd.
Mumbai.

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706913#action_12706913 ]

Ashish Vijaywargiya commented on OFBIZ-2205:
--------------------------------------------

Sounds good to me.
Looking forward to have updated patch from you soon.

--
Ashish Vijaywargiya

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707802#action_12707802 ]

Abhinav Vaid commented on OFBIZ-2205:
-------------------------------------

Hi Jacopo and Ashish,

Thanks Jacopo for your thoughts and comments on our patch.
We have considered all of your comments and made the changes accordingly. We are uploading the updated patch.

We would also like to mention that after having a look at enumeration entity we decided to remove the "exam" as well as the "JobPostingType" entities. As the functionality provided by these two entities can be achieved by using "Enumeration" entity.

Here is my comment on your 5th comment dated 27/Apr/09:

5) EmployeeAction: I am not 100% sure about the meaning of this entity but maybe instead of it we could use the EmplPosition and EmplPositionFulfillment entities (I suspect that they model the same exact data)

Comment :
As per Jacopo's suggestion we have implemented "Relocation" functionality by using
EmplPosition, EmplPositionFulfillment and EmplPositionReportingStruct entities instead of creating an entity "EmployeeAction".

Thanks & Regards
Abhinav Vaid
iLabs, L & T Infotech Ltd.
Mumbai.

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Updated: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708081#action_12708081 ]

Ashish Vijaywargiya commented on OFBIZ-2205:
--------------------------------------------

Hello Abhinav,

Thanks for the updated patch.
Lets see what community members has to say in next few days.

Very soon I will pick it and will commit it if everything looks good or close to me.

--
Ashish Vijaywargiya

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

[jira] Commented: (OFBIZ-2205) Implemented recruitment in HR module

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708400#action_12708400 ]

Aswath Satrasala commented on OFBIZ-2205:
-----------------------------------------

Hello Abhinav,
The HUMANRES_APPROVER securty group is create in the demo.xml file. But, I don't see it being used anywhere in other parts of the patch. How is it used and what is its use?

Thanks
-Aswath

> Implemented recruitment in HR module
> ------------------------------------
>
> Key: OFBIZ-2205
> URL: https://issues.apache.org/jira/browse/OFBIZ-2205
> Project: OFBiz
> Issue Type: New Feature
> Components: humanres
> Affects Versions: SVN trunk
> Environment: Windows XP Professional (5.1, Build 2600) Service Pack 2, Intel(R) Core(TM)2 CPU 4300 @ 1.80GHz (2 CPUs), 1014MB RAM, jdk1.5.0, apache-ant-1.7.0
> Reporter: Abhinav Vaid
> Assignee: Ashish Vijaywargiya
> Priority: Minor
> Fix For: SVN trunk
>
> Attachments: HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch, HR_Recruitment.patch
>
>
> In this patch we have included recruitment in the HR module.
> Recruitment performs tasks such as admin can create new job requisitions.
> He can update or delete new job requisitions.
> Now once the job requisition has been added, it is visible to all the employees.
> Then if interested employee wants to apply for the job requisition he sends it for approval to his superior.
> Superior from his login can check who all have applied for job requisition.
> He can update the status and same is reflected at employee's end.
> Here admin can also create new interview types and he can store the information of the diffrent interviews of employees.
> We have created Security groups:
> HUMANRES_APPROVER
> HUMANRES_EMPLOYEE
> We have created Security permissions:
> HUMANRES_APPROVE
> We have created Login Id's :
> demoadmin belongs to FULLADMIN security group
> demoapprover belongs to HUMANRES_APPROVER security group
> demoemployee belongs to HUMANRES_EMPLOYEE security group

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

123