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