Upgrade 12.0.33 LTS Detailed Features Changes List
Version 10.7.0 (released on 2021-01-14)
CHANGES IN THIS VERSION:
New feature: @INLINE action tag- Allows a PDF file or image file (JPG, JPEG, GIF, PNG, TIF, BMP) that is uploaded to a File Upload field to be displayed in an inline manner on the survey page or data entry form so that the PDF/image can be viewed by the user or survey participant without having to download it.
The PDF/image will be displayed inline on the page immediately above the download link for the field and will be displayed with 100% width by default (i.e., 100% width of the area in which it is contained).
Images will be displayed with their native width:height ratio, although PDFs will be displayed with a 300 pixel height by default. If you wish to manually set the width and/or height of the image/PDF, you may put the width/height values inside parentheses after the action tag in the following manner: @INLINE(width) or @INLINE(width,height). The width/height can be a percentage value (e.g., 50%) or a number representing size in pixels (e.g., 400). Thus @INLINE(50%) will display an image at 50% size for the area in which it is contained on the page, and @INLINE(400,100) would display the image always at 400px tall and 100px wide. To make an inline PDF appear taller on the page, you might use @INLINE(100%,600) since 300px is the default height for inline PDFs.
The @INLINE action tag also works if the File Upload field is embedded inside another field on the page.
Thanks to Andy Martin for his inspiration for this feature, in which it is based on his "Image Viewer" external module. NOTE: Upgrading to REDCap 10.7.0 will not automatically disable the "Image Viewer" module if it is installed and enabled on any projects, nor will it conflict with the "Image Viewer" external module.
New feature: New ":inline" piping option for File Upload fields
If piping using the ':inline' option for a File Upload field, such as [my_field:inline], in which the uploaded file is a PDF file or image file (JPG, JPEG, GIF, PNG, TIF, BMP), the file will be displayed in an inline manner so that it is viewable on the page.
The ':inline' option DOES work inside emails, so you can pipe a field with ':inline' inside the email body, thus allowing you to display inline images inside survey invitations or Alerts & Notifications.
The @INLINE action tag does not need to be used on a field in order to utilize the ":inline" piping option.
Note: Inline images are not able to be displayed inside a downloaded PDF of a survey/instrument that contains data.
Version 10.7.1 (released on 2021-01-22)
CHANGES IN THIS VERSION:
New feature: New ":link" piping option for File Upload fields - If piping using the ':link' option for a File Upload field, such as [my_field:link], the file's filename will be displayed as a clickable hyperlink for downloading the file, which works on webpages and also inside the body of email text (i.e., survey invitations or Alerts & Notifications).
Improvement/change: When using the ":inline" piping option for File Upload files inside an email body (e.g., survey invitations, alerts), if the uploaded file is not an image file, it will still attach the file to the email but will display the file's filename in the email text as an alternative to displaying it as an inline image.
Version 10.8.0 (released on 2021-01-29)
CHANGES IN THIS VERSION:
New feature: Instant Adjudication for Clinical Data Pull (CDP)with improved CDP Field Mapping page
Once enabled here for the whole system via the CDIS page, the Clinical Data Pull "Instant Adjudication" setting can be enabled on a CDP project's field mapping page, after which it will allow users to bypass the normal data adjudication process and will let them import and save all data into the project that has already been cached from the EHR system. This can save a great deal of time when importing lots of patient records. After Instant Adjudication is enabled in a CDP project, users with CDP-adjudication privileges will see the button to initiate this process on the Record Status Dashboard. After the button is clicked, it will begin adjudicating the EHR data for all records in real time, thus saving the data into records in the projects. On the CDIS page in the Control Center, administrators can enable or disable the Instant Adjudication feature for all CDP-enabled projects in the system. By default, the system-level Instant Adjudication option is enabled.
Also, the user interface for the CDP Field Mapping page in all CDP-enabled projects has been updated and improved to allow users to more quickly and easily map their REDCap fields to EHR fields for their CDP project.
Improvement: Custom ranges (min/max) for slider fields - Users may now set a custom minimum and/or custom maximum integer value for slider fields. The default min and max is still 0 and 100, respectively. If no value is entered for the min or max value, it will assume the default value. These can be set via the Edit Field popup in the Online Designer, and via the "Text Validation Min" and "Text Validation Max" columns in the Data Dictionary.
New feature: Ability to to import/export user rights via a CSV file on the User Rights page - Users can download a CSV file to view all the user privileges of the existing users in a project, including their instrument-level user rights. Users can upload a CSV file to grant new users access to the project and/or to modify the user privileges of existing users, including their instrument-level user rights.
Version 10.9.0 (released on 2021-03-26)
CHANGES IN THIS VERSION:
New feature: Field that maps to a participant's Twilio delivery preference - When using Twilio for surveys, users can control each participant's invitation preference automatically using a multiple choice field. If survey participants require using different methods (e.g., email, SMS w/ link, voice call survey) for receiving survey invitations and/or taking surveys, users can select a multiple choice field whose choices represent each survey invitation delivery method. After mapping the invitation preferences to a field, whenever the value of the field is added or modified, the participant's invitation preference will automatically be changed accordingly. IMPORTANT: The multiple choice codings for the selected field must be defined exactly as delineated below, although their corresponding choice labels can be modified to be whatever text the user desires. Also be aware that if the value of the field that is mapped is set to blank/null, then the invitation preference for the participant will revert to the project's default invitation preference (as defined in the Twilio configuration on Project Setup). Additionally, if a participant's invitation preference is modified via the Participant List, that change will also change the value of the mapping field selected above. Mapped field choice options:
EMAIL, Email invitation
SMS_INVITE_WEB, SMS invitation (contains survey link)
SMS_INITIATE, SMS invitation (take survey via SMS)
VOICE_INITIATE, Voice call (participant receives voice call)
SMS_INVITE_MAKE_CALL, SMS invitation (contains phone number to call)
SMS_INVITE_RECEIVE_CALL, SMS invitation (reply via SMS to receive voice call)
New feature: Custom offline message for surveys in offline status- Users can provide custom text that is displayed to participants only when the survey is offline. This custom text will be displayed in place of the default offline text on the survey while the survey is in offline mode. This text can be set at the top of the Survey Settings page.
New feature: Survey-level Stop Action controls(new section on Survey Settings page)
Alternative survey completion text - Users can optionally set alternative survey completion text that is displayed in place of their standard survey completion text whenever a survey is ended via a Stop Action on any field. This is useful when it doesn't make sense for non-eligible participants to see the same survey completion text as those who completed the survey fully.
Prevent survey responses from being saved if the survey ends via Stop Action- Users can optionally choose to prevent submitted responses from being saved as data in the project if the survey ends via Stop Action. This is useful if survey administrators do not wish to keep the data for ineligible participants, for example. This means that if a one-page public survey is started but ends via Stop Action, no data from that response will be saved into the project (i.e., no new record will be created), but it will log this event on the project Logging page (so that users are at least aware of this happening despite no data being saved).
NOTE: If any data has been saved on the survey instrument for a given record prior to the Stop Action being triggered, that data will be deleted from that instrument. For example, if the survey is a multi-page survey in which data has been entered on previous pages prior to triggering the Stop Action, all data collected thus far in that survey will be deleted as if the survey was never taken. Additionally, if the record does not contain data in any other instruments, the entire record itself will be deleted during this process. If data does exist in other instruments, the record will not be deleted.
PRIVACY NOTE: If the option for Data Privacy/GDPR has been enabled in the project, in which it removes the contents of the log for a record that is deleted from the project, then if an entire record is deleted via this particular survey setting via a Stop Action, then all logged data values for the record will be removed from the log as per this project's data privacy setting.
Improvement: New project-level option for importing email addresses for patients from an EHR via REDCap's Clinical Data Interoperability Services (CDIS) - When this option is enabled at the system level on the CDIS page in the Control Center, an administrator can then enable this option for any given project via the "Edit A Project's Settings" page. Once enabled for a project, users will then be able to map the "email address" field in either a Clinical Data Pull or Clinical Data Mart project, thus allowing them to import patient email addresses for the EHR. This option is disabled by default.
Version 11.0.0 (released on 2021-04-30)
CHANGES IN THIS VERSION:
New feature: Project Dashboards
INTRO: Project Dashboards are pages with dynamic content that can be added to a project. They can utilize special Smart Variables called Smart Functions, Smart Tables, and Smart Charts (described below) that can perform aggregate mathematical functions, display tables of descriptive statistics, and render various types of charts, respectively. User access privileges are customizable for each dashboard, and anyone with Project Design privileges can create and edit them. A Wizard is provided on the Project Dashboard creation page to help users easily construct the syntax for Smart Functions, Smart Tables, or Smart Charts, and a basic list of helpful examples is also included. Example dashboard: {+}https://redcap.link/dash1+
Setting project dashboards as "public"
If enabled at the system-level (described in detail below), any project dashboard can be enabled as "public", which means it can be accessed at a unique URL that does not require any authentication. Making a dashboard public is useful if you wish for people to view it without having to be REDCap users or log into REDCap. Public dashboards are simply standalone pages that can be viewed by anyone with a link to them.
Users can opt to create a custom/short url (via the {+}https://redcap.link+ service) for any project dashboard that is enabled as "public".
System-level setting to allow/disallow public dashboards (on the User Settings page in the Control Center) - By default, normal users will be able to set any project dashboard as public. If you do not want users to do this or even know about this feature, you can completely disable it on the User Settings page. Alternatively, it can be set to "Allow public dashboards with admin approval only". If set to allow public dashboards after approval by an admin, the admin will receive the request from the user via the To-Do List page (and via email, if the email notification setting is enabled on the To-Do List page), and after the admin approves the request, the user will receive an email regarding the response to their request.
Setting to control data privacy on public dashboards and other public pages
The User Settings page in the Control Center has a setting to define the "Minimum number of data points required to display data for any Smart Charts, Smart Tables, and Smart Functions on a public project dashboard, survey queue, or survey page". By default, it is set to a value of "11". While only aggregate data is displayed in Smart Charts, Smart Tables, and Smart Functions, if any of these utilize very few data values, it might pose a threat to an individual's data privacy if these are being displayed on public dashboards and other public pages (i.e., where authentication is not used).
If someone is viewing a public page that has Smart Charts, Smart Tables, and Smart Functions that utilize data that does not meet the minimum data point requirement, instead of displaying the chart/table/number on the page, it will instead display a notice saying "[INSUFFICIENT AMOUNT OF DATA FOR DISPLAY]" with a pop-up note with details about the minimum data requirements.
Project-level override: While this behavior is controlled by a system-level setting, the system-level setting can be modified by an administrator via a project-level override for any given project on the "Edit A Project's Settings" page.
Note: This setting does not get used when viewing project dashboards inside a project (i.e., at a non-public URL).
PDF export: Each project dashboard can be exported as a one-page PDF file.
Dashboard cache: To prevent server performance degradation, each project dashboard will have its content cached (stored temporarily) automatically for up to 10 minutes at a time rather than generating its content in real time every time the dashboard is loaded. It will note at the top right corner of the dashboard page when the dashboard content was last cached. If a user is viewing the dashboard inside a project (i.e., not via a public dashboard link), they have the option at the top right to "Refresh" the dashboard at will, which will refresh/generate its content in real time. Note: The refresh option will only be displayed on the page when the dashboard content is at least 30-seconds old.
New feature: Smart Functions
Smart Functions are aggregate mathematical functions that are utilized as Smart Variables. The following Smart Functions exist: [aggregate-min], [aggregate-max], [aggregate-mean], [aggregate-median], [aggregate-sum], [aggregate-count], [aggregate-stdev], and [aggregate-unique]. Each represents the mathematical functions minimum, maximum, mean/average, media, sum, count, standard deviation, and unique count, respectively. Each must have at least one field attached to it that follows a colon - e.g., [aggregate-mean:age]. Multiple fields may be used in each one, which will perform the function over all the data values of all the fields. By default, the functions will utilize all data values for all records in the project. To limit the data values being utilized to a subset of the total project data, see the Smart Variable documentation on how to apply filters, such as attached unique report names, DAGs, and other parameters
Note: When using [aggregate-count:record_id], in which "record_id" in this example represents whatever the variable of the Record ID field is, it performs a special count that does not literally count the number of data values but instead returns a count of the total number of records in the project. This is a quick way to display the total record count of the project.
Smart Functions can be used anywhere in a project where piping is allowed, and can even be used inside calculations, branching logic, and other conditional logic (report filters, alert conditions, etc.).
New feature: Smart Tables
Smart Tables are tables displaying aggregate descriptive statistics in which the results of any or all of the following stats functions can be displayed for one or more fields: minimum, maximum, mean/average, media, sum, count, standard deviation, count of missing values, and count of unique values.
Smart Tables are represented with the Smart Variable [stats-table], which accepts as a parameter the variable names (comma delimited) of all the fields to be displayed as separate rows in the table. There is no limit to the number of fields that can be used. For example, [stats-table:field1,field2,field3].
By default, all available columns will be displayed in the table and are as follows: Count, Missing, Unique, Min, Max, Mean, Median, StDev, Sum. To display only a subset of the columns, you may provide any of the following designations (comma-separated) that represent a specific column in the table: count, missing, unique, min, max, mean, median, stdev, sum. For example, [stats-table:field1,field2,field3:mean,max].
By default, each stats table will have an "Export table (CSV)" link displayed immediately below it to allow users to download the table as a CSV file. But if users wish to hide the export link, they can simply attach ":no-export-link" to the Smart Variable, which will cause the link not to be displayed. For example, [stats-table:field1,field2,field3:no-export-link].
Smart Tables can be used anywhere in a project where piping is allowed.
New feature: Smart Charts
Smart Charts are various aggregate plots and charts utilized as different Smart Variables. The following plots are available for use: bar charts, pie charts, donut charts, scatter plots, and line charts. These are all represented by the following Smart Variables, respectively: [bar-chart], [pie-chart], [donut-chart], [scatter-plot], and [line-chart]. These Smart Variables accept one or more field names and also other optional parameters, as described below for each.
Bar charts - Displays a bar chart for a single multiple choice field. It can optionally perform color grouping if a second field (multiple choice only) is provided. The fields must be comma-separated. For example, [bar-chart:field,grouping-field:parameters]. Bar charts have optional parameters that can be applied to alter their appearance. By appending the parameter ":bar-stacked" when two fields are used, the bars in the chart will appear stacked on top of each other rather than side by side. By default, bar charts are displayed with their bars going horizontally, but by appending the parameter ":bar-vertical", the orientation will be changed to display vertically instead.
Pie charts - Displays a pie chart for a single multiple choice field. For example, [pie-chart:field:parameters].
Donut charts - Displays a donut chart for a single multiple choice field.Note: A donut chart is essentially the same as a pie chart but with the center removed. For example, [donut-chart:field:parameters].
Scatter plots - Displays a scatter plot of one number/date/datetime field for the x-axis and a second field (number field only) for the y-axis. (If a second field is not provided, a random value will be assigned for the y-axis.) It can optionally perform color grouping if a third field (multiple choice only) is provided. All fields must be comma-separated. For example, [scatter-plot:x-axis-field,y-axis-field,grouping-field:parameters].
Line charts - Displays a line chart of one number/date/datetime field for the x-axis and a second field (number field only) for the y-axis. It can optionally perform color grouping if a third field (multiple choice only) is provided. All fields must be comma-separated. Note: A line chart is essentially the same as a scatter plot except with dots connected with a line. For example, [line-chart:x-axis-field,y-axis-field,grouping-field:parameters].
Color blindness accessibility: Pie charts and donut charts have the ability for the user to enable color blindness accessibility, via a gray link displayed immediately below each chart, in which it overlays different patterns onto the colored pieces of the chart to make each color more distinct for many types of color blindness. This option to enable color blindness accessibility is stored in a secure cookie on the user's device and will be used to remember this choice anytime a pie/donut chart is displayed on any page for any REDCap project for that REDCap server.
The colors displayed in each chart/plot are preset and are not modifiable.
Smart Charts can be used anywhere in a project where piping is allowed except for inside the body of outgoing emails.
Optional parameters for Smart Functions, Smart Tables, and Smart Charts
There exist various optional parameters that can be used with Smart Functions, Smart Tables, and Smart Charts to either filter the data used in them (e.g., via a unique report name) or to change their appearance (e.g., bar-vertical). See the descriptions for each below, which are all documented in the Smart Variables documentation.
:R-XXXXXXXXXX Unique Report Name - For Aggregate Functions, Charts, and Tables, filter the data being used by appending a Unique Report Name. Next to each report on the 'My Reports & Exports' page is its unique report name, which has 'R-' following by alphanumeric characters. By default, all Aggregate Functions, Charts, and Tables will use the values of all records in the project, but if a unique report name is appended to any of them, only data from that specific report will be used. Using a report as a surrogate to filter data is a very useful technique of performing complex filtering logic for Aggregate Functions, Charts, and Tables.
:record-name "record-name" - For Aggregate Functions, Charts, and Tables, filter the data being used to the current record by using the literal value 'record-name'. Note: This parameter will only work in a context where a single record is being viewed/accessed, such as on a survey page, data entry form, etc. This parameter can be used with any of the other parameters except unique report names.
:event-name "event-name" - For Aggregate Functions, Charts, and Tables, filter the data being used to the current event (longitudinal projects only) by using the literal value 'event-name'. Note: This parameter will only work in a context where a single record/event is being viewed/accessed, such as on a survey page, data entry form, etc. This parameter can be used with any of the other parameters except unique report names.
:unique-event-names Unique Event Names - For Aggregate Functions, Charts, and Tables, filter the data being used to specific events (longitudinal projects only) by providing an event's unique event name (found on the Define My Events page). You may use one or more unique event names (comma-separated). Note: This parameter can be used with any of the other parameters except unique report names.
:user-dag-name "user-dag-name" - For Aggregate Functions, Charts, and Tables, filter the data being used to the records assigned to the current user's Data Access Group by using the literal value 'user-dag-name'. Note: This parameter will only work in a context where an authenticated user belongs to a project and has been assigned to a DAG in the project (this excludes survey pages and public project dashboards). This parameter can be used with any of the other parameters except unique report names.
:unique-dag-names Unique DAG Names - For Aggregate Functions, Charts, and Tables, filter the data being used to the records assigned to specific Data Access Groups by providing a DAG's unique group name (found on the Data Access Groups page). You may use one or more unique DAG names (comma-separated). Note: This parameter can be used with any of the other parameters except unique report names.
:bar-vertical "bar-vertical" - Display a bar chart with the bars going vertically instead of horizontally (the default) by using the literal value 'bar-vertical'. Note: This parameter can be used with any of the other parameters.
:bar-stacked "bar-stacked" - Only for bar charts using two fields, display the bar chart with the bars stacked on top of one another for each choice. Whereas the default view is that the bars of each field are displayed side by side to show the color grouping. To enable this, use the literal value 'bar-stacked'. Note: This parameter can be used with any of the other parameters.
:no-export-link "bar-stacked" - Only for bar charts using two fields, display the bar chart with the bars stacked on top of one another for each choice. Whereas the default view is that the bars of each field are displayed side by side to show the color grouping. To enable this, use the literal value 'bar-stacked'. Note: This parameter can be used with any of the other parameters.
NOTE: Using Smart Functions/Tables/Charts elsewhere in a project - While project dashboards are an excellent place to use Smart Functions, Smart Tables, and Smart Charts, it is important to know that Smart Functions/Tables/Charts can actually be used almost anywhere in a project, such as on data entry forms, on survey pages, and in report instructions (to name a few). You can use Smart Functions/Tables/Charts anywhere that piping can be used. Click the green "Smart Variables" button on the Project Setup page to learn more about them. Note: The only place that Smart Charts cannot be used is inside the body of outgoing emails.
NOTE: Smart Functions/Tables/Charts do not yet work in the REDCap Mobile App; however, it is planned that they eventually will (to a certain degree).
NOTE regarding permissions for Smart Functions/Tables/Charts:
DAG permissions (i.e., filtering out records not assigned to the current user's DAG) are NOT applied by default to Smart Charts/Tables/Functions but are only applied when the Smart Chart/Table/Function utilizes a unique report name as a parameter (thus mimicking the natural DAG-filtering behavior of reports themselves) OR when the Smart Chart/Table/Function utilizes the "user-dag-name" parameter. This means that if a user is assigned to a DAG and views a project dashboard with the Smart Chart [scatter-plot:weight], for example, the plot will display data for ALL records in the project and not just the user's DAG. To limit the plot to just data in the user's DAG, it could be changed to [scatter-plot:weight:user-dag-name] in this case.
Smart Charts/Tables/Functions that utilize a unique report name as a parameter for data filtering purposes will still function and display normally even if the user does not have explicit access to view that specific report referenced as a parameter.
New feature: CSV Delimiter as a user-level preference - The My Profile page now has a new user preference to allow a user to set their own preferred CSV delimiter (e.g., comma, semi-colon) that will be used as the delimiter character in all CSV file downloads throughout REDCap, such as data dictionary import/export, event import/export, user rights import/export, etc. This setting is not used by data imports and exports because those already have a way to specify the CSV delimiter manually. The system-level default value for this user preference can be set on the User Settings page in the Control Center, in which all new users created afterward will have their user-level preference set with this system-level default value. To modify all existing users' preference after upgrading (if your users would not want a comma delimiter), it will require running an "update" query in the database, such as this: UPDATE redcap_user_information SET `csv_delimiter` = ';' ;
Improvement: Report "description" text now utilizes the rich text editor. Additionally, users may perform piping into a report's description, such as project-level Smart Variables, including Smart Charts, Smart Functions, and Smart Tables.
Improvement: New option for Project Templates called "copy records", which will copy any existing records in the template to the new project created from the template. This option can be enabled for any new or existing Project Templates.
Improvement: A new Project Template was added to illustrate new features in 11.0+. The new template is named "Project Dashboards, Smart Functions, Smart Tables, & Smart Charts".
Change/improvement: The Logic Editor popup is now utilized when editing the "Action Tags/Field Annotation" text box in the Online Designer. (Ticket #103007)
Version 11.1.0 (released on 2021-05-28)
CHANGES IN THIS VERSION:
New feature: More clinical data available via FHIR R4 endpoints for CDIS - The CDIS services Clinical Data Pull and Clinical Data Mart can now utilize version 4 (called "R4") of the FHIR web services from their local EHR system. The new R4 endpoints include the existing data that could be pulled in earlier versions as well as the following: Adverse Events, Core Characteristics (Observation), Encounters, and Immunizations. Note that "Adverse events" are only available for "research" projects where an IRB number is specified, in which the project's IRB number corresponds to the "Study ID" value from the EHR interface for a particular study (which is often the same as the study's IRB number).
Improvements: Other FHIR/CDIS additions
Clinical Data Mart
A new template is used for new DataMart projects when REDCap is set to use R4, including new forms for Encounters, Immunizations, Core Characteristics, Adverse Events.
New option to fetch data in a background process and receive an email when completed.
MRNs can be searched and fetched individually on the Clinical Data Mart page.
Epic institutions using the "legacy" app on the Epic App Orchard will be notified on the CDIS Control Center page with info about how to upgrade to the new R4 enabled version.
While on the CDIS Control Center page, changing the FHIR client ID will now automatically remove all existing FHIR access tokens stored in the backend. Note: This will not impact any data but will require each CDIS user to perform a standalone launch again or else launch REDCap via the CDP embedded window in the EHR interface before they can begin to pull data again from the EHR.
The FHIR statistics in the Control Center now displays CDP instant adjudication.
Version 11.2.0 (released on 2021-07-09)
CHANGES IN THIS VERSION:
New feature: Ability to make reports accessible at a public link
Summary: When editing a report, users can now set a report as "public" and can obtain a public link to the report if they have User Rights privileges in the project. When a report is public, this means that all data in the report will be fully accessible (with no authentication required) to anyone with the public link to the report.
In order to make a report public, all the following must be true:
The user must have User Rights privileges in the project or be a REDCap administrator.
The report cannot have any Identifier fields in it.
The user is required to view the report during their current REDCap session.
The user must agree to and check off the following statements: 1) I understand that making this report "public" means that all data in the report will be fully accessible to anyone with the public link to the report, and 2) I understand that I am responsible if any private, sensitive, or identifying data in the report is exposed to persons who should not have access to such data.
The behavior of how reports are made public can be controlled at the system level near the bottom of the User Settings page in the Control Center using the setting "Allow reports to be made 'public'?". Admins may completely disallow reports to be made public (although admins will still have this ability to do so). But if enabled, they may choose to allow users to make reports public on their own or enable the To-Do List approval process by which an admin will need to approve their request to make a given report public (similar to the same system level approval process for Project Dashboards being made public).
Once a report has been made public, its configuration cannot be modified while it is public (users cannot add new fields, modify filter logic, etc.). In order to modify a public report, the user will need to make it no longer public, then make their changes, and then make it public again.
New Smart Variables
[event-id] - (longitudinal only) The event id number of the current event.
[survey-access-code:instrument] - The Survey Access Code of the specified survey for a given record/event/instance. The format must be [survey-access-code] or [survey-access-code:instrument], in which 'instrument' is the unique form name of the desired instrument. This can be used simply as [survey-access-code] inside the content of a survey invitation, in which 'instrument' is assumed to be the current survey instrument.
[survey-return-code:instrument] - The Survey Return Code of the specified survey for a given record/event/instance in order to allow a participant to return to a completed or partially completed survey response when using the 'Save & Return Later' survey feature. The format must be [survey-return-code] or [survey-return-code:instrument], in which 'instrument' is the unique form name of the desired instrument. This can be used simply as [survey-return-code] inside the content of a survey invitation, in which 'instrument' is assumed to be the current survey instrument.
[user-role-id] - The Role ID of the user role to which the current user is assigned (blank if not assigned to any user role). This value is auto-generated for each user role. NOTE: This value is not just unique for all roles within the project but is also unique across all REDCap projects. Thus, if the project and its user roles are copied, the Role IDs of the user roles in the resulting copy will be different from the ones in the original project.
[user-role-name] - The unique role name of the user role to which the current user is assigned (blank if not assigned to any user role). This value is auto-generated for each user role. NOTE: This value is only unique for roles within the project. Thus, if the project and its roles are copied, the new project will retain the same unique role names, which allows you to utilize the unique role names in conditional logic, calculations, branching logic, etc. that will not break when the project is copied.
[user-role-label] - The name/label of the user role to which the current user is assigned (blank if not assigned to any user role). This value is defined by the user that creates the user role.
New Action Tag: @MAXCHOICE-SURVEY-COMPLETE - Similar to @MAXCHOICE but only counts choices on completed survey responses (does not count data entered as data entry only or on partial responses). Causes one or more specified choices to be disabled (i.e., displayed but not usable) for a checkbox, radio button, or drop-down field after a specified amount of records have been saved with that choice for completed survey responses only.
New feature: Tableau Data Export- Extract all records into Tableau via the REDCap API.
This feature enables Tableau (v10.0+) users to connect Tableau to a REDCap project using an API token. Project data can be exported on demand and be available for use within Tableau to produce summaries and visualizations. The Other Export Option page in any given project has instructions to export project data into Tableau.
NOTICE: It is required for a user to have an API token generated for the project in order to use this feature.
New feature: MailGun Email API Integration
As an alternative for sending outgoing emails from REDCap (rather than using the standard settings in PHP.INI to send them natively from the web server), you may use MailGun, which is a third-party paid service that can send emails on behalf of REDCap.
The option can be configured on the General Configuration page in the Control Center. You merely have to provide the API key and domain name for your MailGun account, and it will begin using the MailGun Web API to send all emails going out of REDCap.
New feature: Project-level setting "Prevent branching logic from hiding fields that have values"
This setting can be enabled by any project user with Project Setup/Design privileges in the Additional Customizations popup on the Project Setup page.
This setting affects both data entry forms and surveys. If it is not enabled (default), then whenever a field is to be hidden by branching logic on a data entry form, it will always ask the user if they wish to hide the field and erase its value, whereas on survey pages it will automatically erase the value of the field being hidden without displaying the confirmation prompt, which has always been the default behavior for surveys. If this setting is enabled, the branching logic behavior will change so that fields with values will not cause the 'Erase the Value of the Field?' confirmation prompt to ask the user if they wish to keep the value or hide the field, and instead fields with values will not be hidden by branching logic and will stay visible. Thus they will be exempt from branching logic. This will prevent data from being erased as it normally does if fields are hidden by branching logic.
When a field should be hidden by branching logic but is not hidden because it has a value, an icon will be displayed on the field to indicate this to the user.
This project-level setting is included in the API Export Project Info method as "bypass_branching_erase_field_prompt". The REDCap Mobile App will soon have this same functionality, but it will only work if the REDCap server is on REDCap 11.2.0 or higher.
The name of Data Quality rule F has been slightly changed when this setting is enabled from "Hidden fields that contain values" to "Fields that contain values that should be hidden".
Improvements for report display and/or data exports- When creating/editing a report, the "Additional report options" section in Step 2 now contains the new options below:
For projects that have repeating instruments and/or repeating events, the repeating fields that are automatically added (e.g., redcap_repeat_instrument and redcap_repeat_instance) can now be excluded from the report and data export. These fields are displayed by default in reports/exports.
Users may choose to display the field label, variable name, or both (default) in the header of a report. Note: This is only used when viewing reports and thus is not applicable for exports since there already exist options for choosing raw vs label format in data exports.
Users may choose to display the field label, raw data value, or both (default) for multiple choice fields in the data displayed in a report. Note: This is only used when viewing reports and thus is not applicable for exports since there already exist options for choosing raw vs label format in data exports.
Version 11.2.3 (released on 2021-08-06)
CHANGES IN THIS VERSION:
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.
11.3.0
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 features: 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
11.3.1
New feature: "DAG Switcher" API method - When using the DAG Switcher functionality in a project, this method allows users to move themselves in and out of a Data Access Group at will using the API just as they would do the same thing in the user interface (assuming they have been assigned to multiple DAGs on the DAG Switcher page).
11.3.2
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.
11.4.0
New action tag: @IF - Allows various action tags to be set based on conditional logic provided inside an @IF() function - e.g., @IF(CONDITION, ACTION TAGS if condition is TRUE, ACTION TAGS if condition is FALSE). Simply provide a condition using normal logic syntax (similar to branching logic), and it will implement one set of action tags or another based on whether that condition is true or false. For example, you can have @IF([yes_no] = '1', @HIDDEN, @HIDE-CHOICE='3' @READ-ONLY), in which it will implement @HIDDEN if the 'yes_no' field's value is '1', otherwise, it will implement the two action tags @HIDE-CHOICE='3' and @READ-ONLY. If you wish not to output any action tags for a certain condition, set it with a pair of apostrophes/quotes as a placeholder - e.g., @IF([my_radio]='1', @READONLY, ''). You may have multiple instances of @IF for a single field. You may also have multiple nested instances of @IF() inside each other. Both field variables and Smart Variables may be used inside the @IF condition. The @IF action tag is also evaluated for a given field when downloading the PDF of an instrument/survey, in case there are any PDF-specific action tags used inside of @IF(). Note: The conditional logic will be evaluated only when the survey page or data entry form initially loads; thus the action tag conditions will not be evaluated in real time as data is entered on the page.
New feature: Protected Email Mode
Users can enable the Protected Email Mode on any project on the Project Setup via the Additional Customization dialog. This setting prevents identifying data (PHI/PII) from being sent in outgoing emails for alerts, survey invitations, and survey confirmation emails.
If enabled, either A) all alerts, survey invitations, and survey confirmation emails or B) those whose email body is attempting to pipe data from Identifier fields will be affected, in which it will not send the full email text to the recipient but will instead send a surrogate email containing a link that leads them to a secure REDCap page to view their original email. If someone is accessing an email in the Protected Email Mode for the first time (or for the first time in the past 30 days), it will send a security code to their inbox that will allow the recipient to view any protected emails for up to 30 days on that same device. The Protected Email Mode is similar to Microsoft Outlook's "sensitivity label" feature.
When enabled in a project, 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.
This feature can be disabled in all projects via a global setting on the Modules/Services Configuration page in the Control Center.
New feature: Email Logging page
This is a new project page that contains a search interface to allow users with User Rights privileges to search and view ALL outgoing emails for that project (also includes searching and viewing of SMS messages if using Twilio services).
This feature can be disabled in all projects via a global setting on the Modules/Services Configuration page in the Control Center.
"Re-send email" feature - When viewing an individual email after performing a search on the page, a "Re-send email" button will be displayed in the dialog to allow users to re-send the email. Note: If the original email contained email attachments, the attachments will not be included in the email that is re-sent.
Only users with User Rights privileges in the project may access the page, and additionally they must opt-in and agree to a disclaimer before being able to view the page. The following text will be presented to the user before accessing the page: "Before viewing and accessing this page, you must first agree that you understand the following important information and conditions. This page is only accessible by users having User Rights privileges in this project. The Email Logging feature allows users to search and view all outgoing emails related to this project, and this includes being able to view all aspects of any given email (i.e., the recipient(s), sender, subject, message body, attachment names). If you are using anonymous surveys in this project, keep in mind that viewing this page and the emails displayed therein might inadvertently cause anonymous survey responses to be identifiable/de-anonymized. Additionally, if the project is using Data Access Groups, you will be able to view the emails related to all DAGs in this project (and thus possibly any data piped into the body of those emails). If you understand and agree to these conditions, click the button below. Please note the act agreeing to this disclaimer will be documented on the project Logging page."
Improve: New data export option - Export blank values for gray instrument status
All instrument complete status fields having a gray icon can be exported either as a blank value or as "0"/"Incomplete". In previous versions, they could only be exported as "0". By default, they are now exported with a value of "0", but this option can be changed via a drop-down option in the "Advanced data formatting options" section of the data export dialog.
When exporting the Project XML file with both metadata & data, the option to export gray instrument status as a blank value will be preselected by default, whereas in other data export contexts (e.g. My Reports & Exports page), the option to export them as "0" will be preselected by default.
The API method "Export Records" has a new optional parameter "exportBlankForGrayFormStatus" that can accept a boolean (true/false) with default value = false, and it functions the same as its equivalent data export option in the user interface.
Note: Exporting gray instrument statuses as blank values is recommended if the data will be re-imported into REDCap. For example, when users export a Project XML file for a project and then create a new project with it, all the gray instrument status icons will be preserved in the new project, whereas in previous versions they were all converted into red status icons.
Improvement: New option "Allow normal users to edit their primary email address on their Profile page" on the User Settings page in the Control Center. This setting will be enabled by default, but an admin can disable it if they wish to prevent any users from modifying their primary email address for their user account.
Major bug fix: When a repeating instrument has data entered on multiple repeating instances, and then afterward the instrument is made to no longer be repeatable, then any new data entered on that data entry form for fields that already have data on other instance might mistakenly get stored in the wrong repeating instance (i.e., get orphaned in the "redcap_data" database table) and thus would fail to be seen when reloading the form again. (Ticket #115308)
11.4.1
New feature: Auto-adjudication for Clinical Data Pull (CDP) projects - As an extension of the existing "Instant Adjudication" feature for CDP projects, any projects with Instant Adjudication enabled can optionally enable the Auto-adjudication feature on the CDP Setup page in a project. Once enabled, if any records in the project have data that has already been pulled from the EHR and are awaiting adjudication, they will be adjudicated automatically by a cron job process that checks every 5 minutes. This allows the data to follow into the project automatically and prevents the need for a user to manually adjudicate data or to click the Instant Adjudicate button. Similar to the Instant Adjudication setting, only users with CDP Setup/Mapping privileges can enable the Auto-adjudication setting.
11.4.2
Improvement: If using Amazon S3 or Azure Blob Storage for the system-level File Storage Method, the same file storage method may also be used for the following system-level settings: 1) 'File Upload' field enhancement: Password verification & automatic external file storage, 2) Record-level Locking Enhancement: PDF confirmation & automatic external file storage, and 3) e-Consent Framework: PDF External Storage Settings (for all projects). These three settings will each utilize a different bucket/container than the system-level file storage method where all other REDCap files are stored (as a means of keeping them separate from the other files). These settings are often utilized for compliance with 21 CFR Part 11 and similar regulations. The addition of the S3/Azure options will be helpful when already running REDCap on AWS/Azure. The bucket/container where the files will be stored for these three options may be set for each near the bottom of the Modules/Services Configuration page in the Control Center.
11.4.4
Change/improvement: When a survey participant partially completes a survey that has the Save & Return Later feature enabled, and an email is then sent to the participant to remind them to finish their survey later, instead of sending that email from the system-level "Email Address of REDCap Administrator" (as in previous versions), the "From" email address of the "Survey partially completed" email will be set to the sender's address from the most recent survey invitation received by the participant. This will create more consistency and will reduce confusion for participants when attempting to reply back to the email, as has been a problem in the past
12.0.0
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.
System-level Configuration: The MLM feature can be completely disabled at the system level, if desired, via the MLM page in the Control Center (on the Settings tab). On this page in the Control Center, admins can optionally seed any User Interface (i.e., stock language) translations for the entire REDCap installation, in which users could import any activated User Interface translations into their project. This will only import the User Interface elements (since those are universal to each project), but it can be a big time saver to prevent the user from having to translate those common elements in their project. These can be imported via the Create New Language process in a project (or via the Edit Language setting also).
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 Action Tags for Multi-Language Management
@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.
@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).
@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.
@LANGUAGE-FORCE-FORM - Same as @LANGUAGE-FORCE, but the effect is limited to data entry forms (i.e. this does not affect surveys).
@LANGUAGE-FORCE-SURVEY - Same as @LANGUAGE-FORCE, but the effect is limited to surveys (i.e. this does not affect data entry forms).
@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).
Thanks to Günther Rezniczek for all his work to help us build the new Multi-Language Management feature.
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.
New feature: Design Checker for the Clinical Data Mart (CDM) - The "Data Mart Design Checker" is a new tool available in the Data Mart fetch page that will report any issue related to the design of the current Data Mart project. Based on the most recent Data Mart XML template available in REDCap, the tool will check, list, and fix any of these issues: missing forms, variables, revisions, or section headers, the lack/presence of repeatability in a form, variables included in the wrong form, etc. An administrator or a user with Project Setup/Design privileges can use the tool to review and automatically fix all reported issues. This tool will mainly be utilized when users have modified the structure of an existing Data Mart project or if new forms and data types have been added to the Data Mart feature itself since the users initially created their Data Mart project.
Major bug fix: When a field is embedded on a multi-page survey, in which the embedded field's parent field is used in branching logic on a later page, the embedded field's value might mistakenly get erased when a later survey page is submitted if the embedded field is set as a Required field. (Ticket #117620)
12.0.3
Improvement/change: When using Multi-Language Management on a survey, the current language name is now displayed next to the globe icon at the top right of the survey page so that participants more intuitively understand what the current language is and to click it to change the language.
Improvement/change: The Online Designer now denotes whether a field on the instrument contains embedded fields inside its label, choices, notes, etc. by displaying a blue box saying "Contains embedded fields", similar to the green "Field is embedded elsewhere on page" boxes for embedded fields themselves. This will provide users with visual cues to know when and where field embedding is occurring.
Improvement: The Design Checker feature for Clinical Data Mart now has improved descriptions of changes that will be made, including the severity of the design issue.
12.0.5
New feature: New design for the "Help & FAQ" page.
New 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. (Ticket #70973)
Improvement/change: 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. (Ticket #115791)
Improvement: When using OAuth2 Azure AD Authentication, you may now specify a different AD attribute whose value determines the REDCap user's username. By default, it uses the AD attribute "userPrincipalName", which often resolves to the user's email address. The Security & Authentication page has a new drop-down setting to allow admins to alternatively specify the AD attribute "samAccountName", which would resolve to something like "pharris", for example. This provides an option if the institution prefers not to use a user's email address as their REDCap username. Note that this setting does not change the Azure AD login name, which is still the user's email address / userPrincipalName. Administrators may want to select the samAccountName to help retain account usernames when transitioning from LDAP to Azure AD, or if samAccountName is considered an immutable (and thus more reliable) user ID at your institution.
Version 12.0.9 (released on 2022-01-07)
CHANGES IN THIS VERSION:
Medium security fix: A Cross-site Scripting (XSS) vulnerability was discovered where a malicious user could potentially exploit it by inserting HTML tags and/or JavaScript event attributes in a very specific way as user-defined text in various places.
Minor security fix: If a field contains integer values (e.g., Textbox, Radio, Drop-down) for a record, and then the field is changed to be a File Upload field, viewing a data entry form or a report that contains that field might (depending on the pre-existing integer value of the field) mistakenly expose the filename of files that have been uploaded to other File Upload fields, including possibly those from other projects. Users are not able to download these uploaded files or view their contents, but can view the filename of the file on a data entry form or a report.
Minor security fix: A Blind SQL Injection vulnerability was found on the Cron Jobs page in the Control Center, in which a malicious user could potentially exploit it by manipulating an HTTP request on that page.
Minor security fix: A Cross-site Scripting (XSS) vulnerability was discovered where a malicious user could potentially exploit it by inserting HTML tags and/or JavaScript event attributes in a very specific way into the URL on the API Tokens page in the Control Center and also on the API page in a project.
Major bug fix: In a longitudinal project with Data Access Groups, importing data via the "Import Records" API method for an existing record that is assigned to a DAG, in which the API parameters format="json" and overwriteBehavior="overwrite" are used, if the JSON data being imported contains a non-blank value for the "redcap_data_access_group" field for one event while another event of data (for the same record) does not contain the "redcap_data_access_group" field at all in the JSON, REDCap would mistakenly perceive the absent "redcap_data_access_group" field as a blank value and thus would un-assign the record from the DAG (due to the overwriteBehavior="overwrite" parameter being used). When this occurs, the DAG unassignment event would also not get logged on the project Logging page.
Bug fix: Drop-down fields using the auto-complete option would cause the webpage to be slow/laggy when typing a value into the field's textbox or when clicking the down-arrow button for the field to view the full list of choices if the field has hundreds or thousands of choices defined. This slowness was due to the auto-complete feature not being set up correctly in the underlying JavaScript. Note: Clicking the down-arrow button for an auto-complete drop-down with 1000+ choices when the field has no value will now display a notice next to the field that the full list of choices cannot be displayed and instead encourages the user to type a value to search all options.
Bug fix: When referencing a Smart Variable inside conditional logic (e.g., Data Quality rules, ASI logic) in which the Smart Variable is appended with a colon+parameter while also being prepended with a unique event name (e.g., [event_1_arm_1][survey-date-completed:form_1]), the logic might fail to be successfully evaluated. This could cause Data Quality rules to throw an error or could cause survey invitations for ASIs not to get sent in specific cases. (Ticket #120543)
Bug fix: When a multi-page survey contains required fields that exist on pages after page 1, in some specific scenarios it might mistakenly display the "Some fields are required!" prompt for fields on later pages after submitting the first page. Note: The participant would still be allowed to continue to the next page after the initial submission of page 1. (Ticket #120518)
Version 12.0.10 (released on 2022-01-10)
CHANGES IN THIS VERSION:
Bug fix: The field drop-down for the "Designate a Secondary Unique Field" setting in the "Additional Customizations" popup on the Project Setup page would mistakenly not include some Textbox fields (notably those with no Action Tags or Field Annotation).
Bug fix: When using Smart Variables that utilize the parameters ":fields" or ":instrument" in a calculated field or @CALCTEXT field, if the user is entering data on a form or survey, the calculation might mistakenly not get updated if fields used inside the Smart Variable exist on a different instrument or event.
Bug fix: For certain server configurations, the REDCap cron job might mistakenly crash due to a floating point precision issue when creating a timestamp. This occurrence is fairly rare. (Ticket #120688)
Bug fix: When using certain Smart Variables inside a calculation or @CALCTEXT field, a calculation error message might mistakenly appear on the data entry form or survey page and thus would prevent calculations from occurring on that page. (Ticket #120660)
Bug fix: When a report contains data from a repeating instrument and/or repeating event, in which the report's checkbox setting "Include the repeating instance fields (redcap_repeat_instrument, redcap_repeat_instance) in the report and data export?" is not checked, viewing the Stats & Charts page for the report would display the charts and tables correctly unless a user selects a Live Filter for the report, in which it would mistakenly cause all/most tables and charts not to display at all on the page. (Ticket #120408)
Version 12.0.11 (released on 2022-01-14)
CHANGES IN THIS VERSION:
Bug fix: A project dashboard with custom access settings might mistakenly not be accessible to administrators using the "View project as user" feature.
Bug fix: When creating or editing a Project Dashboard that has been set as "public", the option to create a custom public link would mistakenly not be displayed on the page (assuming that the URL Shortening Service is enabled at the system level).
Bug fix: When creating or editing a report that has been set as "public", the option to create a custom public link would mistakenly not be displayed on the page (assuming that the URL Shortening Service is enabled at the system level).
Bug fix: If using the @CALCTEXT action tag on a datetime field, in which the [survey-time-completed] Smart Variable is referenced inside @CALCTEXT(), the resulting value might cause the calculation error popup to display on a survey or data entry form, and the value might not save correctly on the form/survey, via data import, or via running Data Quality rule H. This issue occurs mostly when using field validation with formatting H:M (rather than H:M:S) and also with formatting MDY or DMY (rather than YMD).
Bug fix: If a date or datetime field was using the @HIDEBUTTON action tag, the date format label (e.g., "M-D-Y") would mistakenly not be displayed on the right.
Bug fix: PHP error occurs for PHP 8.0 or 8.1 when downloading Automated Survey Invitations as a CSV file in the Online Designer. (Ticket #120965)
Bug fix: When piping data on an instrument for a field from another instrument while also using the Multi-language Management feature for the current instrument, the piped value might mistakenly not display on the page.
Bug fix: When performing calculations for a @CALCTEXT field (whether on a data entry form, survey page, data import, or Data Quality rule H), some dynamically-created regular expressions in PHP that search for other calculated fields or @CALCTEXT fields that are used within the original @CALCTEXT field might cause an overload due to the regular expression being too long, thus possibly resulting in not accurately determining dependent fields used inside the @CALCTEXT field's equation. This means that some @CALCTEXT fields might possibly not get their value updated successfully.
Bug fix: Some long-running reports might mistakenly return the error message "An unknown error has caused the REDCap page to halt..." in specific edge cases.
Bug fix: If an alert has an [aggregate-X] Smart Variable piped into the alert's email body, it might cause the cron job to crash when attempting to send the alert. (Ticket #120561)
Version 12.0.12 (released on 2022-01-25)
CHANGES IN THIS VERSION:
Bug fix: If a file is being imported via API for a File Upload field, in which the field's instrument is a repeating instrument, then it might make the instrument inaccessible in the user interface (e.g., Record Home Page, Record Status Dashboard) if no other field on the instrument contains any data for that instance. (Ticket #120354)
Bug fix: Issues might occur (e.g., blank white page) when installing REDCap on PHP 8.1 due to the setting "mysqli_report", which defaults to "MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT" in that version. This will also require replacing the redcap_connect.php non-versioned file on the REDCap web server.
Bug fix: When attempting to send a File Upload field's file via Send-It from a data entry form, the popup window would display a blank page if using PHP 8.0 or higher. (Ticket #121163)
Bug fix: Remediated PHP 8.X-specific errors that occur when users alter URLs in unexpected ways.
Bug fix: The mouseover text displayed when hovering over the "Members: Everyone" text in the General Notifications channel in REDCap Messenger would mistakenly display the wrong text. (Ticket #121312)
Bug fix: When performing calculations for a @CALCTEXT field (whether on a data entry form, survey page, data import, or Data Quality rule H), some dynamically-created regular expressions in PHP that search for other calculated fields or @CALCTEXT fields that are used within the original @CALCTEXT field might cause an overload due to the regular expression being too long, thus possibly resulting in not accurately determining dependent fields used inside the @CALCTEXT field's equation. This means that some @CALCTEXT fields might possibly not get their value updated successfully. (NOTE: This is a very similar but slightly different fix for the bug fix with the same description in the previous version.)
Bug fix: When using the Auto-Archiver or e-Consent Framework on a survey while also setting the Stop Action survey option to "Do not save the survey response", when a participant triggers a stop action on the survey, it would mistakenly display the error message "X is not an existing record in this project!" at the bottom of the page. (Ticket #121166)
Bug fix: When an administrator is approving a To-Do List request to make a user's report "public", after clicking the "Click here" link to view the report while inside the approval dialog, it would cause the dialog to flash and then go white, thus preventing the admin from approving the request (unless they went into the project manually and viewed that report before returning to the To-Do List request). (Ticket #120893)
Bug fix: Small change to text in the Two-Factor Authentication settings on the "Security & Authentication" page to improve clarity of the option IP Exception setting used for 2FA.
Bug fix: When loading the Participant List inside the "Compose Survey Invitations" popup, it would mistakenly take an unnecessarily large amount of time to load a list of thousands or more participants for certain surveys.
Bug fix: If using WebDAV as the File Storage Method for the following system-level settings 1) 'File Upload' field enhancement: Password verification & automatic external file storage, 2) Record-level Locking Enhancement: PDF confirmation & automatic external file storage, or 3) e-Consent Framework: PDF External Storage Settings (for all projects), these features may no longer be storing files successfully to the external server. A new "authentication type" setting for WebDAV only has been added to all 3 settings on the "Modules/Services Configuration" page in the Control Center to allow an administrator to set the WebDAV authentication as "Basic", "NTLM", or "Digest" (depending on the local configuration of the WebDAV server being used). Setting the WebDAV authentication type appropriately for each of the 3 settings (if being utilized) should fix this issue.
Bug fix: The Google OAuth2 authentication would fail to work in PHP 8.0 and 8.1, thus resulting in a fatal PHP error when attempting to log in. (Ticket #121050)
Bug fix: For some projects, the Multi-language Management page might get stuck during its initialization, thus preventing users from using it. (Ticket #118463)
Bug fix: In some situations when clicking the table headers of the Participant List table, all cells in the Participant Identifier column that were previously editable would mistakenly become no longer editable.
Bug fix: When using the Multi-language Management feature, some embedded multiple choice fields might mistakenly not appear in the expected translated language on a data entry form or survey page. (Ticket #121557)
Version 12.0.13 (released on 2022-01-28)
CHANGES IN THIS VERSION:
Minor security fix: A Cross-site Scripting (XSS) vulnerability was discovered where a malicious user could potentially exploit it by inserting HTML tags and/or JavaScript event attributes in a very specific way into the title of a project.
Minor security fix: A Cross-site Scripting (XSS) vulnerability was discovered where a malicious user could potentially exploit it by inserting HTML tags and/or JavaScript event attributes in a very specific way for certain features of REDCap Messenger.
Bug fix: Some of the example R code in the API Playground mistakenly referenced a function named "fileUpload()" when it should instead be "upload_file()". (Ticket #101454b)
Bug fix: Data Quality rule E was mistakenly using the median and not the mean for the field when determining if the value was an outlier (e.g., two standard deviations from the mean). (Ticket #121704)
Bug fix: Some password-related configuration settings for Table-based authentication might mistakenly contain trailing spaces in their value, thus possibly preventing the settings from working as expected. (Ticket #121716)
Bug fix: The REDCap cron job might crash unexpectedly when attempting to send an Alert containing a [survey-link] Smart Variable when the project does not have any surveys enabled. This only occurs in PHP 8.0 and 8.1. (Ticket #121644)
Bug fix: Survey Queue settings in the "Set Up Survey Queue" popup would mistakenly not get saved for a survey that is currently set to "offline" status. (Ticket #121668)
Bug fix: When uploading a new user role via a CSV file on the User Rights page, some specific user privileges for the new role might mistakenly not get saved correctly during the upload process. (Ticket #121461)
Bug fix: When a user assigned to a Data Access Group is using the Data Resolution Workflow, the Resolution Metrics page would mistakenly display the "Average time for query response (by user in days)" chart when instead it should only display the chart for users who do not belong to a DAG. (Ticket #121527)
Bug fix: When an alert or an automated survey invitation has conditional logic that contains datediff+today/now, in which Smart Variables are used in the logic but no real field variables are used, the alert/ASI would mistakenly fail to be scheduled/sent by the datediff+today/now cron jobs that run every 4 hours. (Ticket #121276)
Version 12.0.14 (released on 2022-02-11)
CHANGES IN THIS VERSION:
Minor security fix: A Cross-site Scripting (XSS) vulnerability was discovered where a malicious user could potentially exploit it by inserting HTML tags and/or JavaScript event attributes in a very specific way into the values of Text Box and Notes Box fields that are piped somewhere else on the same page as where the field exists. This does not occur if they are piped into a different instrument, different event, or elsewhere in the project.
Bug fix: A field's question text on a survey page might mistakenly not get recognized by certain screen reading software, especially if the survey has the "enhanced radio buttons and checkboxes" setting enabled. (Ticket #121765)
Bug fix: When attempting to upload a data dictionary with calculated fields or @CALCTEXT fields that contain Smart Variables inside their calculation, REDCap might mistakenly return an error message saying that the Smart Variables are not real variables, thus preventing the user from uploading the data dictionary.
Bug fix: Too many Google services were mistakenly included during the recent bundling of the Google PHP API Client Services library, thus causing REDCap's resulting code to bloat unnecessary by an extra 15,000 files.
Bug fix: The contents of the email sent to a participant after clicking the “Save & Return Later” option in a survey were mistakenly not translatable via the Multi-language Management feature.
Bug fix: When adding a field to a project in production while in draft mode, an incorrect error message is displayed if the field is being added below a section header. (Ticket #122044)
Bug fix: A fatal PHP error might be thrown in very specific instances when using PHP 8.0+. (Ticket #122182)
Bug fix: A fatal PHP error may occur on the Online Designer page for PHP 8.0+ in certain situations. (Ticket #122108)
Bug fix: Resolved some potential upgrade issues occurring with SQL queries failing in some particular situations when upgrading to REDCap 11.2.0 or higher. (Ticket #121952)
Bug fix: When a project has record auto-numbering enabled, and a user creates a record, renames it, and then deletes it, the next record to be created would mistakenly not have the same record name as the one deleted (assuming no other records had been created during the interim). It is assumed that the next record would have the same name as the deleted one. (Ticket #122090)
Bug fix: When adding hyperlinks into a field label, survey instructions, etc., in which the hyperlink URL contains "on" and also "=" somewhere inside it, the URL might mistakenly get mangled when output on the page in which "onXXXXX=" will be replaced with the word "replaced=". (Ticket #121691)
Bug fix: When uploaded files are being copied on the server (e.g., when copying a project containing Descriptive Text fields with file attachments), if the file somehow can't be found or accessed on the server, it would throw a fatal PHP error in PHP 8.0+. (Ticket #122496)
Bug fix: When required fields are left empty on a data entry form that is submitted, thus displaying the required fields popup, and then the page is refreshed, it would mistakenly keep displaying the required fields popup to the user even when the required fields might have been given values in the interim. (Ticket #122480)
Bug fix: When using [survey-date-completed] or similar Smart Variables inside the conditional logic for Automated Survey Invitations, it might cause the page to crash when submitting a survey or data entry form, resulting in a fatal PHP error. (Ticket #122473)
Bug fix: If an instrument is exported as a PDF with data, in which the instrument contains slider fields that display the slider value next to it, the slider's value displayed in the box next to the field in the PDF would mistakenly always be normalized to be between 0 and 100, rather than displaying the literal value as-is. (Ticket #122035)
Bug fix: Data Quality rule F might mistakenly return false positives for fields that exist on repeating instruments in a longitudinal project, especially when the field's instrument is also utilized as a non-repeating instrument in another event. (Ticket #121343)
Bug fix: When running PHP 8.0+, the Stats & Charts page might fail with a fatal PHP error if number/integer fields somehow contain non-numeric values. (Ticket #122604)
Bug fix: When upgrading to REDCap 11.4.1 or higher, the SQL upgrade script might mistakenly crash with an error on a certain query. (Ticket #122565)
Bug fix: When using Multi-Language Management and translating a survey that has Stop Actions, the User Interface text for the title of the Stop Action popup (i.e., "End the survey?") would mistakenly not appear in its translated form. (Ticket #122644)
Bug fix: When importing the JSON or CSV language file for Multi-Language Management, labels might mistakenly not get updated to their translated form for option choices for some multiple choice fields. (Ticket #122636)
Bug fix: Some text was changed in the Tableau section of the "Other Export Options" tab on the "Data Exports, Reports, and Stats" page because it could be confusing to users if certain institutions have special licensing and/or policy with regard to the installation of Tableau. (Ticket #122618)
Bug fix: If a user is assigned to a Data Access Group, the "Select a previously sent email" drop-down list in the "Compose Survey Invitations" popup on the Participant List page would mistakenly not filter out previously-sent emails pertaining to records that belong to other DAGs. (Ticket #122495)
Bug fix: If more than 500 instances of the @IF action tag are used for a field, whether nested or used in parallel, all the @IFs listed after the 500th @IF would mistakenly not get processed, thus causing the @IFs not to function correctly on the field.
Bug fix: The “Break the Glass” feature in Clinical Data Pull (CDP) was mistakenly not able to perform a successful login for the user, thus was not able to break the glass for a record.
Bug fix: When creating a new project using a Project XML file with an API super token, in some particular use cases depending on the exact setup of the project and its data, the API request might mistakenly crash or might not complete the process if any record data exists inside the Project XML file. (Ticket #121579)
Bug fix: Clicking a slider field to initialize it would mistakenly not immediately trigger its value to be piped if the slider is piped elsewhere on the same page. It would only pipe if the slider’s value was modified after its initialization. (Ticket #122704)
Bug fix: A warning message would mistakenly be returned when attempting to upload a data dictionary containing checkboxes with a dot/period in a checkbox choice coded value, in which that checkbox choice was being referenced in a calculation or branching logic. Notes: Dots/periods are allowed in a checkbox choice code. (Ticket #122581)
Bug fix: When uploading a file for a File Upload field via the API Import File method, the resulting logged event on the project logging page would only display the field name when it should instead display the field_name and back-end edoc ID value for the file in the logged event description. This was changed because it was inconsistent with the logging produced when uploading a file via the user interface. (Ticket #122272)
Bug fix: Text Box fields with the @SETVALUE action tag would always display the red bar on the side of the field (regardless of the value) when instead the red bar should only be displayed when the saved value is different from the displayed value.
Version 12.0.15 (released on 2022-02-18)
CHANGES IN THIS VERSION:
Minor security fix: A vulnerability was discovered where malicious user could potentially exploit it by manipulating an HTTP request for the project Calendar page popup, in which some minimal amount of data from the calendar event could be exposed to a REDCap user for a project to which they do not have access.
Bug fix: A new system-level configuration setting was added to the User Settings page in the Control Center to allow admins to select the default instrument-level user access that gets set for all project users' Data Viewing Rights whenever a new instrument is created while in production status. The available options are "No Access" (default) and "View & Edit". Many administrators have noted that the sudden change in REDCap 11.3.0 for default instrument-level user access for new instruments while in production has caused quite a lot of confusion for users and has thus greatly increased the support workload of administrators. Despite being a new system-level option, this is considered a bug fix because it serves to restore continuity with previous versions by allowing admins (if desired) to revert the behavior back to the way it behaved in pre-11.3.0 versions. (Ticket #120976)
Bug fix: When processing REDCap logic, in some specific instances with specific logic, which may also be dependent upon PHP version, a fatal PHP error might occur and might crash the page. (Ticket #122418)
Bug fix: When using Multi-Languagement Management and defining a Fallback language that is different from the Default language, any User Interface text on a survey page or data entry form might mistakenly be displayed in the Fallback language when the Default language has been selected as the display language.
Bug fix: If an external module utilizes the "redcap_pdf" hook while the system-level "redcap_pdf" hook (in the hook functions file) is also being utilized to perform custom tasks on the server, the results returned from the EM PDF hook would mistakenly not get utilized downstream. (Ticket #122775)
Bug fix: The datepicker widgets used for the time window search on the Email Logging page in a project would mistakenly not stay visible in certain cases when trying to use them. (Ticket #122811)
Bug fix: The URL for the example Login Page logo used on the REDCap Install page mistakenly pointed to a non-existent image/URL.
Bug fix: When attempting to send outgoing emails (e.g., survey invitations, alerts), if the email subject is left empty, it might prevent the email from sending successfully.
Various fixes for the External Module Framework.
Bug fix: In certain situations with longitudinal projects, the Form Display Logic might mistakenly not function correctly to enable/disable the right instruments. (Ticket #122974)
Bug fix: When creating a longitudinal project via a Project XML file, the form-event mapping might mistakenly not get saved during the project creation process.
Bug fix: When exporting and then importing a Project XML file to create a new project that has some Form Display Logic defined, if the project is longitudinal and has some Form Display Logic conditions that references an instrument on "[All Events]", those Form Display Logic conditions might mistakenly not get saved during the project creation process.
Bug fix: When editing an existing report that has fields selected via the drop-down lists in Step 3 (Filters), then the user clicks the "Use advanced logic" link, then the user clicks the "Use simple logic (choose fields from list)" link, then if they select a field in the first filter field drop-down (which has no field selected), it would mistakenly not display a new field/row immediately below that row. Thus, the user is not able to add more than one filter field for the report in this scenario unless they save the report and reload it to edit it again. (Ticket #18065)
Version 12.016 (released on 2022-02-21)
CHANGES IN THIS VERSION:
Bug fix: In some specific scenarios when using PHP 8.0 or 8.1 with some longitudinal project, the Online Designer might mistakenly crash with a fatal PHP error. (Ticket #123103)
Bug fix: When using Multi-Language Management and changing an enumerated value (e.g., choices, Action Tags), the "reference change tracker" was wrongly highlighting some items on the page.
Bug fix: When a Secondary Unique Field is designated in a project while its two display-related checkbox sub-options are left unchecked, then when viewing a data entry form for an instrument that was completed via survey (as opposed to via data entry form), the value and/or label of the SUF would mistakenly be displayed at the top of the data entry form. (Ticket #123127)
Version 12.0.17 (released on 2022-02-25)
CHANGES IN THIS VERSION:
Bug fix: In some specific scenarios while using PHP 8.0 or 8.1, the System Statistics page in the Control Center might mistakenly throw a fatal PHP error when making the AJAX request to obtain the web server space usage. (Ticket #123238)
Bug fix: If some branching logic, conditional logic, or calculations have incorrect syntax in a specific way, depending on the logic/calculation itself, it could result in a fatal PHP error when being processed. (Ticket #123229)
Bug fix: When using the Smart Variable [stats-table] in the content of an outgoing email (i.e., survey invitation or alert), the table would mistakenly be missing all the styling applied to it when viewed in the REDCap application. (Ticket #123207)
Bug fix: When using the Smart Variable [stats-table] in the content of an outgoing email (i.e., survey invitation or alert), the "Export table" link that is normally displayed below the table might mistakenly get included in the email body, which might occasionally cause the link to be removed from the email message by the email client or might cause the entire email message to be flagged as spam and therefore not received by the recipient.
Bug fix: When multiple choice fields have choice values of "0" and "00", and a record has either choice selected and saved on an instrument, if that instrument is then exported as a PDF with data, both choices would mistakenly appear checked as seen in the PDF. (Ticket #123282)
Bug fix: When using Twilio telephony services for surveys, U.S. phone numbers having the area code "667" would mistakenly not work for SMS or voice calls unless the number has a "1" prepended to it. (Ticket #123291)
Bug fix: When using a Custom Record Label that contains Smart Variables but not field variable names, the Custom Record Label would mistakenly not display at all in certain places where the record name is displayed. (Ticket #123187)
Bug fix: The Multi-Language Management setup page would mistakenly fail to load/display any fields on the instrument-level translation tab if a multiple choice field on the instrument contained zero choices. (Ticket #123371)
Bug fix: When exporting data via the user interface, API, or REDCap::getData(), depending on the structure of a project, an error might mistakenly be returned due to hitting the PHP memory_limit threshold and thus throwing a fatal PHP error. This was due to REDCap's internal batch process, which is completely transparent to the user, having too large a value for the size of a given batch.
Bug fix: When the "Filter by records in a DAG" drop-down filter has been selected on the Logging page, and the user then clicks the "Export all pages using current filters" button at the top of the page, the DAG filter would mistakenly not be applied in the resulting CSV export file. (Ticket #123472)
Bug fix: When a project is being created via a Project XML file, and the Secondary Unique Field in the XML file is a calculated field or a @CALCTEXT field, which are not allowed to be set as the Secondary Unique Field, it would mistakenly set the field as the Secondary Unique Field when creating the project. In this case it will now instead unset the Secondary Unique Field setting for the newly created project. (Ticket #123099)
Bug fix: The Multi-Language Management feature would mistakenly display Yes/No or True/False field choices as blank labels when viewing a survey page or instrument for a given translated language. (Ticket #123371b)
Bug fix: Resolved issues where UTF-8 encoded text in field labels gets truncated and displayed in various places throughout REDCap, in which it would sometimes mistakenly display a black-diamond-with-question-mark character at the point of truncation in the label.
Bug fix: The logged event "Change participant invitation preference" (when using Twilio) would mistakenly not be tied to the record name when filtering the logging results by a specific record. (Ticket #123515)
Version 12.0.18 (released on 2022-03-03)
CHANGES IN THIS VERSION:
Major bug fix: The release of REDCap 12.0.17 LTS contained a deploy issue in which the contents of the 12.0.17 LTS zip files were actually the contents of the 12.2.5 Standard Release zip files. This upgrade process for 12.0.18 should fix this and should undo any SQL table-related issues that have occurred if the auto-generated SQL to auto-fix database structure issues has already been run after having upgraded to 12.0.17. After this upgrade has completed, you may or may not see the notice that database structure issues exist, but if so, just execute that SQL to fix those. If you installed 12.0.17 as a fresh install, we ask that you drop all the database tables and perform a new install after re-downloading 12.0.17 and replacing the "redcap_v12.0.17" directory on your server with the corrected version. (Ticket #123525)
Major bug fix: When a user is assigned to a Data Access Group and is attempting to import a record whose record name is the same as an existing record that belongs to another DAG, if the "force record auto-numbering" setting is not enabled as an option during the import process, the user would mistakenly be allowed to import the data with the record name as-is, thus overwriting data to the existing record that does not belong to their DAG. (Ticket #123593)
Bug fix: When using Multi-Language Management, there are scenarios when a form/survey is set to only a subset of languages (but not including the fallback), in the case of a missing translation, the default language would mistakenly be applied instead of the fallback language.
Bug fix: If the "Email Logging" feature has been disabled at the system level, the Email Logging link on the left-hand project menu would mistakenly still be displayed. (Ticket #123563)
Bug fix: When Multi-Language Management is enabled for a specific instrument, and a user/participant fails to enter a value for all required fields, the "Some fields are required" popup would mistakenly fail to be displayed on the page after the page is reloaded. (Ticket #123641)
Bug fix: When using Multi-Language Management, the matrix field floating/stick headers would mistakenly not appear in the desired translated language. (Ticket #123704)
Bug fix: When a Smart Chart uses a unique report name as a parameter, in which a checkbox field is utilized in the Smart Chart and the report has the checkbox option "Combine checkbox options into single column..." checked, the resulting Smart Chart would not be displayed correctly. (Ticket #123574)
Bug fix: When viewing the Training Videos page while not logged in to REDCap, the tables and icons on the page would be displayed, but the text on the page would mistakenly appear invisible. (Ticket #123751)
Various bug fixes for Multi-Language Management.
Bug fix: A participant could inject some JavaScript code into their browser's console that would allow them to bypass the Required Field check (specifically for drop-down fields only), thus mistakenly allowing them to complete the survey page or complete the whole survey without actually entering a value for such drop-down fields. (Ticket #123585)
Bug fix: When using Multi-Language Management, the text for Automated Survey Invitations would mistakenly not save successfully.
Version 12.0.19 (released on 2022-03-10)
CHANGES IN THIS VERSION:
Major bug fix: When an admin attempts to approve a production project's drafted changes, the approval process would mistakenly fail. (Ticket #124102)
Bug fix: When using Multi-Language Management, the text of field validation errors and their associated names/labels displayed in the error popup would mistakenly not be displayed in the translated language.
Bug fix: If an administrator is impersonating a user via the "View Project as User" feature, the admin would mistakenly see all Project Bookmarks on the left-hand menu when instead they should only see the Project Bookmarks that the user being impersonated should see. (Ticket #124021)
Bug fix: Permission-related issues for certain directories on the REDCap web server could lead to fatal PHP errors for some functions throughout REDCap that attempt to list files in specific directories.
Bug fix: A fatal PHP error might occur in certain situations when a participant is submitting a survey while using PHP 8.0+ on the web server. (Ticket #124146)
Bug fix: If a user uses the syntax [field:value] in logic or a calculation, even though this is not correct syntax for logic/calcs (because it is implied that only the raw value should ever be used), it is allowed for compatibility reasons. However, while this syntax works for calculated fields on the same page, it would mistakenly not work for data imports, nor would it work for cross-instrument or cross-event calculations. This syntax will now work in all contexts. (Ticket #124182)
Bug fix: When clicking a table header to sort the column in a DataTables table on any particular REDCap page, the up/down arrow icon in the column header would mistakenly disappear due to a CSS error. (Ticket #124177)
Bug fix: If a field has the @HIDDEN, @HIDDEN-FORM, or @HIDDEN-SURVEY action tag, it would fail to hide the field if the field is embedded in another field on the page.
Bug fix: 18 Laboratory fields and their associated LOINC codes were not originally included on the field mapping page for Clinical Data Pull and Clinical Data Mart.
Bug fix: Line breaks are mistakenly not preserved in the equation of a calculated field when saving the field via the Online Designer. (Ticket #124341)
Bug fix: When piping a datetime field into the min/max validation range check for another datetime field, if the fields being used as the min or max exist on the same page, it would mistakenly throw an out-of-range error if the datetime fields are in MDY or DMY format. Note: This issue does not occur for date fields but only for datetime or datetime w/ seconds fields. (Ticket #124222)
Version 12.0.20 (released on 2022-04-01)
CHANGES IN THIS VERSION:
Minor security fix: A Cross-site Scripting (XSS) vulnerability was discovered where a malicious user could potentially exploit it by inserting HTML tags and/or JavaScript event attributes in a very specific way into the URL on the API Tokens page in the Control Center and also on the API page in a project.
Minor security fix: Updated the Guzzle library due to a security vulnerability reported for that package. (Ticket #125337)
Bug fix: Minor issue with Medication data being pulled from the EHR using a CDIS service.
Bug fix: When using Twilio for surveys in a project, in which a participant is taking a survey and clicks the "Save & Return Later" button followed by clicking "Send survey link", an error would mistakenly be thrown if the preferred contact mode for the participant was set to SMS_INVITE_WEB (i.e., send the survey link via SMS). The phone number would mistakenly be used instead of a valid email in the "from" property of the email. (Ticket #124472)
Bug fix: When using PHP 8.0+ and an API Supertoken is used in the API to retrieve the REDCap version, an error would be thrown. (Ticket #124562)
Bug fix: The “RemoveTempAndDeletedFiles” cron job might mistakenly fail in certain cases with a fatal PHP error if using WebDAV as the File Storage method for REDCap. (Ticket #124802)
Bug fix: When using Multi-Language Management, if the @LANGUAGE-CURRENT-X action tag was used on a drop-down field, branching logic would mistakenly not fire after the value was changed. (Ticket #124748)
Bug fix: The Survey Queue’s UI text would mistakenly not display the translated text when using Multi-Language Management. (Ticket #124855)
Bug fix: When searching for users on the Browse Project page, typing the letter “b” might mistakenly cause HTML to be displayed in the auto-complete output. (Ticket #124935)
Bug fix: The @LANGUAGE-SET action tag would mistakenly not get applied when the corresponding survey field is prefilled from a url parameter. (Ticket #124976)
Bug fix: Using the datepicker widget on a survey page or data entry form might allow users to bypass the field validation on the field if immediately switching to using the datepicker widget on another field on the page. (Ticket #124909)
Bug fix: In some specific scenarios, such as when symlinks exist in the file system on the REDCap web server, the System Statistics page in the Control Center might mistakenly throw a fatal PHP error or be real slow when making the AJAX request to obtain the web server space usage. (Ticket #124710)
Bug fix: Apostrophes that occur in the output of Smart Variables like [user-role-label], [user-dag-label], and [record-dag-label] would mistakenly not get escaped and thus cause JavaScript errors to occur when used in calculated fields. (Ticket #125187)
Bug fix: Fixed typo in @READ-ONY action tag description.
Bug fix: Leading/trailing pipe characters "|" in the choice option column of an uploaded data dictionary would mistakenly create empty/null multiple choice options. (Ticket #125166)
Bug fix: IP addresses in IPv6 format for users would mistakenly get logged as NULL in the redcap_log_view database table. (Ticket #124944)
Bug fix: When using the @CALCDATE action tag with PHP 8.0+, the correct value may be seen as calculated on the survey page or data entry form, but the value may mistakenly get erased upon saving the page afterward. (Ticket #124619)
Bug fix: When a field is embedded and is a required field, the field's value might mistakenly not get saved when submitting a survey page or data entry form if the field also has an @HIDDEN action tag.
Bug fix: When a field contains the @IF action tag and also contains other non-action tag text inside the Field Annotation text, it might cause the @IF action tag not to get interpreted correctly. (Ticket #124974)
Version 12.0.21 (released on 2022-04-08)
CHANGES IN THIS VERSION:
Medium security fix: A Cross-site Scripting (XSS) vulnerability was discovered where a malicious user could potentially exploit it by inserting HTML tags and/or JavaScript event attributes in a very specific way as user-defined text in various places. (Ticket #125900)
Minor security fix: A Cross-site Scripting (XSS) vulnerability was discovered where a malicious user could potentially exploit it on the Data Quality page and Data Comparison Tool page by inserting HTML tags and/or JavaScript event attributes into the name of a record. (Ticket #125952)
Bug fix: Several actions on the Multi-Language Management setup page were mistakenly not getting logged on the Logging page. (Ticket #125513)
Bug fix: When using Multi-Language Management, the piping of choices in a drop-down field works inside the same instrument but mistakenly does cross-pipe into different instruments in the same project. (Ticket #125546)
Bug fix: When using Multi-Language Management, the text for the "Duplicate Value" warning popup was mistakenly not available to be translated. (Ticket #125557)
Bug fix: When using Twilio telephony services for surveys, U.S. phone numbers having the area code "534" would mistakenly not work for SMS or voice calls unless the number has a "1" prepended to it. (Ticket #125591)
Bug fix: The API documentation for the "Delete User" method mistakenly had "dags" as a parameter when instead it should have said "users" as the parameter name. (Ticket #125497)
Bug fix: For full compatibility with all stats packages during a data export, the syntax file for data exports that contain a field with a blank field label will have the field variable name used in place of the field label. (Ticket #125436)
Bug fix: If the Secondary Unique Field is enabled and also has the @HIDDEN action tag, the AJAX call to check the uniqueness of its value might mistakenly get triggered if the field is the first field on a data entry form. (Ticket #125020)
Bug fix: If Twilio is enabled at the system-level, the phone number fields would mistakenly not be displayed on a user's Profile page unless Two-Factor authentication was enabled on the system. Even when not using Two-Factor, it will now display the phone number fields on the Profile page when Twilio is enabled in order to allow users to use their account-associated phone numbers for outgoing Alerts & Notifications via Twilio. (Ticket #124440)
Bug fix: An HTTP 500 error might occur in some cases when using PHP 8.1 if the database connection fails to the REDCap database server. This requires a replacement of the non-versioned file “redcap_connect.php”.
Bug fix: When a user clicks the "Erase all data" button or if deleting all records while moving the project to production, the log entries listed on the Email Logging page would mistakenly not be deleted during this process. It now properly deletes all items on the Email Logging page in both of these cases. (Ticket #125656)
Bug fix: Some contexts that employ a user rights check might mistakenly throw a fatal PHP error in some specific cases when using PHP 8.0 or 8.1. (Ticket #125914, #125923)
Bug fix: If a user selects a record from the drop-down list on the Logging page to filter by record, it might mistakenly display non-record related events on the page, such as events related to creating/editing/deleting user roles in the project. (Ticket #124825)
Bug fix: If a calc or @CALCTEXT field on a non-repeating instrument has a cross-form calculation that utilizes a calc/@CALCTEXT field from a repeating instrument, the calc/@CALCTEXT field on the non-repeating instrument would mistakenly not get triggered or calculated when performing manual data entry on a survey page or data entry form, although it would get calculated correctly when running Data Quality rule H. (Ticket #125456)
Version 12.0.22 (released on 2022-04-08)
CHANGES IN THIS VERSION:
Major bug fix: Some contexts that employ a user rights check might mistakenly throw a fatal PHP error in some specific cases when using PHP 8.0 or 8.1. (Ticket #125951)
Version 12.0.23 (released on 2022-04-15)
CHANGES IN THIS VERSION:
Bug fix: If using the Multi-Language Management feature, changing the language on the page would mistakenly not alter the URL of embedded video in a descriptive text field if a translated/alternative version of the video URL was provided for a language in the project. (Ticket #125502)
Bug fix: When the Survey Queue is enabled in a project, a fatal PHP error might occur in some specific cases when using PHP 8.0 or 8.1 while exporting the Project XML file or while performing other Survey Queue related activities. (Ticket #126079)
Bug fix: When a project’s language is set to be different from the system language, the popup dialogs in a project that display documentation for piping, field embedding, and special functions would mistakenly always be shown in the system language. (Ticket #126117)
Bug fix: Using the action tag @READONLY (including @READONLY-SURVEY and @READONLY-FORM) on a Notes field that also has the action tag @RICHTEXT would mistakenly cause the Notes field not to be disabled/readonly but would still be editable. Going forward, any of the @READONLY action tags will negate @RICHTEXT on a field. (Ticket #126097)
Bug fix: If a user assigned to a Data Access Group attempts to view a data entry form for a record not assigned to their DAG (e.g., by manipulating the URL in order to navigate to the record), it would mistakenly not display the "Record X belongs to another Data Access Group" error message and would display mostly a blank page due to a JavaScript error.
Bug fix: When using the Mailgun service for sending outgoing emails while utilizing the “Universal FROM Email Address” setting, the Reply-To header would mistakenly fail to be set correctly for all outgoing emails. (Ticket #126173)
Bug fix: If a user had downloaded an Adaptive or Auto-Scoring instrument from the REDCap Shared Library, they would mistakenly be allowed to translate the instrument via the Multi-Language Management setup page. Since Adaptive or Auto-Scoring instruments are validated, they should not be able to be translated because such would cause them to no longer be validated. So all Adaptive or Auto-Scoring instruments will be disabled on the MLM setup page, thus preventing users from translating them.
Bug fix: If a user has downloaded an instrument from the REDCap Shared Library, whether it was a curated instrument or not, it now displays a warning when attempting to translate the instrument on the Multi-Language Management setup page that the user should first check to see if the instrument is validated. And if so, they should not translate the instrument because such might cause it to no longer be validated.
Bug fix: When using Multi-Language Management, the survey termination option "Redirect to a URL" would mistakenly not use the translated URL. (Ticket #126255)
Bug fix: When creating a project via Project XML import, the process might crash with a fatal PHP error if using PHP 8.0 or 8.1. (Ticket #126268)
Bug fix: When using Multi-Language Management, if a form or survey page is submitted while leaving some required fields without values, a JavaScript error would mistakenly be thrown after the page reloads, which might cause certain things not to function correctly on the page. (Ticket #126225)
Bug fix: Fields with a @READONLY or @READONLY-X action tag would mistakenly not be disabled on the page if the fields were embedded. (Ticket #126276)
Bug fix: The @IF action tag will mistakenly not evaluate correctly on a survey page or data entry form if the record does not yet exist (e.g., when viewing the first page of a public survey).
Bug fix: The @IF action tag might mistakenly not get parsed correctly in certain instances when using Multi-Language Management.
Bug fix: When using Multi-Language Management, the UI text displayed below a field when using the @CHARLIMIT or @WORDLIMIT action tags would mistakenly not be translatable on the MLM setup page.
Bug fix: On the Survey Settings page, if the option "Send Confirmation Email" is enabled along with the option "Include PDF of completed survey as attachment" while using Multi-Language Management, the PDF of the survey response attached to the confirmation email would mistakenly always be in the default language when instead it should be in the language in which the respondent took the survey. (Ticket #126341)
Bug fix: When a user assigned to a Data Access Group is performing a data import for a project with Record Auto-Numbering enabled, in which the import setting "Yes, rename all records" has been set for the data import, the import process will mistakenly time out and never fully complete. (Ticket #126160)
Version 12.0.24 (released on 2022-04-22)
CHANGES IN THIS VERSION:
Major bug fix: A field's question text on a survey page might mistakenly not get recognized by certain screen reading software. Bug emerged in REDCap 12.2.2 Standard and REDCap 12.0.14 LTS. (Ticket #122843)
Bug fix: The Record Status Dashboard page might crash with a fatal PHP error in specific cases when using PHP 8.0 or 8.1. (Ticket #126395)
Bug fix: When a checkbox is set as an Identifier field and is referenced in the body of an alert, which is set to remove all identifiers from the alert body when sent, it might throw a fatal PHP error in PHP 8.0+.
Bug fix: When using Twilio telephony services for surveys, U.S. phone numbers having the area code "346" would mistakenly not work for SMS or voice calls unless the number has a "1" prepended to it. (Ticket #126590)
Bug fix: When using Twilio telephony services for surveys, U.S. phone numbers having the area codes "220", "223", "458" would mistakenly not work for SMS or voice calls unless the number has a "1" prepended to it. (Ticket #126741)
Bug fix: Clicking certain hyperlinks on a survey page might mistakenly add the green highlighted background to the field if the link exists inside a field that is a container for embedded fields. (Ticket #105242b)
Bug fix: If a line-chart or scatter-plot Smart Variable contains a third field used for categorization, the plot might mistakenly not display but would appear blank if some choices for the categorization field are not all presented in the plot's data.
Bug fix: When importing data in JSON format (including via the REDCap::saveData method), if a single record is represented in the imported data as multiple items/rows (i.e., when importing longitudinal events or repeating instances), if one of the rows for a record contained a leading or trailing space in the record name while other items/rows for that same record did not, the spaces would mistakenly not get trimmed off of the record name but instead would cause the record to end up in a split state in the project, in which it would appear ultimately as separate records. (Ticket #126035)
Version 12.0.25 (released on 2022-04-29)
CHANGES IN THIS VERSION:
Bug fix: The HTML tag "code" was mistakenly not included in the ALLOWED_TAGS list of HTML tags that are allowed to be used in user input (e.g., field labels, survey instructions).
Bug fix: When using the survey setting “Redirect to a URL” together with Multi-Language Management, the resulting URL would not be correct or would be malformed, thus preventing the redirection from working successfully. (Ticket #126791)
Bug fix: When uploading and then downloading a file for a File Upload field on the first page of a public survey, in which a record named record "1" already exists in the project prior to loading this survey, an erroneous message would be displayed along with some JavaScript errors on the page. (Ticket #125758)
Bug fix: When using the export->import process for Multi-Language Management via a JSON/CSV file, there might be issues with successfully importing Alerts and Automated Survey Invitations in the file.
Bug fix: If a drop-down field has the "auto-complete" setting enabled, in which the drop-down contains more than 200 choices, then when viewing drop-down on a survey page or data entry form, clicking the drop-down's down-arrow would mistakenly not open the full list of choices for the drop-down. (Ticket #125257)
Bug fix: Calculated fields containing form status fields (i.e. form+"_complete") mistakenly do not fire when on a survey page. (Ticket #127009)
Bug fix: When importing data for a field that has the @FORCE-MINMAX action tag and also has a minimum or maximum range check value as "now", "today", or a piped variable name, out-of-range values in the data import file would mistakenly not be flagged as errors during the import process and would be saved. (Ticket #126862)
Bug fix: When using Multi-Language Management, the choice text for Yes/No and True/False fields in the MLM “User Interface” section would mistakenly not get changed to the translated text when switching languages on a survey page or data entry form. (Ticket #127022)
Bug fix: When a user requests that their project be moved to production, after the administrator approves their request, the user would mistakenly not receive a confirmation email of this approval if the "Enable email notifications for administrators" checkbox is left unchecked on the "To-Do List" page in the Control Center. (Ticket #127040)
Version 12.0.26 (released on 2022-05-06)
CHANGES IN THIS VERSION:
Minor security fix: An SQL Injection vulnerability was found when submitting the Create Project page, in which a malicious user could potentially exploit it by manipulating an HTTP request on that page.
Bug fix: If an embedded date or datetime field has a @READONLY action tag, the field's Today/Now button and its clickable datepicker icon would mistakenly remain active and allow users/participants to modify the field's value.
Bug fix: If a field being piped into an outgoing email has the @RICHTEXT action tag, the resulting email body would mistakenly not look correct, such as containing too many line breaks or malformed tables. (Ticket #127174)
Bug fix: Some REDCap installations somehow missed the upgrade script from REDCap 9.7 that enabled the "redcap.link" URL shortener. It will now be enabled if not.
Bug fix: When using Twilio telephony services for surveys, U.S. phone numbers having the area code "332" would mistakenly not work for SMS or voice calls unless the number has a "1" prepended to it.
Bug fix: The Publication Matching feature in the Control Center might mistakenly fail with a fatal PHP error when using PHP 8. (Ticket #127359)
Bug fix: If a drop-down or radio button field on a survey has the @DEFAULT action tag, when the page initially loads, it would mistakenly scroll all the way down to the field with the @DEFAULT action tag (thus skipping the fields above it) if the participant was taking the survey on a mobile device. (Ticket #127406)
Bug fix: Fixed an issue pertaining to changes made to Multi-Language Management translations while projects are in draft mode, especially affecting Automated Survey Invitation translations, in which the submitted changes would mistakenly not save successfully.
Bug fix: If the conditional logic for an Automated Survey Invitation in a longitudinal project was mistakenly missing prepended event names for any field variables in the logic, the ASI might mistakenly not get triggered appropriately. (Ticket #127385)
Version 12.0.27 (released on 2022-05-12)
CHANGES IN THIS VERSION:
Bug fix: Fix for an issue in the External Modules Framework that was mistakenly converting all HTML entities in some text and causing JavaScript errors when utilizing a specific EM method that might be used by an EM. (Ticket #126891)
Bug fix: Field labels containing HTML character codes (e.g., ä) would mistakenly not be displayed correctly on the X or Y axis of a [line-chart] or [scatter-plot] Smart Chart. (Ticket #127516)
On the "Modules/Services Configuration" page in the Control Center, the setting to globally disable the "Stats & Charts" page in every project was mistakenly still referring to the page by its old name "Graphical Data View & Stats", which was confusing for admins. (Ticket #127597)
Bug fix: CDIS-related fixes
Several missing LOINC codes were added to the CDP and CDM mapping.
The field “Address (district/county)” in CDM was mistakenly missing as a field in CDM projects.
The deceasedBoolean value in CDM was mistakenly not being saved if False.
Bug fix: If the value of the "report_id" parameter that is passed to the Export Reports API method does not belong to the current project whose API token is being used, if the user who owns the API token has access to the project to which the report_id belongs, the API would mistakenly not return an error but would instead return a list of record names from the other project. Note: No other data from the other project would be returned other than the record names.
Bug fix: When running PHP 8.0+, the Stats & Charts page might fail with a fatal PHP error if number/integer fields somehow contain non-numeric values. (Ticket #122604b)
Bug fix: When Multi-Language Management is disabled in a project, the process of a user's production draft mode changes being approved would inadvertently cause an MLM snapshot to be saved. (Ticket #127650)
Bug fix: If the system-level setting "Enable the Graphical Data View & Stats" has been disabled and then a user is granted access to a project, the user might mistakenly be able to access parts of the "Data Reports, Exports and Stats" page, even when they do not have any data export or reports privileges. (Ticket #127597)
Bug fix: The Record Home Page in a longitudinal project would mistakenly display the column for an event that has no instruments designated for it. It should instead hide the column on the page rather than displaying it as empty. (Ticket #127708)
Bug fix: When branching logic contains certain Smart Variables, especially [aggregate-X] Smart Variables, it would throw a branching logic error on the survey page or data entry form. (Ticket #127741)
Bug fix: When a user calls the API method "Export PDF file of instruments" in a longitudinal project, in which the "event" parameter is either blank or is not provided in the API request, it would return a PDF that mistakenly only contains the first event's data, when instead it should return a PDF with data for all events. (Ticket #127820)
Version 12.0.28 (released on 2022-05-20)
CHANGES IN THIS VERSION:
Bug fix: The Instant Adjudication process for the Clinical Data Pull feature would mistakenly not pull a value from the EHR system when there exists a perfect timestamp match for a data value whose field has been mapped using the Near, Earliest, or Latest preselection strategies.
Bug fix: The install page would mistakenly crash with a fatal PHP error if using PHP 8 when the database credentials in database.php are either not correct or they cannot successfully connect to the database.
Bug fix: When using the same field two or three times (i.e., from different arms) as a Survey Login field, clicking the "Show value" checkbox in the Survey Login dialog would mistakenly cause the field to duplicate itself inside the dialog.
Bug fix: If duplicate instances of the same cron job somehow exist in the redcap_crons database table, which should not happen, REDCap will now detect this issue automatically and remove the duplicate jobs from the table.
Bug fix: If the Smart Variables [form-link] and [form-url] have a literal instance number appended to them (e.g., [form-link:meds][3]), they would mistakenly not get parsed correctly and would always produce a link/URL that points to the first repeating instance. (Ticket #127042)
Bug fix: When using Multi-Language Management, @CALCTEXT and @CALCDATE fields would fail to have their values piped immediately on the page after a language switch. Additionally, when only a single language (out of multiple languages) was active on a survey, the language switch might actually fail to work.
Bug fix: If a participant clicks the “Start Over” button on a partially completed survey that happens to be a repeating instrument or on a repeating event, the Logging page would mistakenly not explicitly state the repeating instance number to which the survey response belonged, thus making it appear as if it references instance #1 always. (Ticket #128018)
Bug fix: When uploading a data dictionary that has calculations or branching logic that contain Smart Variables with a comma inside them (e.g., [aggregate-sum:age,age2], it would recommend stripping out the comma during the upload process, which would not be desirable.
Bug fix: When using CDIS services (CDP or CPM), the FHIR services might mistakenly not function successfully if the EHR endpoint contains custom port numbers in their URL (e.g., https://example.com:8888/FHIR/DSTU2/).
Bug fix: If a Project Bookmark is set to only be displayed for users in specific Data Access Groups, the bookmark would mistakenly fail to display for aa REDCap administrator that is using the "View Project As User" feature to impersonate a user assigned to one of those DAGs. However, the bookmark would display correctly for the DAG-assigned users themselves. (Ticket #128093)
Bug fix: The Survey Settings feature "Save a PDF of completed survey response to a File Upload field" would mistakenly fail to function if enabled for an Adaptive or Auto-Scoring survey that has been imported from the REDCap Shared Library. (Ticket #128156)
Bug fix: In the API Playground, the Export Metadata API method would mistakenly display the Form Complete Status fields in the field drop-down list on the page. It should not display those fields in the drop-down because those fields are never included in the data dictionary, thus they would never return anything from this API method. (Ticket #127974)
Bug fix: Fixed rare issue where the fast refreshing of the main Control Center page would mistakenly display an issue where "redcap_ztemp_X" database tables exist and need to be deleted. (Ticket #128055)
Version 12.0.29 (released on 2022-05-26)
CHANGES IN THIS VERSION:
Bug fix: The datediff() function might not work as expected when using different data types in the parameters (e.g., date and datetime together) for PHP-based implementations of the logic evaluation process, such as the Survey Queue, ASI conditional logic, Data Quality rule logic, etc. (Ticket #128299)
Bug fix: If a survey that is a repeating instrument is displayed in the survey queue, if over 8 instances of the survey have been completed and the survey is to allow participants to return via Save & Return Later in order to modify completed responses, it would mistakenly display all 8+ survey instances as visible in the survey queue when instead it should display them as being collapsed on the page. (Ticket #128362)
Bug fix: If a Descriptive Text field has an inline image attachment, in which the image's file extension does not match its true mime type (i.e., someone has renamed its file extension to something incorrect prior to uploading the image), it would mistakenly cause the PDF export to run a long time and eventually time out when attempting to export a PDF of the instrument. (Ticket #128336)
Bug fix: If using the [survey-link] Smart Variable with Custom Text and with an instance Smart Variable appended to the end (e.g., [survey-link:medications:Take this survey][last-instance]), the custom text would not display correctly but would include the unique instrument name at the beginning of the custom text by mistake.
Bug fix: When granting a user access to a project via the User Rights page, the new user's data export rights in the popup would mistakenly default to "Full Data Set" for all instruments when instead they should default to "De-Identified" if in development status and to "No Access" if in production status. (Ticket #128504)
Bug fix: The ":ampm" piping parameter would mistakenly not work for datetime fields that have DMY date format. (Ticket #128507)
Bug fix: Data Quality rule D "Field validation errors (out of range)" would mistakenly not process the min and max values for the out-of-range check correctly if a field's min/max was set as "today", "now", or as a piped variable (e.g., [other_date]).
Version 12.0.30 (released on 2022-06-10)
CHANGES IN THIS VERSION:
Minor security fix: Updated the third-party package Guzzle to remediate the package’s cross-domain cookie leakage. (Ticket #128703)
Bug fix: Piping would not work successfully in real-time for Dynamic SQL fields on a survey or data entry form when the displayed language is changed on the page via Multi-Language Management. (Ticket #128562)
Bug fix: Added 2 missing LOINC codes for the "social history" observation category in CDIS.
Bug fix: Slider fields would mistakenly not be active and functional when viewed in the Online Designer. (Ticket #128916)
Bug fix: Project-level external module settings would mistakenly not get deleted from the "redcap_external_module_settings" database table after a project has been permanently deleted. (Ticket #128909)
Bug fix: The Record Home Page in a longitudinal project would mistakenly display the column for an event when the current user has no access to any instruments that are designated for that event. It should instead hide the column on the page rather than displaying it as empty. (Ticket #127708b)
Bug fix: All rich text editors would mistakenly strip out any Font Awesome icons that were added to the source code HTML of the rich text editor.
Bug fix: When using Multi-Language Management, a piped label might fail to display its translated language when on a PROMIS instrument (adaptive, auto-scoring, or battery) that was downloaded from the REDCap Shared Library.
Bug fix: The Moment.js library was updated since it was out of date.
Bug fix: The Multi-Language Management setup page might mistakenly not load due to a JavaScript error in some very specific situations.
Bug fix: Prepending [previous-event-name] or [next-event-name] to the Smart Variables [survey-time-X] and [survey-date-X] might mistakenly not return a value (e.g., [previous-event-name][survey-time-completed:followup_survey]). (Ticket #128662)
Version 12.0.31 (released on 2022-06-17)
CHANGES IN THIS VERSION:
Major bug fix: A change in the code for the Multi-Language Management setup page in the previous REDCap version might mistakenly cause certain tabs on the page not to get updated when saved.
Bug fix: If a hook, plugin, or external module is calling the REDCap::saveData() method, in which parameters are passed to the method all in a single array (i.e., $params=[...]; REDCap::saveData($params)), the "dataAccessGroup" parameter's value would mistakenly be ignored if included in the parameter array. (Ticket #129203)
Bug fix: The data entry form page or Online Designer might mistakenly crash with a fatal PHP error in certain situations when using PHP 8.0+. (Ticket #129297)
Bug fix: Documentation of the datediff() function was mistakenly inferring that the "returnSignedValue" function parameter could be provided in all caps (e.g., TRUE). However, its value must always be lower case (e.g., true). The documentation has been changed to reflect this to reduce confusion. (Ticket #129332)
Bug fix: When using Twilio to send invitations via Automated Survey Invitations that utilize the "Participant's Preference" as the invitation type, if the ASI belongs to a survey that is a repeating instrument, it is possible that the participant's preferred invitation type might get stored incorrectly in the backend database, thus potentially causing some invitations to be sent to the participant using the wrong invitation type (e.g., sent via Email instead of via SMS). (Ticket #128878)
Bug fix: The API method "Export Logging" would mistakenly not return the extra text for the "Reason for Data Changes(s)" if the setting "Require a 'reason' when making changes to existing records" is enabled in the project.
Bug fix: The "Survey Link Lookup" link would mistakenly still be displayed on the Control Center left-hand menu even if all survey functionality was disabled globally in the system via the "Enable the use of surveys in projects?" setting on the Modules/Services Configuration page.
Version 12.0.32 (released on 2022-06-24)
CHANGES IN THIS VERSION:
Bug fix: When using Send-It to send a file from the File Repository or a file associated with a File Upload field on a record, although the email being sent would get captured in the backend email log, the email details would mistakenly not get captured in the project-level Email Logging page. (Ticket #129554)
Bug fix: When a record's Survey Queue contains more than five completed surveys, in which case it will hide all the completed surveys in the queue to conserve space on the page, the queue would mistakenly display the text "X surveys completed!" where X is mistakenly the total number of surveys in the queue and not the total number of completed surveys in the queue. (Ticket #128732)
Bug fix: On the System Statistics page, the stats for the number of data values pulled for both the Clinical Data Mart and Clinical Data Pull were not being calculated correctly and might have been previously reporting much lower numbers by mistake.
Version 12.0.33 (released on 2022-06-27)
CHANGES IN THIS VERSION:
Bug fix: If a project is using randomization with strata fields, in which the randomization field and/or strata fields exist on a survey that has "Save & Return Later" enabled, if a participant completes part of the survey for a record that has already been randomized, then returns later to the survey but forgets their return code, then clicks the "Start Over" button on the survey, the randomization field and/or strata fields on the survey would mistakenly have their values erased. All the other field values on the survey should be erased, but the randomization field and strata field data should never get erased for records that are already randomized. (Ticket #129892)