Page History

REDCap 15.0.9 Release Notes

Scheduled Upgrade Date: Wednesday, February 19, 4:45 PM – 7:00 PM (ET)

The REDCap 15.0.9 upgrade introduces new features, API enhancements, performance improvements, and eConsent 2.0. Below is a comprehensive list of changes in this release.

1. Artificial Intelligence (AI) Services. (NOT Yet Available in our Instance) 

Overview:

• REDCap can now integrate with an Azure OpenAI instance of ChatGPT to enhance text-based tasks.
• Private Endpoint Model: The AI is hosted on your institution’s Azure environment, ensuring security.
• Financial Considerations: Usage is billed to your institution’s Azure account.
• Project-Level Overrides: You can globally disable or configure AI, or override the config on a per-project basis.

Key AI Features

1. Writing Tools in the Rich Text Editor:
   • A magic wand icon appears in the editor toolbar.
   • Allows you to refine text (tone, length, reading difficulty, etc.).
2. Summarize Text in Reports:
   • Next to free-form text fields, a “Summarize” button can generate an AI-based summary.
3. Auto-Translate in MLM:
   • A button appears on the MLM page to automatically translate any untranslated text (if the institution has AI configured).

...

2. Enhanced e-Consent Framework & PDF Snapshot Functionality

New "Settings for e-Consent & PDF Snapshots" Page:

• Consolidates all e-Consent and PDF Snapshot options in one place (linked from Online Designer).

Key eConsent 2.0 Features:

1. Multi-Form Consents:
   • Combine multiple instruments or signatures into a single PDF.
2. Logic-Based PDF Snapshot Triggers:
   • Automatically generate snapshots when a specified condition is met (e.g., data import, saving a form, etc.).
3. Re-Triggering Snapshots:
   • Users with proper privileges can manually re-run snapshot triggers via a “Trigger Snapshots” link.
4. Vault Storage Integration:
   • If your institution uses the external e-Consent Vault, e-Consent PDFs can automatically be stored externally.
5. Customizable File Names & Headers/Footers:
   • Use piped text, timestamps, or custom text in PDF file names or in PDF headers/footers.
6. Improved Audit Trails:
   • Consent completions & PDF generations are now more thoroughly logged.

Benefits:

• Streamlined Consent Process: Enhances both participant and researcher workflows.
• Compliance & Security: Satisfies regulatory requirements (ICH, FDA) with version control and robust tracking.

...

3. Longitudinal Functionality for MyCap-Enabled Projects

• In prior versions, MyCap was disabled for longitudinal projects.
• Now supports multiple arms/events in MyCap:
  • If you have an existing MyCap project, a "transition" button on the MyCap Participants page allows migration to the new MyCap apps.
  • The older MyCap Classic apps remain available but do not support advanced (longitudinal) features.

Additional MyCap Enhancements

• New MyCap Action Tags:
  • @MC-PARTICIPANT-CODE: Captures participant’s unique MyCap code.
  • @MC-PARTICIPANT-JOINDATE: Captures date/time a participant installs MyCap for the project (requires date/time validation).

...

4. New Built-In PDF Viewer

• Addresses the long-standing gap where iOS/Android devices could only display the first PDF page inline.
• Automatic Fallback: If the device lacks a native PDF viewer, REDCap uses its built-in viewer. Otherwise, it uses the device's native viewer.
• Inline PDF on e-Consent: Previously displayed “This browser does not support inline PDFs” for certain devices. Now it’s always displayed inline.

Applies to:

• Descriptive fields
• File Upload fields using the @INLINE action tag
• e-Consent certification pages

...

5. Background Data Import (Large Files)

• Asynchronous Data Import: Large files can be uploaded without freezing the user interface.
• One Record at a Time: If any record fails validation, that record’s data is skipped, preserving data integrity.
• Error Handling & Retry: On import completion, errors are summarized. You can download a list of failed records, fix them, and re-import.
• Email Notification: REDCap emails the uploader once the import finishes.
• Cancellation: Ongoing imports can be canceled, though any data already imported remains.
• Currently UI-Only: Future updates may offer an API-based background import method.

...

6. Multi-Language Management (MLM) Overhaul

• New Workflow for Adding Languages:
  • Projects can “subscribe” to system-wide languages, so changes made centrally appear in subscribed projects.
  • Admins can restrict how new languages are initialized: from system languages, from language files, or from scratch.
• Redesigned Editing & Updating:
  • “Edit Language” (rename, notes) is separate from “Update Language” (sync or import translations).
• Auto-Translation with AI (if AI is configured):
  • A single button can rapidly fill in untranslated text.
• ASI Language Source Default: Now defaults to “Language Preference Field” instead of “User’s or survey respondent’s active language.”

...

7. Additional redcap_data Tables (Horizontal Scaling)

• Four Data Tables: redcap_data, redcap_data2, redcap_data3, redcap_data4 for storing project data, assigned automatically.
• Only Affects New Projects: Existing projects stay in redcap_data.
• Dynamic SQL Fields: Use the new [data-table] Smart Variable instead of hard-coding a table name.
• Move Project Data Page:
  • Admins can relocate an existing project’s data to a different table if performance issues arise.
  • The process is transactional—rolls back if an error is detected.

Developer Method: REDCap::getDataTable($pid) to retrieve the correct data table name for a given project.

...

8. Bulk Record Delete

• Two Deletion Modes:
  1. Entire Records (requires “Delete Records” privilege).
  2. Partial Data (by instrument) across multiple records (requires “Delete Records” + instrument “View & Edit”).
• Access Points:
  • Other Functionality page.
  • Record Status Dashboard → Multi-Record Actions dropdown.
• GDPR & Reason for Change Options:
  • If your project has “Delete a record’s logging activity…” or “Require reason for change” enabled, relevant prompts appear.
• System Setting: Bulk Record Delete can be disabled in the Control Center if needed.
• Data Deletion Limitations: E.g., locked forms, completed e-Consent, or disabled editing for survey data.

...

9. New "Test Run" Option for Re-evaluating Alerts & ASIs

• Dry Run: Simulate scheduling/sending of alerts/invitations without actually committing changes.
• Confidence: Users see exactly how many records would be affected before performing a real re-evaluation.
• CSV Download: Option to download a list of all records impacted, whether test or real run.

...

10. Rapid Retrieval Caching

• Page-Level Caching: Known slow pages—Reports, Record Status Dashboard, etc.—can load from a cache for speed.
• Transparently Enabled: A note “Page speed was boosted using Rapid Retrieval” is displayed if a cached result is used.
• Clearing/Disabling:
  • Project-level: “Clear all record & page caches” in Other Functionality.
  • System-level: The Admin can disable or configure it in the Control Center.
• File-Based vs. Database Storage: By default, it stores cached files on the server, but can optionally store them in the DB.

...

11. New Read Replica Server Feature

• If your REDCap server experiences routine slowness:
  • You can configure a secondary read-only database server.
  • Read operations (reports, logging exports, record dashboards) will use the replica, reducing load on the primary.
• Minimal Setup: The hardest part is spinning up a properly replicating MySQL/MariaDB server.
• Recommended for: Larger institutions or those with heavy usage.

...

12. Randomization Enhancements

Multiple Models & Blinded Allocation

• You can define more than one randomization model in a single project.
• Blinded or Open randomization options:
  • Blinded uses a text field to store the randomization number.
  • Open uses a multiple-choice field (radio, dropdown).

New Smart Variables: [rand-number], [rand-time], [rand-utc-time]

• Accept :value to return a raw datetime string.
• :n if multiple randomization models exist.

API & Hook Enhancements

• "Randomize Record" API method.
• Hook: redcap_module_randomize_record to run custom code prior to randomization.

Real-Time Trigger Logic

• Automated randomization upon saving a form if the logic condition is met.

Admin Options (rare/unexpected cases)

• Manually randomize a record, un-randomize, or remove/alter existing allocations.

...

13. Other Notable Features & Improvements

1. Descriptive Popups:

   • A new way to display small pop-up text boxes on hover, integrated from the “Inline Descriptive Popup” External Module.
   • Configurable for all instruments or per instrument/page.

2. Draft Preview Mode:

   • Preview forms with drafted changes as if live, storing ephemeral data in your session. No data is saved to the project.
   • Limitations: No record creation, data changes are transient, etc.

3. AI Writing Tools (Reiterated):

   • Summarize or refine text within the Rich Text Editor.

4. Security & Cookie Policy Updates:

   • “SameSite=Strict” default for cookies, improved 2FA OTP encryption.
   • Newly added “cookie policy” link in the REDCap footer.

5. Mobile Toolbox (MTB) MyCap Measures:

   • Additional cognitive/behavior tasks for MyCap.

6. Additional UI & Accessibility:

   • Color contrast improvements.
   • Control Center and Home Page reworks with more clarity.

7. Multiple Shibboleth / SSO IdPs:

   • Institutions can define multiple identity providers for Shibboleth auth.

8. Improved Database Query Tool:

   • “Smart Variables Context” can be used in queries.
   • Admin can open the DQT from specific pages with the project’s context pre-filled.

9. Enhanced External Module Framework:

   • More robust scanning for security & composer conflicts.
   • Support for local twig templates.

API Enhancements & Connection Stability Updates

Expanded Read Replica Usage for API Exports(Prevents API Timeouts & Connection Drops)

• All API export methods now use the Read Replica database if enabled.

• Faster API response times and reduced primary database load.

Rapid Retrieval Caching for API Exports(Speeds Up Large Data Retrievals)

• API calls for Export Records and Export Reports now reuse cached results.

• Prevents excessive query execution times, reducing API timeouts.

New Background Process for Terminating Stale Queries(Prevents API Session Failures)

• A cron job now runs every few minutes to identify and terminate abandoned queries left running by API users.

• Prevents stuck API sessions that could interfere with new requests.

New "Randomize Record" API Method

• Allows API users to randomize records programmatically.

• Requires parameters: content="record", action="randomize", record=Record Name, randomization_id=Target Field/Event ID.

• Returns: Assigned randomization value or error message.

CDIS API Enhancements(FHIR Validation & New Endpoints)

• FHIR resource validation ensures only supported resources can be retrieved via API.

• New FHIR endpoints: Appointments, Procedures, Medical History, Diagnoses, Device Implants.

Future API Support for Background Data Import(Planned Enhancement)

• Currently, background data import is UI-only.

• Future API updates may allow for asynchronous data imports without API timeouts.

Performance & Usability Enhancements

✔ New Background Process for Pruning Stale Database Queries(Prevents Zombie Sessions)
✔ Survey QR Code Enhancements: Copy, download, and high-resolution SVG support.
✔ File Upload Enhancements: Full file name visibility when hovering over the download link.
✔ Data Import Tool: Now allows tab and semicolon-delimited templates.
✔ Rich Text Editor Upgraded(Now Uses TinyMCE v6).
✔ Updated Help & FAQ Page(Expanded with new documentation from the FAQ Committee).
✔ UI Fixes for Bootstrap 5 Compatibility(Improves system-wide consistency).

New Action Tags

✔ @MC-PARTICIPANT-CODE – Captures the MyCap participant's unique ID when joining via MyCap mobile app.
✔ @MC-PARTICIPANT-JOINDATE – Captures the exact date and time a MyCap participant joins a project.
✔ @SHOWCHOICE – Restricts multiple-choice fields to only display specified choices dynamically.

New Math & Text Functions

✔ Math Functions: mod(dividend, divisor), exponential(number).
✔ String Functions: replace_text(haystack, search, replace), concat_ws(separator, text, text, ...).
✔ New Date Piping Functions: year([dob]), month([visit_datetime]), day([visit_date]).

Dear REDCap Users,

Please note that on Thursday, September 29th REDCap will be down after normal business hours from 6:00 pm to 7:00 pm EST for planned maintenance and an upgrade to 12.4.7. The upgrade will bring more functionality and system improvement to REDCap.

A changelog and summary of new features can be found here: 

https://confluence.research.cchmc.org/pages/viewpage.action?pageId=59703455

Thank you in advance for your patience.

Maxx M Somers, MA

Cincinnati Children’s Hospital Medical Center

Information Services For Research (IS4R)

Senior Project Manager, IS

REDCap Program Manager

Maxx.Somers@cchmc.org

859-866-0653

NEW FEATURES, IMPROVEMENTS/CHANGES & BUG FIXES;

NEW FEATURE: Calendar Sync

• Users may sync their REDCap project calendar or perform a one-time import of their project calendar events to external calendar applications such as Google Calendar, Outlook, Office 365, Zoho, Apple Calendar, or any application that supports iCal or ICS files. They may choose one of the two options below to sync or import their project calendar events to an external calendar application.
  1. Live calendar feed: Add calendar from URL/Internet - A unique web address will be displayed in a dialog on the Calendar page, in which the URL represents a real-time live feed of the REDCap project calendar. Users may copy the URL to paste it as the calendar URL in their calendar application using the option "Add calendar from URL/Internet". This will subscribe their external application to the REDCap project calendar. Privacy Note: This calendar feed URL on the Calendar page is unique to the user in the project. So if the user gets expired, removed from the project, or deleted from the system, their unique calendar feed will go blank and will not output anything anymore (for privacy purposes).
  2. One-time import: Download ICS file - Download and open the calendar ICS file below to import REDCap calendar events manually into the calendar application on your computer, or upload the file to a web-based calendar service. Notice: This is not a live feed but a one-time import. Thus, any new events added to the REDCap calendar in the future will not be automatically added to the external calendar application.
• Feed-syncing Notice: Different calendar applications have different refresh rates. So if new events are added to the calendar in REDCap, they may not immediately appear in the external application that is consuming the feed but will appear after the next refresh interval, which might be some time later that day or the next day (depending on the calendar application). Additionally, the calendar feed represents a one-way feed. This means that while changes made to the calendar in REDCap will automatically show up in the external calendar application, users will not be able to modify them in the external calendar application because they will be read-only.
• Privacy Note: When viewing events from the Calendar page’s feed or downloadable ICS file, any data from Identifier fields will be automatically removed from the feed/file (e.g., if identifier fields are included in the Custom Record Label or Secondary Unique Field, or if the record name is an identifier), in which their data will be replaced with the text “**DATA REMOVED**”.
• New calendar-specific Smart Variables
  1. [calendar-url] - The web address (URL) of the calendar feed or downloadable ICS calendar file belonging to the current record.
  2. [calendar-link:Custom Text] - The HTML web link that, when clicked, will navigate to the calendar feed or downloadable ICS calendar file belonging to the current record. 'Custom Text' is an optional parameter whereby you can specify the visible link text, and if it is not provided, it defaults to simply displaying the URL as the link text.

NEW FEATURE: SendGrid Dynamic Templates for Alerts & Notifications

• SendGrid Dynamic Templates give users significantly more control over the style and design of emails when compared to the standard email alert type. Enabling this feature on the Project Setup page will give users another alert type to choose from on the Alerts & Notifications page called “SendGrid Template”. Thus, similar to Twilio, this feature is a project-level feature that users may enable on individual projects (or users can have administrators enable it for them).
• SETUP & CONFIGURATION: This integration requires that you have an account setup on sendgrid.com. After creating a SendGrid account, you'll need to configure senders for the account, create the dynamic templates you wish to use for REDCap alerts, and generate an API Key with appropriate permissions for REDCap to use. When configuring senders on your SendGrid account, you may specify individual senders, authenticate an entire domain so that any email address associated with that domain may be a sender, or both. Please refer to SendGrid's documentation on how to set up Domain Authentication and how to add individual Verified Senders. To create a dynamic template in your SendGrid account, login to your SendGrid account and use the sidebar to navigate to Email API→Dynamic Templates. Here you can create a dynamic template, give it a name, and associate an email design with it. Please reference SendGrid's documentation on Dynamic Templates and Handlebars to learn more about creating templates in your SendGrid account. Lastly, to create an API Key for REDCap, login to your SendGrid account and use the sidebar to navigate to Settings→API Keys. Here you can create a new API Key and specify its permissions. It is recommended that you create a Restricted Access API Key and only give the API Key the permissions REDCap needs to function. REDCap will need Full Access to Mail Send, Read Access to Sender Authentication, and Read Access to Template Engine. Once you have your API Key, you may use it to configure SendGrid Template email services for alerts & notifications through the REDCap Project Setup page.
• ALERTS & NOTIFICATIONS: The SendGrid Template alert type will allow you to specify a sender email address that's in your SendGrid account's list of Verified Senders or an email address that matches an Authenticated Domain associated with your SendGrid account. You'll also have an interface to choose which of your SendGrid account's dynamic templates you'd like to use for the alert as well as an interface to specify key/value pairs that will be used to populate your template with REDCap data. Lastly, choosing recipients for SendGrid alerts works the same way as choosing recipients for email alerts.
• COST: As REDCap makes API calls to SendGrid's Email API using your account's API Key, your SendGrid account will keep track of REDCap's usage and your SendGrid account will be charged accordingly. This is not done by REDCap but is done internally by SendGrid as you use its services. In this way, no monetary transactions are made by REDCap, and thus it is your responsibility to maintain the funds in your SendGrid account in order to ensure that the service continues to work for your REDCap project. If your SendGrid account runs out of funds, the SendGrid services in REDCap will cease to function. You may reference SendGrid's pricing page to get their latest pricing.

Survey Functionality Improvements

NEW FEATURE: Integration of many features from the “Survey UI Tweaks” External Module. The Survey UI Tweaks EM will not be disabled for any projects

IMPROVEMENT: If custom question numbering is used on a survey page in which no questions have a custom question number defined, the extra space n the left of the questions will be removed to give the questions more room for display on the page.

IMPROVEMENT: On the Survey Settings page, the setting “For Required fields, display the red 'must provide value' text on the survey page?” now has a new option: "Display only the red asterisk". This provides an additional option rather than having to choose between the binary options to hide or not hide the text.

IMPROVEMENT: When taking a survey while on a mobile device, the survey page will auto-scroll whenever selecting a value for a drop-down or radio button field to help the participant scroll down the page more easily.

IMPROVEMENT: New survey setting allows users to set a custom width of the survey displayed on the page between 50% and 100%. The default value for the setting is “Fixed width (default)”.

IMPROVEMENT: New survey setting allows users to display or hide the font resize icons at the top of the survey page. By default, it is set to display the font resize options.

IMPROVEMENT: New survey setting allows users to show or hide the Submit buttons displayed at the bottom of every survey page (including the 'Next Page' and 'Previous Page' buttons).

IMPROVEMENT: New survey setting allows users to provide alternative text for the 'Submit', 'Next Page', and 'Previous Page' buttons displayed at the bottom of every survey page.

CHANGE: The textbox for date, time, and datetime fields are no longer displayed with full width on data entry forms or survey pages where the whole page is disabled (e.g., when locked, when initially viewing a survey response) but instead are now displayed at their typical width.

NEW FEATURE: Instrument-level Data Export Rights -

• Users may specify instrument-level privileges regarding a user's data export capabilities on the User Rights page in a project. A user may be given "No Access", "De-Identified", "Remove All Identifier Fields", or "Full Data Set" data export rights for EACH data collection instrument. This improvement will make it much easier to match a user's Data Exports Rights with their Data Viewing Rights, if you wish, and will give users more granular control regarding what data a user can export from your project.
• Note: Whatever a user’s data export right was in the previous version, that export right will be subsequently extrapolated to all instruments after upgrading. Thus, their export privileges will behave exactly the same as before.
• Improvement: The table displayed on the User Rights page that lists all users’ privileges now includes an instrument count for each category for both Data Viewing Rights and Data Export Rights - e.g., “3 No access, 2 Full Data Set”. This helps provide summary information regarding the user’s instrument-level rights.
• Improvement: When adding/editing a user’s or user role’s privileges in the popup on the User Rights page, as a convenience, users may click the table headers for each Data Export Rights setting or Data Viewing Rights setting to set that setting for all instruments in the project (i.e., as a “check all checkboxes”).
• Note: When adding a new data collection instrument to a project, if the project is in development status, all users will automatically receive "Full Data Set" data export rights for that new instrument. Whereas if the project is in production, all users will automatically receive "No Access" data export rights for the new instrument. This behavior matches how instrument-level rights currently work for Data Viewing Rights when adding a new instrument.
• Change: When importing or exporting users and/or user roles (whether as a CSV file on the User Rights page or via the API), the new instrument-level data export rights are represented as a new column named “forms_export” and are formatted exactly how instrument-level Data Viewing Rights (“forms”) are currently formatted in comma-delimited fashion - e.g., “demographics:1,baseline_data:2,prescreening:3”. In this format, the following represents each data export rights level: 0=No Access, 2=De-Identified, 3=Remove Identifier Fields, 1=Full Data Set.

NEW FEATURE: Survey Start Time and related Smart Variables -

• REDCap now collects when participants begin a survey (i.e., the initial time the survey page is opened). Going forward, any responses collected (partial or completed) will have their start time displayed at the top of the data entry form when viewing the response. NOTE: If the start time is a blank value, it implies that the response began while on an earlier version of REDCap when start times were not yet collected.
• New Smart Variables for Survey Start Date/Time: Users can access the start time via piping by using the new Smart Variables [survey-time-started:instrument] and [survey-date-started:instrument], which can be used inside the @DEFAULT or @CALCTEXT action tags, among other places. If users wish to have them return the raw value, which will be in 'YYYY-MM-DD HH:MM:SS' format and would be more appropriate for conditional logic or calculated fields, simply append ':value' after the unique instrument name - e.g., [survey-date-started:instrument:value].
• New Smart Variables for Survey Duration: Users can obtain the total amount of time that has elapsed since the survey was started (in seconds, minutes, etc.) by using [survey-duration:instrument:units] and [survey-duration-completed:instrument:units]. The Smart Variable [survey-duration] represents the difference between the survey's start time and either its 1) completion time (if completed) or 2) the current time (if not completed), whereas [survey-duration-completed] represents the difference between the survey's start time and completion time, in which a blank value will be returned if the survey has not been completed. Options for 'units': 'y' (years, 1 year = 365.2425 days), 'M' (months, 1 month = 30.44 days), 'd' (days), 'h' (hours), 'm' (minutes), 's' (seconds).

NEW FEATURE: Conditional logic for Survey Auto-Continue - When enabling Survey Auto-Continue on the Survey Settings page for a survey, users may now optionally specify conditional logic to determine whether or not the auto-continue should be applied. As such, REDCap will auto-continue to the next survey *only* if the conditional logic is TRUE or if the logic textbox has been left blank. This new option can be used as a simpler alternative to the Survey Queue, which can require more complex instrument-event level configurations for longitudinal projects.

NEW FEATURE: Dynamic min/max range limits for fields - Instead of using exact values as the minimum or maximum range of Textbox fields (e.g., "2021-12-07"), you may now also use "today" and "now" as the min or max so that the current date or time is always used. These can be used to prevent a date/time field from having a value in the past or in the future. Additionally, you can now pipe a value from another field into the field's min or max range setting - e.g., [visit_date] or [event_1_arm_1][age]. This can help ensure that a Textbox field (whether a date, time, or number) has a larger or smaller value than another field, regardless of whether the field is on the same instrument or not.

NEW ACTION TAG: @FORCE-MINMAX - The action tag @FORCE-MINMAX can be used on Textbox fields that have a min or max validation range defined so that no one will not be able to enter a value into the field unless it is within the field's specified validation range. This is different from the default behavior in which out-of-range values are permissible. Note: @FORCE-MINMAX is also enforced for data imports to ensure the value is always within the specified range.

NEW field validation: "Time (HH:MM:SS)" - This new time-based field validation (unique name "time_hh_mm_ss") will be added automatically and enabled by default during the upgrade process. This validation forces users/participants to enter a time value that contains the hour, minute, and second components. It also includes the usage of the "Now" button and the timepicker popup widget, both of which are displayed next to the field on the survey page or data entry form. Note: Fields with this field validation can be utilized inside the datediff() function. (Thanks to the Field Validation Committee for this addition.)

NEW FEATURE: Smart Variable: [event-number] - The current event's ordinal number as listed on the Define My Events page that denotes the order of the event within a given arm.

IMPROVEMENT:  The Define My Events page now displays a new column to display each event's Event ID number. Also, the Smart Variable corresponding to each column in the table on the Define My Events page (e.g., [event-number], [event-label) are displayed in small gray text below the header text in the table to help users more easily learn where the values of those Smart Variables originate.

NEW FEATURE: Multi-Language Management

• Summary: Users can create and configure multiple display languages for their projects for surveys, data entry forms, alerts, survey invitations, etc. Users can design data collection instruments and have them be displayed in any language that they have defined and translated so that their survey participants or data entry persons can view the text in their preferred language. This eliminates the need to create multiple instruments or projects to handle multiple languages. NOTE: The MLM feature will not auto-translate text, but provides tools so that users may easily translate them themselves.
• Usage: When entering data on a data entry form or survey, users and participants will be able to choose their language from a drop-down list or buttons on the page to easily switch to their preferred language for the text displayed on the page. This feature allows users to translate all text related to the data entry process, both for surveys and for data entry forms. Even various survey settings and email text can be translated. For users on data entry forms, if a language is selected, that selection is stored in the user’s user account settings internally (in the REDCap backend database), whereas a survey participant’s selected language will be stored in a cookie in their web browser as a way to remember their language preference if they return in the future (and also to maintain their selected language from page to page). The language can be pre-selected for a participant, if desired, using the “Language preference field” setting on the MLM page in the project or via the @LANGUAGE-FORCE action tags (seen below).
• User Rights: Users must have Project Design/Setup privileges in a project in order to see the link to the Multi-Language Management page on the left-hand menu.
• Note: The MLM feature works seamlessly with SMS messages sent via Twilio. Additionally, the MLM feature works with the e-Consent Framework, in which the archived PDF of the participant’s consent form will be stored in the File Repository in the same language in which the participant took the survey. Note: When a project is in production, the MLM page and all translations can only be modified when the project is in Draft Mode. So if the user desires to make edits or additions to their translations, they must first enable Draft Mode via the Online Designer, and then return to the MLM page to make translation changes while in Draft Mode. When the drafted changes are approved, their translation changes made while in Draft Mode will automatically be approved together with them.

NEW FEATURE: New Action Tags for Multi-Language Management

1. @LANGUAGE-CURRENT-FORM - Allows you to capture the currently used language in projects where multilingual data is enabled on data entry forms. The @LANGUAGE-CURRENT-FORM action tag can be used on fields of type 'Text Box' (no validation), and 'Drop-down List', or 'Radio Buttons' (these need to have choices whose codes correspond to the IDs of the defined languages - e.g., 'en'). This action tag is only active on data entry forms and will always, when possible, set the field's value to the currently active language.
2. @LANGUAGE-CURRENT-SURVEY - Same as @LANUGAGE-CURRENT-FORM, but works only on survey pages. For multi-page surveys, @LANGUAGE-CURRENT-SURVEY needs to be used on a field of each page where capture of the language is relevant (e.g. for performing branching).
3. @LANGUAGE-FORCE - When used on a field, the data entry form or survey on which the field is located will be rendered in the specified language (which must have been set up using the Multi-Language Management feature). The format must follow the pattern @LANGUAGE-FORCE="???", in which the ID of the desired language should be inside single or double quotes - e.g., @LANGUAGE-FORCE="de". Piping is supported - e.g., @LANGUAGE-FORCE="[field_name]". When the language is forced successfully (i.e., it exists and is active), the language selector is hidden. Using this together with @LANGUAGE-CURRENT-FORM/SURVEY on the source field for @LANGUAGE-FORCE may be used to 'lock in' a user to their selected language.
4. @LANGUAGE-FORCE-FORM - Same as @LANGUAGE-FORCE, but the effect is limited to data entry forms (i.e. this does not affect surveys).
5. @LANGUAGE-FORCE-SURVEY - Same as @LANGUAGE-FORCE, but the effect is limited to surveys (i.e. this does not affect data entry forms).
6. @LANGUAGE-SET - When used on a Drop-down or Radio Button field only, this action tag will allow the field's value to control the currently shown language (in the same way as switching the language via the buttons at the top of the page). Tip: When used in a survey, this field could be prepopulated (and thus auto-selected) by embedding a participant's language ID in the survey URL itself (for details, see the FAQ's "How to pre-fill survey questions" section).

NEW FEATURE: Form Display Logic

• Form Display Logic is an advanced feature that provides a way to use conditional logic to disable specific data entry forms that are displayed on the Record Status Dashboard, Record Home Page, or the form list on the left-hand menu. You might think of it as 'form-level branching logic'. Form Display Logic can be very useful if you wish to prevent users from entering data on a specific form or event until certain conditions have been met. The forms will still be displayed on the page, but they will be disabled in order to prevent users from accessing them. Below you may define as many conditions as you want. A form may be selected in multiple conditions, but if so, please note that the form will be enabled if at least one of the conditions is met. The Form Display Logic does not impact data imports but only operates in the data entry user interface to enable/disable forms. Additionally, Form Display Logic is not utilized by the Survey Queue at all but can affect the behavior of the Survey Auto-Continue feature if the checkbox for it is enabled in the setup dialog. The Form Display Logic setup can be found by clicking the “Form Display Logic” button at the top of the instrument list in the Online Designer.
• This feature serves as the official integration of the Form Render Skip Logic external module created by Philip Chase and his team. Thanks to them for their work on this module. Note: When upgrading REDCap to v12.0.0 or higher, if the Form Render Skip Logic is installed and is being used by any projects, all the configuration settings for the module will automatically be translated into the new Form Display Logic settings format, after which the external module will be disabled for each project and also for the entire system (since it will no longer be needed). This all happens automatically during the upgrade.

IMPROVEMENT: Errors displayed in the Survey Invitation Log when sending SMS or Voice Calls via Twilio will now display the full error message returned by Twilio's API to provide the user with more information regarding why the SMS/Voice Call failed to send successfully.

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, user’s 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.

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).
• “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:  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.

IMPROVEMENT:  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.

IMPROVEMENTS/CHANGES, BUG FIXES;

IMPROVEMENT: The Project Revision History page now displays icons next to each production revision and snapshots, and after being clicked, will display options to compare that revision/snapshot with any other revision/snapshot in the project. (This feature represents the integration of the "Data Dictionary Revisions" external module created by Ashley Lee at BC Children's Hospital Research Institute).

IMPROVEMENT: When using the eConsent Framework in a project, the "PDF Survey Archive" tab on the File Repository page now displays a "Download all" button that will download all PDF files displayed on the page in a single zip file. Additionally, there is a record filter drop-down list and a "file type" drop-down list, which distinguishes between general "PDF Auto-Archiver" PDFs and "eConsent Framework" PDFs. Note: If a user is in a Data Access Group, they will only be able to download and filter on records in their DAG.

NEW FEATURE: New API method “Rename record” and new developer method REDCap: allows users/developers to rename a record in a project. For multi-arm longitudinal projects where a record might exist on multiple arms, the $arm number can be specified to rename the record only on the specified arm, otherwise by default it will rename the record in all arms in which it exists.

NEW FEATURE: New action tag: @RICHTEXT - Adds the rich text editor toolbar to a Notes field to allow users/participants to control the appearance (via styling and formatting) of the text they are entering into the field.

NEW FEATURE: New API methods -

• Delete User - Remove a specified user from a project.
• Export User Roles - Returns a list of user roles, including their role name, unique role name, and privileges, from a project.
• Import User Roles - Allows one to create new roles (specifying their role name and privileges) or edit the role name and privileges of existing roles.
• Delete User Role - Deletes a specified user role from a project.
• Export User-Role Assignment - Returns a list of project users and what user role to which they are assigned.
• Import User-Role Assignment - Allows one to assign, reassign, or unassign one or more users to/from a user role in a project.

NEW FEATURE: New drop-down options on the User Rights page to allow users to perform the tasks listed below using a CSV file in the user interface.

• Upload users and their privileges
• Download users and their privileges
• Upload user roles and their privileges
• Download user roles and their privileges
• Upload user role assignments
• Download user role assignments

IMPROVEMENT: More options/parameters for the API Delete Record method - Users can now specify instrument, event, and/or repeat_instance to delete the data from a specified instrument, event, or repeating instrument/event for the records specified in the API request. In previous versions, the only option was to delete the entire record.

IMPROVEMENT:  On the External Modules page in a project, users with appropriate privileges may now import and export the configuration settings for any module that is enabled in the project. This feature functions as a convenience by allowing users to easily migrate the configuration settings of one or more modules to another project that has the same module(s) enabled.

IMPROVEMENT:  If a user is not assigned to a Data Access Group in a project, the user will now see a new "[No assignment]" option in the "Displaying Data Access Group" drop-down list on the Record Status Dashboard, in which selecting that option will display only records that have not been assigned to any DAG.

IMPROVEMENT/CHANGE:  "Previous instrument" and "Next instrument" buttons were added at the top right of the Online Designer field-view page to allow easier navigation between instruments.

NEW FEATURE: New action tag: @DOWNLOAD-COUNT - The @DOWNLOAD-COUNT action tag provides a way to automatically count the number of downloads for a File Upload field or a Descriptive field attachment. It can be used on a Text field or Notes field so that its value will be incremented by '1' whenever someone downloads the file for either a File Upload field or a Descriptive field attachment. The variable name of the File Upload field or Descriptive field whose downloads are to be counted should be provided inside the @DOWNLOAD-COUNT() function. For example, the Text field 'my_download_count' might have its action tag defined as @DOWNLOAD-COUNT(my_upload_field), in which 'my_upload_field' is the variable of a File Upload field. Whenever the file is downloaded on a data entry form, survey page, or report, the value of the field with this action tag will be incremented by '1'. If that field has no value or has a non-integer value, its value will be set to '1'. NOTE: The download count field must be in the same context as the File Upload field or a Descriptive field. This means that in a longitudinal project the two fields must be on the same event, and in a repeating instrument context, they must be on the same repeating instrument.

...

REDCap Update Summary

Dear REDCap Users,

Please note that Tuesday, March 24th REDCap will be down after normal business hours from 5:00 pm to 6:00 pm EST for planned maintenance and an upgrade. The upgrade will bring more functionality and system improvement to REDCap. REDCap will be upgraded to 9.5.18.

A changelog and summary of new features can be found here: 

https://confluence.research.cchmc.org/pages/viewpage.action?pageId=59703455

Thank you in advance for your patience.

Maxx 

Highlights of what this REDCap update means for REDCap users and researchers

• Improvement: New content was added to the "Help & FAQ" page
• New feature: Built-in activation process for external modules (system-level setting - enabled by default)
  • All modules that have been set as “Discoverable” in the system will now have a “Request Activation” button displayed next to them when viewing the list of available modules on the External Modules page in a project. If a user with Project Setup/Design privileges in the project clicks the button, it will add a new item to the To-Do List in the Control Center (and also send an email to the REDCap administrator if admin email notifications are enabled) that will ask the admin to activate the module. Once the admin has activated the module for the user, the user will receive an email informing them that the module has been activated for the project.
  • Note: This option can be disabled to hide this button for all discoverable modules (e.g., if you wish to use your own module activation process) at the top of the “Modules/Services Configuration” page in the Control Center.
• New feature: Users can self-activate an external module for a project (module level setting - disabled by default)
  • For any given module that has been enabled in the system and that has also been set as “Discoverable”, a REDCap administrator may optionally set a module setting (in the Configure Module popup for the module in the Control Center) that will allow any user with Project Setup/Design privileges in a project to activate the module in their project on their own (i.e., without an administrator having to enable it for them).
  • Since this is a module-level setting, it is completely opt-in by the REDCap administrator for any given discoverable module.
• Improvement: In Alerts & Notifications when clicking the "Preview Message by Record" option, it now displays the Custom Record Label and/or Secondary Unique Field value in the record drop-down list in the dialog.
• Improvements and changes when exporting data from REDCap into SAS
  • Full integration of the Missing Data Code functionality in the SAS data export syntax file to prevent issues when loading data containing Missing Data Codes into SAS.
  • Note: The SAS Pathway Mapper file has been removed and is no longer utilized. Users exporting data to SAS will now need to manually modify the path of the CSV data file in their .SAS syntax file to reflect its locally saved path on the device.
• Improvement:When using the Data Resolution Workflow and exporting all data queries in a CSV file, the following attributes are now all exported as their own separate columns in the CSV file: record name, event name, data access group, data quality rule, and field name. In previous versions, some of these attributes existed together in a single column and thus were harder to parse out individually. Additionally, the following columns have been added to the CSV export file: Current Query Status, Time Raised, and Time Resolved. 
• New Action Tag: @HIDDEN-PDF - Hides the field only in the downloaded PDF of one or more instruments (including blank PDFs, PDFs with data, and compact PDFs with data). Note: Other @HIDDEN action tags will not hide fields inside PDF exports, so @HIDDEN-PDF must be used specifically to hide fields in PDFs.
• Improvement: More rich text editors - The rich text editor is now available when composing survey invitations. This includes composing Automated Survey Invitations or invitations to be sent via the Participant List or via the Survey Options on data entry forms.Improvement: The rich text editor is now available on the Email Users page in the Control Center and also for the Survey Confirmation Email option on the Survey Settings page.
• Improvement: The Configuration Check page now checks if any hook functions are missing from the Hook Functions file used by the REDCap installation. If any are missing, instructions are provided in order to add them.
• Improvement: Line breaks may be preserved in data values in CSV data exports - When creating/editing a report, the section "Additional report options" contains a new setting: "Remove line breaks/carriage returns in all text data values (only applicable for CSV Raw and CSV Label data exports)". This setting will be enabled by default for all existing reports and for any new reports being created. The option will effectively enabled (i.e., will remove line breaks) when exporting Reports A and B in order to be consistent with their current behavior in previous versions. This option is only used for CSV data exports and not for reports or exports to statistical analysis packages. (Ticket #32418)
  Improvement: Added “Copy” and “Paste” options to the [right-click] context menu for all rich text editors.
• Improvement: A custom email “display name” can be set for the email sender when sending an email for Alerts & Notifications, the Survey Email Confirmation option on the Survey Settings page, and when sending survey invitations via Automated Survey Invitations, via the Participant List, or via the Compose Invitation option on a data entry form.
• Improvement: The email “display name” for most outgoing emails is now automatically populated and thus is able to be displayed in the recipient’s email client. Previous versions did not use the display name but left it blank for outgoing emails. For user requests that are triggered by users, such as production change requests, API token requests, etc., the user’s first and last name from their My Profile page will be used automatically as the display name in those emails. For emails originating from REDCap administrators that are automated by the system, the email display name will the “Name of REDCap Administrator” setting (from the General Configuration page) or else the “Contact name to display on Home page” (from the Home Page Configuration page), which is dependent upon the type of email being sent.
• New feature: Missing Data Codes (i.e., “Data Missingness” functionality)
  • Fields that have a blank/missing value may be marked with a custom 'Missing Data Code' to note why the value is blank. These missing codes may be used to aid in data analysis by specifying why a field lacks a value. Users may enable custom missing data codes at the project-level in the Additional Customizations popup on the Project Setup page. The missing codes should be coded just like the choices of a multiple choice field with code + comma + label, in which the codes can only have letters, numbers, dots, dashes, and underscores (e.g., '-999, Not asked' or 'UNK, Unknown'). If no codes are entered, this feature will remain disabled. After missing data codes have been set up in a project, you will see an 'M' icon next to each field when viewing a data entry form. Click the icon to open your list of missing data codes, and select one. Once selected, it will save the missing code as the literal data value for the field. Missing data codes can be used for any field type (e.g., date, slider, file upload fields).
  • If utilizing missing data codes, the functionality will be enabled on all fields by default, and the code will be saved as the literal data value for the field.
  • New action tag @NOMISSING can disable the missing data option for a given field
  • Behavior with branching logic – If a field should be hidden by branching logic, REDCap will ask the user (except on surveys) if they wish to delete the value of the field being hidden. But if the field has a missing data code saved for it, it will still hide the field but will not remove the missing data code as the field’s value. This allows a field to still be “blank” and have a missing code while being hidden by branching logic.
  • New isblankormissingcode() function for branching logic, logic, and calculations - Returns a boolean (true or false) if the field value is blank/null/"" or if the value is a Missing Data Code, in which Missing Data Codes have been explicitly defined in the project on the Project Setup page under Additional Customizations. E.g. isblankormissingcode([age]), in which if "age" has a value of "UNK" (which might be a Missing Data Code in a project), then it will return TRUE. And if the field has any non-blank/non-null value that is also not a Missing Data Code, it will return FALSE.
  • Missing data codes can be imported via API, Data Import Tool, or REDCap::saveData (for plugins/hooks/modules)
  • All the missing data codes are displayed for reference at the top of the Codebook page
  • When creating/editing a report, a new option exists under the “Addition report options” section: “Display any Missing Data Codes in place of blank values (where applicable)”. This option will allow users (based on their preference) to show or not show the Missing Data Codes (if they have been saved for any field in any record) in the report or export.Note: In PDF exports of data collection instruments, any Missing Data Codes will be represented as blank values in the PDF.
  • Changes for Data Quality Rules
    • DQ rule A and B (for finding blank values) will continue to return only truly blank values and thus will not return fields with missing data codes saved as the value.
    • New rule - DQ “Rule I (Fields containing missing data codes)” has been added as a new rule for specifically finding fields with missing data codes saved as the value.
    • DQ rule F (Hidden fields that contain values) will ignore fields that have a missing data code saved as the value because it is allowable for such fields to be hidden by branching logic while still maintaining a missing data code as a value.

• Improvement/change: If a user is viewing a data entry form that has been enabled as a survey and then clicks "Compose survey invitation" in the survey options at the top right of the page, if they compose and send an invitation that is marked to be sent "Immediately", it will display a popup to inform the user that it is recommended that they leave the page very soon before the respondent has a chance to enter any data on the survey page. This is done because if the respondent begins entering data on the survey immediately after receiving the invitation, and then the user (while still viewing the data entry form) saves the form, the user could unwittingly erase the respondent's data values that were just entered.
• Improvement: Major performance improvement when loading the Participant List page for projects with surveys. For projects with thousands of records or more, this page should be significantly faster.
• Improvement: Performance improvement for record searching on the "Add/Edit Records" page when entering part of a record name in the "Enter a new or existing [Record ID]" text box. For projects with thousands of records or more, this functionality should be much faster.
• Improvement: Performance improvement for projects using record auto-numbering, in which the process of generating the record name of the next potential record is much faster, especially for projects with many records.
• Improvement: Performance improvement for large data exports that might have previously taxed the REDCap servers or might have failed to complete altogether for some large projects. An internal auto-batching mechanism is now utilized to limit the performance hit to the servers (both database and web server) when exporting large quantities of data (via API or user interface) in order to improve the user experience and to prevent REDCap processes from using up too many server resources. Note: This does not necessarily mean that data exports will be faster; in fact, some exports might be slightly slower as a means of preserving server resources used by REDCap processes.
• Improvement: Performance improvement for when REDCap is generating the record list cache for a project, especially for projects with Data Access Groups. For each project, REDCap maintains a record list in a database table that is used throughout a project. This record list improves overall performance, especially for large projects. Every few days the record list cache is automatically rebuilt internally. The process of rebuilding the record list is now more efficient, faster, and less error-prone than in previous versions.
• Improvement/change: The Codebook now denotes if an instrument is enabled as a survey, in which it is noted immediately to the right of the instrument name.
• Improvement: If the "File Upload field enhancement: Password verification & automatic external file storage" setting has been enabled in a project, then when a user attempts to delete a file for a File Upload field (including the deletion of older revisions for that field), it will provide a text box in the "Delete file?" popup in order to allow the user to optionally provide a reason for why they are deleting the file (if they wish), after which this reason will be logged on the Logging page.
• New feature: File Version History for File Upload fields (project-level setting)
  • This feature allows a new file to be uploaded onto a File Upload field that already has a file uploaded for it. If a file has already been uploaded, the field will have a new link “Upload new version”, and after being clicked, it will allow the user to upload another file without having to delete the existing one. The old/existing file will not be deleted but will still be accessible as an older version of that file in the Data History popup (by clicking the “H” icon next to the field). Within the Data History popup, a user may view, download, or delete any existing version of the file that exists, in which all versions of the file will be displayed in a table format and listed in chronological order with regard to being uploaded.
  • “Import File” API behavior: When the File Version History feature is enabled for a project, and the “Import File” API method is used to import a file into a File Upload field that already has a file saved for it, the new file will overwrite the existing file but keep the existing file in the File Version History, thus not deleting it. This is different for projects that have the File Version History disabled, in which importing a new file will delete the existing file.
  • For all upgrades/installs, this feature will be enabled for the system and for all projects. It may be disabled for all projects by disabling the system-level setting, which is located on the Modules/Services Configuration page in the Control Center. Alternatively, it may be left enabled at the system level, and you may set it so that all new projects (created in the future) will have the feature enabled or disabled, which can be done on the Default Project Settings page in the Control Center. While this feature will be enabled by default for all projects, if you wish to disable it for all existing projects, then you may run the following SQL on the database after the upgrade: UPDATE redcap_projects SET file_upload_versioning_enabled = 0;
• Improvement: The Control Center's left-hand menu now contains a text field for entering a project's PID (project ID), after which it will direct the user to that project. This provides a quick way of navigating to a project when you have the PID.
• Improvement: The Data History Popup for File Upload fields now provides more detailed information, such as the filename of the uploaded file.
• Improvement: In a project with repeating instruments, the Record Home Page now displays a count of total instances of a given repeating instrument next to the instrument name in the tables of instances displayed at the bottom of that page.
• 10 new Smart Variables
  • [project-id] - The Project ID (i.e., PID) of the current REDCap project.
  • [user-fullname] -The current user's first and last name (as listed on their My Profile page).
  • [user-email] - The current user's primary email address (as listed on their My Profile page).
  • [redcap-base-url] - The base web address for the REDCap installation.
  • [redcap-version] - The current REDCap version number of the REDCap installation.
  • [redcap-version-url] - The base web address of the current REDCap version directory for the REDCap installation.
  • [survey-base-url] - The base web address for surveys for the REDCap installation.
  • [instrument-name] - The unique instrument name of the current survey or data entry form. It will return a blank value if not in an instrument context.
  • [instrument-label] - The instrument label of the current survey or data entry form. It will return a blank value if not in an instrument context.
  • [survey-title] - The survey title of the instrument specified by the 'instrument' parameter (if provided). If the 'instrument' parameter is not provided, the current survey instrument will be used, else it will return a blank value if not in an instrument/survey context.
• 4 new Action Tags
  • @NOW_SERVER - Loads the REDCap server's date+time into a blank Text field - similar to the @TODAY tag but additionally includes the time portion. If the field has validation, the value will adjust to match the date format. NOTE: The time used will be the REDCap server's local time, which might be different from the user's local time if in another timezone. Also, do not use this tag on fields with branching logic because it will always prompt the user to erase the value, so look at using @HIDDEN instead if you wish to hide the field.
  • @TODAY_SERVER - Loads the REDCap server's date into a blank Text field - similar to the @NOW tag but without the time portion. If the field has validation, the value will adjust to match the date format. Also, do not use this tag on fields with branching logic because it will always prompt the user to erase the value, so look at using @HIDDEN instead if you wish to hide the field.
  • @NOW_UTC - Loads the current UTC/GMT date+time into a blank Text field - similar to the @TODAY tag but additionally includes the time portion. If the field has validation, the value will adjust to match the date format. NOTE: The time used will be the current UTC/GMT time, which might be different from the user's local time if in another timezone. Also, do not use this tag on fields with branching logic because it will always prompt the user to erase the value, so look at using @HIDDEN instead if you wish to hide the field.
  • @TODAY_UTC - Loads the current UTC/GMT date into a blank Text field - similar to the @NOW tag but without the time portion. If the field has validation, the value will adjust to match the date format. Also, do not use this tag on fields with branching logic because it will always prompt the user to erase the value, so look at using @HIDDEN instead if you wish to hide the field.
• Improvement: The email sent to the REDCap administrator that contains a link to the page for reviewing production project changes now includes the project ID (PID) in the email subject to allow admins to track emails for projects more easily and not get them confused with one another. (Ticket #48141)
• New feature: Rich text editor for field labels and section headers
  • For any field on an instrument in the Online Designer, users may optionally utilize the rich text editor for styling field labels or section headers with many text-formatting options. The rich text editor allows users to change the color of text (including background color), create tables, add text of varying sizes, bullet lists, and more. For any field labels that were originally created without the rich text editor, users may optionally enable the rich text editor for any field by clicking the 'Use the Rich Text Editor' checkbox. It may also be disabled afterward at any time just the same. Rich text is enabled by default for any new fields being created via the Online Designer.
  • Note: The PDF export of surveys/instruments will *not* reflect all the styling of the rich text editor, so keep in mind that line breaks and paragraphs should be represented well in PDFs, but other text-formatting options, such as large text, bullet points, and colors are not able to be translated into the PDF export of the instrument. This is a current limitation in REDCap.

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

REDCap Update User Summary

Dear REDCap Users,

Please note that Tuesday, Aug 26th (tomorrow) REDCap will be down after normal business hours (5:30 pm to 8:30 pm) for planned maintenance. We apologize for the short notice. We have some functionality issues that need to be addressed via a database improvement and a REDCap Upgrade. Additionally, REDCap will be upgraded to 9.1.3.

Highlights of what this REDCap update means for REDCap users and researchers

New feature: Alerts & Notifications

• The Alerts & Notifications feature allows you to construct alerts and send customized email notifications. These notifications may be sent to one or more recipients and can be triggered or scheduled when a form/survey is saved and/or based on conditional logic whenever data is saved or imported. When adding/editing an alert, you will need to 1) set how the alert gets triggered, 2) define when the notification should be sent (including how many times), and 3) specify the recipient, sender, message text, and other settings for the notification. For the message, you may utilize customized options such as rich text, the piping of field variables (including Smart Variables), and uploading multiple file attachments. While similar in many respects to Automated Survey Invitations, Alerts & Notifications allow for greater complexity and have more capabilities. For example, alerts apply to both data entry forms and surveys, and they also allow for more options regarding who can be the recipient of a notification (project users, survey participants, etc.).

Design Update

• Improvement: The rich text editors on the Survey Settings page have now been updated to a newer version of the TinyMCE package. (Note: IE9 and IE10 will still use the older version of the rich text editor because they are not compatible with the newer one.)
• Improvement: New records can now be created directly from the Record Status Dashboard. If record auto-numbering is enabled, it will display an “Add new record” button, otherwise, it will display a text field for users to enter a new record name to create.
• Improvement: Links to the Online Designer, Data Dictionary Upload page, and Codebook were added to the left-hand project menu for easier navigation. Also, a new section “Project Home and Design” was added on the left-hand menu to contain all these links, as well as the Project Home and Project Setup page links.
• Change: The Quick Tasks box on the Project Home page was removed since all the pages listed inside it are now located on the left-hand project menu, thus making the Quick Tasks box redundant.
• Change: Replaced many of the older icons in the user interface with Font Awesome icons, especially on the left-hand project menu and left-hand Control Center menu.
• Change: Consolidated the two project pages “Record Locking Customization” and “E-signature and Locking Mgmt” into a single two-tabbed page named” Customize & Manage Locking/E-signatures”. Note: If the user only has access to one of these pages, they will simply not see the other page/tab.

eConsent Updates and Improvements 

• Improvement: Force e-Consent signature fields to be erased when modifying responses - The e-Consent Framework setup on the Survey Settings page has a new option to allow users to specify up to five signature fields in the current survey, in which it will force all signature field values to be erased in the survey if the participant clicks Previous Page button while on the certification page (i.e., the last page of the survey). In many situations when using e-Consent, it is required that if the participant completes all the survey responses and gets to the certification page but then decides to go back to modify some responses, the field (or multiple fields) where they supplied their signature must first be erased, thus forcing them to re-sign the survey before they complete it. This new e-Consent Framework option helps to comply with this particular situation. Note: Only freeform text fields, signature fields, and number fields may be used as e-consent signature fields here, and those fields must be Required fields.
• Improvement: Custom message for e-Consent Framework settings - In the e-Consent Framework section on the Modules/Services Configuration page in the Control Center, an administrator may define custom text (including HTML styling), in which that custom text will be displayed at the bottom of the e-Consent Framework section on the Survey Settings page in every project. This may be utilized for informing users of some information surrounding the use of the e-Consent Framework at the local institution, for example.

 Bug Fix

• Major bug fix: When a project is using a public survey that has "Save & Return Later" enabled with "Allow respondents to return without needing a return code" enabled, then if a participant clicks the "Save & Return Later" button on the public survey and leaves the survey open on the "Your survey responses were saved!" page while another participant partially or fully completes the survey, and then if the original participant clicks the "Continue Survey Now" button on the "Your survey responses were saved!" page, then the original participant will mistakenly create a brand new record/response whenever they submit a survey page again after returning.

Previous Updates

...

REDCap Update User Summary

REDCap will be down for a planned outage from 5:00pm to 6:00pm EDT on Wednesday, March 15th. We will be updating to REDCap 8.10.2

Highlights of what this REDCap update means for REDCap users and researchers

REDCap Report Improvements

New feature: Report Folders 
New feature: “Edit Access” for reports
New feature: Report search
Improvement: A project's Record ID field can now be used as a Live Filter in any given report, thus allowing users to easily view the report for a single record.
Improvement: When exporting a report, a new “Data formatting options” section appears in the export dialog to allow users to choose the CSV delimiter character to be used in CSV Raw Data and CSV Labels exports. 
Improvement: When exporting a report, a new “Data formatting options” section appears in the export dialog to allow users to optionally force all numbers into a specified decimal format. 
New report option that will combine checkbox options into a single column of only the checked-off options. Previously, any checkbox fields in a report would have their choices represented as separate columns in the report, but with this new setting, they can now all be represented as a single column with comma-delimited values and comma-delimited labels. 
Report description – Users may now optionally set a description for a report
Change: When exporting a report, it now includes the report’s title as part of the resulting export files’ file name.

Smart Variable Integration Continues

Improvement: Smart Variables are now able to be utilized in Data Quality rule logic. Note: In many cases, Smart Variables in the logic may cause Data Quality rules to take much longer to complete, which is due to the fact that the logic has to be re-evaluated for *every* item being processed by the DQ rule, whereas normally the logic only needs to be evaluated just once at the beginning of when the DQ rule is executed.

Improvement: Data Quality rule H (i.e., "Incorrect values for calculated fields") and auto-calcs (i.e., the process of calc fields being triggered by data imports or cross-form/cross-event calculations) can now handle Smart Variables that are used inside calculated field equations. In previous versions, such calc fields could only successfully run while on a data entry form or survey page.

Performance Boost

Improvement/bug fix: In previous versions, it was very difficult (and sometimes impossible) to create reports with lots of fields in projects that contained >1000 total fields. In some cases, it would cause the Create Report page to be very sluggish or even to crash in some cases. This should no longer happen, and users should be able to easily create reports with thousands of fields, if they wish, with no problem.

Improvement: Performance boost – Certain pages in projects with thousands or more records should now load much faster in most cases. This includes the Record Status Dashboard, various pages utilizing Data Access Groups, and certain reports. Reports A and B should especially see significantly faster loading (excluding when viewing “all” pages in report A or B).

Misc. Notable Improvements

Bug fix: In REDCap Messenger, it might display that there are unread messages for the user to read even though there are none.
Improvement: When selecting a color for an item under "Custom survey theme options" on the Survey Settings page, the color-picker now allows users to provide the Hex color code (e.g., #0b5394) to choose the color of the item. 
Improvement: A new "Filter by event" option was added to the Logging page:
New feature: PROMIS Batteries – 15 batteries of instruments are now available in the REDCap Shared Library. 

API Improvements

Change/improvement: Super API Tokens can now be used for the "Export REDCap Version" API method. In previous versions, only project-level API tokens could be used for this method. This will allow users to be able to obtain the REDCap version number outside the context of a project.

New API method: “Import Repeating Instruments and Events” – Allows users to import a list of the repeated instruments and repeating events for a project as a means of setting which instruments and events should be repeatable.

REDCap Update User Summary
REDCap will be down for a planned outage from5:00pm to7:00pm EDT onMonday October 8th. We will be updating to REDCap 8.5.13.

Highlights of what this REDCap update means for REDCap users and researchers

New Feature: Survey-specific email invitation fields
You can designate any email field in your project to use for sending survey invitations for that particular survey. Thus, you can collect several email addresses (e.g., for a student, a parent, and a teacher) and utilize each email for a different survey in the project. Then you can send each person an invitation to their own survey, after which all the survey responses get stored as one single record in the project. To learn more about Survey-specific email invitation fields click here

New Feature: Smart Variables
Smart Variables are dynamic variables (from a predefined list of 32 that can be found here) that can be used in calculated fields, conditional/branching logic, and piping. Similar to using project variable names inside square brackets - e.g., [heart_rate], Smart Variables are also represented inside brackets - e.g., [user-name], [survey-link], [previous-event-name][weight], or [heart_rate][previous-instance]. But instead of pointing to data fields, Smart Variables are context-aware and thus adapt to the current situation. Some can be used with field variables or other Smart Variables, and some are meant to be used as stand-alone. There are many possibilities. Smart Variables can reference things with regard to users, records, forms, surveys, events/arms, or repeating instances. To learn more about Smart Variables click here

New Feature: Improved e-Consent Framework:
New e-consent tools including an extra certification page, better consent review workflow and PDF saving tools, and improved signature box look and workflow. As an optional tool, additional e-consent values (i.e., name, date of birth, IP Address, etc.) can be added to the PDF as extra documentation of the identity of the person who is consenting. Improved e-signature workflow and look. To learn more about e-Consent Framework click here

New Feature: PDF Auto-Archiver
Upon survey completion, a compact PDF copy of the survey response can be automatically stored in the project's File Repository, from which the archived PDFs can be downloaded at any time.

Improvement: SQL fields can utilize Smart Variables
Utilizing Smart Variables in SQL fields can be very powerful because they allow the query to be truly dynamic and change from context to context or record to record, rather than it always being a static query that gets executed against the database.

Bug fix: Twilio Participant Preference Selection with DateDiff logic
When using the Twilio telophony module for sending survey invitations while also using Automated Survey Invitations that contain conditional logic containing datediff+today or datediff+now, if the ASI has "Participant Preference" as the invitation type, then in certain cases (but not all the time) it would mistakenly send the invitation via email rather than via the participant's preferred delivery method. And if those participants do not have an associated email address, then the invitation would simply fail to send, as noted in the Survey Invitation Log.

To see a full list of new features and bug fixes please click here.

Have questions? Please attend a workshop to ask questions and have a discussion about a specific issue or attend a training to see a presentation covering the basics. All users can be found at: CCTST Events

Full List of Updates and Bug Fixes

BUG FIXES & OTHER CHANGES:

• Medium security fixes: Many Cross-Site Scripting (XSS) vulnerabilities were found in various pages in which a malicious user could potentially exploit them by manipulating the query string or POST parameters of an HTTP request.

• Minor security fixes: Some Cross-Site Scripting (XSS) vulnerabilities were found on the "Create users (bulk upload)" section of the "Add Users" page in the Control Center, in which a malicious user could potentially exploit them by manipulating the contents of the CSV file that an administrator uploads on that page to create new Table-based users.

• Bug fix: If a survey is using "Save & Return Later" with the option "Allow respondents to return without needing a return code" enabled, then if a participant takes a survey using a public survey link and clicks the "Save & Return Later" button at the bottom of the survey, REDCap would mistakenly email them the public survey link rather than their private survey link which would normally allow them to return to their survey response to begin where they left off. The public survey link that gets emailed to them would mistakenly not allow them to continue their survey response.

• Bug fix: If text data that contains line breaks/carriage returns is piped into another field value via piping inside an @DEFAULT action tag, the piped text would mistakenly contain HTML break tags (e.g., <br>) rather than proper line breaks/carriage returns.

• Bug fix: If a project's "Character encoding for exported files" option (on the Edit A Project' Settings page) is set to "Chinese (UTF-8)", then the webpage would crash with a fatal PHP error whenever a user attempted to download a PDF of one or more data entry forms. (Ticket #32892)

• Bug fix: When piping a radio button field into another field's label on the same instrument, if the piped field is modified on that page, thus instantly piping the new selected value's choice label, the choice label being piped would mistakenly be non-bolded text, even though the rest of the field label remains as bolded text.

• Bug fix: For a project that utilizes the randomization module, if any of the strata fields being used in the randomization have field labels or field notes into which data is being piped, then the randomization dialog popup that displays these strata fields would mistakenly not have the data piped into their labels/notes. (Ticket #33282)

• Bug fix: When a project contains repeating instruments, and a report is created that contains fields from a repeating instrument, the "Stats & Charts" view of that report might mistakenly display an incorrect number of missing values for fields on a repeating instrument. (Ticket #32078)

• Bug fix: On a data entry form or survey that utilizes a calc field or certain action tags anywhere on the page, a random blank text field might mistakenly have a red sidebar appear on the input field for no reason.

• Bug fix: If an External Module is utilizing the API endpoint URL, and a new REDCap version has been placed on the web server but the upgrade has not been completed yet, then the API endpoint would mistakenly redirect to the wrong place. (Ticket #33520)

• Bug fix: For surveys that have no questions and have been set to "One section per page (multiple pages)" in their survey settings, it would mistakenly display the Form Status field on the survey page. (Ticket #33467)

• Bug fix: In a production project in draft mode when adding a matrix of fields in the Online Designer and assigning it a matrix group name that already exists, it mistakenly allows the user to add that matrix group name, but then subsequently displays an error message when the whole matrix setup is saved. (Ticket #33661)

• Bug fix: When using the Data Search feature on the "Add/Edit Records" page, the "Searching..." text/spinner would not accurately reflect the search request time but would mistakenly disappear on some long searches, thus making it appear that the search has completed when it actually has not. (Ticket #7805)

• Various fixes for External Modules framework

• The Help & FAQ page content was updated

• Bug fix: When using the @TODAY or @NOW action tag for a field on a survey instrument, although the action tags will correctly insert the date/timestamp when the instrument is opened as a survey page, it would mistakenly not do this on the data entry form. Note: This only occurs on an instrument that has been enabled as a survey and is being opened as a data entry form when the field has no value. (Ticket #33609)

• Bug fix: The "simultaneous users" check that prevents two different users from viewing the same record/instrument/event in the same project would not successfully stop a user from viewing the data entry form if the user already on the form performs one of the following actions: 1) upload a file onto a File Upload field, 2) download a file, 3) delete a file, or enter a value into the Secondary Unique Field (if enabled).

• Bug fix: In certain rare cases, if a respondent clicks the download link for a File Upload field on a survey page, it might mistakenly display an error page rather than downloading the file.

• Bug fix: When deleting a message in REDCap Messenger, in which a non-English language is being used for the system, it mistakenly would tell the user to type the translated version of the word "delete" for the local language; however it was instead expecting the user to literally type the English word "delete", not the translation of the word. For technical reasons, the English word must be typed, so the instructions have been changed to clarify this. (Ticket #34174)

• Major bug fix: When downloading the CSV export of a survey's Participant List, a race condition might occur if multiple users are downloading the list (or if multiple requests are coming from the same user) near-simultaneously, in which it could possibly return a Participant List export file that contains Survey Access Codes that do not really exist and are therefore not valid access codes. (Ticket #34862)

• Bug fix: The setting for "External Modules: Alternate module directories" on the Modules/Services Configuration page in the Control Center did not have clear examples and had confusing instructions.

• Bug fix: The dashboard page in the Randomization module might mistakenly not get rendered correctly and thus may not be viewable if malformed HTML exists in the field label or choice label of the randomization field or a criteria field.

• Bug fix: The "Set up Survey Queue" popup in the Online Designer would mistakenly note that the first survey instrument is not displayed in the popup and therefore cannot be used in the Survey Queue. However, this is no longer true (but was true in earlier versions), so that incorrect text has now been removed.

• Bug fix: For a survey that does not have "Save and Return Later" enabled, if a respondent returns to an incomplete survey response using a unique survey link, it would mistakenly display the "Start Over" button to allow them to erase their answers even if the response had been locked by a user on the data entry form. Respondents should not be able to modify data or erase data if the form has been locked. This has been changed so that if the response is locked, it will not display the "Start Over" button and will inform the respondent that they cannot do anything until a survey administrator has unlocked their response. (Ticket #34676)

• Bug fix: Fields having any of the "Number (comma as decimal)" validations would mistakenly not have their scatter chart or descriptive stats displayed on the "Stats & Charts" page for a report.

• Bug fix: When copying an instrument via the "Copy" action in the Online Designer, if the instrument contains a "calc" field in which its equation has been left blank, it would display an error stating that the instrument could not be copied.
• Minor security fix: Due to security vulnerabilities found in the Bootstrap 3.3.7 library, Bootstrap has been upgraded to 3.4.0dev, which is the only 3.X version with the fixes.
• Major bug fix: When using the "Save & Return Later" survey feature, and a participant has partially or fully completed a survey, in certain cases if they use the return code and enter it while using the public survey link (as opposed to a private/unique survey link), it might mistakenly create a new record instead of modifying the existing record.
• Bug fix: When viewing the Participant List of a survey that is a repeating instrument or is on a repeating event, REDCap would mistakenly add extra placeholder rows in the Participant List if the instrument is utilized on multiple events. These extra ghost/placeholder rows would point to non-existing instances of an instrument. Note: If these placeholder rows have already been created in the Participant List, then unfortunately they will not be able to be removed. (Ticket #34741)
• Bug fix: When a non-CSV file is being uploaded into a place where only CSV files are permitted (e.g. Data Import Tool, Data Dictionary), it would mistakenly provide a link to a Microsoft webpage that no longer exists. The link URL has now been replaced with a working link.
• Bug fix: When performing a data import in a project with repeating instruments or repeating events, in which the redcap_repeat_instance field is included in the import file but is mistakenly given a non-numerical value, then the data values on that row might mistakenly be saved in the database incorrectly. (Ticket #35143)
• Bug fix: In the Scheduling module when using a Start Date with the year 2038 or higher, it would mistakenly return dates in the year 1969 for the projected schedule that is generated. (Ticket #35178)
• Bug fix: Fixed compatibility issues when using REDCap with PHP 7.2. This includes a fatal PHP error on the REDCap install page, and a fatal PHP error when downloading a PDF of an instrument. (Ticket #35240)
• Bug fix: On the Data Dictionary upload page, it might mistakenly display some uninterpreted HTML tags and some misformatted text for warnings and errors on the page after uploading a Data Dictionary. (Ticket #35499)
• Bug fix: If running PHP 5.3 on the REDCap server, in certain situations the Configuration Check page might mistakenly fail to mention that PHP 5.4 or higher is required in order to use External Modules.
• Bug fix: When using the "Save & Return Later" survey feature with the option enabled to "Allow respondents to return and modify completed responses", if a respondent begins a public survey and clicks "Save & Return Later", and then returns to the partially completed survey using a private survey link (not using the public survey link as before) and completes the survey, and then returns to the completed survey again using the public survey link (not the private survey link), using the return code they obtained the first time they visited the survey (not the return code they obtained later that is tied to the private link), and then they click "Save & Return Later", it will mistakenly set the survey status back to incomplete even though the survey has been completed. (Ticket #35210)
• Bug fix: When downloading a PDF of an instrument while on a data entry form, in which data has been modified on the form, after clicking a "download PDF" option it would mistakenly display a confirmation prompt letting the user know that they will be abandoning the page, which is not true. So the prompt is unnecessary and confusing.
• Bug fix: When downloading a file attachment for a Descriptive field on a survey, in which data has been modified on the survey page, it would mistakenly display a confirmation prompt letting the participant know that they will be abandoning the page, which is not true. So the prompt is unnecessary and confusing. (Ticket #35436)
• Bug fix: If a report is being sorted by the record ID field in descending order or the record ID field is sorted as asc/desc with one or two other sort fields, and the project has record auto-numbering enabled but the record ID field does not have integer/number validation, then the report would fail to order the results correctly.
• Bug fix: When viewing the "Stats & Charts" page for a report, slider fields and calc fields would mistakenly not have a scatter plot displayed for them.
• Bug fix: The field label of the Secondary Unique Field would mistakenly get displayed even if the field has no value. It should not display the label unless there is a value. (Ticket #35637)
• Bug fix: When importing data into a project in XML format via the API or via the plugin method REDCap::saveData(), in certain cases it would not gracefully handle an error in the XML but would instead mistakenly cause a PHP fatal error. (Ticket #35368)
• Bug fix: If a survey is using "Save & Return Later" with the option "Allow respondents to return without needing a return code" enabled, then if a participant clicks the "Save & Return Later" button at the bottom of the survey, in the email that REDCap sends to the participant with the survey link needed to continue the survey, the email text would mistakenly mention that a return code would be needed, which is not correct. (Ticket #33365)

• Major bug fix: If a longitudinal project has more than one arm and also has the Secondary Unique Field enabled, if a record exists in multiple arms, then whenever a user saves a value on a form or survey for the Secondary Unique Field, it would mistakenly set that value for all events in all arms for that record when instead it should only set that value for all events in the current arm.

• Minor security fix: Some Cross-Site Scripting (XSS) vulnerabilities were found on various pages in which a malicious user could potentially exploit them by manipulating the HTTP Referrer header of an HTTP request.

• Bug fix: When viewing a record on a data entry form that exists on a repeating event and then clicking a PDF download option to download that instrument with saved data, the resulting PDF would mistakenly contain all the repeated instances of the instrument for that record instead of just the current instance being viewed. This issue does not occur for repeating instruments but only for instruments on a repeating event.

• Bug fix: For a matrix of fields displayed in the Online Designer, the matrix headers were not aligning correctly with the radio button/checkbox for the fields. This only occurred when viewing a matrix in the Online Designer.

• Bug fix: When using the date-picker or datetime-picker widget to select a date/time on a form, survey, or other page in REDCap, the field validation alert might get called prematurely, which can cause it to be displayed to the user unnecessarily or may even cause the user to get stuck (because the widget keeps displaying whenever it is closed) and have to reload the whole page. (Ticket #35735)

• Various fixes and updates for External Modules framework

• Bug fix: When uploading a file using Send-It, if the recipients text box is left blank when the submit button is clicked, it would forever say "Working...", in which the user would have to manually reload the page in order to start over. (Ticket #35986)

• Bug fix: When using the Record Status Dashboard in a project with Data Access Groups, if the paging drop-down has a specific page selected and then the user selects a Data Access Group from the DAG drop-down, it could mistakenly try to display a "page" of records that does not exist for the new resulting data set and thus would display "no records", which could be confusing. In this case, it will now revert back to page 1 if the selected page no longer exists for the new DAG selection. (Ticket #36053)

• Bug fix: When using the Randomization module in a project and attempting to randomize a record on a data entry form in which the @NOW or @TODAY action tag is used *and* piping is also being performed on the same form, then the "Randomize" button would fail to appear if the user was specifically using iOS (Mobile Safari web browser). (Ticket #35998)

• Bug fix: On the Field Comment Log page in a project, if a user is using the Internet Explorer web browser, clicking the "Apply filters" button would mistakenly cause it mistakenly to search for the keywords "Keyword" and "search" even when the "Keyword search" text box has been left blank. This would often cause it to return no results, which is confusing. (Ticket #36266)

• Bug fix: Projects that use repeating events or repeating instruments will now *always* output the "redcap_repeat_instrument" and "redcap_repeat_instance" fields in a report or data export, as well as the output of REDCap::getData, regardless of whether the report/export contains any repeating data or not. In previous versions, it would mistakenly only output those fields if any data in the report/export was repeating. This means that the number of columns would vary unpredictably based on the filters applied to the report/export (or based on the parameters passed to REDCap::getData), which is confusing and inconsistent with how reports/exports typically behave. (Ticket #36263)

• Bug fix: When a record is deleted in a project (either via the user interface or via API), the logging page would mistakenly display the event name for the logged event, which is confusing because the record as a whole was deleted, not just for a specific event. It now no longer displays the event name for the logged event, and if the project contains multiple arms, it will instead display the number and name of the arm from which the record was deleted. (Ticket #36358)

• Bug fix: When viewing the data entry form of a repeating instrument, in which the "Current instance" drop-down list is displayed at the top of the page, if a user clicks the "+" button inside the drop-down rather than clicking the "Add new" text, it would mistakenly take the user to an incorrect page.

• Bug fix: When viewing/exporting a report or using the REDCap::getData() method in a longitudinal project with multiple arms, in which the user is exporting data from an arm that currently has no records in it (i.e., the data set being returned should be empty because there is no data from that arm to return), then it would mistakenly output a list of all records from other arms but with blank/default values. (Ticket #36470)

• Bug fix: In a longitudinal project with multiple arms, in which a record exists on more than one arm, if a user clicks the "Lock all instruments across all events" on the Record Home page on a certain arm, it would mistakenly lock all the instruments/events on other arms in addition to the current arm. It should only lock the instruments on the current arm. Note: The unlocking process does not appear to be affected by this issue.

• Bug fix: When using DDP Custom or DDP on FHIR and adjudicating temporal data for several different events, if a field value is adjudicated in one event, it might mistakenly get marked as adjudicated for that same field in other events. This causes the field to be hidden in the DDP adjudication popup when viewing the other events, so it makes it appear as if it has already been adjudicated when it has not.

• Bug fix: On certain occasions, the Scheduling module might mistakenly crash due to a fatal PHP error when attempting to generate a schedule for a record. This appears to only occur for PHP 5.3. (Ticket #36592)

• Various fixes and updates for External Modules framework

• Bug fix: On the Project Templates page in the Control Center, it would mistakenly display deleted projects in the project drop-down list when choosing a project to enable as a project template. (Ticket #36672)

• Bug fix: When the "Save & Return Later" setting is enabled on a survey and the "Allow respondents to return without needing a return code" option is checked, if a participant's email address is known when they click the "Save & Return Later" button on the survey page, it would mistakenly display some text on the page that implied that they would need a Return Code to return to the survey, which is incorrect. (Ticket #36729)

• Bug fix: In a longitudinal project, when a user clicks the "Delete data for THIS FORM only" button on a data entry form, if data exists on other events for the current record AND the form being deleted is the only form containing data on the current event, then that event would mistakenly still show up in reports and data exports even though it no longer contains any data and shows gray status icons for all the instruments in the event. (Ticket #35814)

• Bug fix: In a longitudinal project, the Scheduling module might mistakenly crash due to a fatal PHP error when attempting to generate a schedule for a record. This was often due to using either a negative Day Offset value or negative Offset Range value for certain Start Date values. Bug emerged in REDCap 8.1.5. (Ticket #36592)

• Bug fix: REDCap Messenger might throw a JavaScript error after being opened because certain web browsers are beginning to deprecate synchronous AJAX requests in JavaScript. (Ticket #36970)

• Bug fix: When using the @NOW action tag for a date field (rather than a datetime field), it mistakenly inserts the full timestamp into the date field, which results in a field validation error. It now instead inserts only today's date as a value into the field, as if @TODAY were used. (Ticket #36969)

• Bug fix: If a slider field on a survey or data entry form is set to display its numerical value, if "100" is selected for the slider, the text field would partially cut off the value being displayed. (Ticket #37048)

• Bug fix: When using "<>", "<", or "<=" in the choice labels for drop-down, radio, or checkbox fields on an instrument, they would not display correctly on the page but instead might omit those operators or instead display nothing as the choice label. (Ticket #37007)

• Various fixes and updates for External Modules framework

• Bug fix: When using the Data Search feature on the "Add/Edit Records" page, clicking the keyboard's down arrow button mistakenly no longer selects an option returned from the search. (Ticket #37144)

• Bug fix: In a longitudinal project, when a user clicks the "Delete data for THIS FORM only" button on a data entry form, if data exists on other events for the current record AND the form being deleted is the only form containing data on the current event, then that event would mistakenly still show up in reports and data exports even though it no longer contains any data and shows gray status icons for all the instruments in the event. In the previous version, this bug was fixed for most scenarios (traditional longitudinal and repeating instruments) except not for repeating events. This now fixes the issue for repeating events. (Ticket #35814, #37290)

• Bug fix: If a user requests that their project be moved to production by an administrator, in which the administrator does not use the To-Do List nor the link in the request email but instead just goes to the project directly to move it to production, then the original request would mistakenly not get removed from the To-Do List. (Ticket #37159)

• Bug fix: On very rare occasions, creating a new user role in a project might mistakenly result in displaying an error to the user that states that an email could not be sent to the user, which does not make sense because there is no user in this context. (Ticket #37465)

• Minor security fixes: Some Cross-Site Scripting (XSS) vulnerabilities were found on various pages in which a malicious user could potentially exploit them by manipulating the query string or POST parameters of particular HTTP requests. Part of this batch of fixes includes a change in the REDCap API's "content-type" HTTP header for CSV exports from "text/html" to "text/csv" as an extra preventative measure to protect against XSS.

• Major bug fix: On some extremely rare occasions when loading a public survey, it might mistakenly display the data from a previous response rather than displaying the page with all fields blank.

• Bug fix: The "expand" link would mistakenly not work for the "Custom text to display at the top of the Help & FAQ page" textbox field on the General Configuration page in the Control Center.

• Bug fix: When deleting a repeating event instance on the Record Home page, it might mistakenly delete all files uploaded to any File Upload fields on other repeating instances of that event. (Ticket #37988)

• Various fixes and updates for External Modules framework

• Bug fix: When using the REDCap Mobile App for a project that contains Descriptive fields that have inline images, if the file storage setting has been set to "WebDAV" on the File Upload Settings page in the Control Center, the images would mistakenly not get synced to the mobile app correctly.

• Bug fix: The action tags @NONEOFTHEABOVE and @MAXCHECKED would not work well together and would cause @NONEOFTHEABOVE to malfunction when using both tags on a single checkbox field. (Ticket #38119)

• Bug fix: When using a custom Data Quality rule to find a field with a blank value, in which the field exists on a repeating instrument, it would not always return the correct results. (Ticket #37067)

• Various fixes and updates for External Modules framework

• Bug fix: The documentation for action tags @TODAY and @NOW mistakenly state that a field using either action tag would be disabled and not edidtable, which is no longer true but used to be true in older versions. (Ticket #32537)

• Bug fix: When uploading an instrument zip file in the Online Designer, it would mistakenly truncate the form name to 50 characters in length when instead it should be truncating it to 64 characters if the form name was longer than that.

• Bug fix: When clicking the "exclude" or "remove exclusion" link in the discrepancy results in the Data Quality module when using a non-English language for the text of that project, it would mistakenly only show the text in English right after clicking those links. It should instead display them in the project language. (Ticket #38408)

• Bug fix: If using an SSL database connection for MySQL, plugins and some external modules pages would mistakenly return an error and not load. After upgrading to this version, an administrator will need to download the zip file containing outdated non-versioned files on the Configuration Check page, and then follow the instructions there. (Ticket #37763)

• Bug fix: On very rare occasions, creating a new user role in a project might mistakenly result in displaying an error to the user that states that an email could not be sent to the user, which does not make sense because there is no user in this context. This was supposedly fixed in the previous version but was not. (Ticket #37465)

• Bug fix: When deleting a form's data using the "Delete data for THIS FORM only" button at the bottom of a data entry page, if it is a repeating instrument, it would mistakenly fail to mention that this action would only delete the current repeating instance of the form, not all repeating instances of that form.

• Bug fix: The SQL mapping file for installing the DDP Custom demo web service might cause an SQL error and not execute successfully if DDP mapping has already been performed for any DDP Custom project in the system.

• Bug fix: The Dynamic Data Pull (DDP Custom) module was mistakenly unable to utilize repeating instruments or repeating events for capturing temporal data.

• Bug fix: When using AAF authentication, the cross-site request forgery (CSRF) protection would not work properly.

• Bug fix: When an unsuccessful login attempt occurs in REDCap, it now only logs the username value entered if the value is a valid REDCap user's username. If not, it instead logs it as "[not_valid_username]" in the redcap_log_view database table. This fixes a potential security hole in which some users might mistakenly enter their password in the username login field, in which it would log their password in plain text in the redcap_log_view database table and thus could be viewable to anyone with direct access to the backend database.

• Bug fix: When adding a new user in REDCap (in several places throughout the application), if user attempts to create a username containing an ampersand, it would not allow it even though the error message says that ampersands are allowed. This error message text is incorrect because ampersands are not allowed in REDCap usernames. (Ticket #39267)

• Bug fix: When running Data Quality rule H, it might mistakenly not return some discrepancies in very specific cases. This would most often occur when the calculated value has a decimal while the saved value does not contain a decimal (and vice versa). (Ticket #38488)

• Bug fix: When using a Live Filter on the "Stats & Charts" page of a report, in which no results should be displayed for the selected Live Filter, it would mistakenly display all records in the charts and stats tables on the page. (Ticket #39349)

• Bug fix: When using conditional logic, report filters, etc., in which certain text is used inside double quotes or single quotes (i.e., text that is used internally by REDCap as special processing tokens), it would sometimes mistakenly return no results instead of the desired results. (Ticket #32295, #39418)

• Bug fix: Inside the red box that appears at the top of the data entry form when viewing a survey response, it would mistakenly report that other users contributed to the survey response, even though those users may have entered data on another instrument for that record. This issue cannot be fixed for existing responses, but the issue will no longer occur for any new responses created. Additionally, the text that denotes the users that have contributed after the survey was completed would be incorrect if users may have entered data on another instrument for that record, but this issue (unlike the other one described above) will be fixed retroactively for existing responses and for new responses. Also, both of these issues would mistakenly include calc fields when determining contributors; however, calc fields will no longer be considered because they can be triggered from data being entered elsewhere for a record. (Ticket #38545)

• Bug fix: When exporting data to a stats package for a project that contains repeating instruments, the choices listed for the field "redcap_repeat_instrument" in the stats package's syntax file would mistakenly have the instrument label repeated multiple times for that field if that instrument were set to be repeating on multiple events in the project. (Ticket #38529)

• Bug fix: When viewing the Public Survey Link page of a project containing multiple arms, if the first data collection instrument is not designated for the first event of the current arm, it would mistakenly display the public survey link of another arm (typically the first arm). It now displays a warning on the page to inform the user to fix this issue by designating the first instrument for the first event of that arm. (Ticket #39647)

• Bug fix: On some specific server configurations, the REDCap Upgrade module would not set certain server path constants correctly. (Ticket #40203)

• Bug fix: For longitudinal projects using a public survey on multiple arms, regarding all arms except the first arm, the public survey link would mistakenly be blank on the Public Survey Link page. (Ticket #40311)

• Bug fix: When using the Twilio telophony module for sending survey invitations while also using Automated Survey Invitations that contain conditional logic containing datediff+today or datediff+now, if the ASI has "Participant Preference" as the invitation type, then in certain cases (but not all the time) it would mistakenly send the invitation via email rather than via the participant's preferred delivery method. And if those participants do not have an associated email address, then the invitation would simply fail to send, as noted in the Survey Invitation Log. (Ticket #29316)

• Bug fix: When calling the API method "Export Project XML" and setting the parameter "returnMetadataOnly" as FALSE, it would mistakenly not return data but would only ever return just the metadata.

• Bug fix: The Smart Variables [survey-queue-link] and [survey-queue-url] were mistakenly not working when used inside the email subject or email message for an Automated Survey Invitation.

• Bug fix: When downloading a PDF of an instrument that contains a matrix of fields, the matrix headers might mistakenly overlap the radio buttons or checkboxes of the first field in the matrix under specific circumstances. (Ticket #40969)

• Bug fix: When using record auto-numbering for a data import (via Data Import Tool, API, or Mobile App) that contains data for a repeating instrument or repeating event, then all the data for a given record in the import might be reduced from multiple instances/events of data to a single event/instance of data, thus causing much of the data to mistakenly not get imported. (Ticket #41283)

• Bug fix: When viewing the "Stats & Charts" page, if a field has some missing values, and the user clicks the link to view the record names that have missing values, it might mistakenly return incorrect records-instances. This only occurs in projects having repeating instruments or repeating events. (Ticket #37674)

• Bug fix: When importing data (via Data Import Tool or API) into a longitudinal project and setting true/"yes" for the import option "Allow blank values to overwrite existing saved values?" when importing blank values for checkbox fields into a longitudinal event for which the checkbox's instrument is not designated, it would display the erroneous error that the checkbox field "exists on an instrument that is not designated for the event". (Ticket #37627)

• Bug fix: When adding a new field to an instrument on the Online Designer while in Draft Mode, if the field is being added between a section header and another field, in which the instrument begins with that section header, then the new field would get successfully created but would mistakenly not be visible in the Online Designer on that instrument, thus leaving it in a quasi-orphaned state. (Ticket #41359)

...