Version 6.12.2 - (released 3/18/2016)

• 
  Major bug fix: If the function min() or max() is used in a calculated field in which one of the values used in the function is blank/null, then auto-calculations (via data import, Data Quality rule H, etc.) would mistakenly return an incorrect answer. This is despite the fact that it would calculate it correctly when viewing the calculated value on a data entry form or survey. In this way, the calculation might get saved correctly initially but then may get changed later to the incorrect value via auto-calculations or by running rule H in the Data Quality module.
  
• 
  Major bug fix: If a calculated field has somehow ended up having an incorrect value when its value should instead be blank/null, then auto-calculations (via data import, Data Quality rule H, etc.) would mistakenly not be able to correct the value to set it as blank/null. This would often be seen when running rule H in the Data Quality module, in which it would appear not to fix any values even though it said that it did fix them. (Ticket #1156)
  
• 
  Major bug fix: If a user executes rule H in the Data Quality module in which some of the values listed exist on a data entry form that has been locked, then the process will fail when the user attempts to fix all incorrect calculated values, even though it may mistakenly say that it did fix them. This prevents any of the calculations from being fixed in the project. (Ticket #1156)
  
• 
  Bug fix: If a user accesses a data entry form that has been disabled (either because they have read-only form rights or because the form is locked), then calculations could be triggered on that page when the page loads, thus changing the values of the calc fields and possibly showing/hiding other fields if they have branching logic based on those calc fields. This is normally fine if the data is not being saved; however, if the user leaves the page, it would mistakenly display for them the "Save your changes?" dialog, which inadvertently allows them to save the values of those calc fields even though they should not be able to modify data on that page. (Ticket #1128)
  
• 
  Bug fix: If a drop-down field on a survey has a Stop Action and the auto-complete feature is enabled for the drop-down field, then if the Stop Action gets triggered by a participant, then it would not correctly remove the field's value if the participant clicked the button "Continue survey and undo last response" and might also cause lots of popups to pile on top of each other.
  
• 
  Bug fix: If a survey participant is using IE6 or IE7, then it would throw a JavaScript? error on the Survey Completion Text page after completing the survey (although it would successfully save their responses with no problem). (Ticket #1142)
  

 New feature: Live Filters for reports

• 
  Any report can now have up to 3 fields that can be designated as a Live Filter. The Live Filters are displayed as drop-downs when viewing a report at the top-right of the page, and selecting a Live Filter will cause the report to be re-run in real time using the Live Filter value as a filter.
  
• 
  If exporting a report that has a Live Filter selected, the export popup window will provide an extra choice to allow the user to export the full report data set or to apply the currently selected Live Filter to the report when exporting.
  
• 
  Note: Currently only multiple choice fields can be used as Live Filters (as well as Events, if longitudinal, and Data Access Groups, if any exist).
  

 NEW FEATURES & IMPROVEMENTS:

• 
  Improvement: New option to download charts displayed on the "Stats & Charts" tab of the "Data Exports, Reports, and Stats" module. The charts will download as PNG image files.
  
• 
  New feature: Users may now export a project’s data in CDISC ODM format. This new option is found on the “Data Exports, Reports, and Stats” page in the data export popup when selecting export format.
  
• 
  New feature: An entire REDCap project can now be exported as a single XML file (which happens to be in CDISC ODM format). The file includes events, arms, instruments, fields, and project attributes – even Descriptive field attachments. If the project contains data, then the user can also optionally export the project data (including uploaded files) in the same XML file. This XML file can serve as a snapshot or backup copy of the project, and can even be imported on the Create New Project page to create a clone (more or less) of the project.
  
• 
  New feature: Create a new project from a REDCap XML file (or other XML file containing metadata in CDISC ODM format). This is a new option on the Create New Project page, which allows the user to optionally upload their XML file rather than choosing a project template or creating the project from scratch.
  
• 
  New and improved SDK developer methods for plugins and hooks
  
  • 
    REDCap::getProjectXML – New method – Returns the contents of an entire project (records, events, arms, instruments, fields, and project attributes – even uploaded files and Descriptive field attachments) as a single XML file, which is in CDISC ODM format.
    
  • 
    REDCap::getData – Parameter for data format now accepts value of “odm” to export data in CDISC ODM format. This only returns data (not the project structure/metadata).
    
  • 
    REDCap::saveData – Parameter for data format now accepts value of “odm” to import data in CDISC ODM format. This only returns data (not the project structure/metadata).
    
• 
  New and improved API methods
  
  • 
    Export Project XML – New API method – Returns the contents of an entire project (records, events, arms, instruments, fields, and project attributes – even uploaded files and Descriptive field attachments) as a single XML file, which is in CDISC ODM format.
    
  • 
    Export Records – Parameter for data format now accepts value of “odm” to export data in CDISC ODM format. This only returns data (not the project structure/metadata).
    
  • 
    Import Records – Parameter for data format now accepts value of “odm” to import data in CDISC ODM format. This only returns data (not the project structure/metadata).
    
  • 
    Create Project – New optional parameter named “odm” can be used to pass the ODM XML string of an entire project’s structure (the same as output by the Export Project XML method) when creating a new project using a Super API Token. This will allow you not only to create the project with the API request, but also to import all fields, forms, and project attributes (and events and arms, if longitudinal) as well as record data all at the same time.
    

• 
  Major bug fix: When using Table-based authentication, in which a new user account is created and the user receives an email to set their password, in some cases it would mistakenly cause multiple false logins after loading the page, which might possibly trigger the auto-lockout feature. If this happens, the user would have to wait until after the set lockout period has passed, but it is possible that the auto-lockout could occur again, thus preventing the user from gaining access to REDCap for a while. This does not occur on all occasions but only randomly. This bug was thought to have been fixed in a prior version but apparently still occurred in certain cases. (Ticket #1112)
  
• 
  Bug fix: If running PHP 5.1 or 5.2 on the REDCap web server, REDCap might not be able to send emails successfully but instead will throw a PHP parsing error. Bug introduced in REDCap 6.11.0.
  
• 
  Bug fix: When using a survey theme on a survey containing a matrix of fields, it would mistakenly not highlight the matrix field labels in green when focus is put on the field.
  
• 
  Change: Added a new check to confirm that the version directory of the current REDCap version (e.g., redcap_v6.12.0) has not been mistakenly removed from the web server, thus resulting in a strange non-styled Home page or My Projects page.
  
• 
  Bug fix: If the system-level setting "Enable the use of surveys in projects?" is disabled on the Modules Configuration page in the Control Center, then it would mistakenly still allow users to access survey modules in a project if surveys had been enabled in the project prior to the disabling of the system-level survey setting. (Ticket #1124)
  
• 
  Bug fix: The Logging page in a project would mistakenly not display the logged event correctly when uploading or downloading a file attachment on a Descriptive field. Instead it would display it similar to that of a file uploaded to a File Upload field.
  

 New feature: Domain whitelist for cross-domain HTTP access control - By default, for flexibility purposes, AJAX requests (via JavaScript?) can be made to REDCap from any domain/URL. If you wish to restrict this so that only certain domains can make cross-domain AJAX requests to REDCap, then you will need to set the domain name of all allowed access control origins (i.e., the domain of the URLs) in the text box to the right. If the text box is left blank (default), then any domain will be able to make cross-domain AJAX requests to REDCap. Restricting access control to specific domains is generally considered to make REDCap more secure to prevent against possible Cross-Site Scripting attacks by malicious users. This setting can be found at the bottom of the Security & Authentication page in the Control Center.

 Major bug fix: If the "Save & Return Later" option had been enabled for a survey and an instrument had been locked by a user for a specific record/response, then a survey participant having a unique survey link (as opposed to a public survey link) would mistakenly be able to return to the response and erase all the data values on the survey using the "Start Over" button, even though the responses should have been locked and not editable. This has been changed so that if the response is locked, it will not even display the "Start Over" button or the text field for entering a Return Code but instead will display to the survey participant a message saying that they cannot return to the response at this time because it is currently locked.

 Bug fix: On certain pages, such as the "Table-based User Management" page in the Control Center, in which the PEAR DB module is utilized for database connections, if REDCap was not using the default MySQL port (i.e., 3306), then the page would result in a fatal PHP error. This bug emerged in version 6.11.0.