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:

Entering no user details: error should show for each field and generic login error

Entering a userId only: error should show for password field and generic login error

entering a password only: error should show for userid field and generic login error

entering both fields with one of the fields being invalid: generic login error

attempting to login more than 3 times with both fields populated: reCaptcha should show and be required to continue

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:

A session should be destroyed when the browser or tab is closed: test by logging in, closing tab and reopening.

A session should be destroyed when a user logs out: test by logging out and refreshing page.

A session should be destroyed when a user is inactive: test by logging in, then going inactive for duration of time set in RMS.

A session should be retained through page refreshes: test by logging in and refreshing the page.

A session timeout should be refreshed when navigating to another page.

A session timeout should be refreshed by any user interaction (moving mouse, clicking buttons).

A session timeout should be refreshed on modals and in iframes.

If a user is still active, a request (to the server to keep the session alive) should be sent every 29 seconds.

When a session is close to timing out, it should display a modal giving the user a chance to refresh the session.

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:

It should hide breadcrumbs on scrolling

When the screen is too small to display all links, it should show a clickable menu icon instead.

When the window or display is reduced or expanded it should re-evaluate if the menu Icon is necessary and display it accordingly.

When the menu icon is clicked it should display the collapsible menu according to the configured method.

The collapsible menu should contain all configured links.

If a search link is displayed on the collapsible menu, it should have a sub-nav tree which contains the search filters panel.

If a link is configured to display when "logged in", and a volunteer is logged in, it should display.

If a link is NOT configured to display when "logged in", and a volunteer is logged in, it should not display.

If a link is configured to display when "not logged in", and a volunteer is not logged in, it should display.

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:

It should allow menu items to be added.

It should allow menu items to be rearranged.

It should allow menu items to be deleted.

It should allow link URL, label, and title (hover title) to be configured

It should allow custom classes to be added.

It should allow menu items to be configured with icons.

It should allow menu position to be configured.

It should allow configuring of "logged in" and "not logged in".

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.

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:

When an attachment is not uploaded, it should provide an upload link.

When an attachment is uploaded, the attachment should show uploaded and provide delete and reupload links.

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:

When a filter is selected, it should add that filter to the URL automatically.

When a filter is removed, it should remove that filter from the URL automatically.

When a sort is added, it should be added to the URL automatically.

When a sort is removed, it should remove it from the URL automatically.

When a filter or Sort is changed it should update all corresponding displayed records.

Search filters/sorts should be retained when any back button or link is used.

Search filters/sorts should be retained when any back button or link is used.

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:

It should update search results automatically after clicking on a checkbox or radio button

It should update search results after pressing enter or leaving the keyword field

It should allow search results to be sorted by title in ascending or descending order

It should allow search results to be sorted by publish date in ascending or descending order

Map view test cases:

It should provide a pin for each opportunity that has custom coordinates, a location address or a contact address

If custom coordinates are provided, it should provide a pin based on custom coordinates first

If no custom coordinates are provided, it should provide a pin matching the location address

If no location address is provided, it should provide a pin matching the contact address

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)

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.

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:

It should display schedule slots for the filtered opps on the calendar.

If there is no schedule slot for the opportunity, it should do nothing.

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:

It should not display schedule slots that exist past the opportunity's expiration date.

It should not display day off schedule slots.

If the Start Date filter is used: It should not display schedule slots that start before the set date.

If the End Date filter is used: It should not display schedule slots that end after the set date.

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.

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.

If A buffer time is configured: it should filter out events that start before the current date plus the buffer time.

It should load and make available for display, the amount of slots equal to what is configured in RMS.

Test cases for list view:

It should provide details about the parent opp for each schedule slot, such as opp title (this is configurable, and may vary).

It should provide a message indicating the number of results.

It should default to sort by date/time.

It should allow sort by title, which sorts by opportunity title.

It should provide links to opportunity details (note the search criteria are not applied to opp details)

Test cases for calendar view:

If there are 3 or fewer slots, it should list each slot available for that day.

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

If an individual slot is clicked, it should open a modal window with information about that slot

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.

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.

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:

It should get all historical waivers for the current user.

It should only add waivers that match the "require when" configuration criteria to the required waivers.

It should compare all current waiver requests to historical waivers before adding them to required waivers.

It should open a modal notification that users accept, before loading any waivers.

It should display required waiver(s) when requested (on opp sign up or other trigger event).

If the waiver is a generic waiver, it should show the survey iframe.

If the waiver is a DocuSign waiver it should show the DocuSign iframe (full screen frame).

If multiple waivers are required, it should display the next waiver after the current waiver is completed, until all waivers are signed.

Cancelling a waiver should close all user interface components for that waiver.

Waiver type Logbook entries should not display in the logbook with normal LBE entries.

Test cases for opp prerequisite waivers:

It should display a message modal with a list of all required waivers before displaying the first waiver.

Once all waivers are signed, it should place/refer volunteer to opportunity as configured. (see general test cases for process)

If the waiver is cancelled, it should not place or refer you to the opportunity.

Test cases for triggered waivers:

When triggered, It should load the proper waiver in either a full screen frame or a modal based on configuration.

If the waiver process is cancelled it should not perform any additional actions.

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:

It should create a LBE if there are mapped LBE fields in the waiver configuration.

It should create a DocuSign envelope and put the envelope GUID into the mapped LBE or VOL field.

It should pass the OPP ID, LBE ID, Survey ID, and all configured custom field values to the DocuSign envelope record.

It should populate the DocuSign document tabs with data from the configured display fields in the DocuSign visible document & envelope record.

It should attach the DocuSign document to the mapped VOL or LBE attachment after being signed.

It should update the mapped LBE or VOL field with the DocuSign status.

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.

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:

It should display the current time within 1 second.

It should allow eCoordinator (admin) login access.

It should allow the user to select a station and opportunities to use.

It should show all volunteers who are placed in a schedule slot, based on selected opportunities, for the current day.

It should allow admin users to see all scheduled volunteers for the day.

It should allow admin users to modify start and end times for any volunteer for the day.

It should allow admin users to log in or log out any volunteer scheduled for the day.

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.

It should allow admin users to find a volunteer and place them with a specific schedule or opp that is configured for the station.

It should allow admin users to create a guest account

Open roster test cases:

It should pull opportunity and schedule slots for selected Sign in Stations, regardless of recruiter visibility.

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.

It should be able to filter roster names by a search field for first and last name.

It should allow users to set their group size (when enabled).

When allow guest is enabled, it should allow guest sign up into currently available schedule slots.

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).

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:

It should provide an error message if the username/password or email could not be validated.

It should provide an error message if the email exists for multiple volunteers.

It should provide a list of upcoming schedule slots and/or opportunities when a user logs in.

It should allow users to take an additional survey upon entering credentials after already logged in (if enabled).

Guest sign in test cases:

It should check for existing records based on email address.

It should create a new record using the volunteer name and email.

It should present a list of opportunities and/or schedule slots available for the guest to sign in for.

It should add the guest to the roster list if the open roster mode is the main mode.

Take Survey

It should be possible to enable additional surveys to be completed without signing out of the sign in station.

Additional surveys should be determined by those available for the volunteer and opportunity.

It should be possible to restrict/specify which surveys are available via the "Take survey" link.

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:

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.

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.

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.

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.

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.

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:

Login Modal

Report Service Modal

Confirm Modal (confirm/cancel)

Missing Fields Modal

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