Release Schedule
Description | Date & Time |
|---|---|
Release No. | 6.4.0 |
Pilot Release | 02.19.19 - 9:00AM PST |
Production Release | 03.15.19 - 6:00PM PST |
| Release Type | Maintenance Window | Major Release |
Release Scope
| Description | Scope |
|---|---|
| Applications | CCCApply Standard Application (Apply) |
| Changes to Residency Logic | No |
| Changes to Download Client | Yes - (Download Client Jar 6.4.0) |
| Changes to Documentation | Yes - Data Dictionaries & User Guides |
| Anchor | ||||
|---|---|---|---|---|
|
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
Release Scope
| # | Change Requirement | Application | Notes & Change Request Docs |
|---|---|---|---|
| 1 | CCCApply Redesign |
| Project - User Interface Enhancements | CCCApply Standard & International Applications | See "Changes to User Interface" section |
| 2 | CCCApply |
Noncredit Application Path (Phase 1: Development |
) | CCCApply Standard Application only | CCCApply Noncredit Application | |
| 3 | Maintenance & Support (Admin Support, Tech Updates, and Bug Fixes) | CCCApply Standard & International Applications | See "Maintenance & Support" section |
| 4 | Bug Fixes | CCCApply Standard Application | See "Bug Fixes" section |
| 5 | Issue Resolution: |
| Problems with new Race & Ethnicity |
| Data Fields (Version 6.3.0, Dec 2018) | CCCApply Standard & International Applications | See "Issue Resolution" section Included in Hotfix 6.3.1 - January 25, 2019 |
Release Summary
This is the third release (3 of 4) of the CCCApply Redesign Project (Phase 1: Short-Term Redesign) - under under the guidance of the CCC Chancellor's Office, the CCC Technology Center, and the CCC Foundation to revise the CCCApply application in compliance with AB 3101. Read more about the CCCApply Redesign Project, including the project objectives and project planned release schedule for the first phase of the project (short-term revisions to the existing application) and future long-term plans to rebuild the application (holistic redesign). Also included in the redesign project, CCCApply Noncredit Application - Phase 1: Development
of the CCCApply Non-Credit Application| Note |
|---|
This is the third release (3 of 4) of the CCCApply Redesign Project (Phase 1: Short-Term Redesign) - under the guidance of the CCC Chancellor's Office, the CCC Technology Center, and the CCC Foundation to revise the CCCApply application in compliance with AB 3101. Read more about the CCCApply Redesign Project, including the project objectives and project planned release schedule for the first phase of the project (short-term revisions to the existing application) and future long-term plans to rebuild the application (holistic redesign). |
Pilot Preview
Due to the short timeline for this release, the Pilot preview period - the period in which our two external-facing CCCApply environments are not aligned, providing colleges user preview and implementation support prior to an upcoming production release - will begin Monday, November 19 through December 7, 2018. The CCCApply Support Services team will be monitoring feedback on the CCCTechnology.info support site and additional online support documentation and training will be available.
Release Schedule & Timeline
- February 19 - 9:00AM - 1:00PM (Note the Pilot Site will be down during this release).
- March 15 - 6:00PM - 11:00PM - Production Maintenance Window
| Info |
|---|
Stay Informed! For all the news, release announcements, updates, and CCCApply System Alerts, follow us on "CCCApply System Alerts" on CCCTechnology.info. |
, and information about the soft-launch of the College Pilot Project.
Pilot Release
The Pilot environment release is scheduled for February 19, 2019. This period is for colleges to preview interface changes and test bug fixes and prepare for new or changed data fields prior to the production release (March 15). The CCCApply Support Services team will be monitoring feedback on the CCCTechnology.info support site, and additional online support information will be available.
Release Schedule & Timeline
- February 19 - 9:00AM - 1:00PM (Note the Pilot Site will be down during this release).
- March 16 - 6:00PM - 11:00PM - Production Maintenance Window
| Info |
|---|
Stay Informed! For news, release announcements, updates, and CCCApply System Alerts, follow us on "CCCApply System Alerts" on CCCTechnology.info. |
Changes to the CCCApply Standard Application
The following changes and enhancements were approved and deployed in the 6.4.0 release code.
| # | Change Specification | Additional Info | |
|---|---|---|---|
| 1 | |||
- User Interface Enhancements | Approved changes intended to shorten & streamline the Standard App | |
| |||
Revise layout of the Residency page | See Changes to User Interface section below. |
Remove/Hide Questions from Special Residency Section Depending on Out-of-State Activity Response Hide the following questions in the Special Residency section by default for all users
| See changes to field values in Changes to Downloads below. See Changes to User Interface section below. |
Revise the "Out-of-State Activities" section on the Residency page and add skip logic to Show Special Residency questions |
| Revise/Hide Question on the Education page | See changes to field values in Changes to Downloads below. | ||
| 2 |
| Noncredit Application Path (Phase 1: Development) |
| See the CCCApply Noncredit Application See the Noncredit Application Path Requirements | |||
| Implement a new workflow path in the Standard Application, with no residency questions and does not calculate a preliminary residency determination via the Submission Calculation Service. | For students enrolling exclusively in noncredit courses | ||
; no credit is given. |
Implement new URL exclusively for the | |||
Noncredit path in the Standard Application. Unique for each college, based on MIS code. Replace XXX with college MIS code. |
| Revise the Confirmation |
| number (prefix) for applications |
| started and submitted using the |
| Noncredit URL |
| To identify and distinguish Noncredit applications from Standard applications, |
| Noncredit confirmation numbers |
| have |
| a prefix "NC-" for all applications that are started and submitted |
| using the |
| Noncredit URL. Example: "NC-4144323" |
| Hide the Citizenship & Military page in the |
| Noncredit App/Path | See |
| Changes to User Interface below. |
| Hide the Residency page in the |
| Noncredit App/Path | See changes to field values in Changes to Downloads below. |
| Hide questions on the Needs & Interests page in the |
| Noncredit App/Path |
| See Changes to User Interface below. | ||
|
| See Changes to User Interface below. |
| Add a new " |
| Noncredit Status" data field to Standard Application and set flag to "True" when the |
| Noncredit URL is used | See |
New & Changed Data Fields section |
| Add new "Integrity Flag 81" data field to the Integrity Flags table (Standard Application) and trigger if applicant applies using the |
| Noncredit URL | When Integrity Flag 81 is triggered, admissions office is flagged, "Applicant applied using the |
| Noncredit Application URL" |
| Add new value to the "Residency Status" field to identify " |
| noncredit / exempt" status | See New & Changed Data Fields section See changes to field values |
| in Changes to Downloads below. |
| Exclude |
| Noncredit App/Path from residency determination logic | If the new "non_credit" flag is set to "True" - the application is not put through the Submission Calculation Service and the residency status field is set to "N = |
| noncredit / exempt" |
| Add new value to "Residency Areas" status fields to identify " |
| noncredit / exempt" status | See changes to field values |
| in Changes to Downloads below. |
| Add logic to allow student's who submitted a |
| Noncredit application using the |
| Noncredit URL to re-apply to the same term, same college using the Standard Application | See Noncredit Application Workflow Change Requirements Removed restriction for |
| Noncredit > Standard Application transition only. |
| Implement auto-population for fields hidden in the |
| Noncredit Application if student re-applies using the Standard Application within 2 years. |
| Noncredit students may want/need to re-apply to enroll in credit courses. They should re-apply using the Standard Application to get residency-determination status. |
| See Noncredit Application Workflow Change Requirements | |||||||||
| 3 |
| ||||||||
| Add new v.6.4.0 fields to CCCApply Administrator Rules module: |
|
| The new v.6.4.0 data fields have been added to the Rules module in the CCCApply Administrator, and can now be used in |
| college email rules |
| and error messages. |
Add new v.6.4.0 fields to CCC Report Center |
domain and Full Application report templates: |
|
| The new v.6.4.0 data fields have been added to the Report Center. The Full Application report has been updated with these fields. Colleges can now be |
| used in custom |
| reports |
| . | ||
Add v.6.3.0 fields to the CCC Report Center and |
the CCCApply Administrator Rules module:
| Due to a bug in the Report Center admin service, these tasks were unable to be completed after the 6.3.0 release (Dec 2018). |
Add v.6.3.0 & 6.4.0 fields to the "Full Application" Report templates in the |
CCC Report Center
|
|
| Anchor | ||||
|---|---|---|---|---|
|
| # | Bug Description | Fix Details | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Issues: Problems with new Race & Ethnicity field values that were implemented in v.6.3.0 (Dec 2018) | |||||||||||
Issue 1 |
| Issue 2For affected submitted Apply and IA applications that have been submitted post Dec 14, 2018 and | have been downloaded by the college, the old values stored in the DB were sent over with | the submitted application without being translated | into to the XNY MIS Format. The formats are wrong in this use case and were to be fixed. Worst case scenario, the SIS has bad values and the colleges may/may not even be aware. | Solution 2: For affected submitted Apply and IA applications that have been submitted post Dec 14, 2018 and have been downloaded by the college, the old values stored in the DB were sent over with the submitted application without being translated into the XNY MIS Format. The formats are wrong in this use case and were to be fixed. Worst case scenario, the SIS has bad values and the colleges may/may not even be aware. See "Issue Resolution: Problems with the New Race & Ethnicity Disaggregation Project 2018" | Issue 3 The SPAM training is not working. After developer research, the training process began to fail because of the bad race/ethnicity values in the submitted apps table. | Solution 3: Unlike Issue 1, where the number of applications at-risk of being affected (in-progress applications) is diminishing over time, and Issue 2 - where the bad data is cleaned up and translation scripts are being run, Issue #3 potentially affects a larger number of applications that are not going through the spam filter training service due to the bad race values See "Issue Resolution: Problems with the New Race & Ethnicity Disaggregation Project 2018" | |||
| Issue 2 The SPAM training is not working. After developer research, the training process began to fail because of the bad race/ethnicity values in the submitted apps table. | Solution 2: Unlike Issue 1, where the number of applications at-risk of being affected (in-progress applications) is diminishing over time, Issue 2 potentially affects a larger number of applications that are not going through the spam filter training service due to the bad race values in the submitted applications table. This issue necessitated a hotfixhot fix release (Hotfix 6.3.1) which was deployed Friday, January 25, 2018 to production. | Missing Temporary workaround to app-export service so that it skips over any records that do not have the XYN format in the race ethnicity field. Records that contain numbers and commas should NOT be output since it breaks the SPAM retraining model. | |||||||||
| Issue: Missing Instructional Text in the new Race & Ethnicity Section that was intended for original implementation | Solution: Added missing instructional text for the Race/Ethnicity Section to read as follows:
| When doing my application for a new student via CCCapply, I got CCGI token and SSID from yesterdays application from a different user | |||||||||
Issue: Applicants reported getting 'Application not completed' email after successfully submitting their appapplication The issue affects any college with pre-submission rules and NO supplemental questions, this explains why our | dev development team didn't find this during regression testing, as our testing of college rules is based on a feature to allow rules to run against supplemental question fields. | Fix solutionSolution: we we fixed the residency calculations, as well as multiple other calculations we have to set residency flags, to happen when the user clicks the submit button. We run the pre-submission colleges rules before these calculations happen however. The flow is something like: expand What appears to be the root cause of this ticket is a null pointer exception thrown when we attempt to run the college validation rules. In the process of running the rules, we convert the application to its submitted format so that the field names and properties match up to the various database columns we map to on the submitted side so the colleges can reference the fields that way in the rules. To convert the residency flags, we call the toString() method on this object and if it is unitializedinitialized then it throws an NPE. If the college has supplemental questions, we run the residency calculation flow during the transition from the supplemental questions page to the submission page so the flags get properly initialized. However, if the college does not have supplemental questions, as is the case with Moreno (All of their supplemental questions as set to "active = false" in Prod), then the calculations that would populate these flags only occur after the flags have caused the NPE. | |||||||||
Issue: Fixed length varies with new download client | Missing validation in the Date of Birth field allowing future DOBs to be submitted | An applicant who submitted their application on 10/22/18 was allowed to provide a future date of birth of 01/20/19. Added logic that prevents an applicant from entering and saving a DOB that is a date greater than the current date:
| Address confirmation modal was not being displayed to homeless applicants | Implemented a fix to deliver expected behavior. The following message is now successfully displaying:
| Edit Account app is incorrectly saving the country code (i.e., U.S.) to the Phone Number Extension field and leaving the Problem: We added code that would strip out characters in what is called the "multilingual Supplementary Plane" of the unicode encoding. Unfortunately, some characters are not in that plane, but it still requires 3 bytes to encode it. | Solution: We updated the way we handle UTF-8 3 and 4 byte characters in the "Basic Multilingual Plane". Added flag to the download client to output code to either UTF or ASCII. Updated the Download Client User User v.2019.1 | |||||
| Issue: Missing validation in the Date of Birth field allowing future DOBs to be submitted | Solution: An applicant who submitted their application on 10/22/18 was allowed to provide a future date of birth of 01/20/19. Added logic that prevents an applicant from entering and saving a DOB that is a date greater than the current date:
| ||||||||||
| Issue: Address confirmation modal was not being displayed to homeless applicants | Solution: Implemented a fix to deliver expected behavior. The following message is now successfully displaying:
| ||||||||||
| Issue: Edit Account app is incorrectly saving the country code (i.e., U.S.) to the Phone Number Extension field and leaving the country code blank when the users went to edit their account in the applications. | Solution: Edit Account systems in the Standard, Promise Grant, and International Apps is now mapping and saving the correct phone number data values for the phone number, the extension, and the country code, etc., for the respective phone number for the Account Main and Secondary phone numbers after editing an account. | ||||||||||
| Issue: International App not saving the Current Mailing Postal Code correctly in downloads | Solution: Fixed an issue on the Account Information & Mailing page, where the database was not storing the same data values for the Current Mailing Address fields when the applicant checks the box stating that it is the "Same as their Permanent Address". QA has verified that these data values now match in the database. | ||||||||||
| Note |
|---|
All Changes Are Backwards Compatible - No Actions Required: All the front-end changes (user interface) and back-end API and database changes ( XYZ ) being implemented in this release are designed to be backwards compatible with your existing Download Client and download files. |
| Anchor | ||||
|---|---|---|---|---|
|
Problems Encountered After Deployment of the New Race & Ethnicity Implementation (v.6.3.0, December 2018)
In the CCCApply 6.3.0 release (December 2018), CCCApply was updated to include a larger set of race groups and ethnicities as part of the 2018 Race & Ethnicity Disaggregation project. The objective of the project was to add expand upon the race groups and ethnicities collected in CCCApply and disaggregate the existing race groups in order to support student equity services across the system.
- The objectives for development was to add over 200+ new race groups and ethnicity options to the database (and to the user interface) for delivery to the college, but still also maintain delivery of the original data fields and values for MIS reporting. In order to deliver both these files, we had to refactor the code in the background to ensure the data was clean and easy to maintain.
- Before the 6.3.0 release, the raw values for the users choices were stored to the database column "race_ethnic" in a CSV format (example: "02, 03, 06, 16"). At submission time, this would be translated to the MIS format of "YYYNNYNNNNNNNNNYNNNNN" and stored in the "race_ethnic" column of the submitted application.
- In the process of the new implementation, we changed where we do this translation to whenever the user saves their demographic information so that in the new code we are never storing the raw values, we are always storing the "YYYNNY..." format to the race_ethnic column.
- At submission time, this value is sent over directly with the submitted application without needing translation at submission time.
- However, a use case that is often challenging to significant development changes to CCCApply are the "in-progress applications" that are started but not submitted before a major release. This was also the case with this implementation, and we ran into an issue with applications that were started before the 6.3.0 release on December 14th, 2018 and resumed after the release to a page that was after the Demographic Information page. In this case the old, raw values would still be stored with their in-progress application, loaded from the database and submitted with their application.
- Note that this only affects applications that were resumed directly to a page after the Demographic Info page which are the Supplemental Questions page or the Submission page and then submitted without the user going back through the Demographic information page and revising their responses for the new Race & Ethnicity format and layout. Due to the nature of this bug (affecting in-progress applications), the number of applications that will be submitted that were in-progress before Dec. 14th is limited and will diminish over time. In fact, by the time the issue was identified, researched, and resolved - we saw a significant decline in reports from colleges and the number of at-risk, in-progress applicants diminished as predicted.
Types of Issues Reported
Immediately following the 6.30 release, we received requests for support from 6 colleges related to:
- Problems with bad data interrupting download processes
- Bad data appearing in Report Center reports
Work-arounds proposed and documented
- We do not have a proposed work around at this time. The issue is that the affected applications have bad data in them, the best we can suggest is to maintain a record of the affected apps downloaded, and we can provide instructions for how to translate the race_ethnic value to the correct format if necessary.
- For colleges affected by this, if they maintain a record of the affected applications they could potentially wait until we run the script to fix the values in the submitted application DB, and then reset those apps for download again so they can load them into the service they have that consumes the submitted applications. Each colleges process is probably too different and customized to be able to provide a concrete work around however.
Solution: Fix to the Translation Logic and Data
- The first is to put the translation logic back in at submission time. If an application is submitted that does not have without the MIS formatting, then it will be properly translated before it is submitted.
- The second approach is we have built a small script that will connect to the submitted application database, search for the affected applications, and perform the translation of any race_ethnic values that have the improper format.
Data fixes will roll out in the March release (6.4.0)
| Anchor | ||||
|---|---|---|---|---|
|
The The following data fields have been added or changed in the CCCApply applications. Please see specific data and logic specifications in the updated version of the CCCApply Standard Application Data Dictionary. For all data specification documents, please see the CCCApply Data Dictionaries and For updated data specification documents, please see the CCCApply Data Dictionaries and CCCApply User Guides space.
| Note |
|---|
Update Your Download XML Files: In order to download new or revised data fields, you they must first add them to your corresponding be added or updated in the CCCApply Format Definitions XML file(s) and update/replace the current and the download client jar file must also be updated with the latest version = < transfer-client.jar v.6V6.4.0 >jar > For more information, please see the CCCApply Download Client User Guide > CCCApply User Guides |
New & Changed Data FieldsAnchor data-fields data-fields
The table below provides an overview of the new or changed data fields in CCCApply Standard, and "Glue for Apply".
Description
Data Element
See these data specification changes in the CCCApply Standard Application Data Dictionary V.2019.1 in the Data Dictionaries space.
Description | Data Element | Type | Value / Response Options | Format / Length | Allows Null | Required | Notes | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Non-Credit Noncredit Status | <non_credit> | New Field | 1 = True 0 = False | Boolean, 1 | Yes | No | Optional; Value set to "True" if applicant applies using the new Non-Credit Noncredit Application URL; otherwise it is "False" | Confirmation Number | <confirmation> | Changed Value | IF non_credit=True then" | String | No | SystemIF an application is submitted using the Non-Credit URL then the value for <confirmation> = "NC-" | |
| Integrity Flag 81 | <integrity_fg_81> | New Field | 1 = True Null | Boolean, 1 | Yes | No | Flag triggered if applicant applies with the new Non-Credit Noncredit Application URL; otherwise it is blank. NOTE - this is consistent with how we have all the other integrity flags structured. | Residency Status | <res_status> | New Value | |||||
| Confirmation Number | <confirmation> | Changed Value | IF non_credit=True then | String | No | System | IF an application is submitted using the Noncredit URL then the value for <confirmation> = "NC-" | ||||||||
| Residency Status | <res_status> | New Value | New NC default value = N 1 = resident | bpchar, 1 | No | Residency status is calculated at submission for Standard Application only. For the new Non-Credit Noncredit Application path (in the Standard Application) if applicant applies using the new Non-Credit Noncredit URL then: <non_credit> status is set =True and <res_status> status is set ="N" | |||||||||
| Residency Area A | <res_area_a> | New Value | New NC default value = 9 | Boolean, 1 | No | Residency area status defaults to "9" when (non_credit =True) | |||||||||
| Residency Area B | <res_area_b> | New Value | New NC default value = 9 | Boolean, 1 | No | Residency area status defaults to "9" when (non_credit =True) | |||||||||
| Residency Area C | <res_area_c> | New Value | New NC default value = 9 | Boolean, 1 | No | Residency area status defaults to "9" when (non_credit =True) | |||||||||
| Residency Area D | <res_area_d> | New Value | New NC default value = 9 | Boolean, 1 | No | Residency area status defaults to "9" when (non_credit =True) | |||||||||
| Declared Residency Outside California for Taxes | <ca_outside_tax> | Default values = False / Null | Values = True / False / Null 1 = True 0 = False Null | Boolean, 1 | Yes | No | IF the question is displayed:
IF question is hidden:
NOTE: IF hidden, such as in the Non-Credit Noncredit application, then default to NULL For a standard application, it will default to False, unless the user checks the checkbox. | ||||||||
| Declared Residency at a College Outside California | <ca_outside_college> | Default values = False / Null | Values = True / False / Null 1 = True 0 = False Null | Boolean, 1 | Yes | No | Same as Above. | ||||||||
| Registered to Vote Outside California | <ca_outside_voted> | Default values = False / Null | Values = True / False / Null 1 = True 0 = False Null | Boolean, 1 | Yes | No | Same as Above. | ||||||||
| Lawsuit Filed Outside California | <ca_outside_lawsuit> | Default values = False / Null | Values = True / False / Null 1 = True 0 = False Null | Boolean, 1 | Yes | No | Same as Above. | ||||||||
| Public School Employee | <ca_school_employee> | Default value = Null | Values = True / False / Null 1 = True 0 = False Null | Boolean, 1 | Yes | Required response If appears onscreen | |||||||||
| State College Employee | <ca_college_employee> | Default value = Null | Values = True / False / Null 1 = True 0 = False Null | Boolean, 1 | Yes | Required response If appears onscreen | |||||||||
| Seasonal Agricultural Worker | <ca_seasonal_ag> | Default value = Null | Values = True / False / Null 1 = True 0 = False Null | Boolean, 1 | Yes | Required response If appears onscreen | |||||||||
| Citizenship Status | <citizenship> | New Value | Default to value = X when (non_credit = True) | character(1) | No | Required to have non-null value in DB. | In the new Non-Credit Noncredit Application workflow, the Citizenship status question is hidden; value stored = "X" | ||||||||
| Military Status | <military_status> | New Value | New NC default value = X Default to value = X when (non_credit = True) | character(1) | No | Required to have non-null value in DB. | In the new Non-Credit Noncredit Application workflow, the Military status question is hidden; value stored = "X" | ||||||||
| Comfortable with English | comfortable_english | Allow Null | NC default value = null | Boolean, 1 | Yes | No | In the new Non-Credit Noncredit Application workflow this question is hidden; value stored = Null | ||||||||
| Financial Assistance | financial_assistance | Allow Null | NC default value = null | Boolean, 1 | Yes | No | In the new Non-Credit Noncredit Application workflow this question is hidden; value stored = Null | ||||||||
| TANF-SSI-GA | tanf_ssi_ga | Allow Null | NC default value = null | Boolean, 1 | Yes | No | In the new Non-Credit Noncredit Application workflow this question is hidden; value stored = Null | ||||||||
| Athletic Interest: Intramural | athletic_intramural | Allow Null | NC default value = null | Boolean, 1 | Yes | Required response If appears onscreen | In the new Non-Credit Noncredit Application workflow this question is hidden; value stored = Null | ||||||||
| Athletic Interest: Intercollegiate | athletic_intercollegiate | Allow Null | NC default value = null | Boolean, 1 | Yes | Required response If appears onscreen | In the new Non-Credit Noncredit Application workflow this question is hidden; value stored = Null | ||||||||
| Athletic Interest: No | athletic_not_interested | Allow Null | NC default value = null | Boolean, 1 | Yes | Required response If appears onscreen | In the new Non-Credit Noncredit Application workflow this question is hidden; value stored = Null |
| Anchor | ||||
|---|---|---|---|---|
|
| Page / Section | Description | Current UI State | New Revised UI State | Notes to Colleges |
|---|---|---|---|---|
| Residency page | Revise the layout of the Residency page Reorder the questions and sections on the Residency Page for all users
| Currently the layout of the Residency page places the Special Residency section in the middle between the California Residence and the Out-of-State Activities sections. This layout prohibits the ability to implement skip logic to streamline the experience for CA residents. | The new order of sections/questions on the Residency page is:
| This is a layout change and there are no changes required by the college
|
| Residency | Hide three questions in the Special Residency section by default for all users
Add logic to Show the three questions as a group if user selects one or more Out-of-State activities and the most recent year is within 2 years of the RDD. | Currently, all Special Residency questions display to all users in Yes/No radio button format and a response to each question is required. | The Special Residency section now only displays the Homeless Youth Status and Foster Youth Status questions to all users with all existing validation and logic in place. If user selects (checks) one or more of the "Out-of-State Activities" with the most recent year of activity is within 2 years of the RDD, then the three hidden special residency questions will display as a group and responses will be required. | Note: The Homeless Youth and the Foster Youth questions ALWAYS display and each requires a response by all users. College needs to be aware that this field will now allow a null Note: In 2018, only 1% of all applicants responded Yes to this question. |
| Residency | Revise the "Out of State Activities" Section by combining four separate, required questions into one optional question with skip logic to shorten the Special Residency section Combine the four current "Out-of-State Activity" questions into ONE new question, and change the format of the response options from required, Yes/No radio buttons and set the default to "No". | Currently, the "Out-of-State Activities" section consists of four separate, required, Yes/No questions with conditional "Year" fields that appear if the user answers Yes to any of the specific questions. | The new "Out-of-State Activities" section now contains one question (onscreen text) with four optional checkbox response options (the original four OOS questions, revised). "As of <RDD minus 2 years>, have you engaged in any of the following activities? Check each activity that applies." [checkbox] I paid taxes outside of California [checkbox] I registered to vote outside of California [checkbox] I declared residency at a college or university outside of California [checkbox] I filed for a lawsuit or divorce outside of California All existing data fields would persist (no change to data output, downloads, etc.) | There is no change to the text, conditions, logic or data fields for the four, corresponding Out-of-State Activity Year fields section/questions. The four Out-of-State Activities questions/fields are now optional (responses are no longer required by default) and the data fields will now accept Null or blank. |
| Education | Hide the College Education Level and Add logic to the College Enrollment Status question to only show college sections if the user is NOT a first-time in college after leaving high school | Currently, the College Education Level section and the Colleges/Universities Attended sections are required questions/sections that appear to all users on the Education page, even for students who have never attended college in the past. | The College Education Status and Colleges/Universities Attended sections/questions will not display on the Education page unless the user indicates they have attended one or more colleges in the past. If the user selects "first-time in college after leaving high school" option in the College Enrollment Status question, do not show college questions and default field value to Null. | |
| Non-Credit Noncredit Application | Add a Prefix to the Confirmation Number for Non-Credit Noncredit Applications | The Confirmation number (as well as the App_ID) will include a prefix of "NC" if the application is started and submitted using the Non-Credit Noncredit URL. | Example: NC-4140067 | |
| Non-Credit Noncredit ApplicationThe Residency Page does not appear | Hide the Residency Page in the Non-Credit Noncredit Application path | When a student applies to your college using your Non-Credit Noncredit URL, the user interface and the user experience will be very similar to the Standard Application but the residency page is not included in the workflow. No residency page questions are required at the time of submission.Non-Credit | ||
| Noncredit Application | The Hide the Citizenship & Military Page does not appear in the Non-Credit in the Noncredit Application path | The Citizenship & Military page of questions do not appear in the Non-Credit Noncredit Application workflow | ||
| Non-Credit Noncredit Application | Question Hide questions from the Needs & Interests Page do not appear in the Non-Credit Noncredit Application path: Main Language: Financial Assistance: Athletic Interest: | Several Needs & Interests page questions do not appear in the Non-Credit Noncredit Application workflow; however, the Programs & Services table DOES APPEAR in the Non-Credit Noncredit Application workflow as a series of optional checkboxes. | ||
| Non-Credit Noncredit Application | Auto-population of Non-Credit Noncredit Application responses in the Standard Application | Non-Credit Application | Questions and pages that WILL APPEAR in the Non-Credit Application Path | Non-Credit App |
Changes to "Glue for Apply" and SuperGlue College Adapter
NOTE: Talk to Glue team about whether the race fields from 6.3.0 are being added this time or if they're already added from the last Glue release in January?| Note: Auto-population will pre-fill previously submitted responses from the last application submitted within 2 years of current date. | ||||
| Noncredit App | Add logic to allow applicants to re-apply to the same college and the same term when transitioning from Noncredit to Credit status | Currently, the Standard Application prevents a user from submitting two applications to the same college for the same term. This | With the implementation of the Noncredit Application path, a student who submits a Noncredit Application to college (A) for term (A) is now able to re-apply with the Standard Application to college A for term A. This logic has been modified for Noncredit > Standard Application only. | (NOTE: This means that a student who has submitted an application to a college (example: College A, Term A) using the Noncredit Application, can now re-apply (submit a Standard Application to the same college for the same term A). However, this only applies to students transitioning from Noncredit status to Credit status; otherwise they will be blocked from submitting a second Standard Application to the same college, same term.) |
| Anchor | ||||
|---|---|---|---|---|
|
Description | Data Field | Format / Length | Required | Notes |
|---|---|---|---|---|
| Non-Credit Noncredit Status | <non_credit> | Boolean (True/False) | No | Optional field set to "True" if applicant applies with the new Non-Credit Noncredit Application URL; otherwise it is "False" |
| Integrity Flag 81 | <integrity_fg_81> | Boolean (Y/N) | No | Flag triggered if applicant applies with the new Non-Credit Noncredit Application URL; otherwise it is blank. |
| Race Ethnicity Full | <raceEthnicFull> | CSV delimited Maximum Expected Width: 805 characters (201 * 3 character long values + 200 commas + 2 surrounding quote marks for CSV delimiting in the output format) | No | NOT AVAILABLE in the Release 6.3.0. |
| Note |
|---|
The new Race & Ethnicity values included in this release will be passed directly to colleges using the Glue for Apply feature. However, the new full Race & Ethnicity field is not yet available through Glue for Apply at this time. An upcoming release of the SuperGlue College Adaptor will include this new data. |
User Acceptance Testing (Pilot)
User acceptance testing and implementation support for this release is focused on the user interface changes deployed as part of the CCCApply Redesign Project - Phase 1. Colleges are encouraged to preview the new implementation in the Pilot Environment on February 15. For all release announcements and system alerts, please follow "CCCApply System Alerts" on CCCTechnology.info.
- UAT GOALS & OBJECTIVES
- UAT SUCCESS CRITERIA
- UAT STEPS
User Acceptance Testing (Pilot)
User acceptance testing for this release involves previewing the user interface changes that are being deployed as part of the CCCApply Redesign project. Colleges are encouraged to log in to their Pilot application (after the deployment on February 19) and review the changes.
UAT Plan: CCCApply Release 6.4.0
| Info | ||
|---|---|---|
| ||
To participate in the CCCApply Noncredit Application College Pilot Project, please contact Patty Donohue, Product Manager, pdonohue@ccctechcenter.org Details will be emailed to volunteers, including an informal MOU agreement, bi-weekly meeting schedule, IT implementation checklist tasks, and Admission staff testing criteria. NOTE: We will not exclude any college that wants to participate fully in this project; however we have just 12 weeks to test and discuss enhancements before the June 2019 production release. An online demonstration webinar will be announced for the week of February 25 (and the demo will be recorded). |
UAT Feedback & Resolution Process
- Gathering Feedback: Feedback should be categorized as bugs, issues or enhancements. Only Severity 1 issues (issues that prevent critical business functions from being accomplished) will be considered as production release blockers.
- Reporting Feedback: User feedback should be noted in the result section. The following criteria should be followed and documented:
- Any identified bugs with severity and priority
- Enhancement requests with priority identified
- Issues that prevent critical business functions
UAT Plan: CCCApply Release 6.4.0
| Info |
|---|
Preview & Send Us Feedback: During the Pilot preview, your feedback is important to our commitment to continuous improvement. If you find a bug or experience any issues, please let us know by posting in the CCCApply Support category on CCCTechnology.info. |
Data Dictionaries & Release Documentation
The following links point to the most current versions of the CCCApply Data Dictionaries and User Guides.
| Description | Version / FILE | Format | Release | Date Published | |
|---|---|---|---|---|---|
| CCCApply Standard Application Data Dictionary | V.2019.1 | Release 6.4.0 | 02.1519.19 | ||
| Download Client Jar File V.6.4.0 | transfer-client | -V.6.3.0.V6.4.jar | jar | Release 6.4.0 | 02.19.19 |
| CCCApply Download Client User Guide | V.6.4.0.0 | jarONLINE | Release 6Release 6.4.0 | 02.1519.19 | |
| 2019-2020 CC Promise Grant Data Dictionary | CCPG-V2019 | 2019-2020 | 11.20.18 | ||
| CCCApply International Application Data Dictionary | V.2019.1 | Release 6.4.0 | 02.1519.19 |