Release 6.4.0 Summary Notes
- Patricia Donohue
- Mary Gwozdz (Deactivated)
- Dawn Edmunds (Unlicensed)
- Amanda Mason (Unlicensed)
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 |
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 of the CCCApply Redesign Project 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 release schedule for the first phase of the project and future long-term plans to rebuild the application (holistic redesign). Also included in the redesign project, CCCApply Noncredit Application - Phase 1: Development, 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
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 | CCCApply Redesign - 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. Example: https://pilot.opencccapply.net/cccapply-welcome?cccMisCode=XXX&nonCredit=True | |||
| 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 | Maintenance & Support Changes | ||
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
| |||
Bug Fixes
| # | Bug Description | Fix Details | |
|---|---|---|---|
| Issues: Problems with new Race & Ethnicity field values that were implemented in v.6.3.0 (Dec 2018) | |||
Issue 1 |
For affected submitted Apply and IA applications that have been submitted post Dec 14, 2018 and downloaded by the college, the old values stored in the DB were sent over with submitted application without being translated 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. 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 hot fix release (Hotfix 6.3.1) which was deployed Friday, January 25, 2018 to production. 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:
| ||
Issue: Applicants reported getting 'Application not completed' email after successfully submitting their application The issue affects any college with pre-submission rules and NO supplemental questions, this explains why our 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. | Solution: 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:
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 initialized 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 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. | ||
Issue Resolution: Problems with the New Race & Ethnicity Data Fields
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 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 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)
Changes to the CCCApply Download Client
The following data fields have been added or changed in the CCCApply applications. For updated data specification documents, please see the CCCApply Data Dictionaries and CCCApply User Guides space.
Update Your Download XML Files: In order to download new or revised data fields, they must first be added or updated in the CCCApply Format Definitions XML file(s) and the download client jar file must also be updated with the latest version = < transfer-client.V6.4.jar > For more information, please see the CCCApply Download Client User Guide > CCCApply User Guides
New & Changed Data Fields
The table below provides an overview of the new or changed data fields in CCCApply Standard, and "Glue for Apply".
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 |
|---|---|---|---|---|---|---|---|
| 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 Noncredit Application URL; otherwise it is "False" |
| Integrity Flag 81 | <integrity_fg_81> | New Field | 1 = True Null | Boolean, 1 | Yes | No | Flag triggered if applicant applies with the new Noncredit Application URL; otherwise it is blank. NOTE - this is consistent with how we have all the other integrity flags structured. |
| 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 Noncredit Application path (in the Standard Application) if applicant applies using the new 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 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> |