Follow

Recruiter 2.0 Specifications

This page is divided into sections representing the various modules in the system. Each section outlines expected functionality.

Sections:

 

Legend: (c) configurable.

Login

 

The login module handles all login requests as well as redirection to specific resources after being logged in. The main component us the login form and Login controller. The login form has the following test cases:

  1. Entering no user details: error should show for each field and generic login error
  2. Entering a userId only: error should show for password field and generic login error
  3. entering a password only: error should show for userid field and generic login error
  4. entering both fields with one of the fields being invalid: generic login error
  5. attempting to login more than 3 times with both fields populated: reCaptcha should show and be required to continue
  6. attempting to login more than 6 times: message counter is applied indicating remaining attempts.
  7. attempting to login more than 10 times: Button becomes disabled.

 

 

 

 

 


top

User Sessions

Sessions are stored until the browser is closed, a person logs out, or there is no activity for a duration of time which is configured in RMS. Sessions will be retained through page refreshes. Sessions should meet the following test cases:

  1. A session should be destroyed when the browser or tab is closed: test by logging in, closing tab and reopening.
  2. A session should be destroyed when a user logs out: test by logging out and refreshing page.
  3. A session should be destroyed when a user is inactive: test by logging in, then going inactive for duration of time set in RMS.
  4. A session should be retained through page refreshes: test by logging in and refreshing the page.
  5. A session timeout should be refreshed when navigating to another page.
  6. A session timeout should be refreshed by any user interaction (moving mouse, clicking buttons).
  7. A session timeout should be refreshed on modals and in iframes.
  8. If a user is still active, a request (to the server to keep the session alive) should be sent every 29 seconds.
  9. When a session is close to timing out, it should display a modal giving the user a chance to refresh the session.
  10. If a user dismisses the modal, it should reset the session.

top

Navigation


topThe Navigation component contains the primary links for a user to navigate the system. When a user is logged in they will have access to additional links such as, "dashboard" or "log out". The Navigation component is designed to fit any width screen. When links do not fit on the screen, they are compressed into a hidden menu accessed via a "hamburger" link.

Navigation Test Cases:

  1. It should hide breadcrumbs on scrolling
  2. When the screen is too small to display all links, it should show a clickable menu icon instead.
  3. When the window or display is reduced or expanded it should re-evaluate if the menu Icon is necessary and display it accordingly.
  4. When the menu icon is clicked it should display the collapsible menu according to the configured method.
  5. The collapsible menu should contain all configured links.
  6. If a search link is displayed on the collapsible menu, it should have a sub-nav tree which contains the search filters panel.
  7. If a link is configured to display when "logged in", and a volunteer is logged in, it should display.
  8. If a link is NOT configured to display when "logged in", and a volunteer is logged in, it should not display.
  9. If a link is configured to display when "not logged in", and a volunteer is not logged in, it should display.
  10. If a link is NOT configured to display when "not logged in", and a volunteer is not logged in, it should not display.

Navigation Admin Configuration Test Cases:

  1. It should allow menu items to be added.
  2. It should allow menu items to be rearranged.
  3. It should allow menu items to be deleted.
  4. It should allow link URL, label, and title (hover title) to be configured
  5. It should allow custom classes to be added.
  6. It should allow menu items to be configured with icons.
  7. It should allow menu position to be configured.
  8. It should allow configuring of "logged in" and "not logged in".
  9. When settings are saved it should provide a configuration object (JSON).

Volunteer Assignment Service

The Volunteer Assignment Service handles all placements and referrals to opportunities and schedule slots. The service provides options for logging in or registering. As well as signing up with a group, presenting prerequisite information, and any other precursor steps to signing up for an opportunity.

Opportunity Test cases:

  1. It should perform all checks according to the Sign Up Action Button
  2. It should attempt to place/refer a volunteer to the opportunity according to the settings for the opportunity.
  3. If a waiver is required it should request the waiver signature before place/refer.
  4. If a prerequisite is not met on a placement opportunity, it should refer instead.
  5. If the user is not placed/referred for any reason to the opportunity, a message should be displayed clearly stating the reason.

Schedule slot test cases:

  1. It should perform all checks according to the Sign Up Action Button
  2. If the user is not referred/placed with the slot's opportunity, it should first place/refer the user to the slot's opportunity.
  3. If the user is only referred to the opportunity, and the schedule slot is configured to allow referral, it should refer to the schedule slot.
  4. If the user is only referred to the opportunity, and the schedule slot is NOT configured to allow referral, it should not refer to the schedule slot.
  5. If the user is not placed/referred for any reason to the schedule slot, a message should be displayed clearly stating the reason.

top

Attachments

There are three places where attachments can be uploaded: inline attachments, attachment list, vol photo attachment. Attachments can be inserted inline on forms, dashboards, or any other place a logged user would like to see them.

  • Inline attachments can be set to required when in forms. Inline attachments include a link to download or delete the file.
  • Vol Photo attachment: A volunteer's image can be attached from the vol photo attach directive, which is usually on the dashboard. This tool includes an image cropper.
  • Attachments can also be updated through the attachment list. "Other" type attachments can be uploaded on the attachment list view.

 

Test cases:

  1. When an attachment is not uploaded, it should provide an upload link.
  2. When an attachment is uploaded, the attachment should show uploaded and provide delete and reupload links.
  3. On refresh, uploaded attachments should provide delete, download and reupload links.
  4. When an attachment is deleted it should confirm delete before proceeding.
  5. When an attachment is deleted it should provide an upload link again.
  6. When an attachment is deleted it should remove the thumbnail
  7. When an attachment is changed all UI references to that attachment should be updated.
  8. When an "other" type attachment is added it should be added to the attachment list with the name provided.
  9. When an "other" type attachment is deleted it should provide an upload link.
  10. When an "other" type attachment is deleted and the page is refreshed, the other type should be removed from the list.
  11. When an attachment is an image (jpg, png, gif) it should show a thumbnail preview in the attachment list after being uploaded.
  12. When an attachmen is not an image, it should show an icon for the type of file it is.
  13. When an attachment is uploaded that is larger than 3mb it should provide an error.
  14. When an attachment is the wrong file time it should provide an error.
  15. When an attachment is being uploaded, but not yet complete, a message should display indicating the file is still being uploaded.
  16. When the vol photo attach tool is used it should display an image cropper before uploading
  17. When the vol photo attach tool is used it should update the volunteer's profile image
  18. When the vol photo attach tool is used it should only accept jpg, jpeg, png, or gif files.
  19. When the vol photo attach tool is used it should convert the attachment to jpg.
  20. When the vol photo attach tool is used it should resize the cropped attachment to 300px X 300px

 

 

Attachment List

 

 

Attachment errors

 

 

Deleting an attachment

 

 

Choosing a file in the attachment list

 

-

Choosing a file in the vol profile image tool

 

 

 

3 steps to upload vol photo.

 

 

 

Error messages for the vol photo attach

 

 

 

 

 


top

Opportunity Details

Test cases:

  1. It should filter out schedule slots that exist past the opportunity's expiration date.
  2. It should provide a static map image with pin matching the location address.
  3. If no location address is available it should provide a static map image with pin matching the contact address

top

Search Filtering and Sorting

The search filters system uses opportunity attributes that are displayed in a variety of ways based on configuration. Searches are performed on opportunities and schedule slots. Search settings can be retrieved using the URL at the top of the page. Below are some example URL string

Search Filtering Test Cases:

  1. When a filter is selected, it should add that filter to the URL automatically.
  2. When a filter is removed, it should remove that filter from the URL automatically.
  3. When a sort is added, it should be added to the URL automatically.
  4. When a sort is removed, it should remove it from the URL automatically.
  5. When a filter or Sort is changed it should update all corresponding displayed records.
  6. Search filters/sorts should be retained when any back button or link is used.
  7. Search filters/sorts should be retained when any back button or link is used.

top

Searching for Opportunities

The Search applies filters immediately to a set of records. This improves responsiveness and decreases server requests. Searches can be configured into groups. Each group will act as an OR between all criteria in that group. Groups are then compared against each other as AND logic. Aside from custom search criteria there is also keyword search and location/zip and distance. Search filters can also be applied using quick link URLs.

Note: Opp search filtering only applies to the specific results views that are part of the search feature, The list, map and calendar views.

 

List view test cases:

  1. It should update search results automatically after clicking on a checkbox or radio button
  2. It should update search results after pressing enter or leaving the keyword field
  3. It should allow search results to be sorted by title in ascending or descending order
  4. It should allow search results to be sorted by publish date in ascending or descending order

Map view test cases:

  1. It should provide a pin for each opportunity that has custom coordinates, a location address or a contact address
  2. If custom coordinates are provided, it should provide a pin based on custom coordinates first
  3. If no custom coordinates are provided, it should provide a pin matching the location address
  4. If no location address is provided, it should provide a pin matching the contact address
  5. When a pin is clicked, it should open an info window for each pin with details about the pin (detail window may vary in format)
  6. It should cluster the map pins when they are close enough to each other and indicate the number of records for the new clustered pin.
  7. If there are only 2 records in the cluster, when clicked, it should open an info window with a listing each record in the cluster

Calendar view test cases:

  1. It should display schedule slots for the filtered opps on the calendar.
  2. If there is no schedule slot for the opportunity, it should do nothing.

See Schedule slot filtering for more calendar test cases


top

Search for Schedule Slots

Schedule slot search filtering filters all available schedule slots in the current view. After applying most search criteria to the parent opportunities, schedule slots are pulled for the filtered opps. a user can do a more exhaustive search of slot specific fields, such as date and time, to refine results further. The views that support slot results are the list and calendar views.

Note: Slot search filtering only applies to the specific results views that are part of the slot search feature, The list and calendar views.

 

Test cases for both views:

  1. It should not display schedule slots that exist past the opportunity's expiration date.
  2. It should not display day off schedule slots.
  3. If the Start Date filter is used: It should not display schedule slots that start before the set date.
  4. If the End Date filter is used: It should not display schedule slots that end after the set date.
  5. If the Start Time or End Time filters are used: It should display all schedule slots that are "touching" (in-between, starting before the end time but after the start time, ending after the start time but before the end time.
  6. If the Group Size filter is used: It should not display schedule slots that have an available group size that is less than the set group size.
  7. If A buffer time is configured: it should filter out events that start before the current date plus the buffer time.
  8. It should load and make available for display, the amount of slots equal to what is configured in RMS.

Test cases for list view:

  1. It should provide details about the parent opp for each schedule slot, such as opp title (this is configurable, and may vary).
  2. It should provide a message indicating the number of results.
  3. It should default to sort by date/time.
  4. It should allow sort by title, which sorts by opportunity title.
  5. It should provide links to opportunity details (note the search criteria are not applied to opp details)

Test cases for calendar view:

  1. If there are 3 or fewer slots, it should list each slot available for that day.
  2. If there are more than 3 slots, it should group slots into one clickable slot placeholder with a count indicator of how many slots are on that day
  3. If an individual slot is clicked, it should open a modal window with information about that slot
  4. If a grouping of slots is clicked, it should open a modal window with a listing of all the slots on the day, sorted by time.
  5. If a grouping modal is opened it should display a sticky footer with "modal specific" navigation that is fixed to the bottom of the screen.

top

Waivers

The waiver system can be enabled to require waivers be signed within specific places in the system. Waivers can be configured to be requested in four places: registering as a new volunteer, upon opportunity sign up, on the volunteer dashboard, and as part of an onboarding process.

 

Test cases:

  1. It should get all historical waivers for the current user.
  2. It should only add waivers that match the "require when" configuration criteria to the required waivers.
  3. It should compare all current waiver requests to historical waivers before adding them to required waivers.
  4. It should open a modal notification that users accept, before loading any waivers.
  5. It should display required waiver(s) when requested (on opp sign up or other trigger event).
  6. If the waiver is a generic waiver, it should show the survey iframe.
  7. If the waiver is a DocuSign waiver it should show the DocuSign iframe (full screen frame).
  8. If multiple waivers are required, it should display the next waiver after the current waiver is completed, until all waivers are signed.
  9. Cancelling a waiver should close all user interface components for that waiver.
  10. Waiver type Logbook entries should not display in the logbook with normal LBE entries.

Test cases for opp prerequisite waivers:

  1. It should display a message modal with a list of all required waivers before displaying the first waiver.
  2. Once all waivers are signed, it should place/refer volunteer to opportunity as configured. (see general test cases for process)
  3. If the waiver is cancelled, it should not place or refer you to the opportunity.

Test cases for triggered waivers:

  1. When triggered, It should load the proper waiver in either a full screen frame or a modal based on configuration.
  2. If the waiver process is cancelled it should not perform any additional actions.
  3. If the waiver process is completed, it should perform the configured callback response function. eg: open a success modal, change a field value or other custom action. (see each recruiter configuration specs for more details).

Test cases for DocuSign waivers:

  1. It should create a LBE if there are mapped LBE fields in the waiver configuration.
  2. It should create a DocuSign envelope and put the envelope GUID into the mapped LBE or VOL field.
  3. It should pass the OPP ID, LBE ID, Survey ID, and all configured custom field values to the DocuSign envelope record.
  4. It should populate the DocuSign document tabs with data from the configured display fields in the DocuSign visible document & envelope record.
  5. It should attach the DocuSign document to the mapped VOL or LBE attachment after being signed.
  6. It should update the mapped LBE or VOL field with the DocuSign status.
  7. If a waiver is cancelled, it should still create the LBE and leave the status as "Sent" with a waiver Envelope GUID in the mapped LBE fields.

 

Modal notification before opening waiver(s).

 

DocuSign initial load view.

 

Populated Volunteer Name and Opp Title in DocuSign.

 

Interface change after clicking "finish" in docusign

 

Showing sign up after signing.

 

LBE survey of incomplete DocuSign waiver signing

 

LBE of completed DocuSign waiver signing

 

 

Example of waiver configuration settings.


top

Groups

The Groups system allows users to be assigned to groups, manage groups, and records belonging to the group.

Test cases:

  • Triggering a Group Action Button should display a modal with group search, add, remove, and edit controls.
  • Searching a group name should display a list of results matching the search criteria.
  • The list should be scrollable when necessary.
  • The list should be scrollable when necessary.

top

Sign In Station

The sign in station allows for various configurations and modes. The modes include Open Roster, Email, Username/Password, Barcode, Volunteer ID, and Driver License. Each mode requires some level of configuration, either through the admin settings panel or through the associated angular-config.js file.

Test cases:

  1. It should display the current time within 1 second.
  2. It should allow eCoordinator (admin) login access.
  3. It should allow the user to select a station and opportunities to use.
  4. It should allow users to switch between modes (Open Roster, Email, Username/Password, Barcode, Volunteer ID, and Driver License).
  5. It should allow users to set all miscellaneous settings.
  6. It should save all configuration settings when the save settings button is clicked.
  7. When "Reset Station" is clicked it should reset the station to not configured.
  8. It should display a message stating the station is not configured, if there is no configuration settings file stored.
  9. It should perform a display reset ever X seconds(c).  Display reset clears user data, and displays the default sign in method.

Admin Roster cases:

  1. It should show all volunteers who are placed in a schedule slot, based on selected opportunities, for the current day.
  2. It should allow admin users to see all scheduled volunteers for the day.
  3. It should allow admin users to modify start and end times for any volunteer for the day.
  4. It should allow admin users to log in or log out any volunteer scheduled for the day.
  5. It should allow admin users to find a volunteer based on email, who is able to report service at the sign in station, and sign them in or out.
  6. It should allow admin users to find a volunteer and place them with a specific schedule or opp that is configured for the station.
  7. It should allow admin users to create a guest account

Open roster test cases:

  1. It should pull opportunity and schedule slots for selected Sign in Stations, regardless of recruiter visibility.
  2. It should display placed volunteers of schedule slots which are for selected opportunities of the station, and fall within the "Allow early sign in" and "Allow late sign in" configurations.
  3. It should be able to filter roster names by a search field for first and last name.
  4. It should allow users to set their group size (when enabled).
  5. When allow guest is enabled, it should allow guest sign up into currently available schedule slots.
  6. When "Enable additional survey prompt" and "Show additional survey link on roster" settings are selected, a link should display which allows users to report service using other surveys available to the volunteer (based on volunteer's surveys).
  7. When "Hide volunteer from roster after sign in" is enabled, it should remove names from the roster after they sign in

Email, Username/Password test cases:

  1. It should provide an error message if the username/password or email could not be validated.
  2. It should provide an error message if the email exists for multiple volunteers.
  3. It should provide a list of upcoming schedule slots and/or opportunities when a user logs in.
  4. It should allow users to take an additional survey upon entering credentials after already logged in (if enabled).

Guest sign in test cases:

  1. It should check for existing records based on email address.
  2. It should create a new record using the volunteer name and email.
  3. It should present a list of opportunities and/or schedule slots available for the guest to sign in for.
  4. It should add the guest to the roster list if the open roster mode is the main mode.

Take Survey

  1. It should be possible to enable additional surveys to be completed without signing out of the sign in station.
  2. Additional surveys should be determined by those available for the volunteer and opportunity.
  3. It should be possible to restrict/specify which surveys are available via the "Take survey" link.

top

File Caching

Almost all files delivered from the CSTOOLs folder are managed by the Cache Manager. This module holds an array of these filenames and their date modified times. When you call for a cache URL it matches that URL to one in the array and returns the URL you are calling with an appended version number. If a file is updated, the Cache Manager will automatically update the version number to the new date modified time. File names are manually added to the Cache Manager by a developer when a new resource becomes available. In addition, the commonly modified angular-config.js, recruiter-styles.css, and recruiter-responsive.css are also handled by this module.

The Cache Manager requires two files to work, the cache manager itself and a copy of cacheVersions.php which is stored in the local custom folder of the recruiter. This combined with no-cache headers prevents resources from being cached after they have been updated.

 

Test cases:

  1. When a module file is updated, and it exists in the cache manager module, the file should get a new version number and a new copy of the file should be retrieved from the server.
  2. When a partial template file is updated, and it exists in the cache manager module, the file should get a new version number and a new copy of the file should be retrieved from the server.
  3. When a form JSON file is updated, and it exists in the cache manager module, the file should get a new version number and a new copy of the file should be retrieved from the server.
  4. When a stylesheet file is updated, and it exists in the cache manager module, the file should get a new version number and a new copy of the file should be retrieved from the server.

top

System Status Tool

The system status tool provides module information as well as basic bug tracking information. The module information is updated every 4 hours, and is collected using keen.io. The bug information is updated by the minute for the last 24 hours, and is collected using www.atatus.com. The tool can be found at https://cstools.samaritan.com/data/system-status.php


top

Architecture

There are 4 main modules that support the Angular recruiter project. The UserManager, RecordManager, ConfigSettings and SamaritanDataService.

  • The SamaritanDataService is the direct communication path to the database via the Custom Environment. Requests are made through the sDs eg: sDs.send('er_volFields', ...).
  • The UserManager maintains roles for volunteers, organizations, and guests. Each role has their own record store for user specific records such as opp and slot placements, logbook entries, attachments, waivers etc. The user manager also stores many record formatters for the various records that are requested and stored. The userStore can be used to pass the current state of authorized users throughout the system.
  • The RecordManager maintains non-user specific records, such as opportunities, schedule slots and organizations. Records are provided to other parts of the system through the recordStore as the main container of non-user-specific data. The RecordManager also contains many record formatters to structure data properly before putting it in the recordStore.
  • ConfigSettings combines AMS, RMS and custom settings used throughout the system. The settings control functionality across various modules, within templates, and even within the RecordManager and UserStore.

top

Components

 

Modal: Modals are delivered using bootstrap's modal structure, and the bootstrap.ui angular module. There are basic confirm/cancel modals and custom or templated modals, which can all be configured to some degree. Custom modals can be called using the same service and will often be intermixed within standard functionality.

A list of modals includes:

    1. Login Modal
    2. Report Service Modal
    3. Confirm Modal (confirm/cancel)
    4. Missing Fields Modal
    5. New Required Fields Modal

 

Full Screen Frame: A full screen frame acts like a modal except that it takes up the entire screen. There is a close button that can close the frame. Full screen frames are often used to display iframes or menus and other navigation.

 

Sign Up Action Button: The Sign Up Action Button is a single button that is used for all assignment of volunteer to opp or slot (refer and place). The button begins a sign up wizard that can be configured to direct the user through the sign up process. The wizard can be configurable but almost always contains most of the following steps

List of common wizard steps:

  1. Group or individual?
  2. Log in or register?
  3. Confirm requirements message (prerequisites)
  4. Profile check / answer additional questions
  5. Select schedule slot
  6. Assign Volunteer (last step in all cases)

 

 

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

Powered by Zendesk