I then tried a more programmatic approach and searched for a solution at the theming level, my hope was that I could build a condition that would detect for the employer role then add a unique class to the body tag that would only appear for employers. This class could be used to style the employer pages as required, including the removal of the Latest News block. All attempts to implement such a routine have been ineffective. Resulting in either nothing happening or the breaking of the site. I’ve spent sooo much time trying to figure this one out and I really am no further along than I was last week. It is really very discouraging.

On the bright side of this is that in trying to find a solution to the layout problems, I found solutions for almost all of the other tasks our group identified as deliverables for our project! Specifically:

1. incorporating the elements for the employer front page (as identified in the Pei’s mock ups)
2. figuring out how to make unpublished posting invisible to students and
3. having unpublished postings show for admins
4. customizing the create a posting form
5. getting pagination to work on the job listings page

I initially created the job listings page with the Views module, but later struggled with getting pagination to work on this page. As it turns out, the Job Posting module comes with a built in listing of job postings and comes with built in pagination. An added bonus is that unpublished postings DO NOT appear on the listing pages (as they should). This was something else that I was struggling with. The work I did with views was not a waste however, as this is the page I’m referring admins to in order to approve postings. Postings that are pending for approval are watermarked as UNPUBLISHED on the Views module page. The whole thing worked out quite well, I couldn’t be happier.

In order to do both changes I had to modify the PHP code for the job_posting module. I found the template file at /drupal/sites/all/modules/job_posting/ the file that I had to modify was job_posting.module. I found what I was after in the ‘Implementation of hook_form()’ section.

All form elements including the descriptions on the form were organized in arrays, so it was a matter of tracking down the appropriate passage and modifying it to our needs.

1. I tweaked the description for the e-mail address section, removing any reference to application processing as this feature was soon to be removed.
2. After changing the default setting for application processing to ‘disabled’ I remarked the entire section out, just in case we want it back at some future point.
3. I simplified the language explaining the application deadline section, replacing the words ‘nodes’ and ‘view’ and ‘module’ to something more friendly and generic.

As it turns out the solution isn’t through the workflow module, although it may be possible to use this module to give us the functionality we require. It is more complex to implement and to be frank I couldn’t figure it out. After activating this module and creating a pending-approval workflow I got to a point where Drupal was spitting out warnings that the sites’ permissions had to be re-created. A scary idea, and one that I could not predict the consequences of, so I elected not to go this route.

Instead, I turned to Content Types. This area can be found at: admin menu > administer > content management > content types.

1. I went into the content type for Job Posting (clicking on it’s edit link in the listing)
2. Unchecked “published” under the workflow section
3. Since we don’t want the general public to see our advertised jobs, we only want students and faculty to see job postings, I also unchecked the ‘promote to front page’ option as well.

Now when employers create a job posting (when save is pressed) the posting is flagged as unpublished (by the word unpublished watermarked in the background) until such time that the post is published by a technician or administrator. It appears that authenticated users can still view the post, so I still have to figure out how to make it invisible to students. If all else fails this could be removed with CSS as unpublished postings are wrapped with a container with a ‘node-unpublished’ class, but I’ll have to figure out a way of making these viewable for techs and admins only.

I still needed to find a way to notify admins (the role that will approve job postings) of new job posting requests. For that I turned to actions and triggers. Actions are automated tasks that Drupal can do when a certain event occurs:

Located at: admin menu > administer > site configuration > actions-
I added a system action that sends an e-mail to the Web site administrator whenever a post is created for approval. I’m not sure but now that I think of it Doug mentioned that as a policy the server that the MS site is hosted on is not configured to send e-mail. I’ll have to follow up on this with Doug.

Triggers are events that occur in Drupal such as when a user logs in or in our case when a job posting is added:

1. Located at: admin menu > administer > site building > triggers
2. I assigned a trigger to this new action above for the post a job routine

1. the ability to alter their own profile
2. the ability to list all the job postings on the system
3. the ability to post a job
4. and a link to log out of the site

The Menu

The following is the series of steps I took to accomplish this task. The first thing I tackled was developing a custom menu just for employers:

1. Create a new menu item just for employers. This is done via admin menu > administer > site building > menus and creating a new menu (the add menu tab)
2. Add the appropriate menu items to the new menu. This is done via admin menu > administer > site building > menus > menu name (in our case Menu) and press the add item tab, fill out the form and repeat the process as required. Finally adjust the order as necessary.
3. Add the new menu block to the page region that you wish it to appear. This is done through the block manager via admin menu > administer > site building > blocks. This in effect creates a new block for our menu. I made the menu appear in the left-hand side bar
4. Edit the configuration of the new menu block so that only employers can view the menu. Done via admin menu > administer > site building > blocks and clicking on the configure link for the block of interest.
5. Edit the configuration of all the other menu blocks so they do not appear for employers, but do appear for all other roles (faculty, students, and techs)

Blocks

Blocks was also  key in simplifying the employer interface. Again each block that you do not wish to appear on the employer interface has to be turned off for employers through blocks configuration. I did this for the following items on the MS front page:

• In the media block
• The four course offering teasers
• The random quotes
• The spring fall course spotlight (the right column, although I had to leave spring 2010 item until we sort out the 2 column issue through css)

Configuring

After downloading and installing the Job Posting module (with a little help from Chris), we were ready to start learning and using the module in order to evaluate it for our use. The ‘Job Posting’ menu item is the first and most obvious thing that appears (in the Admin Menu — of the MS site) after installing Job Posting. It appears in two locations:

1. Under Admin Menu > Administer > Site Configuration > Job posting settings — this is the area were one can control the behavior of the application by adjusting the job reference number prefix, job posting display order, and controlling the number of postings per page. I left all settings at their default settings.
2. Admin Menu > Job Posting — the area were job postings are actually created

Working With Views

The other important aspect of getting the job forum to work was to set up a new view specific to the Job Forum. This is done via the Views manager at Admin Menu > Administer > Site Building > Views. Working with views can be confusing and to be frank, I know very little about them. However, it’s my understanding that the Views module is a kind of visual interface for building MySQL queries, but it’s complexity can be overwhelming. The way I ended up getting the Job Posting view to work was to clone the screencast view and modifying this copy in order to give me what I needed. There were three setting I had to change with the cloned copy:

1. The name of the view
2. Renamed the page path setting
3. Changed the filter from Screencast Videos to Job Posting

Dealing with User Access and Permissions

Once this is set up and a few job postings are entered into the system its a matter of setting up Drupal with the job postings module. The main work centered around setting up the various levels of access to the job forum, this was done by adjusting user roles within Drupal:

1. I’ve given administrators and technicians full viewing, adding, and editing ability to the  job postings module
2. Faculty now has the ability to view all job postings, and can also add, modify, and alter all job postings
3. I have created a new user role for employers and provided the same level of access (with respect to the job forum) as faculty, the only difference being that employers can only modify postings they own.
4. I’ve Given students the ability to view job postings only

Note that user and role management is done through the Drupal’s user manager component under Admin Menu > Administer > User Management

Creating Menu Items

Finally, I had to add a menu item to the main navigation system so that when authenticated users visit the site they’ll be able to access the job forum. I did this via the menus module at Admin Menu > Administer > Menus > Explore in order to add the item to the Explore Menu and went to Admin Menu > Administer > Menu > Navigation in order to manage the Admin Menu. I’ve added a few bogus  job postings and will be giving access to this site to the rest of the team.

I was able to get joobsbox running on my Web hosted space (with Dreamhost). The process was quite similar to installing a WordPress or Drupal powered site in the sense that you must create a database first, take note of the database meta data (db name, user, password and hostname) for later entry, and finally run a PHP script that configures the Web application (this routine also creates an admin account for back end management). Once you go through the process joobsbox is fully functional and ready to accept job applications.

The nice thing about joobsbox is it’s simplicity the front end seems to be straight forward in its design and layout. A categorized listing of jobs dominates the core page (the first page you see when viewing the site). Adding jobs can be done anonymously, but has to be approved by the administrator for display. Joobsbox has a built in search feature and has RSS capabilities how well these features work however remains to be seen.

This simplicity is carried over to the back end of the site, where the administrator can create job categories, manage postings (this includes approval of postings), switch themes, and adjust various other settings. The ability to create themes in joobsbox suggests that the appearance and layout of joobsbox is highly customizable, good news for our team.

Our team reviewed joobsbox and agreed that it does show potential, but if we were to go ahead with joobsbox we would have to sacrifice some of the functionality that we imagined for our job forum application. The main shortfalls being:

• anonymous access to content (although there are ways to mitigate this issue)
• anonymous access to creating job postings, which may prove taxing to the administrator as all job postings have to be approved before being published
• single access to the back end–in other words, only the admin user can gain entry to the back end and other users can not be created
• a very basic job posting entry form that is used to collect job posting information
• no ability to manage e-mail

Even with its shortcomings, we are still open to implementing a joobsbox powered solution. However we will be looking at other solutions, the most promising of which is a Drupal powered add on.

I’m thinking we should dismiss any proprietary solutions as the ones I’ve located don’t seem to be in-line with our objectives. However I think that it’s worth test driving joobsbox (an open source solution), I think it would be worth installing this on our development server.

Next Steps

1. Get FTP access to mediastudies.viu.ca (request to Chris sent out)
2. Install and evaluate Job Posting Drupal Module
3. Evaluate what is better for the project; the Drupal add on module or the custom content type
4. Come to some kind of conclusion (or at least offer recommendation) on how we should proceed. Its too early for this as we need to go through steps one to three above first.
5. Continue to firm up project scope. We will need to meet with the client

We could build our own Web application from scratch. We would have to build our own database, normalize it, then create all the scripts that would interface with it. Most of the work would involve designing a CMS (or back-end) component that would include a user manager, job posting manager, student and employers manager. In parallel to this we would have to build the public or front-end from scratch, also a significant amount of work. The main advantage of this approach is that it could look like anything we imagine it to be, including having the same (or a similar) interface as the new MS site. This offers the most flexibility but also will involve the most work and the steepest learning curve.

Pros

• The most flexible solution, this can be tailored to our needs

Cons

• Time constraints, we may not have enough time to build all the features we have imagined

There are a number of open source and proprietary solutions out there. The following are the ones we researched in order of perceived suitability to the job forum project:

Open Source Solutions

http://www.joobsbox.com/ – Seems like a viable solution, however more research is required. May be worth downloading in order to evaluate further. Offers the following features:

• Plugins and Themes are available (which means we can create our own theme)
• Categorized jobs
• Search Engine
• Approve, edit and delete job postings
• Has the ability to set duration of job postings
• RSS feed capable
• Seamless integration into existing site (I`ll believe it when I see it)

Pros

• Free Download available
• Appears to be fully CSS customizable

Cons

• A bit of an unknown without installing and testing it. Don`t know what the backend looks like yet

http://www.jobberbase.com/ – Seems like it could be used for a basic job forum, but the demo is not very impressive. More research is required. From looking at their demo site it looks like it has the following capabilities:

• Listing of all jobs
• Categorized job listings
• Ability to search for jobs

Pros

• Free Download available
• Looks like it could be fully CSS customizable, I`m assuming this as it appears that it is downloaded and installed on the server. At this point it would be open for manipulation.

Cons

• Unclear whether or not it has the ability to set various levels of user access
• Appears to be a lack of documentation
• An unknown without installing and testing it. Don`t know what the back end looks like yet
• Anonymous job postings – not good

http://www.jobamatic.com/ – A fully hosted solution meaning that the Web site lives on their servers including the database of jobs, students, and employers.

Pros

• Completely CSS customizable (the term they use is brandable)
• Free – but not sure if there are any catches like advertising
• Easy to setup and start using (big assumption, but there would be no setup)

Cons

• Data resides on external servers
• Less flexible
• Not sure if it will meet the requirements of the MS project

Proprietary Solutions

We didn`t spend too much time investigating proprietary solutions as we were not sure how receptive VIU would be towards a solution that has a cost associated with it.

http://www.applicantstack.com/ – A recruiting system and applicant tracking, this looks to be a hosted enterprise solution. Sounds like its beyond our scope seems like this will do the job (and a whole lot more), but its proprietary and will cost a monthly fee. One user with 4,000 applicants version costs $35.00 per month. We don’t think this is quite in-line with what we want to accomplish with the MS job forum.

http://www.talentpen.com/ – recruiting system sounds like its beyond our scope, more research required. Proprietary, not sure of cost. We don’t think this is in-line with what we want to accomplish with the MS job forum.

http://www.24x7softech.com/ – recruiting system sound like its beyond our scope, more research required. Proprietary, not sure of cost. We don’t think this is in-line with what we want to accomplish with the MS job forum.

As a result from the job forum concept map that our team assembled it was identified that there needs to be three levels of access to the job forum in order to effectively manage the site. Administrative access, employer access, and student access. Theoretically, this is already built into Drupal. In other words, it may be possible to handle this functionality using the existing MS site. Further research will have to be conducted in order to verify this possibility.

The ‘Job Posting’ Module

The Job Posting module adds a new node content type (‘job posting’) intended to facilitate the advertisement of available employment opportunities. This module is recommended for use with Drupal version 6.x, so it offers the most promise with regards to a Drupal powered solution. The module brief indicates the following features. Located at http://drupal.org/project/job_posting:

• Display of most recently added job postings
• Paginated display of job postings
• A mechanism to control the duration of job postings, in other words the posting could expire after a certain date
• Includes a basic job application routine that allows students to apply on-line, including the ability to upload their resume in MSWord or PDF format

Pros

• offers the most potential
• existing solution that could work without too much effort
• no cost with the exception of labour to set it up and learn how to use it.

Cons

• unknown, we don`t know what it looks like or how it works
• may not meet all the requirements identified in the concept map
• could be a steep learning curve

Job Plus Job Board System

This is a complete ready to use Job Board System that uses the job module to create a full system. It comes with the necessary Views and creates a descriptive breadcrumb. Unfortunately it is recommended for use with Drupal 5 and so it’s not officially supported and tested with Drupal 6 (the version of Drupal that the MS site employs). I don’t think this would be a viable solution for us to consider. Located at http://drupal.org/project/jobplus

Pros

• N/A – not a viable solution

Cons

• N/A – not a viable solution

Custom Content Type

We could create our own custom content type in Drupal that effectively deals with Job postings. With the help of the CKK and Views (two other modules that are already installed on the MS site), it may be possible to produce a listing of all the job postings.

Pros

• Has the potential to be highly flexible and adaptable to our requirements, everything would be custom built for our needs

Cons

• May not be as robust as the Job Posting module above
• Steep learning curve