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

CommentFileSizeAuthor
#19 translate_refresh__job_appln.PNG26.23 KBclashar
jobappln.zip17.31 KBNewZeal

Comments

clashar’s picture

Thank you very much!! it's exactly what I wanted to find

jolidog’s picture

Status: Active » Needs work

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

NewZeal’s picture

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.

clashar’s picture

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.

NewZeal’s picture

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.

mrgoltra’s picture

subscribing

NathanM’s picture

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.

NewZeal’s picture

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.

NathanM’s picture

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

mandclu’s picture

@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?

clashar’s picture

I also would like to see implementation for Location instead of Addresses

NewZeal’s picture

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.

NewZeal’s picture

I contacted Khalid. As you can see from his reply supplied by Nathan:

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.

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.

NewZeal’s picture

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.

NewZeal’s picture

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.

clashar’s picture

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

NewZeal’s picture

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.

clashar’s picture

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?

clashar’s picture

StatusFileSize
new26.23 KB

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.

NewZeal’s picture

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.

clashar’s picture

New Zeal, thanks for quick reply, I thought it belongs to your job_appln module

janacor’s picture

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,

NewZeal’s picture

Jobplus is being deprecated in favour of the Listing Module

clashar’s picture

there is also Drupal Recruit

clashar’s picture

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.

ramonoak’s picture

Hey @clashar can you give more hint's? I want to do this that you sugested but I can't figure how to do.

I have two content's, CV and job posting, but how can I creat a content that let me apply my CV to a job?

This gonna send my CV by email that I have added in the Job posted, how can do that?

Sorry for my bad english.

clashar’s picture

ramonoak,
to link one content type (for example Job Application) with 2 others (for example CV and Job Post) you need to use Node Reference module (for Drupal 6) or Entity Reference module (for Drupal 7) where one field links to CV content type and another to Job Post content type.
So that Job Application content type has two fields of Entity (Node) Reference, for example:
field_ref_cv
field_ref_jobpost

But I highly recommend to use this project: http://drupal.org/project/recruiter
it's ready out of box and seems to be very powerful solution for job board site.

ramonoak’s picture

I tried, but I can't use solr on my host. I'm happy building from scratch with drupal my page, I'm learned a lot from the last three months.

I gonna try Entity Reference module. Thanks for your attention.

clashar’s picture

ramonoak,
latest dev of Recruiter can work without solr just with standard Search API.

ramonoak’s picture

Every time I try to install Recruiter I get a error like that:

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: http://localhost/recruiter/install.php?profile=recruiter&locale=en&id=1&... StatusText: Internal Server Error ResponseText: 500 Internal Server Error Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, webmaster@oakz.org and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

But I can continue the install.

clashar’s picture

ramonoak,
you need to open separate issue on the recruiter project page.

clashar’s picture

Issue summary: View changes

Module discontinued

xamount’s picture

Issue summary: View changes
Status: Needs work » Closed (won't fix)

I am closing this issue as its seems to be ported to another module and not the jobsearch module.