Major security fixes: Several cross-site scripting vulnerabilities and one blind SQL injection vulnerability were found that could possibly be exploited if a malicious user or non-user knows how to manipulate the URL of certain pages in a special way and then have another user navigate to that URL, in which it could execute malicious JavaScript on that page or could be used to possibly expose the content of back-end database tables.
Bug fix: When importing a file via the API File Import method for a longitudinal project in which the event to which the file is being imported does not yet have any data, although the record does exist, it would mistakenly give the error message "The record 'XX' does not exist. It must exist to upload a file", which is not true. This error would prevent the file from being uploaded. (Ticket #879)
Post-release patch: Intermittent issue when using a CAT in Internet Explorer 11, in which it would sometimes fail halfway through the survey.
Version 6.4.5 (released 04/27/2015)
Major security fix: A cross-site scripting vulnerability was found that could possibly be exploited if a malicious user knows how to manipulate the URL of a project's data entry page in a special way and then have another user in their project navigate to that URL, in which it could execute malicious JavaScript on that page.
Bug fix: If the Dynamic Data Pull (DDP) is enabled for a given project, the DDP user right options "Setup / Mapping" and "Adjudicate Data" would mistakenly not be displayed in the popup when creating or editing a user role, thus making it impossible to allow a role to be given DDP user privileges. However, those options would be displayed when adding or editing an individual user's privileges.
Bug fix: The "All Data" report (Report A) would mistakenly display the Survey Identifier field in the report even though the project had no surveys enabled.
Version 6.4.4 (released 03/13/2015)
Major bug fix: If a survey respondent completes the last page of a multi-page public survey and then they click the Back button in their browser and then reload the survey page, it would mistakenly allow them to re-submit their survey results and even change some survey responses after having completed the survey already. This does not apply to one-page surveys and does not apply to unique survey links. (Ticket #831)
Major bug fix: When a user is using cross-event logic for a survey in the Survey Queue of a longitudinal project in which the event that is explicitly referenced in the logic did not yet have any data saved for it for a given record, it would mistakenly not always display the survey in the survey queue when it should. This misinterpretation of a logic string could also occur when evaluating the logic for Automated Survey Invitations and thus could send/schedule invitations prematurely.
Major bug fix: When a user is adjudicating data using the DDP (Dynamic Data Pull) module, if a data value being imported via the DDP contains a "<" character immediately followed by any character other than a space, then it would truncate the value beginning at the "<" character when it is saving the value, thus resulting in an incorrect value being saved during the DDP adjudication process. (Ticket #829)
Bug fix: When a user is adjudicating data using the DDP (Dynamic Data Pull) module, if a data value being imported via the DDP contains a "<" or ">" character, it will convert those characters to HTML character codes when dynamically added those values into the fields on the data entry form (assuming those particular fields exist on the form being viewed). It still saves the value correctly during the DDP adjudication, but it can be confusing to the user if they see their data values with HTML character codes. (Ticket #829)
Bug fix: In a longitudinal project, if Automated Survey Invitations are set up for surveys not on the first event, and then the project is converted back to a non-longitudinal project, it would mistakenly schedule and send invitations for those events that are now orphaned and no longer utilized in the classic project.
Bug fix: If the "domain whitelist for user email addresses" has been enabled in order to restrict the types of email accounts that users can associate with their REDCap account, then when a REDCap administrator is adding new Table-based users on the Bulk Upload section of the Table-based User Management page in the Control Center, it would mistakenly not enforce the email domain whitelist and thus allow emails from any domain to be added for new users. This would only occur for the Bulk Upload and not for the Create Single User section. (Ticket #828)
Bug fix: If a project has surveys enabled and has an active survey in which participants have already received a survey link to take the survey, then if a user in the project disables surveys in the project via the "Main project settings" section on the Project Setup page, the surveys will mistakenly still load and function normally for participants when instead they should display an error message that the survey is not active.
Version 6.4.3 (released 02/20/2015)
Improvement: Small performance improvement for auto-calculations when saving data on a form or survey or importing data via Data Import Tool or API (up to 25% faster in some cases).
Improvement: Performance improvement for auto-calculations when saving data on a form or survey that contains lots of calc fields, in which the auto-calculation process will not get executed on calc fields that were just submitted on that form/survey because their value has already been calculated by JavaScript? on the webpage. This reduces the amount of auto-calculations that need to be performed on *some* instruments if the instrument itself contains lots of calc fields.
Change: The "Export PDF" API method's optional parameter "allrecords" has been changed to "allRecords" to be more consistent with API parameter naming conventions. Note: To be backward compatible, the older version "allrecords" will still work the same as before if it is used. (Ticket #808)
Change: If a project contained only one data collection instrument, then a user would mistakenly be able to delete the instrument on the Online Designer. It now prevents the user from deleting the only instrument but instead recommends that they add a new instrument and then delete the old one. (Ticket #811)
Bug fix: When viewing the "Stats & Charts" page for a report, checkbox fields would have an incorrect count for the "Unique" count.
Bug fix: When sending a survey invitation that utilizes piping in the content of the email (when sending the invitation from the Participant List, Automated Survey Invitation, or top of data entry form), then if the user later went to the Participant List to compose another invitation and clicked the "load message box with text from a previous email?" option, it would mistakenly include some HTML "span" tags around the piped data value when loading in the message from that previous email.
Bug fix: When uploading a data dictionary containing a minimum or maximum validation range for date, datetime, or datetime w/ seconds fields, it would mistakenly prevent the user from uploading the data dictionary if those date[time] fields are not in Y-M-D date format. (Bug emerged in version 6.4.1.)
Bug fix: When using the "user" drop-down filter on the Field Comment Log page in a project, it would mistakenly not filter properly by user if the user's username for their user account was in a different case than how their username appears in the drop-down list.
Bug fix: When using the Survey Queue in a longitudinal project, in which cross-event logic is utilized in the logic of a survey in the Survey Queue, then it might mistakenly not display all the surveys in the queue that should be displayed.
Bug fix: When using the Survey Queue in a project in which the survey title of one or more surveys is blank, it would make it impossible in some cases to know which survey was which when viewing the Survey Queue setup popup because they would all have no title listed. It now displays the instrument name in place of the survey title in the Survey Queue popup if the title is blank.
Bug fix: In a longitudinal project when using cross-event logic in report filters, Data Quality rules, Survey Queue logic, Automated Survey Invitations, etc., the logic might mistakenly not get evaluated correctly. This occurs on certain occasions where all the fields used in the logic do not have a value (i.e., they are blank) for a certain event for a given record, even though that particular event has had some data entered (i.e., data entered for other fields not used in the logic). This would cause it to think that that event has no data and thus prevent the logic from getting evaluated correctly.
Bug fix: When exporting data to SAS, the SAS syntax file produced will no longer remove apostrophes contained in the option labels of multiple choice fields but instead will escape them as a double apostrophe. This allows for a more proper viewing of the option labels in SAS. (Ticket #820)
Bug fix: If using cross-event logic for a calculated field in a longitudinal project that contains more than one arm, the auto-calculations that get triggered each time a form/survey is saved or when a data import is performed would mistakenly cause that record to get created in the other arm that is referenced in the cross-event calculation if the record does not already exist in the other arm. (Ticket #821)
Major bug fix (post-release patch): If a report has a filter with a field that uses "not =" as the filter's operator, then it would cause the report to fail and display an error message to the user.
Major bug fix (post-release patch): If a logic string used in a report filter, Data Quality rule, Automated Survey Invitation logic, etc. is using the datediff() function with the "returnSignedValue" parameter explicitly defined as either "true" or "false" (without surrounding quotes), then the logic would not get parsed correctly by REDCap and might display an error message to the user.
Major bug fix (post-release patch): If a logic string used in a report filter, Data Quality rule, Automated Survey Invitation logic, etc. contains a line break or tab character, then the logic *might* not get parsed correctly by REDCap and might display an error message to the user.
Version 6.4.2 (released 02/13/2015)
Major bug fix: If a PROMIS adaptive instrument (CAT) was downloaded from the REDCap Shared Library, it is possible that while a participant is taking the survey, it might be possible for the participant to inadvertently click the Submit button twice in a row (if done fast enough), thus sending a double request to the CAT server, which might cause the survey to mistakenly end prematurely and result in an erroneous final score for the CAT.
Change: Choices for multiple choice fields are now allowed to have a blank option label. In previous versions, choices with no option label would be automatically removed unless " " was used as the option label.
Bug fix: When saving a Signature field or uploading a file for a File Upload field for an existing record in a project, it was mistakenly not displaying the document ID number (corresponding to the primary key of a database table) on the Logging page as the value of that field. This was inconsistent with how it was displayed on the Logging page when saving a Signature field or uploading a file for a File Upload field for record that was being created.
Bug fix: If using a datetime field as a filter in a report, when the report is run or when a user goes back to re-edit the report, the filter value for the datetime field will have the minute value of its time component mistakenly replaced with "00" (e.g., if saved with datetime value of "12-31-2014 23:59", it will get replaced with "12-31-2014 23:00"). This only affects datetime-validated fields and does not affect text fields with datetime w/ seconds validation.
Improvement: Better support was added on the Configuration Test page when checking if the InnoDB table engine for MySQL was enabled. In some cases, it would return a false positive if the InnoDB engine existed but was listed with Support=NO in the MySQL configuration.
Bug fix: Depending on a given MySQL setup, an SQL error may occur during a REDCap upgrade or installation because the MySQL database name was not surrounded with backticks in the "USE DBNAME;" query at the beginning of the SQL script. (Ticket #809)
Bug fix: The Configuration Test page in the Control Center was mistakenly displaying an error message stating that the MySQL database server was on a version prior to MySQL 5 if MariaDB was being used as the database in place of MySQL. (Ticket #810)
Bug fix: The "Close survey" button that is displayed at the top of a completed survey was mistakenly not closing the tab/window in certain web browsers. Note: There are some cases where the window/tab simply cannot be closed if the window was opened with the survey as the first tab in the window (due to restrictions by the web browser itself), in which case it will instead revert to displaying a blank web page instead.
Major bug fix (post-release patch): If a user is sending a survey invitation to a participant by using the Compose Survey Invitation option at the top of a data entry form, in which they choose to enter a new email address rather than using the email address that originates from either the Participant List or the Designated Survey Email Field, then it will mistakenly not send the invitation to the new email address specified but instead to the one from the Participant List or the Designated Survey Email Field. (Ticket #816)
Version 6.4.1 (released 02/09/2015)
Improvement: The signature image for Signature fields now gets displayed in the downloaded PDF of a survey or data entry form.
Improvement: Inline image attachments for Descriptive fields now get displayed in the downloaded PDF of a survey or data entry form.
Improvement: The project Logging page now has the ability to filter logged events within a specified range of time in which the user can provide a begin time, end time, or both a begin and end time to limit the results to a specific window of time.
Improvement: When a project's language is set in the Control Center as a language other than English, it will now use the project's language in the text of survey invitations that are emailed to participants. Due to limitations up till now, all survey invitations previously had their stock language in English only.
Improvement: Form labels can now contain two-byte unicode characters (e.g., Chinese, Japanese). This is true for the labels of forms as you see them displayed on the left-hand project menu, but the unique form name (column B in the data dictionary) must still be only numbers, underscores, and lower case Latin characters.
Improvement: When entering data on a form or survey for an integer-validated Text field when using a mobile device (tablets included), it will display the device's number keypad instead of the default QWERTY keyboard in order to make data entry easier.
Major bug fix: The advanced functions sum(), median(), and stdev() would mistakenly return a "0" value (instead of a blank/null value) from an auto-calculation after saving a calculated field using those functions where all the field values that were passed into those functions were blank/missing values.
Major bug fix: The new API methods released in version 6.4.0 will fail and return nothing from the API request if the REDCap web server is a Linux or Unix server. However, they would apparently work on a Windows server.
Bug fix: The Data Dictionary Codebook page would mistakenly display stop actions for choices on multiple choice survey fields even if those choices had been deleted.
Change: Added a couple new paragraphs of helpful text on the Plugin FAQ page on the Plugin & Hook Documentation page.
Bug fix: When a calculated field in a longitudinal project is utilizing a Cross-Form or Cross-Event calculation, then if the user clicks the "Save and go to Next Form" button on the data entry page, it might on certain occasions mistakenly take them to another event for that record when instead it should take them to the next instrument in the same event. (Ticket #795)
Bug fix: If an M-D-Y or D-M-Y formatted date or date/time field is set as the Secondary Unique Field in a project, then the check to prevent unique values for that field would fail whenever a duplicate value was entered on a survey or data entry form. (Ticket #782)
Bug fix: If a field has been given the validation "Number (X decimal place - comma as decimal)" with either a minimum or maximum range value defined, then it would mistakenly always display the range check error on a survey or data entry form whenever a valid value was entered into that field.
Bug fix: If a Text field has field validation with either a minimum or maximum range value defined, then if a user is in the Online Designer and changes the validation to another validation type that cannot utilize the min/max range check (thus hiding the min/max input fields in the popup), then it would mistakenly retain the min/max values and save them, which could cause the "out of range" error to popup mistakenly during data entry. (Ticket #598)
Improvement: When uploading a data dictionary that contains a field with a minimum and/or maximum validation value, it now checks to make sure that the min/max value is in the correct format for that field's particular validation type. Previous versions did not check the format of the min/max values.
Version 6.4.0 - codename "Fortune Cookie" (released 01/30/2015)
NEW FEATURES & IMPROVEMENTS:
New feature: New "MySQL Dashboard" page in the Control Center is an enhanced version of MySQL's process list that displays a comprehensive view of real-time server activity for REDCap. This page can be helpful to troubleshoot any issues with regard to server performance. It provides contextual details to each server request (MySQL process ID and query, PHP process ID, REDCap project ID, REDCap username, REDCap URL, etc.) when available. It also allows REDCap administrators to execute a MySQL "kill" command on a given query from this page (if a long-running query needs to be killed for whatever reason), but this can only be done if that setting has been enabled via the back-end database (details for enabling this are noted on this page).
6 new API methods - see API Help page for full details
"Export PDF file of Data Collection Instruments" - Returns a PDF file of one or all instruments in the project, either with no data (blank), with a single record's data, or with all records from the project.
"Export a Survey Link for a Participant" - Returns a unique survey link (i.e., a URL) in plain text format for a specified record and data collection instrument (and event, if longitudinal) in a project.
"Export a Survey Queue Link for a Participant" - Returns a unique Survey Queue link (i.e., a URL) in plain text format for the specified record in a project that is utilizing the Survey Queue feature.
"Export a Survey Return Code for a Participant" - Returns a unique Return Code in plain text format for a specified record and data collection instrument (and event, if longitudinal) in a project with surveys that are utilizing the "Save & Return Later" feature.
"Export a Survey Participant List" - Returns the list of all participants for a specific survey instrument (and for a specific event, if a longitudinal project).
"Export List of Export Field Names" - Returns a list of the export/import-specific version of field names for all fields (or for one field, if desired) in a project. This is mostly used for checkbox fields because during data exports and data imports, checkbox fields have a different variable name used than the exact one defined for them in the Online Designer and Data Dictionary, in which *each checkbox option* gets represented as its own export field name in the following format: field_name + triple underscore + converted coded value for the choice.
4 new developer methods for plugins and hooks- see documentation page for full details
"getPDF" - Returns the content of a PDF file of one data collection instrument or all instruments in a project, in which the instruments can be 1) blank (no data), 2) contain data from a single record, or 3) contain data from all records in the project.
"getParticipantList" - Returns the list of all participants for a specific survey instrument (and for a specific event, if a longitudinal project) in the desired format (CSV, JSON, XML).
"getEventIdFromUniqueEvent" - Returns the event_id associated with an event in a longitudinal project when given its associated unique event name.
"getExportFieldNames" - Returns a list of the export/import-specific version of field names for all fields (or for one field, if desired) in a project. This is mostly used for checkbox fields because during data exports and data imports, checkbox fields have a different variable name used than the exact one defined for them in the Online Designer and Data Dictionary, in which *each checkbox option* gets represented as its own export field name in the following format: field_name + triple underscore + converted coded value for the choice.
Improvement/change: Negative values can now be used as the raw coded values for checkbox fields with regard to their usage in data exports and data imports. In previous versions, negative values for checkbox choices would save successfully on surveys and data entry forms, but due to certain limitations, they would not work when importing values for those choices using the Data Import Tool or using the API data import. In the same regard, they would also cause problems when exporting data into a statistical analysis package. Now negative signs can be used for checkbox options, in which the negative sign will be replaced by an underscore in the export/import-specific version of the variable name (e.g., for a checkbox named "meds", its choices "2" and "-2" would export as the fields "meds_2" and "meds2", respectively).
Improvement: When viewing a survey's Participant List or the Survey Invitation Log, if a participant's email or identifier was too long, it would get truncated and not be fully visible in the table. It now wraps the text to the next line for better viewing of the whole text.
BUG FIXES & OTHER CHANGES:
Major bug fix: At the top of data entry forms, it would mistakenly display the two PDF export choices for downloading PDFs containing data even if the user had "No Access" data export privileges. This would mistakenly allow the user to export data in a PDF file even though they do not have privileges to be exporting data. It now does not allow them to export data in PDFs unless the user has data export privileges of some kind, and it also no longer displays those two options at the top of the page to download PDFs containing data. In spite of this, users will still be able to download blank PDFs (i.e. with no data).
Major bug fix: If a PROMIS adaptive instrument (CAT) was downloaded from the REDCap Shared Library, it is possible that while a participant is taking the survey, if the REDCap server momentarily experiences a network/connectivity issue and cannot make contact with the CAT web service on the consortium server hosted by Vanderbilt, then REDCap mistakenly assumes that the survey has ended and marks the response as "completed" while erroneously saving a value for the final T-score for the instrument (the final score should not exist unless the participant truly completed the survey). Currently, this bug has only been reported as having occurred at one institution for a handful of instances.
Bug fix: When a user is downloading a PDF file (either blank or containing data) at the top of a data entry form, it would mistakenly remove any data collection instruments from the PDF that the user does not have access to on the web interface (i.e. if they do not have instrument-level privileges to an instrument). Since instrument-level privileges only apply to viewing web pages in the web interface, it should not have been removing any instruments from an export file, such as PDF files. Thus, in order to be consistent with how user rights are implemented throughout the rest of REDCap, users will no longer have any instruments removed from the PDF exports due to their instrument-level privileges.
Bug fix: When a user is downloading a PDF containing data at the top of a data entry form when the user's data export privileges is "De-Identified" or "Remove all tagged Identifier fields", it would mistakenly hash the record ID value in the PDF for the first field in the first instrument. It would, however, not do this when displaying the record ID value in the top right corner of the PDF. This bug is only seen when the first instrument is included in the PDF.
Change: Modified the name of new feature in the Online Designer from "Choose Existing Choices" to "Copy Existing Choices".
Improvement: In the popup for "Copy Existing Choices" in the Online Designer, it now displays the choices better in the popup if a given field has a lot of choices, which could make it hard to view many sets of choices at once.
Bug fix: In a project with Double Data Entry enabled, calculated fields would mistakenly get displayed on the page where values are merged from the two records. It now no longer displays calc fields on the merge page, and it now also performs an auto-calculation after the merge takes place in order for all calc field values to be correct for the newly created record.
Bug fix: In a project with Double Data Entry enabled, if the user was merging two records on the Data Comparison Tool page, in which one of the fields was a Text field whose value contained an apostrophe, then when the user chose the value from the first or second value, it would throw a JavaScript error and thus would mistakenly not merge that value into the newly created record.
Bug fix: When using the designated survey email field in a project in which an email address was first entered into the Participant List and then a different email address was entered for the designated survey email field for that same record, then the Participant List would mistakenly display the original email address entered into the list when instead it should have displayed the email address from designated survey email field's value.
Bug fix: When creating or editing a report and using a filter that includes date or date/time fields with D-M-Y or M-D-Y date formatting, then if a user clicked the "Use advanced logic" link to convert the filters into advanced logic text, then it would mistakenly not convert the date/time values into Y-M-D format, which is required when using a literal value inside a logic string of text.
Bug fix: When viewing a report that contained a survey timestamp field, instead of displaying "[not completed]" for the timestamp field of a partial response, it would mistakenly display a partial timestamp filled with zeros instead.
Bug fix: If a multi-page survey is being administered in a longitudinal project, in which *all* fields on a given page in the survey contain branching logic that explicitly references fields on other events, then if any of those events referenced in the logic do not have any data saved for them yet for that record (i.e., those events do not show up in reports or exports for that record), then the branching logic might mistakenly return a FALSE value when it should evaluate as TRUE. The overall effect of this is that it could cause entire pages to be skipped in the survey mistakenly when viewing the survey in multi-page mode.
Bug fix: When utilizing the REDCap::getData method in a REDCap plugin or REDCap hook, in which the parameters are set with $combine_checkbox_values=TRUE and $exportAsLabels=TRUE, then it would mistakenly output the raw coded values for checkboxes rather than the option labels.
Bug fix: If using PROMIS adaptive instruments (CATs) downloaded from the REDCap Shared Library, then if the CAT API token and ID stored in REDCap ever became invalid (for whatever reason), it would fail to communicate with the CAT server hosted by Vanderbilt University. It now will simply generate a new CAT API token and ID in this situation to allow seamless functioning of the CATs.
Bug fix: When a datediff() function is used inside the equation of a calculated field, in which a literal date or date/time value (as opposed to a variable name or "today" - e.g., "01-01-1970") exists as the first parameter, the second parameter, or both the first and second parameters in the function, then if the date format parameter is either "mdy" or "dmy", the auto-calculation that is performed when the record is saved will actually result in a different value than the one displayed on the form/survey prior to the save. (Ticket #799)
