Version 11.4.4

CHANGES IN THIS VERSION:

• Improvement: New parameter "repeat_instance" was added to the API method "Export PDF file of Data Collection Instruments" to allow users to export a PDF of an instrument for a specific repeating instance of a repeating instrument/event. (Ticket #117182)
• Change/improvement: When a survey participant partially completes a survey that has the Save & Return Later feature enabled, and an email is then sent to the participant to remind them to finish their survey later, instead of sending that email from the system-level "Email Address of REDCap Administrator" (as in previous versions), the "From" email address of the "Survey partially completed" email will be set to the sender's address from the most recent survey invitation received by the participant. This will create more consistency and will reduce confusion for participants when attempting to reply back to the email, as has been a problem in the past.

Version 11.4.0

CHANGES IN THIS VERSION:

• New action tag: @IF- Allows various action tags to be set based on conditional logic provided inside an @IF() function - e.g., @IF(CONDITION, ACTION TAGS if condition is TRUE, ACTION TAGS if condition is FALSE). Simply provide a condition using normal logic syntax (similar to branching logic), and it will implement one set of action tags or another based on whether that condition is true or false. For example, you can have @IF([yes_no] = '1', @HIDDEN, @HIDE-CHOICE='3' @READ-ONLY), in which it will implement @HIDDEN if the 'yes_no' field's value is '1', otherwise, it will implement the two action tags @HIDE-CHOICE='3' and @READ-ONLY. If you wish not to output any action tags for a certain condition, set it with a pair of apostrophes/quotes as a placeholder - e.g., @IF([my_radio]='1', @READONLY, ''). You may have multiple instances of @IF for a single field. You may also have multiple nested instances of @IF() inside each other. Both field variables and Smart Variables may be used inside the @IF condition. The @IF action tag is also evaluated for a given field when downloading the PDF of an instrument/survey, in case there are any PDF-specific action tags used inside of @IF(). Note: The conditional logic will be evaluated only when the survey page or data entry form initially loads; thus the action tag conditions will not be evaluated in real time as data is entered on the page.
• New feature: Protected Email Mode
  • Users can enable the Protected Email Mode on any project on the Project Setup via the Additional Customization dialog. This setting prevents identifying data (PHI/PII) from being sent in outgoing emails for alerts, survey invitations, and survey confirmation emails.
  • If enabled, either A) all alerts, survey invitations, and survey confirmation emails or B) those whose email body is attempting to pipe data from Identifier fields will be affected, in which it will not send the full email text to the recipient but will instead send a surrogate email containing a link that leads them to a secure REDCap page to view their original email. If someone is accessing an email in the Protected Email Mode for the first time (or for the first time in the past 30 days), it will send a security code to their inbox that will allow the recipient to view any protected emails for up to 30 days on that same device. The Protected Email Mode is similar to Microsoft Outlook's "sensitivity label" feature.
  • When enabled in a project, users may specify custom text/HTML to display at top of the sent email and web page where the original email is viewed. This will allow users to also display logos/images pertaining to their project or institution.
  • This feature can be disabled in all projects via a global setting on the Modules/Services Configuration page in the Control Center.
• New feature: Email Logging page
  • This is a new project page that contains a search interface to allow users with User Rights privileges to search and view ALL outgoing emails for that project (also includes searching and viewing of SMS messages if using Twilio services).
  • This feature can be disabled in all projects via a global setting on the Modules/Services Configuration page in the Control Center.
  • “Re-send email” feature - When viewing an individual email after performing a search on the page, a “Re-send email” button will be displayed in the dialog to allow users to re-send the email. Note: If the original email contained email attachments, the attachments will not be included in the email that is re-sent.
  • Only users with User Rights privileges in the project may access the page, and additionally they must opt-in and agree to a disclaimer before being able to view the page. The following text will be presented to the user before accessing the page: “Before viewing and accessing this page, you must first agree that you understand the following important information and conditions. This page is only accessible by users having User Rights privileges in this project. The Email Logging feature allows users to search and view *all* outgoing emails related to this project, and this includes being able to view all aspects of any given email (i.e., the recipient(s), sender, subject, message body, attachment names). If you are using anonymous surveys in this project, keep in mind that viewing this page and the emails displayed therein might inadvertently cause anonymous survey responses to be identifiable/de-anonymized. Additionally, if the project is using Data Access Groups, you will be able to view the emails related to all DAGs in this project (and thus possibly any data piped into the body of those emails). If you understand and agree to these conditions, click the button below. Please note the act agreeing to this disclaimer will be documented on the project Logging page.”
• Improvement: New "Banned IP Addresses'' pagein the Control Center allows administrators with "Manage User Accounts'' privileges to add or remove IP addresses to/from the blocklist of banned IP addresses for the REDCap installation. The IP addresses listed on that page are IPv4 or IPv6 addresses that have been blocked manually using that page or have been banned automatically via the Rate Limiter feature (enabled on the General Configuration page in the Control Center).
• Improvement: When using the ''Reason for Change'' feature in a project, a new button is displayed underneath each "reason for change" textbox on the Data Import Tool summary page. Users can simply click the button to copy the text to all other "reason for change" textboxes on the page, thus saving lots of time of having to add text to each individually. This feature is the integration of Luke Steven’s “Copy Change Reason” external module, which will be automatically disabled at the system-level when upgrading to (or past) REDCap 11.4.0 to prevent any conflicts.
• Improve: New data export option - Export blank values for gray instrument status
  • All instrument complete status fields having a gray icon can be exported either as a blank value or as "0"/”Incomplete”. In previous versions, they could only be exported as “0”. By default, they are now exported with a value of “0”, but this option can be changed via a drop-down option in the “Advanced data formatting options” section of the data export dialog.
  • When exporting the Project XML file with both metadata & data, the option to export gray instrument status as a blank value will be preselected by default, whereas in other data export contexts (e.g. My Reports & Exports page), the option to export them as “0” will be preselected by default.
  • The API method “Export Records” has a new optional parameter “exportBlankForGrayFormStatus” that can accept a boolean (true/false) with default value = false, and it functions the same as its equivalent data export option in the user interface.
  • Note: Exporting gray instrument statuses as blank values is recommended if the data will be re-imported into REDCap. For example, when users export a Project XML file for a project and then create a new project with it, all the gray instrument status icons will be preserved in the new project, whereas in previous versions they were all converted into red status icons.
• Improvement: New option “Allow normal users to edit their primary email address on their Profile page” on the User Settings page in the Control Center. This setting will be enabled by default, but an admin can disable it if they wish to prevent any users from modifying their primary email address for their user account.
• Improvement:The developer methods REDCap::getSurveyLink() and REDCap::getSurveyQueueLink() now have an optional parameter "project_id" that (when provided) allows one to call the method outside of that target project's context. If project_id is not explicitly provided, then the methods must still be called within their target project's context.
• Minor security fix:A Cross-site Scripting (XSS) vulnerability was discovered where a malicious user could potentially exploit it by inserting HTML tags and/or JavaScript event attributes in a very specific way as user-defined text on the Project Setup page.
• Major bug fix: When a repeating instrument has data entered on multiple repeating instances, and then afterward the instrument is made to no longer be repeatable, then any new data entered on that data entry form for fields that already have data on other instance might mistakenly get stored in the wrong repeating instance (i.e., get orphaned in the "redcap_data" database table) and thus would fail to be seen when reloading the form again. (Ticket #115308)
• Improvement/change: New LOINC codes were added for CDIS-related functionality.
• Change: All CDIS-related features and functionality now utilize a centralized set of assets in the code, rather than each feature having only their own private set of assets. This change reduces the entire size of the REDCap code by half, thus saving lots of space on the REDCap web server.
• Various updates and fixes for the External Module Framework, such as the following: PID parameter safety improvements, Documentation updates, Prevented unnecessary errors from the Portable UTF-8 library's auto-redirection, Increased the setting lock timeout, and Fixed a getSafePath() case with absolute paths.

Changelog LTS version 10.2

Improvements to Data Resolution Workflow Feature

• When a user is opening a new data query and assigning the query to a user, there are new options to send a notification to the assigned user via email and/or REDCap Messenger to inform them about their query assignment.
• Attachment files uploaded to an opened data query may now be deleted after the fact, if needed. Note: As a precaution, only REDCap administrators may delete such attachments.

For existing data queries, users may now be assigned to an opened query after the fact, and if the data query already has a user assigned to it, it may be reassigned to another user.

REDCap-Branded URL Shortener (https://redcap.link)

• The “Get short survey link” and “Create custom survey link” buttons on a project’s Public Survey Link page now utilize the REDCap-branded URL Shortener (https://redcap.link) instead of BIT.LY and IS.GD, which are third-party websites utilized by previous versions. 

Project Life Cycle Changes

• “Inactive” project status renames to “Analysis/Cleanup.”
• Projects that are in "Analysis/Cleanup" status can now optionally have their project data set as "Locked/Read-only" or "Editable" (see the top of the Project Setup or Project Home page). This will give users more control to prevent data collection from happening while in this project status.
• Mark a project as "Completed": If users are finished with a project and wish to make it completely inaccessible, they may mark the project as Completed. Doing so will take it offline and remove it from everyone's project list, after which it can only be seen again by clicking the Show Completed Projects link at the bottom of the My Projects page. Once marked as Completed, no one in the project (except for REDCap administrators) can access the project, and only administrators may undo the Completion and return it to an accessible state for all project users. Marking a project as Completed is typically only done when users are sure that no one needs to access the project anymore, and they want to ensure that the project and its data remain intact for a certain amount of time.

Surveys to Capture Custom Information During Project Status Transition 

• On the User Settings page in the Control Center, four optional fields have been added to allow you to utilize public surveys to capture custom information from users when projects transition to a new status (i.e., move to Analysis/Cleanup status, mark as Completed). This allows administrators to create custom surveys to capture all the info they desire from users during these project transitions. The survey will be presented inside an iframe on the page. The user must complete the survey before completing the process on the page. You may use any or none of these fields.

 DAG Switcher  

• Users assigned to Data Access Groups (DAGs) can optionally be assigned to multiple *potential* DAGs, in which they may be given the privilege of switching in and out of specific DAGs on their own whenever they wish.
• When assigned to multiple DAGs, the user will see a blue banner at the top of every project page, which will present them with the option to switch to another DAG. NOTE: Users may not move themselves into another DAG unless someone with rights to this page has explicitly granted them privileges to be in multiple DAGs.
• To assign a user to multiple DAGs, navigate to the Data Access Groups page in a project where you will see the DAG Switcher near the bottom of the page. Then follow the directions provided there. The DAG Switcher feature is optional and can be used in any project that has Data Access Groups.
• NOTE: The DAG Switcher feature does not override a user's current DAG assignment, as set on the Data Access Groups page or the User Rights page.
• This feature is the result of integrating the “DAG Switcher” external module built by Luke Stevens. We thank him for his contribution and for agreeing to let us integrate this useful module into REDCap. NOTE: Because the “DAG Switcher” external module is not compatible with this integrated functionality in v9.9.0, when upgrading REDCap to 9.9.0 or higher, if the “DAG Switcher” external module is already installed and enabled on your REDCap system, it will be automatically disabled at the system level during the upgrade process to prevent a conflict.

 Changes for Long-Standing Quirks with Calculated Fields and Branching Logic 

• Change: In previous versions, calculated fields could only utilize either numeric fields or date/datetime fields in the calculation. Now non-numeric fields may be used, most notably inside IF statements. For example, if ([field1] = “A”, 0, 99).
• Change: In previous versions, using > or < in branching logic would not always work as expected. For example, [a] > [b] would have to be formatted as [a]*1 > [b]*1 to work correctly 100% of the time, which is not intuitive. This is no longer required, in which [a] > [b] will work as one would expect in branching logic. Note: This does not apply to calc fields, which have never had this problem.
• Change/improvement: The datediff() function used in branching logic and calc fields no longer requires the date format parameter (“ymd”, “mdy”, “dmy”). This was required for datediff() in calc fields and branching logic but was not required elsewhere, such as in report filters, DQ rule logic, ASI/Alert conditions, etc. The $returnSignedValue parameter (if provided) can now be provided as the fourth parameter - e.g., datediff([dob], “today”, “y”, true). NOTE: Both of the date/datetime fields used in the datediff function must still be in the same date format (“mdy”, “dmy”, or “ymd”), so that is still a requirement.
  

Record-Level Locking Feature 

• This feature allows users to lock an entire record (as opposed to locking individual instruments) so that none of the record’s data can ever be modified unless someone with record-level locking/unlocking privileges goes and unlocks the record again.
• The old “lock all forms for all events” feature has been changed into this new record-level locking feature, which is distinguishable from the existing instrument-level locking feature. Now the instrument-level locking can only be used while on a data entry form (using the Locking checkbox at the bottom of the form). Whereas the record-level locking feature is available as an option on the Record Home Page and the project’s left-hand menu after a record has been selected.
• While records have always been able to be locked (i.e., made read-only) for individual data collection instruments in a project, you may now easily lock an ENTIRE record so that no data in the record can ever be modified while it is locked.
• WHAT HAS CHANGED? It is important to note that the old user privilege "Lock all forms" has now been converted into the new record-level locking feature, which works entirely independently from instrument-level locking (i.e., the checkbox at the bottom of data entry forms). Instead of that particular user privilege allowing you to lock all forms individually (which was the previous behavior), it will now serve in a slightly different capacity as the record-level locking user privilege to lock an entire record fully.
• HOW TO USE IT: You may lock an entire record via the "choose action for record" drop-down on the Record Home Page or by clicking the "Lock Entire Record" link on the project's left-hand menu when viewing a record. Note: Since the record locking and instrument locking are completely separate features, they both may be used together in a project, if you wish. However, please note that since record locking is a higher-level locking than instrument locking, an entire record may be locked or unlocked while one or more instruments are currently locked, but an instrument cannot be locked or unlocked while the entire record is locked.

 Field Embedding 

• Field Embedding is the ultimate way to customize surveys and data collection instruments to make them look exactly how you want. Field Embedding is a Shazam-like feature that allows you to reposition field elements on a survey page or data entry form so that they get embedded in a new location on that same page. Embedding fields gives users greater control over the look and feel of your instrument. Users may place fields in a grid/table for a more compact user-friendly page, or position fields close together in a group if they are related.
• To use Field Embedding, users need to place the REDCap variable name of a field inside braces/curly brackets - e.g., {date_of_birth} - and place it in the Field Label, Field Note, Section Header, or Choice Label of any other field on that same instrument. Field embedding will not work across instruments but only on the current instrument/survey being viewed. If on a multi-page survey, then the embedded field must be on the same survey page as its host field.
• No action tags or custom HTML is required to use Field Embedding. Users can use the rich text editor in the Online Designer to design their layout and then place the field variables inside that layout. The layout does not have to be a table/grid (although tables are common for this), and fields can be embedded inside *any* field type (not just Descriptive fields).
• We wish to thank Andy Martin (Stanford) because his popular Shazam external module served as the conceptual inspiration of the Field Embedding feature.
• Note: When installing or upgrading to v10.0.0, a new project “Field Embedding Example Project” will be automatically added as a project template to easily allow users and admins to see some examples of Field Embedding in action.

 Online Designer’s “Add/Edit Branching Logic” 

•  A new feature was added dialog to help users modify branching logic for many fields at once if they had the same branching logic.

 Modify Multiple Fields Together on the Online Designer 

• Users may select multiple fields on the Online Designer by holding the Ctrl, Shift, or Cmd key on their keyboard while clicking on the field in the table, which will reveal the options to Move, Copy, or Delete all the selected fields. To make users aware of this feature, a floating note now appears near the right side of the Online Designer page with instructions on how to use this.

Changelog LTS Version 8.10.11