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

["Abhinav Vaid (JIRA)" <ji...@apache.org>]

    [ 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.


> 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.