| Project: | Job Search |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
As discussed, attached is a module that works with the job module to turn applications into nodes. It comes with a number of views handlers and some default views. The uid of the application node is assigned to the job creator and not the person who made the application. This means that the job creator can view all applications made to his/her jobs and the applicant can no longer change their application, which is how it normally happens in the real world. With applications as nodes then the applications for jobs can be manipulated using views. This would provide a solution to many of the feature requests being made.
In order to make this work you will need to run a small patch, which adds a link to node_view and also runs a script on job/apply. My suggestion is that some kind of module_implements might come in handy at both those locations in order to hook new modules into the fray.
Uploading to the community for testing.
Edit: Note that his module is now deprecated in favour of the Listing Module
| Attachment | Size |
|---|---|
| jobappln.zip | 17.31 KB |
Comments
#1
Thank you very much!! it's exactly what I wanted to find
#2
Hello,
I've been testing this module, I like the idea, it makes perfect sense.
On a first look, the content that is created has the following fields:
Title
Brief Statement
Application
Status
Comments
Regarding the Brief Statement, from what I can understand is a field that is supposed to be filled by the applicant, but they never get to fill it out, because the node is automatically created and assigned to the job creator. So it's existence is not relevant, at least for now.
Regarding the Application (body field), the module creates a link to the user and then dumps the complete user profile. It's a good idea it means fewer clicks to reach the user profile, but I don't think it's a good implementation.
There is already a dependency on the content module, so why not depend also on user reference module and link to the user, would it be possible?
From what I understand this way it would be cck responsible for creating the db table connecting the applicant > job < job creator.
If this is something that might be considered, then the Comments field could be the body field.
The end result would be:
Title
Comments (body field)
Status (text field with allowed values on php code)
Applicant (user reference)
So this module could be more of a glue code, type of module. Perhaps also easier to maintain?
Another thing I noticed and it's easy to correct, the allowed values, should be php code like so:
return array('1' => t('Pending'),
'2' => t('Hold'),
'3' => t('Short list'),
'4' => t('Accept'),
'5' => t('Reject'),
);
This way, they can be translated.
Anyway, it's looking good! Hope to see it on beta somewhere soon :D
#3
I've added this module to the jobplus module: http://drupal.org/project/jobplus and have made your changes regarding translation.
Regarding the other suggestions, the whole point of putting the whole resume into the body field is to mimic what happens in the real world when you apply for a job. You send off your resume and that is it, you can't change it. With the jobsearch module as it currently is, you can change your resume and the potential employer will see the changes when they link to it. This results in potentially out of control job management, whereby you change a resume for an employer and forget that you have sent the link to that resume to another employer.
The brief statement field is one I have yet to nominate a place for but the applicant will get a chance to enter some leading text, as if in a letter to precede their resume.
The comments field is then for the employer to make notes in during the decision making process.
#4
Whether jobappln module will still be available without jobplus module?
I am wondering, cause I use jobappln without jobplus and don't plan yet to activate jobplus.
#5
We can move the jobappln module somewhere else later but at this point I'd prefer to fix bugs via the CVS rather than attach as zip files to comments. The jobappln module is independent of jobplus so you can download the jobplus module and just use the jobappln module.
#6
subscribing
#7
To what degree are the Job Plus and Job Search people working together on this project? Is this planned to be permanently worked into the job search module, perhaps as a 2.x branch distinct from the current branch? I'd like to use this, but I don't want to get into a situation where I need to continually apply patches to upgrades in order to keep it working.
#8
You might like to apply your request to the maintainer of the job module. I've emailed a number of times and to no avail. That is largely why I added this module to the jobplus package, even though it probably belongs here. Good luck.
#9
Who did you contact? I got a response in about 5 minutes:
On Wed, Oct 13, 2010 at 8:33 PM, wrote:
Hi,
I've been using job search for about 6 months ago to set up my site, (which I'm still getting ready to launch). I recently noticed the job application module, which allows individual applications to be used as nodes, and thought it would be a good idea. However, I noticed that job search needs to be patched in order for it to work. And so I was wondering if there are any plans to integrate this into the job search module, perhaps as a separate branch, (1.x for the current application process, 2.x for the node application process)? I'd like to use this, but I don't want to get into a situation where I need to continually apply patches to upgrades in order to keep it working.
Best Regards,
Nathan Mittelstaedt
Features get in when they meet certain criteria.
Testing by other people is one of them, to confirm they are working.
Making sure that they do not break something else is another.
Backwards compatibility and being optional also helps.
So test it and see if it does what you want. If you are happy with it, reply in the
relevant issue pointing out the exact patch you tested, and the outcome. If you
had to modify the patch, then attach the new version, and explain what changed.
--
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra
Simplicity is the ultimate sophistication. -- Leonardo da Vinci
#10
@New Zeal - who did you email? There are four maintainers, and I know kbahey maintains quite a number of modules and may not be your best place to begin.
I'd certainly be interested in discussing how to merge the two projects. I think the community would be served better by a single project that combines the best of both. I have to confess I'm not familiar with Job Plus. Can you give me a quick rundown on how you see it as different from what Job Search currently offers?
One question I have: why use Addresses instead of Location?
#11
I also would like to see implementation for Location instead of Addresses
#12
JobPlus is jobsearch and more. Jobsearch is a relatively simple module that just creates some functionality around a content type or types which are selected as job types. JobPlus adds to this with location and category search. The category search is of a particular kind using advanced taxonomy menu. JobPlus works without the advanced taxonomy and you can use any other taxonomy search you wish instead. JobPlus, in conjunction with Adv_taxonomy_menu creates a contextual breadcrumb. JobPlus is intended to be a complete install package.
I have developed a dynamic category display which only displays links to jobs available within a given country or state / province and there are other features to come.
When I developed jobplus I used addresses because that was the best choice at the time (Drupal 5). Also, most employers do not really want to have a google map of their business location so I would stick with this implementation. Jobsearch uses location so maybe people could use it if they are keen to use the location module.
#13
I contacted Khalid. As you can see from his reply supplied by Nathan:
I got a similar reply which is why the module is now with jobplus.
So it is really up to you guys. It's out of my hands really. Sorry.
#14
What I suggest is as follows:
jobsearch maintainers create a hook in the job module. Let's call it hook_job_appln. This does a module_invoke on any hook_job_appln functions enabling site admin to select one from admin/settings/jobsearch. If such a hook is selected then the modulename_job_appln function is run instead of the job module application code. If no hook is selected then the job module code is run.
This is different to the code that I have in my patch which is jobappln module specific.
The jobappln module is completely optional so adding it to the jobsearch project will not automaticaly break anything. Having said that, people do need to test it and find out what bugs there are. So, if you guys want this module in jobsearch, then keep testing and post issues either here or at jobplus. I am currently not testing it a great deal myself but will be soon.
#15
I am currently working on a job board where the client has requested that anonymous users be able to apply for jobs. With the current job module that is not possible but with the jobappln it is provided that the applicants supply their address details. While we wait for the catch22 situation regarding acceptance of the jobappln module into the jobsearch project to resolve itself, I am going to add a hook_link function to the jobappln to replace the job module implementation of the job apply link and in the process hide the old job apply link. This will mean that the jobappln module will no longer need a patch and the drupal community can look forward to job applications being handled in any way that they request.
#16
New Zeal, could you please say what normal permissions should be for jobseeker and employer for following fields:
view
field_jobappln_brief
field_jobappln_comments
field_jobappln_status
edit
field_jobappln_brief
field_jobappln_comments
field_jobappln_status
#17
There is no need at this time to apply field permissions. When the applicant creates the job application they are not presented with a form to fill, but instead, their application is created programmatically and the content of their resume is entered into the body field of the job application. The fields you mention above are the current default fields of jobappln. Since these are CCK fields you can do what you like with them, although the status field probably needs to be kept since this is intended to be used to filter the applicant using views and slowly weed out the best applicant. The brief field is a field I was intending to use to enable the applicant to add a kind of covering letter to the application but that is not implemented yet. The comments field is simply there for the recruiter to take notes.
#18
New Zeal,
thanks for explanation, ok, I just would not change these permissions.
I would like to see very much brief field implementation for covering letter, as it is very useful and widely used.
Do you have any approximate plans for implementing it?
Got another question for: "create", "edit", "delete any", "delete own" of "jobappln content", is it the same thing, everything is automatically and no need to change it?
#19
New Zeal,
when I do translate refresh for i18n, there is a notice message block:
* The string block:1:body for textgroup blocks is not allowed for translation because of its input format.
* The string job_applications:default:empty for textgroup views is not allowed for translation because of its input format.
* The string my_applications:default:empty for textgroup views is not allowed for translation because of its input format.
* The string seeker_applications:default:empty for textgroup views is not allowed for translation because of its input format.
I don't know what are these strings exactly and I am wondering if they should be translatable.
Please see screenshot.
#20
Clashar, those strings all belong to the jobsearch module and not jobappln and they refer to view names. I'm not sure if you really need to translate those and if you do you might encounter problems.
#21
New Zeal, thanks for quick reply, I thought it belongs to your job_appln module
#22
Hi,
I try to implement in the site but I've looked for a easy document to work with this module (job search & jobplus) but I no found any articles or guide.
Anybody knows about a document or guide to implement this module ??
thanks,
#23
Jobplus is being deprecated in favour of the Listing Module
#24
there is also Drupal Recruit
#25
And another way is just to create content types:
1. job posting
2. cv
3. application
And in "application" we could create two node reference fields referring to cv and job posting.
So no specific job modules would be required.