Provide a job application workflow

Currently there is no such feature, we plan to add it to the distribution at some point though.

No news for the apply now button ?

Marked #1334314: Where is the apply for this option? as duplicate.

how about a location field in the search ?

@elwood, this seems unrelated to this issue, please open a new one.

This could be handled with the flag module and rules.

Check out the video tutorials from Itangalo@NodeOne at http://dev.nodeone.se/sv/node/875 for the Flag module if you are not familiar with it.

@#6,That is what I am planning to do,But then i am struck with the next step, how to administer the next process for an internal job board. just seeking inputs...

Not sure I get what you mean with internal job board and adminster it?

WIth flag, you can use rules to send message when someone allies, make a view of all applications etc.

I categorize the job posting and applying in to two categories
1. Job posting by recruiter - and applicants will send the applications along with resume to the recruiter directly to his email
2.The applicant applies to a job i.e merely "flags" the job that "I am interested",
then recruiter views the list of applicants who flagged "I am interested",(generates a VBO candidate list), which has the necessary data to see and "select" applicants from the list, "check marks" to bulk shortlist,.....

Just wanted to strongly endorse the desire to see that this feature is added as soon as possible. Any word of its future?

I'd like to move to eRecruiter and out of a "homegrown" solution using php and filemaker, but I can't even consider it as an option until applicants can apply for specific vacancies using the system.

Thanks so much for creating this solution! I look forward to future improvements!

hi jefferytrouse - this would definitely be a desired feature.

as drupal & eRecruiter are open source and an application workflow is not on our (epiqo) agenda, we would encourage you / others from the community to contribute such feature and can provide guidance and feedback on the approach.

see related #1336220: Add messaging so applicants can attach resumes to contact employers.

I just want to add to the discussion on this topic, as we're keen to use Drupal for an update of our job board which is currently on an open source job board system.

It amazes me that this whole distribution has been planned and developed without any job application functionality, as that is one of the only things that makes it a recruitment platform.

"Through a job website a prospective employee can locate and fill out a job application or submit resumes over the Internet for the advertised position."
Source: http://en.wikipedia.org/wiki/Job_board

Please don't take this the wrong way, as what you're doing is great, but without it, isn't this just a Drupal installation with relevantly titled content types and user roles, and some suitable search/subscribe modules?

There's a few routes that we're looking at for applications, with the following requirements;

Applicants - Allow to apply for jobs, either using CV on file or providing upload, along with covering letter and notes. Area to view current applications and deny from applying for the same job twice.

Recruiter - View applications for jobs posted. Be notified of every applications.

One of the ways that we're trying this at the moment is with Node Hierarchy in the following way;

• We create a child node type of 'Application' to job nodes.
• Create an 'apply' button to job nodes linking to 'node/add/application&parent=[nid]&parentname=TestJob
• CV upload field can default to pull resume from profile or applicant can upload specific one for this job
• User submits application, gets redirect to job node with message. User's then unable to create another 'application node' for that job type and the button changes.
• Recruiter gets email via rule informing them of the application, attaching the CV to the email.
• Both recruiter and applicant have views showing them their applications sent or received.
• 'Applications' field added to recruiter's jobs view, with a number of applications, linking to view of applications nodes attached to that job node.

We'll hope to have a working example live in the next few weeks, and hopefully something like this, or another idea, could be implemented into the distribution at some point.

Do we have an "apply" button? I was seriously not aware about this! but still keeps me up...
If anyone can guide me over i can try doing this in meanwhile on the time!

Cheers

Can we make it a major issue? i think this workflow is a much more needed feature to lift the distro!

No, there is no application function with Recruiter.

Coincidentally, we've achieved what I proposed in #13, and it's gone live today.

PM me if you'd like to find out more about how we achieved it, as I feel that this might be getting off the topic.

We will also be submitting it to the community showcase, as there isn't many (any?!) examples of job boards being built. We've achieved a fully functional platform from a fresh D7 installation, with just 32 modules and 320 lines in a custom module in 10 days.

inboxed yoU!

ad #15: adam wood, we would love to be reading about your showcase and maybe add it to the Websites using Recruiter section on http://drupal.org/project/recruiter !

as the API for Recruiter should be very stable since RC1 being released, we would be glad to see custom additions being contributed by the community. feel free to contact me in that matter or use the issue queue.

also, we just relaunched http://drupaljobs.epiqo.com/ and contributed foundational theming components to omega 4 (see http://epiqo.com/en/drupaljobs-responsively-relaunches-recruiter-rc1-and...).

Since I've had so much interest in this and people enquiring as to how it works on the front-end, I've created a white-label demo site of what we've done.

NOTE: Once again, this is not using Recruiter in any way. We ended up building this from scratch as it was easier than moulding Recruiter to what we needed, however I feel that the functionality could be added into this or other job distributions quite easily with a few modules and views, if it's of interest. I should also note, as it's great that you're using Omega, that this is a fully adaptive site running on Adaptive Theme.

Feel free to:

• Apply for jobs; you'll have to create a job seeker account, upload a CV in Edit Account|Job Seeker and find a job to apply to.
• Register as a recruiter and post a job; under My Account|Manage Jobs|Post Job.
• Ideally: Create your own jobs and apply for them to see the whole process and not be sending applications to people who've posted test jobs.

Main application features:

Job Seekers: CV Upload on profile, 'My Applications' tab on profile, using stored CVs at application, email confirmation of applications and can't apply for the same job twice (you technically can, but the option isn't visible).

Recruiters: Receive email notifications of applications with CV attached, track applications via tab on job page and profile, manage jobs with a application count (linked to list of applications).

This site is a bit behind our current live version, so you will see some errors (mainly around users), untidy parts and permission issues, however nothing critical.

Please note that the site is on a daily reset and we're not responsible for the content of it or any applications that you received if you chose to post a job. Stick to Lipsum or example jobs from elsewhere if you wish to post a job.

Job Board Demo

If this feature is of interest to the maintainers of this or other profiles, I'd be happy to discuss the easiest way to integrate it and provide the steps to achieve this. I don't however have the time currently to maintain anything.

There's a PDO exception in this one, however Adam, are you planning this as a distro of its own into drupal?

Sorry, the demonstration reset was playing up... Try it again.

As I said in my previous post, I think this would be better added into the existing Job Board distros rather than adding another one.

@ADAM i tried downloading DROPJOBS and installing, this even failed, can we talk to merging DropJobs with ERecruiter?

Hi madrahul,

I, nor this example, are anything to do with Drop Jobs. This is simply an example of a job application function on a Drupal 7 site, that could be implemented into Recruiter or Drop Jobs.

Oh i just thought you are the maintainer for dropjobs

We're currently planing a simple job application workflow that will probably implemented this way:

• New content type: job_application
• Fields: title, body, node reference to job (with entity reference module) (others can add additional fields)
• Application Node Access: applicants with a complete resume can add and view own applications, author of referenced job can view application as well (content access module)
• Resume Access: author of referenced job gains access to the private information of the resume
• An email notification is sent to the author of the job when a new application has been added (with Rules)
• Views listing for the applicant (my applications), the recruiter (incoming applications) and the site admin (all applications)
• Write new application page: either with Page Manger + Context Admin + some variants or custom callback that takes the the job node nid from the URL and directly fills the entity reference. Additionally we can add links for writing an application to the job search and the job view page.
• (optional) Comment module can be used by recruiter / applicant for further communication

I have been playing around with the following workflow:

- User flags a job that is available for online application
- User is redirected to node/add/application (Node reference URL widget with title and body only).
- At the same time (triggered by the flag, a PDF is saved on the server)
- User fills in the cover letter and saves/sends
- When user clicks save, the node/application (cover letter) is sent with the PDF in an email to the owner of the job posting.

I think you can also use only Node reference URL (http://drupal.org/project/nodereference_url)

sorry for double post.

iRex,

We've implemented exactly what you describe in #27.

I suggest you read my post #18 and visit that test site, create a recruiter account, post a job, then create a jobseeker account and apply for it, and then try to apply again.

If it fits what you want to do, I'll post the exact instructions and code to achieve it.

Adam

@hanspln

At the same time (triggered by the flag, a PDF is saved on the server)

PDF of what? user filled resume? or user uploaded resume?
If so, can you please share how that is achieved?

to provide an "apply for job" link there are many modules,
The problem is to remove the link after the applicant has applied
Other things are easy i.e creating various views

As there seems to be enough people looking for this 'Applied button that changes/disappears' function, this is how we've achieve it and it's working perfectly.

Note: You may have to change parts of this depending on your configuration (most important is that the 'child node' type is called 'application' - or you can change it to your content type name). It is designed to work using node hierarchy to create child (applications) of job nodes, as I explained in #18. When a logged-in user hasn't applied for a job, it will create an 'apply' button linking to the application page, once they've applied, it changed to a non-linked button, showing 'Applied'. It basically checks the DB to see if that user has create a child node for that parent node.

Once again, this wasn't done using Recruiter, and you will have to set the rest of the application function up as mentioned above before this will work.

Code on our job node page (node--job.tpl.php)

<?php 
    $children = _nodehierarchy_get_children_menu_links($node->nid);
    $hasapplication = false;
    foreach ($children as $child) {
      $childnode = node_load($child['nid']);
      //drupal_set_message('<pre>' . print_r($childnode, true) . '</pre>');
      if ($childnode->uid == $GLOBALS['user']->uid) {
        $hasapplication = true;
      }
    }
    if ($hasapplication):
  ?>
    <div id="applied-button">
      Applied
    </div>
  <?php else: ?>
    <div id="apply-button">
      <a href="/node/add/application?destination=node/<?php print $node->nid; ?>&parent=<?php print $node->nid; ?>&parentname=<?php print $node->title; ?>" rel="nofollow">Apply</a>
    </div>
  <?php endif; ?>

Hopefully this will give people ideas about how they can achieve it. This doesn't require any external modules, other than Node Hierarchy, to work.

Adam

An alternative to the custom content type + node access is private message. We'll evaluate it to see if it's of help for this use case.

Whilst an option, I see many unnecessary challenges with that approach. These include:

• Attributing the application (private message) to the job node permanently - this has knock-on issues, such as being able to display the number of applications for a job in the recruiter's 'my jobs' section, if you want this.
• Attaching content to the messages and then subsequently the email notification (i.e. CVs), pulled from jobseeker profiles
• Creating displays (views) for both users. I.e. For recruiters: Seeing applications just for each job, For jobseekers: Seeing which jobs they've applied for and removing the ability for them to apply twice.

It seems to create more problems that it solves.

Core, Rules and Node Hierarchy can achieve this relatively easily.

Out of interest, mh86, how do you handle applications on your paid version of Recruiter?

Thanks for the feedback, Adam.

Private Messages are fieldable entities as well, hence I don't think it would be difficult to implement. Nevertheless, I've never used Privatemsg so far, so you are maybe right.

Concerning our paid version, we don't have a general solution yet. Requirements are often very specific and differ from one portal to the other. And what we've seen on recruiting sites the last years is that applicants prefer direct email applications anyway.

I have been playing with this and a combination of the suggestions above ie #25 with the addition of @adam's suggestion and code snippet and it is looking very promising. Additionally, I believe a number of different and flexible application mechanisms are probably required. Many recruiters (both agency & company) now require applications to be sent directly to their applicant tracking systems and services such as Broadbean have a requirement to have this option enabled on jobs boards they deal with.

This means that in addition to offering an "on-site" application mechanism - most jobs boards also require the ability to hand this off on a job by job basis.

Also, many candidates will want to use different versions of their CV (customised to the particular job) so I have been experimenting with storing the CV's in a directory customised to each user eg. /files/user-id/filename.ext using the File (Field) Paths module - and then using the File Field Sources module (with a custom version of the attach.inc) to give the user the ability to either upload a new CV or select an existing file stored in their attachments. This is not complete yet, but it does seem promising.

Hi finmccarthy,

There's a few things which you've mentioned that we've been playing with - I'm glad someone else is looking at the more advanced sides of modern job boards too!

Having been a recruiter, recruited staff directly and have used online job boards as a candidate, I've got quite a few ideas which I thing people would find useful, but I don't think this thread is the best place for them. We've already setup external XML feeds from Drupal to services such as job aggregators an can also accept incoming job postings via one of the main job posting distribution services, which a lot of the large recruiters use to save time. PM me if you'd like to discuss them. They could possibly be suited to a sub-module for Recruiter.

In regards to your multiple CV system, it sounds pretty similar to what we've done. If you play with the demo in #18 and register as a jobseeker, you can then upload multiple CVs to your profile (with descriptions), and then they are available to you when you apply for any of the jobs (feel free to).

We've achieved that just with a file field on their profile, mixed with the Media module to select the CVs when creating an application node. We had to modify Media to only allow users to see their own CVs (solved/covered in #1701614: Only allow users to see/select their own media from library) that they had uploaded to their CV field (and remove them from selection when they removed them from their profile!).

We're still ironing out a few issues, but its working well at the moment. I'd be interested in hearing how you get on with attach.inc.

@kaizerking:
With views PDF and Views Field, I have done the following:

Created one view called CV Master, then one View for each of the field collections (Personal, Experience etc)

On the field collection views, I use fields and also combine each of them and rewrite them in one field with a
tag.

The master field looks like this:

Name
Header of field collection (global text field)
View of field collection (added with View:include), this is just a master view from profile/user

repeat with all views

I control the headers and fonts etc with the settings of the Views pdf

you mean we can dynamically generate the pdf profile is it correct?
if so I wonder how it works work experience field collection, where the no of experiences aren't constant for users.i.e if we have some 10 work experience field collection items then it will become a multiple page document, so the template remains the same. how that works is my question
I have been searching for this for so many weeks(months). What I tried view PDf where we need to create a template. But thought was only a static.
I will try now, come back if i need more help.If you don't mind:) . I know angels are hard to find but never thought it would take so long.
EDIT; there are so many modules with the name views field could you please share the link for view field module

@kaizerking
Both modules are included here: http://drupal.org/project/views_pdf

I found it easier to place the items on the pdf if I made the header global text and format it with views pdf.

There are no empty rules on the headers, so they will print even if the included view is empty.
Most of the included views will have to be moved up by -15 in the pdf settings. Write them "from last position"

Simplest way to create Application feature
Required modules:1.rules link 2entity reference pre-populate,3flag

1.Create flag :Not applied, unflag :applied
Set allowed /not allowed for applicant and admin(for you to test)
set display options to none(we don't want the link should appear any where, we will set the flag using rules from back end

2. Create content type application
3.create job_reference field as entity reference field check pre-populate set hidden (field permissions module)

4. Create a rules link job apply, give link text "apply"
Set rules link rules and conditions for the link should appear on the job node
ex:user has roles->site:current user, content type is select all job types in recruiter
condition flag node , of your job content types check negative(this will make sure that the link only appears on the jobs user has not applied
set reaction: to page redirect: here you enter the url as given in the entity reference pre-populate it will be like : node/add/application?job_reference=[node:nid]
5.go to rules not rules link create new rule after saving a new content , and set other parameters like user has roles, and the content is of type application, in reaction rules select the 'flag node'
select flag ,in the flag to be set data find the field node:field-job-reference then set flag on behalf of 'current user'
hint:when ever you are selecting user roles select Admin along with applicant and set "any" in the bottom select box this will facilitate you to test your work flow in one go

Now go and test you workflow you don't need to hack any thing enjoy :)

Short update:
I've started to work on this feature. As a first step, a rework of the access system for private resume fields was necessary. By default recruiter users do not see the personal information and the attachments of the resume (an anonymous variant), but if an applicant applies for a job, this information should become visible to the owner of the job.
Previously we've used the Profile2's private field settings, which cannot be altered (a field always stayed private). So I've removed that and added an own field access system with hooks. Other modules (like later the application feature) can now easily define who has access to the private information of a resume. Furthermore the definition of private fields can be altered as well. All of this has been documented in the recruiter_resume.api.php file, and it will become clearer with the application feature implementation.

Next step will be the creation of the content type + implementation of the access system (node + resume), but it may take a while until I can continue here.

please keep scope for work flow to determine the eligibility to view a job or to view a resume.
I am trying to do is, Applicant applies for job->recruiter can see only a snapshot(job preferences) and then shortlist the application, on short listing status of the application the applicant can see the organization details, if still he is interested he will "accept' .on accepting then only the recruiter can see the complete resume.
I am using a "status" in application node to change the work flow status of application process, using rules link.
Even if you are not implementing this please leave flexibility for this.

In order to keep you up-to-date, I post some implementation plans. Me and Sebastian (sepgil) will mainly work on the feature and try to keep you informed about our decisions. Some of the points are still in discussion and might be realized in a different way, or left out.

• New module "recruiter_job_application". It is optional and it won't be enabled by default (maybe later).
• Additional module dependencies: Page Manager, Context Admin (Dev Version), Content Access, Message
• Content type "job_application", additional fields: "job_application_job_ref" entity reference field
• Page Manager page "job_application_add" (node/%nid/apply, local action?!) with 3 variants:
  • 1. Current user is not an applicant: display message that he has to login as applicant, and show login block
  • 2. Current user is applicant, but profile is not completed (patch from http://drupal.org/node/1011370 required for profile relation): show information that the resume needs to be completed first
  • 3. Applicant has visible resume: show node form and pre-populate job reference field
• After the application node has been inserted, send an email to the owner of the job, cc the application email address and inform him about the new incoming application and link to it (with Rules)
• Content Access: Grant job owner (recruiter user) view access to the application node (with Rules)
• Application node view: Display applicant's real name (from profile) instead of the user name. Hide name if resume is not visible any more.
• API functions: job application exists for certain applicant and job, job application exists for certain applicant and recruiter user (+ maybe Rules conditions)
• Hooks: Implement hook_recruiter_resume_private_fields_view_access() to grant recruiters with applications access to the private field, and hook_recruiter_resume_private_fields_info_text_alter() to tell applicants their private information is going to be visible for recruiters the applicant applied to.
• Rules Link for sending an application (redirects user to application page and checks whether the applicant has already sent an application). This link needs to be integrated in the standard job search.
• Views: My applications (applicant) 'applicant/applications', Incoming applications (recruiter) 'recruiter/applications'
• Message Log: [applicant:real-name] has sent you a new application [node:title].
• Resume profile view: Add information for the recruiter that the applicant has sent an application.
• Comments: (optional) if it should be possible that the applicant and recruiter exchange further information via the system
• Workflows: (optional) Flags can be added so that recruiters can track the application

Reasons to not use Private Message for the job application workflow:

• An application is job related, thus a job reference field would be necessary on the private message type. Each answer to the application message would again have the job reference field, which does not make any sense.
• By default only one private message bundle exists, other bundles would have to be implemented in code.
• Complex handling of the recipient field for our use case: recruiters are not allowed to write to applicants without previously receiving an application, the recipient field would need to be hidden, or an real name for recruiters (the company name?!) and applicants (from profile, but private info) would be necessary
• Private message module can still make sense for communication between recruiters and applicant

Hi mh86,

That all sounds good.

Are you intending on including CVs with this? From the look of how your architecting this, it should be easy to add it as a field to the jobseeker profile and attach it/pre-fill it to the application?

I agree about Private Mesage: by attaching the content type 'application' to the job node, it gives us more options for working with them, also, I don't think there is a need for communication between recruiters/applications. This isn't a normal feature of a job board, as a recruiter doesn't want any direct communication with an applicant, beyond their application. If they are suitable for the role, they'll be contacted directly.

We are not planing to attach a CV, but it should be easy for site builders to implement it (as you said).
When looking at this thread, many have slightly different needs for an application feature, so we'll try to implement the basics and to make it extensible.

Neither recruiter nor the applicant should be able to share the their important information without specific consent.to attaching a resume like word document ,is some thing I feel doesn't fit, what is the purpose of resume, we are building?
My view of the work flow should be
1. Applicant registers
2.fills in the resume
3. recruiter posts job
job is only available to be searched:
1. if all the required information is provided- this is mandatory like organization, job type, joining time, location for recruiters the organization name is private info.
2. Job is published,.
3. the job is current ( so far there is nothing in this direction there should be some job scheduling available which will expire the job on conditions this prevents the recruiter of posting URGENT jobs which are not actually urgent.also a prevent old jobs which are no longer available unknowingly applicants will apply for non-current jobs
4.Each step after application posted should have concurrence of the follower to release the next level of the private/important information.
5. The full end to end recruitment process should be mapped . I think that is the purpose of job board, if that is not the purpose then simply a job posting with recruiters email id is sufficient and user simply applies with an word doc cv attached.
yes there are conditions when a recruiter posts a job and he/she is not the actual employer. but just a resume puller for remuneration , in that case the recruiter should able to forward the resume,in which case he/she needs to attach the resume. for that a resume generating function should be used like views pdf.

A job cannot be deleted if at least one application pending against the job, to delete the job first un publish, then close the job, then delete

An applicant cannot hide the resume to that particular recruiter when there is an application pending.if he wants to hide the resume first the applicant need to withdraw the application then he can hide. the process can be made renewable means if he withdraws an application again the applicant apply but there will be a warning indication that he withdrew an a earlier application.i.e is if there is any document pending with reference to the other the doccument cannot be revoked.

Hi Venkata,

I think your idea of an application workflow is similar to what we're implementing, except that it has specific workflows and constraints, that need to be implemented by yourself.

1. if all the required information is provided- this is mandatory like organization, job type, joining time, location for recruiters the organization name is private info.

Just make the job fields required.

3. the job is current ( so far there is nothing in this direction there should be some job scheduling available which will expire the job on conditions

You can use the Rules scheduling system.

A job cannot be deleted if at least one application pending against the job, to delete the job first un publish, then close the job, then delete

I don't think we have to implement this. If a job is deleted (most of the time the workflow state is set to unpublished), then the application would just loose it's relation to the specific job.

An applicant cannot hide the resume to that particular recruiter when there is an application pending

I think we should also leave the option for the applicant to just hide the resume. But still, I'm sure there are ways to implement it.

Well here is the job application feature that I've implemented. I have added all features except for two optionals. Please test it out and give me feedback.

here is the patch...

Sorry I'm having trouble with my network connection. But here at least is the patch:

#52 panles is dependency it seems,

Fatal error: Class 'panels_display' not found in C:\xampp\htdocs\recruiter\profiles\recruiter\modules\recruiter_features\recruiter_job_application\recruiter_job_application.pages_default.inc on line 109

Hey Sebastian,

thanks for posting the patch. I'll do some testing soon. Here are a few comments concerning the code.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,121 @@
+    $profile = profile2_load_by_user($variables['uid'], 'resume');
+    if ($profile->field_resume_state[$variables['language']][0]['value'] == t('visible')) {

First check if the profile exists, then use recruiter_resume_get_state($profile) to get the state and directly compare it to 'visible' (not t()).

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,121 @@
+      $personal_info_field = field_collection_item_load($profile->field_resume_personal_info[$variables['language']][0]['value']);
+      $first_name = $personal_info_field->field_resume_firstname[$variables['language']][0]['value'];
+      $last_name = $personal_info_field->field_resume_lastname[$variables['language']][0]['value'];

Entity metadata wrappers are of great help for such cases, but you can also leave it that way.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,121 @@
+      $link = l(check_plain("$first_name $last_name"), 'resume/' . $variables['uid']);

The l() function will check plain the name for you.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,121 @@
+    $query->propertyCondition('uid', $user->uid, '=');
+    $query->fieldCondition('field_job_application_job_ref', 'target_id', $job, '=');

As far as I know, '=' is the default operator.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,121 @@
+  if (!in_array('recruiter', $account->roles)) {
+    return FALSE;
+  }
+
+  $applications = recruiter_job_application_for_recruiter($profile->uid, $account->uid);
+  return  !empty($applications);

Please do not return FALSE in case the application feature can't decide. Just return TRUE if access should be given.

+++ b/recruiter_job_application/recruiter_job_application.info
@@ -0,0 +1,49 @@
+name = recruiter_job_application
+core = 7.x
+package = Features
+php = 5.2.4

And change the package to Recruiter, adapt the name and add a description (you can take a look at other recruiter features).

+ as kaizerking noted in #53, panels is missing as dependency

Thx for the quick reply. Here is the corrected patch.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,121 @@
+  if (empty($applications[$applicant->uid][$job])) {
+    $query = new EntityFieldQuery();
+    $query->entityCondition('entity_type', 'node');
+    $query->propertyCondition('uid', $user->uid, '=');
+    $query->fieldCondition('field_job_application_job_ref', 'target_id', $job, '=');
+    $query_result = $query->execute();
+
+    if (empty($query_result)) {
+      return $query_result;
+    }
+
+    $applications[$applicant->uid][$job] = node_load_multiple(array_keys($query_result['node']));
+  }

If the user has no applications, the static $applications variable is never initialized and the query will run on every function call. Furthermore only check if the array is set for the applicant, not for a specific job.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,121 @@
+  return $applications[$applicant->uid][$job];

The variable might be empty, please check it return NULL in case it is empty.

Both applies for recruiter_job_application_for_recruiter() as well.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,121 @@
+    $query = db_select('field_revision_field_job_application_job_ref', 'jr');

Is there any special reason to use the revisions table? I would recommend to use the 'normal' one, as it only contains the latest entries.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,121 @@
+    $applications[$applicant->uid][$recruiter->uid] = $query->execute()->fetchCol();

In this case we are going to return a list of node ids, not node objects, as the documentation says.
I'm fine with node ids, as it is faster, but we should make both functions and the documentation consistent.

Interdiff from #56 looks good. I'll come back with some more feedback after some testing.

+++ b/recruiter_job_application/recruiter_job_application.views_default.inc
@@ -0,0 +1,387 @@
+  $handler->display->display_options['menu']['name'] = 'menu-recruiter-menu';

Both views depend on a menu that does not exist in the default Recruiter.

We have resume administration, job administration, We don't have application administration,
may this should be included in this sprint

yep, good point. application administration is still missing.

Another point: the permissions for the rules link do not seem to be exported yet

Added those requests to the latest patch.

Added those requests to the latest patch.

where is the patch?

sorry, had problems with the network connection in the office again. Here is the patch:

The the terminology seems to be some kind of weird to me
Shouldn't they be some thing like Applications Manager, Resume Manager, Job manager, instead of 'Administration' , it sounds like some office administration rather than document management.

#66 rules are showing errors
1.I don't see any event or conditions and only reactions
2.Job application administration
a)include the organization field (the employer)
b The title to be changed to Job title
c )Application title not required may be if possible a entity reference no:
3. A dash board may be required for each of the menu instead of in navigation ,in user menu as 'My dashboard' for Jobs, resumes, applications accessible by permissions
screen shot attached

Here is another update with a few fixes:

• Fixed message type and the according rule
• Fixed label for job reference field
• Marked job reference field as required
• Added context admin as dependency (the current dev version needs to be installed)
• Renamed module name from "Job application" to "Recruiter job application"
• Fixed permission for admin view (from access published content to administer content)

Todo:

• Export the sent applications block on the resume with context
• Expose the email address of an applicant on the personal information on the resume, so that the recruiter can contact the applicant.

We'll post more updates after some testing.

Shouldn't they be some thing like Applications Manager, Resume Manager, Job manager, instead of 'Administration' , it sounds like some office administration rather than document management.

I think it's ok to leave the Administration part, as it indicates that this part is for admins only ;-)

1.I don't see any event or conditions and only reactions

You can react upon the content creation event.

3. A dash board may be required for each of the menu instead of in navigation ,in user menu as 'My dashboard' for Jobs, resumes, applications accessible by permissions

Currently we don't plan to include a dashboard in the standard Recruiter, but site builders can easily add one.

I have down loaded current dev still it shows context admin missing
The patch 69 break the site with PDO exception

It seems this is coming from message module

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT COUNT(cid) FROM {comment} WHERE status = :status; Array ( [:status] => 0 ) in comment_count_unpublished() (line 314 of C:\xampp\htdocs\recruiter\modules\comment\comment.module).
Additional

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => php [:db_insert_placeholder_2] => %type: !message in %function (line %line of %file). [:db_insert_placeholder_3] => a:6:{s:5:"%type";s:12:"PDOException";s:8:"!message";s:154:"SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT COUNT(cid) FROM {comment} WHERE status = :status; Array ( [:status] => 0 ) ";s:9:"%function";s:27:"comment_count_unpublished()";s:5:"%file";s:61:"C:\xampp\htdocs\recruiter\modules\comment\comment.module";s:5:"%line";i:314;s:14:"severity_level";i:3;} [:db_insert_placeholder_4] => 3 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => http://localhost/recruiter/admin/modules [:db_insert_placeholder_7] => http://localhost/recruiter/ [:db_insert_placeholder_8] => 127.0.0.1 [:db_insert_placeholder_9] => 1350525125 ) in dblog_watchdog() (line 154 of C:\xampp\htdocs\recruiter\modules\dblog\dblog.module).

Updated patch:

• Fixes text for the message log
• Links the job on the job application form
• Changes the 'Save' button on the job application form to 'Send application'
• Updates the settings to the latest Content Access version

Next I'll update the make files, so you'll have a chance to download all necessary modules and patches.

And we have not yet tested the application feature with the comment module.

Just updated the make files for the recruiter, diff: http://drupalcode.org/project/recruiter.git/commitdiff/daa7cc9?hp=763e2f...

patch 79 did not work
Additional uncaught exception thrown while handling exception.
Original

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT COUNT(cid) FROM {comment} WHERE status = :status; Array ( [:status] => 0 ) in comment_count_unpublished() (line 314 of C:\xampp\htdocs\recruiter\modules\comment\comment.module).
Additional

PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => php [:db_insert_placeholder_2] => %type: !message in %function (line %line of %file). [:db_insert_placeholder_3] => a:6:{s:5:"%type";s:12:"PDOException";s:8:"!message";s:154:"SQLSTATE[HY000]: General error: 2006 MySQL server has gone away: SELECT COUNT(cid) FROM {comment} WHERE status = :status; Array ( [:status] => 0 ) ";s:9:"%function";s:27:"comment_count_unpublished()";s:5:"%file";s:61:"C:\xampp\htdocs\recruiter\modules\comment\comment.module";s:5:"%line";i:314;s:14:"severity_level";i:3;} [:db_insert_placeholder_4] => 3 [:db_insert_placeholder_5] => [:db_insert_placeholder_6] => http://localhost/recruiter/admin/modules?filter=jo&enabled=1&disabled=1&... [:db_insert_placeholder_7] => http://localhost/recruiter/admin/modules [:db_insert_placeholder_8] => 127.0.0.1 [:db_insert_placeholder_9] => 1350528489 ) in dblog_watchdog() (line 154 of C:\xampp\htdocs\recruiter\modules\dblog\dblog.module).

Please try to disable the comment module

Disables comment it did not break,
Still the rules set data values showing errors

Set a data value
Parameter: Data: [new-message:field-message..., Value: [node:field-job-application...
Error: Data selector new-message:field-message-audience:0 for parameter data is invalid.

Set a data value
Parameter: Data: [new-message:field-job..., Value: [node]
Error: Data selector new-message:field-job-application for parameter data is invalid

Both fields are exported in the patch from #72. Try to revert the feature and clear caches.

I have tried all the ways, rules error remains

clicking on apply link error
Notice: Trying to get property of non-object in ctools_entity_field_value_ctools_access_check() (line 142 of C:\xampp\htdocs\recruiter\profiles\recruiter\modules\ctools\plugins\access\entity_field_value.inc).
EntityMalformedException: Missing bundle property on entity of type profile2. in entity_extract_ids() (line 7632 of C:\xampp\htdocs\recruiter\includes\common.inc).

You need to apply some patches, please see the link in comment #73

Here is a new patch which includes the exported applications block for the resume view. The applicant applications view and the recruiter applications pages are now rendered using a content pane view on page manager pages.

Here is a interdiff from mh86 last patch

Thanks for the update!

Here a few notes:

• Patch naming: there are no clear conventions, but it's good to have the issue and comment number included (73 was my comment number)
• Please test if commenting on the application node (recruiter and applicant) would basically work
• Recruiter application block: do not unnecessarily load the first and lastname, if not needed. Better remove the fields and relations for this specific display.
• Recruiter application view in general: the relation " ... Entity with the Personal information .." seems unnecessary to me, "(Profile) Profile: Personal information" should be enough. Please try that.
• Views relationships: set "Require this relationship" if it makes sense (in most cases, e.g. the user has a resume profile). This results in inner joins, which is slightly faster.
• Recruiter job applications page:
  • maybe the machine name should be job_application_recruiter instead of job_applications_recruiter, but not sure about that
  • A selection criteria (e.g. role check) is missing for the access check
  • The current title is "Foo" :-)
  • No menu item provided (I would recommend the same as we did with Views)
• Applicant job applications page:
  • again naming: applicants definitely without 's' at the end
  • selection rules, menu item and title missing as well
• Application node form: maybe we should link the job the way it gets opened in the overlay?
• Application permissions: I think we can remove the edit permissions for applicants.
• Application node view:
  • "View resume" link can be hidden for the applicant
  • Job field: I would move it a bit up (before the body)
• Applicant sent applications view: again, we can link the job so that it gets opened in the overlay
• Recruiter incoming applications view: add a column with the job reference
• The applicant's name stays visible in the message and in the recruiter incoming application view, even if the resume gets hidden. Seems difficult to fix and should be ok if we leave it that way

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,180 @@
+    } else {
+      $variables['submitted'] = t('Submitted on %date', array('%date' => format_date($variables['created'])));
+    }

Add a new line before the else statement.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,180 @@
+ * Rules condition callback wrapper for application exists for job condition.

It's not only for Rules.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,180 @@
+ * @param $applicant
+ *   Either the uid of an applicant user or the user object itself.

According to the code, only the user object is possible

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,180 @@
+ * @param $job
+ *   The node id of a job offering.

The job node

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,180 @@
+ *  TRUE if there is job for this applicant, FALSE if else.

better: TRUE if there is an application for this job and applicant, else FALSE.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,180 @@
+  $applications_exists = &drupal_static(__FUNCTION__);
+  if (!isset($applications_exists[$applicant->uid])) {

This could need some documentation (the reason we're fetching all job references at once)

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,180 @@
+ *
+ * @param $job
+ *   The node id of a job offering.

Most of the time, you use $job for the node object, here it's the node id. The naming should be clearer and more consistent

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,180 @@
+ * @return array|NULL
+ *   An array of job applications or NULL if first argument is not an
+ *   applicant.

What is returned if there are no job applications?

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,180 @@
+      return $query_result;

Is the $query_object null, false, ... in this case?

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,180 @@
+ * @return An array of job applications or NULL if first argument not an
+ *          applicant and second not a recruiter.

NULL is also returned if no application for this recruiter exists

+++ b/recruiter_job_application/recruiter_job_application.features.inc
@@ -0,0 +1,107 @@
+    "description" : "Job application recruiter message",

"Job application" alone is enough for the label of the message type.

I've corrected all the issues mentioned above except for the problem, with the applicants name. That indeed seems difficult to fix.

Noticed the inter-div was wrong. Here is the correct one:

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,185 @@
+  if ($variables['type'] == 'job_application' && !in_array('applicant', $user->roles)) {

why do you check for the applicant role here? I think you should compare the global uid and the node uid.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,185 @@
+ * Returns if threre are job applications for a certain job.

Returns what? TRUE?

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,185 @@
+    $applications[$applicant->uid][$job] = node_load_multiple(array_keys($query_result['node']));

Why do we load the nodes here and even cache them? I think it would be better to just keep the NIDs, the caller should load them on demand.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,185 @@
+ * @return array | NULL
+ *   An array of job applications or NULL if first argument not an applicant and
+ *   second not a recruiter or there were no results.
+ */
+function recruiter_job_application_for_recruiter($applicant, $recruiter) {

This function returns the NIDs, right? So the documentation on @return should reflect that.

+++ b/recruiter_job_application/recruiter_job_application.module
@@ -0,0 +1,185 @@
+ if ($variables['type'] == 'job_application' && !in_array('applicant', $user->roles)) {

I actually kicked out the check for the role, since applicants should view the same content as the admins.

Besides that I improved the issues mentioned above in this new patch.

Improved the access a little bit and besides, the link on the application now uses the proper link with colorbox.

I guess this is ready now, you can commit it yourself :-)

cliciking on apply button gives this error
Notice: Trying to get property of non-object in ctools_entity_field_value_ctools_access_check() (line 142 of C:\xampp\htdocs\recruiter\profiles\recruiter\modules\ctools\plugins\access\entity_field_value.inc).
EntityMalformedException: Missing bundle property on entity of type profile2. in entity_extract_ids() (line 7632 of C:\xampp\htdocs\recruiter\includes\common.inc).

I've committed the patch, therefore I think you should open new issue, this thread is too long anyway.

sepgil committed, so this feature request is fixed - congratulations :)

please test with a clean install & open follow up issues separately.

yeah, it's finally committed :-) thanks to everyone who was involved in this issue!

Guys I'm sorry to opening again this thread, I tried to apply the patch 1204554-job-application-89.patch, i activated the module "job application" but, when i try to apply to a job, drupal returns this PDO issue
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '16-2-acl' for key 'PRIMARY': INSERT INTO {node_access} (nid, realm, gid, grant_view, grant_update, grant_delete) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5), (:db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11), (:db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15, :db_insert_placeholder_16, :db_insert_placeholder_17); Array ( [:db_insert_placeholder_0] => 16 [:db_insert_placeholder_1] => acl [:db_insert_placeholder_2] => 2 [:db_insert_placeholder_3] => 1 [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => 0 [:db_insert_placeholder_6] => 16 [:db_insert_placeholder_7] => content_access_rid [:db_insert_placeholder_8] => 30037204 [:db_insert_placeholder_9] => 1 [:db_insert_placeholder_10] => 0 [:db_insert_placeholder_11] => 0 [:db_insert_placeholder_12] => 16 [:db_insert_placeholder_13] => content_access_author [:db_insert_placeholder_14] => 18 [:db_insert_placeholder_15] => 1 [:db_insert_placeholder_16] => 0 [:db_insert_placeholder_17] => 0 ) in node_access_write_grants() (line 3551 of /usr/local/zend/apache2/htdocs/recruiterphanteon/zemogajobs/modules/node/node.module).

Anyone knows what 's going on here? Thanks a lot for your help.