Version 6.5.1 LTS is based off of 6.5.0 Standard Release + the additions below.
Bug fix: When using Rule H in the Data Quality module and clicking the "Fix calcs now" button, it would mistakenly not exclude any results that the user had explicitly excluded for that rule.
Bug fix: When using Rule H in the Data Quality module, in which one or more results had been excluded and then the rule was run again at a later time, then if the user clicked the "view" link in the results popup to view the exclusions, the "Fix calcs now" button would fail to work if the user tried to click it afterward.
Bug fix: When utilizing the Randomization module in a project that has UTF-8 encoded field labels for the randomization field or the strata fields used (especially if multi-byte characters are used in the label), then on certain occasions the Randomization Dashboard page would not display correctly.
Bug fix: When survey participants returned to a partially completed survey, in which it displayed the "Start Over" button to allow them to erase their current responses and start the survey over from the beginning, it was too easy for them to accidentally click this button without realizing the repercussions of data loss. It now gives them an extra confirmation dialog that they must click so that they more fully understand the repercussions before starting the survey over.
Version 6.5.0 - codename "Oatmeal Raisin" (released 05/22/2015)
NEW FEATURES & IMPROVEMENTS:
New feature: REDCap Mobile App for iOS and Android - The REDCap mobile app is an app that can be installed on a tablet or mobile device so that data may then be collected in an offline fashion on that device, after which it may then be synced back to this project on the REDCap server. The app is most useful when data collection will be performed where there is no internet service (e.g., no WiFi or cellular service) or where there is unreliable internet service. Once a user is given 'REDCap Mobile App' privileges in a project, they can navigate to the mobile app page on the left-hand menu and set up the project inside the mobile app on their device. Once the mobile project is set up on the device, the user can collect data (which is stored locally on the device), and then at some point sync that data back to their project on the REDCap server.
About the REDCap Mobile App (PDF): http://projectredcap.org/app/about.pdf
Security in the REDCap Mobile App (PDF): http://projectredcap.org/app/security.pdf
Before users can use the mobile app for a project, they must first be given "Mobile App" user privileges, after which they will be able to see the "REDCap Mobile App" link on the project's left-hand menu and then be able to access that page, which will provide links to download the Android and iOS app and instructions for initializing that project in the app on their mobile device. Note: When a user creates a new project, they will automatically be given "Mobile App" privileges by default.
There is an additional user privilege "Allow user to download data for all records to the app?" that specifically governs whether or not the user is allowed to download records from the server to the app. This may be done to prevent users from unwittingly (or wittingly) downloading lots of sensitive data to their mobile device. If a user is given this privilege, then when they initialize the project in the app and the project contains at least one record, then the app will prompt the user to choose if they wish to download all the records to the app or not.
Syncing data back to the REDCap server: When the user has collected some data in the app and now wishes to send the data back to the server, they will go to the "Send data to server" page in the app. If there are any possible issues that might arise when sending the data to the server, the app will prompt the user to make a decision before sending the data. For instance, if the project uses record auto-numbering, and a record already exists on the server with the same record name, then it will let the user know that it will rename the record accordingly during the sync process in order to prevent any overwriting of the record already on the server. There are many different scenarios that can occur in which a user might be prompted to make a decision, and the app is fully capable of providing the user with just the right amount of guidance so that they feel confident sending their data to the server with no issues.
Remote lockout: If a user sets up a REDCap project on the mobile app, and then another user revokes their "REDCap Mobile App" user privileges on the User Rights page in that project, then it will prevent them from accessing it on their mobile device by locking them out of that particular project. In this way, you may perform "remote lockout" to further protect data stored on mobile devices. Additionally, a user can revoke/delete their API token for the project, which will also cause a remote lockout, although the lockout will be permanent and will cause all data currently stored in the app to be lost.
Admins: If you do not want your REDcap end-users to be able to use the mobile app at all, the mobile app can be disabled at the system level, if desired. When disabled, it will hide all information and all pages that mention the mobile app as if it does not exist. This setting is located on the Control Center's Modules Configuration page.
New feature: Copy Instrument - On the Online Designer, users can click the "Choose action" drop-down next to a given instrument to copy the instrument. They will be given the choice to name the new instrument and to also provide the suffix text that gets appended to each variable name to prevent duplication of variable names.
New features: Instrument ZIP Upload and External Instrument Libraries
In the Online Designer, if a user clicks the "Choose action" button in the Instruction Actions column and selects "Download Instrument ZIP", they can download a zip file of that data collection instrument, which also includes any attachment files for descriptive fields in the instrument. Using this feature makes it easy to share in individual instrument with colleagues or to keep for yourself if you want to re-use it and re-upload it into another REDCap project.
If user has obtained an instrument zip file from another project, from another user, from an institutional library of recommended zips, or from an External Instrument Library, they may upload the instrument on the Online Designer using the "Upload" button to add the instrument to the list of data collection instruments in the project.
External Instrument Libraries now exist in which REDCap users can navigate to an external website that can provide them with an instrument in the REDCap instrument zip format so that they can then take that zip file and upload the instrument into their REDCap project. It is somewhat similar to how the Shared Library works, except these external libraries are not associated with the REDCap consortium but are advertised as REDCap-friendly libraries or tools for creating instruments. The Online Designer contains a link to the current list of recommended external libraries where instrument zip files can be downloaded by users.
New feature: Auto-scoring Instruments - A new class of instruments called "auto-scoring instruments" were recently added to the REDCap Shared Library. They cannot be used by previous REDCap versions but only by v6.5.0 and later. An auto-scoring instrument is a type of survey that contains scoring that is automatically performed and saved once the survey has been completed. Most of them are referred to as "short forms". An auto-scoring instrument is static (not adaptive), and can only be implemented in survey format as one question at a time. Similar to CATs (computer adaptive tests) downloaded from the Shared Library, users will not be able to modify any fields on the instrument at any time. This auto-scoring instrument can only be taken in survey form. If the data entry form is viewed for this instrument, all fields will be displayed as read-only. Also similar to CATs, auto-scoring instruments utilize the external CAT server hosted by Vanderbilt University. The external server provides the auto-scoring functionality once the survey has been completed. Users can find these auto-scoring instruments by searcing the REDCap Shared Library.
New feature: Field Annotation - Can be used to add explanatory notes or commentary about a given field. An annotation can be added to any field via the Online Designer or Data Dictionary (column R). It can be used for several purposes, such as for the bookkeeping of a project's field structure (as metadata about the given field) for reference purposes regarding what the field represents or how it should be used (during data entry, analysis, etc.). Field annotations are not displayed on any page but are merely for reference. Field annotations can also be used to map the field to various standards (e.g., CDISC, SNOMED, LOINC) using whatever notation the user sees fit (e.g., using a simple ID code for the standard or a complex XML structure containing information about how to transform the data to the standard). Since it is just an annotation for reference purposes, REDCap will not do anything with the field annotation text on its own, but the annotation can be obtained by users at any time for any purpose (typically accessed via the Data Dictionary download or via the API metadata export). Summarily, field annotations are essentially open-ended, so users may use them in whatever way they so choose.
New feature: Project Notes - When creating a new project, users may optionally provide project notes, which are comments describing the project's use or purpose for documentation purposes. Once a project has been created, its project notes can be edited in the "Modify project title…" popup on the Project Setup page. Also, any projects having project notes will have a small icon displayed next to the project title on the My Projects page, and if a user moves their cursor over the project title, it will display the project notes in a hovering tooltip so that it can be quickly viewed. The project notes text can also be useful for other things, such as if someone is utilizing the Field Annotation attributes of fields in the project for standards mapping, in which the project notes fields could be used as a way to store project-level metadata about how the Field Annotation is being used (e.g., what type of standard is being used).
New feature: API method "Export Project Information" - Exports some of the basic attributes of a given REDCap project, such as the project's title, if it is longitudinal, if surveys are enabled, the time the project was created and moved to production, etc. See the official API documention/help page in 6.5.0 for all the details.
Improvements to the REDCap Upgrade Module
Improvement: The REDCap Upgrade module now has an option to download the SQL upgrade script as a file, which can be saved on the database server and then executed by MySQL command line. The upgrade module displays instructions on how to execute that file in MySQL, which sometimes may be preferable to executing all the SQL upgrade commands in a window in a MySQL client, which could time out if it runs too long.
Improvement: REDCap can now (on certain occasions) be upgraded to a newer version without being taken offline. The upgrade module now has the ability to let an administrator know if an upgrade can be performed without setting REDCap's online status to "offline" beforehand. If the upgrade module detects that this is possible, it will provide a note about it in Step 1 of the upgrade page. In instances where REDCap is upgraded without being taken offline, there are special safeguards in place to prevent loss of data while users are using REDCap during the upgrade. Being able to upgrade REDCap without taking it offline will be a great asset to institutions that upgrade often.
New feature: New delete buttons at the bottom of data entry forms allow users to delete all data on the current form of a given record and also (for longitudinal projects) to delete all data on the current event of a given record. The user must have "Delete records" user privileges in order for these buttons to be displayed and utilized.
Improvement: When building reports in a longitudinal project, Step 3 now contains a new checkbox option: "Show data for all events for each record returned". If this option is CHECKED, then *all* events are returned for each record, but if UNCHECKED, then some events in each record *may* get removed (depending on the filters defined in the report). This option provides users with more control when using report filters, in which it allows them to apply filters to return a group of records (e.g., a cohort) and then optionally filter those records returned even further, such as by removing specific events. This will make report filtering much more palatable for longitudinal projects.
Improvement: When building a report on the "Data Exports, Reports, and Stats" page, a new "Quick Add" button has been added to Step 2, in which it opens a popup window to allow users to select fields for the report very rapidly using the old-style checkboxes (similar to the Data Export Tool in REDCap version 5.X).
Improvement: On the "Data Exports, Reports, and Stats" page, users can now create a new report based on the custom selections made in Report B. This makes it much easier to create a report that includes all fields from many instruments and/or events.
Improvement: On the Browse Users page in the Control Center, a new user account setting called "Display user on 'Email Users' page?" can be set to "No" so that an individual user will no longer be displayed on the Email Users page in the Control Center, thus preventing them from receiving any emails sent using that page. This can be useful if a user requests to opt out of system-wide announcements sent to REDCap users by administrators, for example.
Improvement: The Data Entry Trigger now sends the parameter "username" to the defined URL. This corresponds to REDCap user that is triggering the Data Entry Trigger. Note: If it is triggered by a survey page (as opposed to a data entry form), then the username that will be reported will be '[survey respondent]'.
Improvement: New option for Automated Survey Invitations to ensure that the ASI's conditional logic is still true before sending the survey invitation. When enabled, REDCap will re-evaluate the logic against the record's data values whenever the record values are changed AFTER the invitation has been scheduled but BEFORE it has been sent to the respondent. And if the logic is no longer true (i.e., if the data values have changed during the time after the survey invitation was scheduled), it will not send the invitation to the respondent but will instead delete it (as if it had never been scheduled). Additionally, if the invitations get deleted due to this setting, then the invitations *may* get scheduled again later if data values are changed such that the logic evaluates as true again. Enabling this setting provides you with greater control over when and how invitations get sent when using conditional logic for Automated Survey Invitations.
BUGS & OTHER CHANGES:
Major bug fix: For user-uploaded files on the File Repository page in a project, it is possible for a user to manipulate the URL of a given uploaded file and be able to view the name/label, filename, and upload date of files in the File Repository of other projects to which the user does not have access. The user would not be able to edit or delete the files from other projects, but could only view the file's associated metadata information.
Major bug fix: When utilizing datediff() and some other advanced logic functions in the logic used in Data Quality rules, Automated Survey Invitations, Survey Queue, report filters, etc., it might mistakenly evaluate the logic as true when it should return false. This could cause Automated Survey Invitations to get sent prematurely or cause surveys to appear in the Survey Queue prematurely, among other things.
Major bug fix: If any data had been imported into REDCap using the Dynamic Data Pull (DDP) module, it would no longer be able to display the data in the DDP adjudication popup. This is due to an inadvertent, recent change in REDCap to accommodate issues with Mcrypt in PHP 5.6. REDCap will have to refresh the cache of all non-adjudicated data imported via DDP from the source system. This will not affect any data that has already been imported via DDP. The data refresh may take several hours to complete after the REDCap upgrade has finished.
Major bug fix: When using the round() function in a calculated field, in which the calculation results in a value of "0", it might get mistakenly reverted back to a blank/null value if running Rule H on the Data Quality module or if an auto-calculation is triggered when using cross-form or cross-event calculations. This bug emerged in REDCap 6.3.0.
Improvement: Longitudinal projects using lots of calc fields should now experience a speed improvement when it comes to performing and saving auto-calculations on data entry forms/surveys and also for Rule H on the Data Quality page.
Improvement: General speed improvement when it comes to performing and saving auto-calculations on data entry forms/surveys. In versions 6.3.0 till 6.4.6, it would evaluate *all* fields on a form/survey when performing auto-calculations, but it now only evaluates fields on the page whose value was changed, deleted, or added. This will allow it to ignore irrelevant fields and thus increase the processing speed of calculated fields in general.
Improvement/change: On the "Data Exports, Reports, and Stats" page, the multi-select boxes (e.g., those in User Access or in Additional Filters section) now behave more intuitively when users select choices from them. Users no longer need to hold down the Ctrl/Command button when clicking multiple choices, but instead simply clicking a choice adds it as selected without de-selecting the other options already selected.
Improvement: When viewing reports in longitudinal projects, any fields displayed in the report that are not designated for that particular event (i.e., row in the report) will be grayed out to show that the field is not designated. This makes it easier for users to discern if a field's value is not applicable or if it is missing.
Improvement: Added new "Edit project settings in Control Center" link at the top of every project's Project Setup page (can be seen only by super users), which allows them to navigate to the Control Center in order to modify any project-level settings that only administrators are allowed to modify (e.g., enable Double Data Entry).
Change: The parent-child functionality (i.e. project linking feature) has been removed in REDCap 6.5.0 and all versions thereafter. Any projects that were using the parent-child functionality will now operate as normal projects do and will no longer be linked to each other in any way. All functionality related to the parent-child feature (e.g., being able to export parent data from the child Data Export page, viewing parent or child forms on the left-hand menu of the other project) will cease to work and will be removed automatically. However, during the REDCap upgrade process, a project bookmark will be added to both the parent and child project so that users can navigate back and forth easily from the parent project to the child (and vice versa). And if a record is being viewed in the child, then clicking the bookmark will take the user to that same record in a data entry form in the parent project (and vice versa). For the announcement and discussion of why this feature was removed, please see https://groups.google.com/d/msg/project-redcap/CqXDO2JjawU/Kokyz4vhu6wJ
Change: Temporary passwords are no longer sent in emails when resetting passwords for Table-based users or when creating new Table-based user accounts. Instead, a unique link is sent in the email that will allow the user to set a new password for their REDCap account.
Improvement/change: The Browse Projects page in the Control Center no longer displays Archived projects by default but instead displays a "Show Archived Projects" link at the top of the page that, when clicked, will display the Archived projects in the project list.
Improvement: If using the Dynamic Data Pull (DDP) module in a project, and the value of the source identifier field (e.g., MRN) for a given record is changed *after* REDCap has already imported and cached the data from the source system for that record, then it will now purge the previously cached values for the record, after which it will begin to import new data from the source system for the new value of the source identifier field.
Change: Information on the "sql" field type is no longer located on the REDCap consortium wiki but has been integrated into the Online Designer (for super users only).
Change: Record auto-numbering is enabled by default for new projects that are created from scratch.
Change: When performing a fresh installation of REDCap, all the template projects now have record auto-numbering enabled. (Note: This will not enable record auto-numbering for template projects that already exist.)
Change/improvement: When an administrator is approving production changes to a project, the optional feature to send the user an email so that they may confirm the pending changes now has slightly modified text for the pre-filled confirmation email in order to improve clarity regarding what the user should do.
Change: The auto-suggest functionality for searching for users on the Browse Users page, Browse Projects page, or User Rights page in a project now ignores commas so that more accurate results are returned in cases where a user enters "LastName?, FirstName?", for example.
Improvement: Added user's "sponsor" and "Institution ID" field for their user account to the popup that lists users on the Browse Users page in the Control Center.
Change: Due to the fact that Google is deprecating OpenID 2.0, which was used by REDCap in versions prior to REDCap 6.5.0, the "OpenID (Google)" authentication method in REDCap will now utilize Google OpenID Connect (OAuth2), which uses a different protocol. So as far as the REDCap user is concerned, their login process will not change at all. However, this change to using OAuth2 requires an extra setup step, in which a REDCap administrator must go to the Security & Authentication page in the Control Center and enter a Client ID and Client Secret if they are using the "OpenID (Google)" authentication method. If they upgrade to REDCap 6.5.0 and then log in, they will immediately see an error message giving the administrators instructions on how to obtain a Client ID and Client Secret for the Google API, which should only take a few minutes.
Change: When creating Project Bookmarks in a project (or Custom Application Links in the Control Center), the "Link URL / Destination" is no longer required to be full URL (beginning with "http") but can now be a relative link (i.e., beginning with "/") or can begin with another non-http protocol. This adds flexibility for users creating bookmarks.
Change: When adding the URL for a Data Entry Trigger for a project, it is no longer required to be full URL (beginning with "http") but can now be a relative link that begins with "/".
Change/improvement: New instructional text was added to the top of the "Help & FAQ" page to inform the user that they can use Ctrl+F (or Command+F) on their keyboard to do a keyword search on the page.
Bug fix: When using the Data Comparison Tool for a project with Double Data Entry enabled, if the records entered by DDE person 1 and person 2 had a record name that was in a different case than the other in the pair, then it would mistakenly not allow the user to compare the pair of records nor merge them together. (Ticket #823)
Bug fix: When using the Scheduling module in a longitudinal project containing more than one arm, in which either the Custom Record Label or Secondary Unique Field is being used, then it would mistakely display the Custom Record Label or Secondary Unique Field for only the records from the first arm. For all other arms, there would not be a value displayed for the Custom Record Label or Secondary Unique Field for a given record in that arm. (Ticket #790)
Change/bug fix: When editing the record ID field (i.e., first field in project) in the Online Designer when record auto-numbering has been enabled in the project, it would not allow you to set the validation as "Integer" even though "Integer" is technically a valid option when record auto-numbering is enabled. It will now allow you to set it as "Integer" but will display an error message if changed to any other validation type. In previous versions, the field validation for the record ID field could be changed via the data dictionary but not in the Online Designer. (Ticket #736)
Bug fix: For longitudinal projects that utilize surveys in which a survey is not designated for the first event in the project, when a user first navigates to the Participant List page (i.e., by clicking the "Participant List" tab), it would mistakenly not have the first option selected in the drop-down list of surveys in the Participant List. This might cause the user to think they are viewing the Participant List of a different survey if they are not paying close attention.
Improvement: It now does a better job of not removing "<>", "<=", or "<"+number in text, which in previous versions might mistakenly get removed on certain pages (e.g. field labels on forms/surveys) because they were assumed to be an illegal HTML tag.
Change: Some text was added below the big text box on the Email Users page in the Control Center to remind administrators that they are permitted to use HTML formatting in the body of their email message.
Bug fix: On certain rare occasions, such as when a user is assigned to a Data Access Group and records have been created via a data import of only the record ID field and no other fields, the Record Status Dashboard might mistakenly not display all the records that it should on the page.
Bug fix: Any users that were suspended from the system but still had a user-level expiration date set would mistakenly receive an email warning letting them know that their account would expire soon, which is confusing because their account had already been suspended. It now no longer sends the expiration warning email to suspended users.
Change: The font size of some of the text on the main login form was increased.
Bug fix: When viewing the Stats & Charts view of a report (excluding Report A and B), the fields would mistakenly not be displayed in the order in which they are defined in the report but instead would be displayed according to their order/placement as displayed on the project's instruments.
Bug fix: When adding new arms or renaming arms on the Define My Events page in a longitudinal project, certain non-Latin (UTF-8) characters would not save correctly in the arm name, thus resulting in a black question mark symbol for that character. (Ticket #825)
Bug fix: When viewing a PDF export of a survey or data entry form in which non-Latin (UTF-8) characters are used in a Slider field's field label or in its slider labels, the text would not display correctly in the PDF. (Ticket #683)
Bug fix: When creating a new instrument from scratch in the Online Designer, if a new instrument's name is very close to an existing instrument's name, in which the name is also very long (>50 characters), then there is a chance that when the instrument is being created it will get stuck in an infinite loop and never actually create the instrument.
Bug fix: When viewing the Stats & Charts page of a report that has filters and is in a longitudinal project, in which the record ID field is not a field in the report, it would mistakenly not display the charts on the page and would have incorrect counts for the descriptive stats for each field.
Change: The "Help & FAQ" page was updated.
Change/improvement: When using the Scheduling module in a project with multiple arms, if a user chooses to schedule an existing record by selecting the record from the drop-down on that page, it will now auto-select the arm in the arm drop-down based on the arm on which that record exists. If the record exists on multiple arms, it will auto-select the first arm on which it exists. This will prevent users from inadvertently scheduling a record on the wrong arm while also giving the user the flexibility to schedule the record on another arm, if they choose to do so, why changing the arm selection from the one that is auto-selected for them.
Change: When the recipient of a Send-It file loads the webpage to download their file, the password field now has the autocomplete="off" attribute to prevent web browsers from possibly auto-filling the password, if the browser had somehow stored it.
Bug fix: A change in PHP 5.6 for Mcrypt encryption/decryption would cause a few very minor things to fail internally for very specific configurations.
Bug fix: When adding a new filter field in a report, if the user then selected the operator drop-down or value drop-down for that filter field within 2 seconds of selecting the field used in the filter, it would mistakenly cause the drop-down selection to jump around to different options while being selected, which could be frustrating.
Bug fix: When using record auto-numbering in a longitudinal project, there is a chance that when two users are creating a record at the same time in which one user clicks the "Save and Continue" button on the form to create the record, they will mistakenly get locked out of that record until the other user saves their record and leaves the data entry form. It does not appear that data gets overwritten for the record nor that records get duplicated. It merely locks a user out of a record mistakenly when it should not.
Bug fix: The field validation type "Phone (U.S.)" was modified to be more inclusive of more area codes. Also, it was renamed to "Phone (North America)" since it actually applies to all of North America and not just the United States.
Change/improvement: When viewing the Survey Queue of a record in a longitudinal project, it now displays the event name in parentheses next to the survey title in each row. In previous versions, it did not display the event name, which could make it difficult to know which survey in the queue belonged to which event.
Change/improvement: When navigating to the Data Quality module in a project, the record drop-down list on that page now loads via AJAX after the page has been fully loaded. This makes the page load much faster for projects containing lots of records.
Bug fix: When viewing the Survey Queue of a record in which one or more of the completed surveys in the queue have the setting enabled to "allow respondents to return and modify completed responses", then if more than 5 surveys were completed in the queue, it would compact the rows of those surveys but would mistakenly not compact the "Edit response" buttons on those rows. So the buttons would display even those the row itself was hidden, which is confusing to the user.
Change/improvement: The Stata syntax file that is produced during data exports now explicitly defines the minimum version as Stata 12. This reduces the number of issues that might occur when loading REDCap data into Stata by setting the first line of the syntax file as "version 12".
Bug fix: When a user that is assigned to a Data Access Group is accessing a longitudinal project via the mobile web view, it would mistakenly display all the records for the project in the record drop-down list on the page when instead it should only display the records belonging to the user's DAG. If the user clicked any records not in their DAG, it would not allow them to access them, as expected.
Change: When uploading a data dictionary containing a Text field with a min or max validation range in which the validation type of the field is a "number_Xdp" validation, it will accept values for the min or max if it is a number even though it does not follow the validation rule explicitly (e.g., it will allow a min of 5.6 even though the validation requires 3 decimal places). This is done because Microsoft Excel often removes any trailing zeros after decimals when opening the data dictionary and re-saving it. So this serves as a workaround for Excel's undesirable behavior without compromising anything with regard to data quality.
Bug fix: When using the REDCap::getData() method in a plugin or hook and providing a value for the $filterLogic parameter in which no records in the project match that logic, then instead of returning an empty array as it should, it would mistakenly return an array of every event's default values with a blank/null as the array's key (i.e., with a blank record name).
Bug fix: When using the auto-start feature for a survey in the Survey Queue, it would mistakenly not trigger the redcap_survey_complete hook when the survey was completed before auto-starting the next survey in the queue.
Bug fix: When a plugin or hook calls the REDCap::getData method for a project having a Data Access Group whose unique group name is numerical, it would ignore that numerical-named DAG if passed in the method's $groups parameter, thus causing an incorrect data set to be returned. (Ticket #839)
Bug fix: The "email" field validation type was modified to be more inclusive so that it now allows for plus signs (+) in email addresses, which is allowable for certain email services.
Bug fix: Some language was mistakenly not abstracted (i.e., was hard-coded in English) in the "Return Code" popup on a survey's "Save & Return Later" page.
Bug fix: The JavaScript? functions that enable Slider fields and reset their value were mistakenly employing branching logic prior to calculations when it should have been performing calculations first for calc fields.
Bug fix: A user with special knowledge of how the Data Access Group page in a project makes AJAX requests to load the DAG list on that page might be able to bypass certain user privileges, such as being able to remove or change their own DAG assignment. (Ticket #848)
Change: When the API crashes due to exceeding web server memory during a data export or import, it now returns a 500 error code with the message "REDCap ran out of server memory. The request cannot be processed. Please try importing/exporting a smaller amount of data." In previous versions, it would return different status codes, which could be confusing and not helpful for the user to troubleshoot the situation. (Ticket #847)
Bug fix: When using the method REDCap::getPDF() inside a REDCap hook, it would mistakenly force a PDF file download instead of returning the PDF content string. It would work as expected for plugins but would only fail for hooks.
Bug fix: If the REDCap web server is on PHP 5.5.0 or higher, then it would fail whenever a user attempted to submit a data collection instrument to the REDCap Shared Library.
Change: The file_import.php file inside the API Example ZIP file was updated to work with PHP 5.5.0 and higher.
Bug fix: When initially installing REDCap, the two template projects named "Longitudinal Database (1 arm)" and "Longitudinal Database (2 arms)" that are auto-created during the installation contain some fields whose field label does not match the variable name, which could be confusing. (Ticket #858)
Bug fix: For certain web server configurations, some REDCap installations are not able to use the PROMIS CATs functionality due to cURL not being able to verify the PROMIS server's SSL certificate. This is now more compatible to work for all server configurations. (Ticket #862)
Bug fix: If the extra UTF-8 PDF package for REDCap has not been installed on the web server, then when a user attempts to export a PDF of a form/survey containing Signature field images, it would throw a PHP fatal error. It now displays the text "[signature]" in the PDF in this case when it is not able to display the Signature image itself inside the PDF.
Change: For the REDCap cron job, the maximum execution time in PHP was increased from 20 minutes to 60 minutes to prevent some long cron jobs from timing out.
Bug fix: When a Table-based user resets their own password and is setting a new one, in which they attempt to enter a password that has fewer than 9 characters, which is the the minimum, it displays an error message that mistakenly says it must be "10 characters" at minimum when it should instead say "9 characters". (Ticket #875)
Bug fix: When clicking the "Erase all data" button on the Other Functionality page in a project, although it does make all files in the File Repository no longer accessible (i.e., "deleted"), as it should, it mistakenly does not set those files for deletion on the server after 30 days. So those files mistakenly never get removed from the back-end after 30 days but instead remain on the server indefinitely as permanently orphaned.
Bug fix: If the Participant List for a survey contains more than 50 participants, and a user goes to remove a participant, then after removing the participant, it would mistakenly reset the list back to the first page of participants rather than keeping it on the current page of participants. This would make it very difficult to remove many participants in some cases.
Change: The API method "Export Users" will now return two new attributes for each user: "mobile_app" and "mobile_app_download_data". If mobile_app's value is "1", then the user has privileges to use the REDCap Mobile App for that project. If "0", then not. If mobile_app_download_data's value is "1", then the user has the ability to download all records from the project to the mobile app, but if "0", then the user will not have the option in the app to download any records to the app.
Bug fix: When using survey invitation reminders for a PROMIS or Neuro-Qol CAT, when the survey is completed by the participant, it would mistakenly not delete any reminders that were still to be sent in the future. This would cause the participant to keep receiving the survey invitation reminders (if any had not been sent at that point) after they had completed the survey, which is confusing.
Bug fix: When using a survey confirmation email for a PROMIS or Neuro-Qol CAT, when the survey is completed by the participant, it would mistakenly not send the confirmation email to the participant.
Improvement/bug fix: If a survey's title is blank (has no text), then the row for this survey in the Survey Queue would show up as blank, which could be confusing to participants. This also occurs when in the Automated Survey Invitation setup popup, in which the survey's option shows up as blank in the drop-down list of surveys. In these cases, it now displays the instrument name in place of the title if the title is blank.
Bug fix: In certain cases when a user has been suspended after their user expiration has taken affect for their user account, it would mistakenly keep sending them an email each week to let them know that their account was just suspended.
Change: Replaced the "Detailed Overview" video
Bug fix: When using the Dynamic Data Pull (DDP) module in a project, under certain circumstances (e.g., a record was missing a value in REDCap for the external source's identifier field when data is being pulled via the cron job) a record would mistakenly get used endlessly by the cron job when fetching data from the source system, which could bog it down and overwhelm the DDP data web service that calls the source system.
Post-release fix: If the REDCap server is set to send its stats to the consortium "automatically" and fails to do so, then it would redirect to the user to the Control Center and keep reloading the page over and over again to no end.
