Recruiter can see "Apply for this job"

It's an interesting question. My first thought would be that it needs a user_access call around the contents of the last "else" condition.

I suppose the larger question is if there should be any visual cue to someone who is logged in but doesn't have the permission to apply.

You could also argue that the current logic assumes that only authenticated users can apply. That might lead one to conclude the user_access call should come before the user id check, and enclose that whole structure.

I think we should be careful about writing this to be too specific about your particular needs. A recruiter won't need to apply for her own jobs, but might want to apply for a job by another recruiter. Also, testing for roles instead of permissions seems very un-Drupal.

I think we should take the time here to map out the use cases, and that will be the coding much, much easier.

Off the top of my head:

Someone who has permission to apply and isn't the person who posted the job:
Show the "Apply" link

An anonymous user who can't apply:
Show the "Login or Register" link
(sidebar: this implies that authenticated users have access to apply)

All others:
Show nothing?

The "others" would be authenticated users who do not have permission to apply. To cite an example you mentioned earlier, it might be a user who hasn't yet paid for the access to apply. This one will be difficult to anticipate, as the best solution will probably vary widely based on how the job board is being set up. I suppose the Cadillac solution would be to provide a settings field that would allow an administrator to specify the message that would be shown to such users.

That snippet has a couple of problems. First, it's dependant on a role called 'recruiter', which is a problem. Ideally it should be testing for the permission to apply, using a test like user_access(JOB_PERM_APPLY) instead.

Also, I thought we established in #4 that recruiter might need to be able to apply for jobs in some circumstances, so the business logic is off anyway.

I would suggest that the testing for permission to apply for a particular node be spun out to a separate helper function, something like

function _job_apply_node_perm($nid) {
  global $user;
  $uid = $user-> uid;
  
  // find who posted the job
  $node = node_load($nid);
  $nuid = $node->uid;
  
  // Can't apply for own job
  if (user_access(JOB_PERM_APPLY) && $nuid != $uid && !_job_check($node->nid, $uid)) {
	return true;
  }
  
  return false;
}

That way, the same logic can be used for deciding whether or not to show the apply link, as well as for determining access to the application menu callback.

Based on that helper function, you could have the job_link function look something like:

function job_link($type, $node = NULL, $teaser = FALSE) {
  global $user;
  $links = array();
  
  // If not a job node, don't bother
  if ($type != 'node' || variable_get(JOB_NODE_TYPE . $node->type, 0) == 0) {
    return $links;
  }
  
  if (_job_apply_node_perm($nid)) {
	// OK to apply
	$links['job_apply'] = array(
	  'title' => t('Apply for this job'),
	  'href' => "job/apply/$node->nid",
	);
  }
  else {
    // Now, determine why the user was denied
    
    if (!$user->uid) {
	  // User is not logged in
	  // NOTE: consider an admin-defined message here
	  $links['job_apply'] = array(
	  'title' => t('Please login or register to apply'),
	  'href' => 'user/login',
	  );
    }
    else if (_job_check($node->nid, $user->uid)) {
	  // User has applied for this job
	  // NOTE: consider a link to withdraw application here, if permitted
	  $links['job_apply'] = array(
		'title' => t('You applied for this job'),
	  );
    }
    else {
	  // Catch-all for authenticate user without permissions
	  // NOTE: consider an admin-defined message here
	  // for now, show nothing;
    }
  }
  
  return $links;
}

OK, the attached patch implements the code above, as well as a tweak to use the permission function for the job_apply function. That latter function could probably use a little more attention too (some of its checks are now redundant) but this patch addresses the issue at hand.

Please test and let me know how this works.