Redcap Version 15 Vanderbilt to Release Oct. 6, 2015 hsph upgrade Oct. 23, 2015 new features and improvements: redcap Mobile App for ios and Android



Download 214.23 Kb.
Page3/4
Date30.06.2017
Size214.23 Kb.
#22175
1   2   3   4

  • Bug fix: When using the "user" drop-down filter on the Field Comment Log page in a project, it would mistakenly not filter properly by user if the user's username for their user account was in a different case than how their username appears in the drop-down list.

  • Bug fix: In a longitudinal project when using cross-event logic in report filters, Data Quality rules, Survey Queue logic, Automated Survey Invitations, etc., the logic might mistakenly not get evaluated correctly. This occurs on certain occasions where all the fields used in the logic do not have a value (i.e., they are blank) for a certain event for a given record, even though that particular event has had some data entered (i.e., data entered for other fields not used in the logic). This would cause it to think that that event has no data and thus prevent the logic from getting evaluated correctly.

  • Bug fix: When exporting data to SAS, the SAS syntax file produced will no longer remove apostrophes contained in the option labels of multiple choice fields but instead will escape them as a double apostrophe. This allows for a more proper viewing of the option labels in SAS.

  • Bug fix: If using cross-event logic for a calculated field in a longitudinal project that contains more than one arm, the auto-calculations that get triggered each time a form/survey is saved or when a data import is performed would mistakenly cause that record to get created in the other arm that is referenced in the cross-event calculation if the record does not already exist in the other arm.

  • Change: Choices for multiple choice fields are now allowed to have a blank option label. In previous versions, choices with no option label would be automatically removed unless " " was used as the option label.

  • Bug fix: When saving a Signature field or uploading a file for a File Upload field for an existing record in a project, it was mistakenly not displaying the document ID number (corresponding to the primary key of a database table) on the Logging page as the value of that field. This was inconsistent with how it was displayed on the Logging page when saving a Signature field or uploading a file for a File Upload field for record that was being created.

  • Bug fix: The "Close survey" button that is displayed at the top of a completed survey was mistakenly not closing the tab/window in certain web browsers. Note: There are some cases where the window/tab simply cannot be closed if the window was opened with the survey as the first tab in the window (due to restrictions by the web browser itself), in which case it will instead revert to displaying a blank web page instead.

  • Major bug fix (post-release patch): If a user is sending a survey invitation to a participant by using the Compose Survey Invitation option at the top of a data entry form, in which they choose to enter a new email address rather than using the email address that originates from either the Participant List or the Designated Survey Email Field, then it will mistakenly not send the invitation to the new email address specified but instead to the one from the Participant List or the Designated Survey Email Field.

  • Major bug fix: The advanced functions sum(), median(), and stdev() would mistakenly return a "0" value (instead of a blank/null value) from an auto-calculation after saving a calculated field using those functions where all the field values that were passed into those functions were blank/missing values.

  • Bug fix: The Data Dictionary Codebook page would mistakenly display stop actions for choices on multiple choice survey fields even if those choices had been deleted.

  • Change: Added a couple new paragraphs of helpful text on the Plugin FAQ page on the Plugin & Hook Documentation page.

  • Bug fix: When a calculated field in a longitudinal project is utilizing a Cross-Form or Cross-Event calculation, then if the user clicks the "Save and go to Next Form" button on the data entry page, it might on certain occasions mistakenly take them to another event for that record when instead it should take them to the next instrument in the same event.

  • Bug fix: If an M-D-Y or D-M-Y formatted date or date/time field is set as the Secondary Unique Field in a project, then the check to prevent unique values for that field would fail whenever a duplicate value was entered on a survey or data entry form.

  • Bug fix: If a field has been given the validation "Number (X decimal place - comma as decimal)" with either a minimum or maximum range value defined, then it would mistakenly always display the range check error on a survey or data entry form whenever a valid value was entered into that field.

  • Bug fix: If a Text field has field validation with either a minimum or maximum range value defined, then if a user is in the Online Designer and changes the validation to another validation type that cannot utilize the min/max range check (thus hiding the min/max input fields in the popup), then it would mistakenly retain the min/max values and save them, which could cause the "out of range" error to popup mistakenly during data entry.

  • Improvement: When uploading a data dictionary that contains a field with a minimum and/or maximum validation value, it now checks to make sure that the min/max value is in the correct format for that field's particular validation type. Previous versions did not check the format of the min/max values.

    • Major bug fix: At the top of data entry forms, it would mistakenly display the two PDF export choices for downloading PDFs containing data even if the user had "No Access" data export privileges. This would mistakenly allow the user to export data in a PDF file even though they do not have privileges to be exporting data. It now does not allow them to export data in PDFs unless the user has data export privileges of some kind, and it also no longer displays those two options at the top of the page to download PDFs containing data. In spite of this, users will still be able to download blank PDFs (i.e. with no data).

    • Bug fix: When a user is downloading a PDF file (either blank or containing data) at the top of a data entry form, it would mistakenly remove any data collection instruments from the PDF that the user does not have access to on the web interface (i.e. if they do not have instrument-level privileges to an instrument). Since instrument-level privileges only apply to viewing web pages in the web interface, it should not have been removing any instruments from an export file, such as PDF files. Thus, in order to be consistent with how user rights are implemented throughout the rest of REDCap, users will no longer have any instruments removed from the PDF exports due to their instrument-level privileges.

    • Bug fix: When a user is downloading a PDF containing data at the top of a data entry form when the user's data export privileges is "De-Identified" or "Remove all tagged Identifier fields", it would mistakenly hash the record ID value in the PDF for the first field in the first instrument. It would, however, not do this when displaying the record ID value in the top right corner of the PDF. This bug is only seen when the first instrument is included in the PDF.

    • Bug fix: In a project with Double Data Entry enabled, calculated fields would mistakenly get displayed on the page where values are merged from the two records. It now no longer displays calc fields on the merge page, and it now also performs an auto-calculation after the merge takes place in order for all calc field values to be correct for the newly created record.

    • Bug fix: In a project with Double Data Entry enabled, if the user was merging two records on the Data Comparison Tool page, in which one of the fields was a Text field whose value contained an apostrophe, then when the user chose the value from the first or second value, it would throw a JavaScript error and thus would mistakenly not merge that value into the newly created record.

    • Bug fix: When using the designated survey email field in a project in which an email address was first entered into the Participant List and then a different email address was entered for the designated survey email field for that same record, then the Participant List would mistakenly display the original email address entered into the list when instead it should have displayed the email address from designated survey email field's value.

    • Bug fix: If a multi-page survey is being administered in a longitudinal project, in which *all* fields on a given page in the survey contain branching logic that explicitly references fields on other events, then if any of those events referenced in the logic do not have any data saved for them yet for that record (i.e., those events do not show up in reports or exports for that record), then the branching logic might mistakenly return a FALSE value when it should evaluate as TRUE. The overall effect of this is that it could cause entire pages to be skipped in the survey mistakenly when viewing the survey in multi-page mode.

    • Bug fix: When a datediff() function is used inside the equation of a calculated field, in which a literal date or date/time value (as opposed to a variable name or "today" - e.g., "01-01-1970") exists as the first parameter, the second parameter, or both the first and second parameters in the function, then if the date format parameter is either "mdy" or "dmy", the auto-calculation that is performed when the record is saved will actually result in a different value than the one displayed on the form/survey prior to the save.

  • Major bug fix: If the advanced functions "isnumber" and "isinteger" were used in branching logic or a calculation for a calc field, it would mistakenly display an error on a survey or data entry form and thus not execute successfully.

  • Change: The Help & FAQ page was updated with minor changes.

  • Bug fix: If the Secondary Unique Field or Custom Record Label is enabled in a project, then they would not display correctly on a report in a classic project or in a longitudinal project that contained only one arm. Bug emerged in version 6.3.0.

  • Major bug fix: In certain specific situations where calculated fields are used, in which a user is importing data via Data Import Tool or API or is saving data on a survey or data entry form, the Auto-Calculation feature would mistakenly go into a very long loop (or sometimes an infinite loop) and would take many minutes to actually save all the data and finish.

  • Major bug fix: If a user was uploading a data dictionary with branching logic or a calculated field's equation that was malformated in a certain way, or if a user was attempting to add such logic/calculation to a field in the Online Designer, then it would mistakenly go into an infinite loop and never fully process the action. Bug emerged in version 6.3.0.

  • Bug fix: If a user downloads an instrument from the Shared Library and then later attempts to download another instrument that is similarly named for that same project, then on certain occasions REDCap will mistakenly go into an infinite loop and will not be able to successfully add that new instrument to the project.

  • Change: Some outdated language on the longitudinal event grid was updated.

  • Change: The form status icons that appear on the Record Status Dashboard, left-hand project menu, and longitudinal event grid now behave slightly differently for the gray status icons. The gray icons denote that no data has been entered on the data collection instrument, but due to the new auto-calculation feature in 6.3.0, calculated values can get stored on other forms even though a user has never navigated to that form. This could cause confusion if the icon is red when no one has ever entered the form. So now calc fields are excluded when determining if an icon should be gray. This allows the behavior of the colored icons to remain the same as it did in prior versions with regard to user experience and workflow.

  • Change: Changed the language and added a detailed explanation in the User Access section on the Create New Report page that more clearly explains how a report's user access controls work and how they are different from a user's user rights.

  • Change: The disclaimer text for calculated fields that was displayed on data entry forms, on the Online Designer, and on the Data Dictionary Upload page has been removed from those pages due to the introduction of newer features (e.g. the auto-calculation feature and Data Quality rule H) and is additionally due to a general ideological softening of extreme prejudice against calc fields by the REDCap development team.

  • Change: When new Table-based users have their account created, in which an account expiration date is set, in addition to listing the date/time of expiration in the email text, it now also specifies how many days from now that will be. This provides greater clarity of when the expiration will occur for some users.

  • Change: When a user receives an email letting them know that their REDCap account will expire soon, the following text has been added to the email to explain why their account will expire: "Your account has been set to expire because a REDCap administrator has chosen this date as the expiration date for your account."

  • Improvement/change: A "print page" button was added to the top of the User Access Dashboard page to allow users to print the page in order to review it offline.

  • Bug fix: When viewing a report containing over 1000 rows, in which it displays the "displaying record" drop-down to allow paging, then in some particular cases it would mistakenly not load the desired page of the report after being selected due to a JavaScript error.

  • Bug fix: Users whose username contains only numbers would mistakenly not be able to be assigned to Data Access Groups.

  • Bug fix: When clicking the Add Signature link or Upload Document link in order to capture a signature or upload a file on a form or survey, respectively, it would mistakenly not employ piping in the field's label when displaying it in the popup that appears.

  • Bug fix: When using a numerical field validation where a comma is used as the decimal character, the Add/Edit Field popup on the Online Designer would mistakenly not display the min and max text fields to allow one to enter range values for the field.

  • Bug fix: If a checkbox field has an option label that contains a double quote, then it would prevent that field from being displayed on the Stats & Charts page of a report and would thus cause all other charts below it not to display as well.

  • Bug fix: For a longitudinal project containing more than one arm, in which either the Custom Record Label or Secondary Unique Field is enabled, it would mistakenly only display the Custom Record Label and/or Secondary Unique Field that belongs to the first arm when viewing a report, and if the record did not exist in the first arm but did exist in another arm, then the label would not display at all in the report. It now displays the label that belongs to the current arm for the row of data being displayed in the report. Also, in this case, the Record Status Dashboard would mistakenly display the Custom Record Label and/or Secondary Unique Field for only one of the arms (often the last arm containing data for the label) even when the record existed on multiple arms. It now displays the label for every arm for a given record on the Record Status Dashboard.

  • Major bug fix: When a user is viewing a partially completed or fully completed survey response on a data entry form, it would mistakenly display the Save buttons at the top right of the page even if the user did not have "Edit survey response" user privileges. This would not allow the user to modify any responses on the form because all the fields would remain locked and read-only, but if they clicked one of those Save buttons, it would inadvertently cause some of the data values on that page to get erased.

  • Change/improvement: Small improvements to speed up the sending of survey invitations when sending large batches (i.e., thousands) of invitations all near the same time.

  • Bug fix: When uploading a file for a File Upload field on a data entry form on an iOS device, it would not upload successfully but instead return an error message. This would not occur on survey pages but only on forms.

  • Bug fix: When using the Real Time Execution aspect of a custom Data Quality rule in a longitudinal project, then when a rule violation occurs on a data entry form, in which one of the fields in the rule's logic occurs on that instrument but on a different event, it would mistakenly make the data value into a clickable link in the violation popup. And when that link is then clicked, it puts focus on that field on the current instrument, which can be confusing because it really refers to a different event. It now only makes the data value into a clickable link in the violation popup if the field exists on that instrument on that same event.

  • Major bug fix: When using the datediff() function inside branching logic, calc fields, Data Quality rules, Automated Survey Invitations, etc., it would not work correctly if "TODAY" was used in capitalized form inside quotes (single or double quotes) for either of the two date parameters in the function. It would work, however, if not surrounded by quotes (in either upper case or lower case) and also if lower case surrounded by quotes.

  • Major bug fix: When using the datediff() function inside branching logic, calc fields, Data Quality rules, Automated Survey Invitations, etc., it would not work correctly if "today" (in upper or lower case, either surrounded by quotes or not) was used as the second date parameter when the first date parameter in the function is today's date as a literal value (e.g., "2014-11-18").

  • Bug fix: On the "Stats & Charts" page, the descriptive stats for "counts/frequency" would mistakenly display as "0, 0.0%" for any choices of a multiple choice field where the choice's coded value was non-numeric.

  • Bug fix: When importing XML data in an API data import request when the XML data is not formatted correctly, it could sometimes throw a fatal PHP error, thus mistakenly returning a HTTP 500 or 200 error rather than a 400 error with an appropriate error message.

  • Bug fix: When creating or editing a report that contains an "SQL" type field as a filter in the report, it would mistakenly not display a drop-down of the SQL field's choices after choosing it as a filter but instead would just display a text box for entering the filter value. It now displays a drop-down with the field's choices.

  • Bug fix: When a user in a project has no access to any of the data collection instruments, it would still mistakenly display the "Add/Edit Records" link on the left-hand menu, and whenever they clicked that link, it would mistakenly take them outside the project to REDCap's Home page. It now no longer displays that link on the left-hand menu if they do not have access to any instruments.

  • Bug fix: If a user in a project has no access to the first data collection instrument, then it should display "View/Edit Records" for the link text on the left-hand menu, but instead it mistakenly displays the link text as "Add/Edit Records" if the user has "Record Create" rights but has no rights to the first instrument, which is the only place a record can be created in the web interface.

  • Bug fix: When sending a survey invitation from a data entry form using the "Survey options"->"Compose survey invitation" popup and manually providing an email address in the text box even though one or more existing email addresses are displayed as a drop-down choice in the popup, it would mistakenly not send the invitation to the email address that was manually entered but would instead send it to the email address originating from either the Participant List or (if applicable) designated survey invitation field.

  • Bug fix: When viewing the participant list of an initial survey (i.e., first instrument), the "Remove all participants" button was mistakenly removing participants who had already completed the survey (partially or in whole), which could incidentally cause some "ghost" participants to appear in the list afterward and cause confusion. It should only be removing participants that have not started the survey yet and thus do not have a corresponding record in the project.

  • Bug fix: If a project contains a field with the variable name "page", then if a user is viewing a survey response on the data entry form and clicks the "Edit response" button at the top, it will take them to a non-existent page (i.e. a 404 error).

  • Bug fix: If a user with "Full Data Set" data export privileges performs a data export on the "Data Exports, Reports, and Stats" page and checks the "Hash the Record ID field" checkbox option, it would mistakenly not hash the Record ID unless the Record ID field had been tagged as an Identifier field. In this case, it should always hash the Record ID if the checkbox is checked when the user has "Full Data Set" data export privileges.

  • Bug fix: When executing rules on the Data Quality page when the project contains data access groups, if a user excluded a particular discrepancy that was returned from one of the rules, it would mistakenly not deduct that excluded discrepancy from the DAG discrepancy counts when the rules were executed again (although the total discrepancy count would be accurate).

  • Bug fix: In very rare instances where Field Labels with special characters (e.g. non-Latin, UTF-8 encoded) are being displayed on certain pages, the Field Label's text might mistakenly not display on the page at all but appear as blank.

  • Major bug fix: When using Automated Survey Invitations to send survey invitations, if the ASI's "Conditions" section only uses the conditional logic option and does not use the "when the following survey is completed" option, then on certain occasions invitations might be mistakenly re-sent to respondents even though they had already completed that survey, which would result in a "survey has already been completed" message when the respondent clicks the survey link in the invitation.

  • Change: When uploading a file for a File Upload field on a survey or data entry form, it now auto-closes the popup after a couple seconds as a convenience. It does this also when deleting a file for a File Upload field.

  • Change: In reports, any headers (i.e. field labels) that are over 100 characters long will be truncated to prevent the header row from getting too tall.

  • Change: Small aesthetic changes to the look and behavior of the Compose Survey Invitations popup on the Participant List page.

  • Major bug fix: If a user has user privileges of either "De-identified" or "Remove all tagged Identifier fields" as their data export rights, then when using the "Export Records" API method, in which no fields are explicitly provided in the API request, then it will mistakenly not perform the de-identification process or remove Identifier fields as is dictated by their user rights. However, in this situation, if instead some fields are manually provided as an array in the API request, this issue does not occur.

  • Major bug fix: When a user with "De-identified" data export rights performs a data export on the "Data Exports, Reports, and Stats" page, it would mistakenly hash the Record ID in the resulting CSV data file, even though the Record ID field is not an Identifier field. It should only do this when the Record ID field is an Identifier.

  • Bug fix: If Automated Survey Invitations are enabled for surveys in a project, and a survey invitation has been scheduled to send but has not sent yet, then if a user clicks the "Save and Mark Response as Complete" button on the data entry form, it mistakenly does not prevent the scheduled survey invitation from sending later on, even though the survey has already been completed. So the respondent will mistakenly receive the invitation to their survey that has already been completed. If the survey is completed on the survey page itself (rather than on the data entry form), then this issue does not occur.

  • Bug fix: If the designated survey email field was enabled in a project that uses surveys, then it would mistakenly allow the user to edit the email address in the Participant List of an initial survey when the email address displayed in the list originated from the designated survey email field. In this case, the email address should only be modifiable on the data entry form to which it belongs.

  • Bug fix: When adding a new field on the Online Designer, if the "Descriptive" field type had been selected in the drop-down list in the "Add New Field" popup window, after which the user saved or canceled that popup, then before leaving the page if the user clicked the "Add Field" button immediately afterward to re-open the popup window, it would mistakenly display the Required, Identifier, Custom Alignment, and Field Note sections. In this case, it should instead be hiding those sections in the popup since they do not apply to Descriptive fields.

  • Major bug fix: If using the "Export Records" API method, it sometimes would not hash the record name in the exported data set when it should if the user whose API token is being used has "De-identified" or "Remove all tagged Identifier fields" user privileges. If the user has "De-identified" rights, it would mistakenly hash the record name in all cases every time, regardless of whether or not the record ID field is an Identifier field. Also, if the user has "Remove all tagged Identifier fields" rights, it would mistakenly never hash the record name, even when the record ID field is an Identifier field. It now correctly hashes the record name if the record ID field is an Identifier field AND if the user has either "De-identified" or "Remove all tagged Identifier fields" user privileges.

  • Major bug fix: The "simultaneous users" check that prevents two different users from viewing the same record/instrument/event in the same project would not successfully stop a user from viewing the data entry form if they had been assigned to a user role, but *prior* to being assigned to the role, the user had either No Access or Read-Only user privileges for that instrument. This issue would not occur if the user possessed Edit user privileges for that instrument prior to being assigned to the role.

  • Bug fix: If a project is using the Custom Record Label, but it has been set up incorrectly in which no variable names are including in the custom record label at all, then it could cause some pages to crash (e.g., data entry page, record status dashboard) if a large amount of records exist in the project.

  • Bug fix: When viewing the Participant List in a project containing surveys, in certain situations it would mistakenly allow the user to remove a participant from the list even when the record exists. It should only let users remove it if the record does not exist yet. Also, it would mistakenly allow users to edit a participant's email address even if the email was missing and thus displayed the text "[No email listed]". In this case, it should not allow anyone to edit the email address since it is assumed to be pulling the email address from the designated survey email field.

  • Bug fix: When adding/editing a report that contains hundreds of fields, especially when the project itself contains hundreds or thousands of fields, the page may load very slowly or may not load completely at all.

  • Bug fix: When viewing the Participant List in a project containing multiple surveys while utilizing the "designated email field for survey invitations" feature, it would mistakenly not allow the user to click the checkmark icon in the "Responded?" column in order to navigate to the record on the data entry form (assuming the response is either partially completed or fully completed). This issue only occurs for the first instrument in the Participant List.

  • Major bug fix: The Survey Login feature was mistakenly being case sensitive with regard to the respondent's login credentials entered on the survey when it should instead have been case insensitive.

  • Major bug fix: If Data Access Groups are being used in a classic project (excludes longitudinal projects) when a given DAG does not contain any records yet, if a user assigned to that DAG navigates to the Add/Edit Records page, then the user will mistakenly see a list of ALL records in the project from all DAGs rather than an empty drop-down list. If they attempt to view a record in the list that is not in their DAG, they will not be able to access or view any data from it, but it could be confusing as to why records from other DAGs have their record names displayed. This bug would only cause data access issues if the record ID field for the project is an identifier field (i.e. PHI), which is always discouraged.

  • Bug fix: Some computers/networks were forcing Internet Explorer to always use Compatibility Mode when viewing REDCap, which would cause some functionality not to work properly. REDCap now disables Compatibility Mode in Internet Explorer to prevent such issues.

  • Improvement: When a user exports an instrument as a PDF file, it now displays the current date/time at the bottom left of each page in the PDF representing when the file was downloaded.

  • Improvement: The text boxes for Text field types are now 50% wider as displayed on data entry forms and surveys to allow for more text to be seen.

  • Major bug fix: When creating a new record in the Scheduling module in a longitudinal project, it would mistakenly allow users to add records whose record name began or ended with spaces, which causes various issues in other modules. It now trims the record name (client-side and server-side) when scheduling a new record.

  • Bug fix: In certain cases, the form name and form label of an instrument can get inadvertently lost, which either causes the instrument to become invisible and inaccessible or it causes the form label to be replace with an "[X]". It now does a better job of recovering the form name or label if it somehow gets lost.

  • Bug fix: In the user/role list displayed on the User Rights page, it would sometimes mistakenly show a user as not being suspended when in fact their account had been suspended. This would occur due to case sensitivity mismatching of their username as recorded for their REDCap user account compared to their username when it was added to the project's User Rights page.

  • Bug fix: When using piping when doing the Post Pre-fill method to pre-fill survey questions (documented on the "How to pre-fill survey questions" section of the Help & FAQ page), the piping would mistakenly not work when the survey page loaded.

  • Bug fix: When adding a new field to a data collection instrument on the Online Designer when the project is in production status and in Draft Mode, if the new field is added as the first field in the instrument, it will mistakenly cause the instrument name (which is displayed on the left-hand project menu and in the Online Designer list) to get removed and thus end up as "[ ? ]" if that instrument does not exist in the project yet but only exists in Draft Mode.

  • Major bug fix: When a respondent returns to a survey to enter their Return Code, it might take an extremely long time before it would display their survey after entering a valid Return Code.

  • Bug fix: When viewing the Survey Invitation Log in a project containing surveys, in the "Invitation send time" column it might mistakenly display the time that the email was scheduled to send rather than the time the email actually got sent, in which these two times might be slightly different due to various valid reasons.

  • Bug fix: If a date or date/time field is chosen as the Secondary Unique Field in a project, it would mistakenly display the value of the Secondary Unique Field in Y-M-D date format on the page even if that field had been designated to display as M-D-Y or D-M-Y format. It now displays its value according to its designated date format.

  • Bug fix: When using a Custom Record Label and/or Secondary Unique Field in a longitudinal project, it would mistakenly not display those values for a given record in the record drop-down list in the mobile web view of the project. For classic projects, however, it would correctly display the Custom Record Label and/or Secondary Unique Field in the mobile web view.

  • Bug fix: If a date or datetime field is used as a filter in a report and the value of that filter field is left blank/empty, then it would not return the correct results in the report. And if the report were edited, the value of the date/time filter in the report would mistakenly appear as "0000-00-00", which might accidentally get saved when the report is re-saved.

  • Bug fix: If survey responses are collected using a Public Survey link and the designated email field is enabled but is left blank (thus no email address was entered for the person), then that survey will have an incorrect number of participants listed at the top of its Participant List, in which it is mistakenly including all the responses with no email addresses even though it is not displaying them on the page. This can cause confusion if the user tries to navigate to the last page of the Participant List (if there are many participants), in which the Participant List will show up as empty for those latter pages.

  • Bug fix: When importing XML-formatted data via the API data import, it would mistakenly truncate any text being imported if the text contained an ampersand (even if the ampersand was properly escaped in the XML). Note: This only occurs when the text is not put inside a CDATA block in the XML.

  • Bug fix: When creating a new record on a data entry form, the "download PDF" option to download "this data entry form with saved data" would mistakenly be displayed even though the record does not exist yet. And if the user clicked that option, it would result in a completely blank PDF file.

  • Bug fix: If the HTML character code for non-breaking spaces ( ) is included in the field label, field note, section header, or multiple choice label of a field, then a PDF export of the instrument containing that field will mistakenly display the HTMl character code as-is in the PDF rather than rendering it properly as a space in the PDF.

  • Change: Email addresses in the Participant List now order correctly as case insensitive natural ordering. In previous versions, they ordered as case sensitive natural ordering.

  • Bug fix: When using the Randomization module and performing the randomization of a record, if the "Randomize" button in the popup window is clicked rapidly several times, it might allow the request to be sent multiple times, which could cause issues.

  • Bug fix: If REDCap was in the process of being upgraded to a newer version, in which the new REDCap version directory had been moved to the web server prior to the upgrade SQL script being executed, then users making API requests might have their results returned from the API as a doubled response, where it would return the expected API response concatenated with itself.

  • Bug fix: When attempting to import data via the API Import Records method, in which one or more of the import fields is a Descriptive field, which cannot have data, it was mistakenly not returning an error message in this instance and would mistakenly add the data to the redcap_data table as orphaned data, although this does not affect anything ultimately. It now returns an error message and halts the import if a Descriptive field is included in the imported data.

  • Change: The Participant List for initial surveys now displays all responses that have been created - either partial or fully completed - including those initially created via a Public Survey link. In previous versions, those responses that were not created via the Participant List were not displayed for initial surveys, although they would appear in the Participant List of follow-up surveys (i.e., non-initial surveys). Tangential to this, only participants that have *not* begun the initial survey yet will have the "remove" link displayed for them in the Participant List, which means that if a response is either partial or complete, it will not be able to be deleted from the Participant List as it was in previous versions. This is to keep the behavior for initial surveys more consistent with behavior of other surveys in the project. Note: The email address for responses created via a Public Survey link will not to be editable in the Participant List because if there is an email address, it will be originating from the Designated Email Field, which is a data value.

  • Change: Merged all survey options at top of data entry forms into a single all-purpose drop-down

  • Change: Survey links generated for public surveys will now have a human-readable hash in the URL to make them more easily typed by hand for respondents. (This applies only to public survey links and not to survey links that are unique to participants.)

  • Major bug fix: If users have enabled the feature to display aggregate survey results to respondents after completing a survey, it would mistakenly display a drop-down list of records from the project on that page, which should only be visible on the "Stats & Charts" page in the "Data Exports, Reports, and Stats" page. And if a respondent selected an option from that drop-down, it would lead to a survey page displaying an error message. (Bug emerged in version 6.0.0.)

  • Change/improvement: Data that is piped from a Text or Notes field whose data values (i.e. text) contains HTML tags will now be displayed on the page as interpreted HTML rather than as the exact text (i.e. HTML-escaped text, which is how it was displayed in previous versions). This means that if "text" was the data value being piped on the page, it would display the word "text" as an underlined word rather than displaying it exactly as "text" with the HTML tags visible.

  • Change: Validation codes for the "Save & Return Later" functionality for surveys are now displayed in all capital letters now. This does not change anything because they have always been case insensitive, but this should make them easier to read by participants.

  • Change: When performing a data export for the Stata statistical software package, if the resulting CSV data file is UTF-8 encoded, then it would prepend a Byte Order Mark (BOM) to the beginning of the syntax file, which might cause it to have issues when loading it into Stata. Instead, it no longer prepends the BOM to the CSV data file for Stata.

  • Change: For any date/time fields used as filters in a report, it would mistakenly not display the date/time format text (e.g., M-D-Y) to the right of the filter value text box, thus making it difficult to know in what format the date/time value should be entered. It now displays the date/time format for such fields used as filters.

  • Bug fix: When a user is randomizing a record on the mobile web version of the data entry form, the randomization popup dialog will sometimes not display properly, which makes it impossible to see the whole dialog and may thus prevent the user from performing randomization.

  • Bug fix: If a user clicks on an attachment link for a Descriptive field on a data entry form after some data has been entered on the page, it would mistakenly display the "save your changes?" popup prompt before allowing the user to download the attachment. It now no longer displays the prompt when downloading an attachment for a Descriptive field.

  • Bug fix: When a user is using the Data Resolution Workflow module and is opening, responding to, or closing a query, after clicking the save button in the Data Resolution Workflow popup, the text of the button would mistakenly change back to its original value when the popup was first opened, which could be confusing to the user if they notice it.

  • Bug fix: If two or more users are modifying a project at the same time, in which they enable Draft Mode for the project at the same time or they submit drafted changes for approval at the same time, it now performs some extra checks so that those users do not overlap in their actions and accidentally end up having all their fields deleted.

  • Bug fix: In some rare cases, the section header of a Form Status field will for unknown reasons get mistakenly merged with another existing section header. If this occurs now, it will auto-fix itself and set the section header text back to "Form Status".

  • Bug fix: If an instrument had been locked for a given record and that instrument had been enabled as a survey, then if someone returned to the survey page for that record, they would mistakenly be allowed to modify and re-save the responses on the survey page, thus allowing a respondent to bypass the record locking feature completely.

  • Bug fix: When viewing a report that is sorted in descending order by the record ID field, in which the project has "record auto-numbering" enabled but the record ID has not been explicitly set with "number" or "integer" field validation, the report would mistakenly sort the records using string/text sorting methods rather than sorting it numerically, so the records would not appear sorted in the correct order.

  • Bug fix: When performing an API data export (using either "Export Records" or "Export Reports" method) in "xml" format, if a Text field or Notes field contained the text string "]]>", it would make the XML output invalid because "]]>" is never allowed inside a CDATA section in XML. In this case, it now replaces "]]>" with "]]]]>" so that it splits that text string into two CDATA sections (ending the first with "]]" and beginning the next with ">", thus avoiding the issue of producing invalid XML.

  • Bug fix: Typo in text on a project's Data Access Group page that mistakenly stated that user roles could be assigned to DAGs, which is incorrect.

    • Major bug fix: When exporting data via the "Export Records" API method in "eav" format for an "sql" type field, it would mistakenly return the value as blank even if it contained a value. This only affects "sql" type fields and does not affect it in "flat" export format.

    • Major bug fix: If a value existed for a field previously but was later removed (set to blank), after which a user imported data for that field via the Data Import Tool, it would mistakenly leave two rows in the redcap_data database table for that field (one row with a blank value and another with the new value) rather than simply updating the existing row with the new value. Currently, there does not appear to be any evidence that this causes any issues within the application with regard to the entering or exporting of data. (Note: This does not affect the API data import but only the Data Import Tool.)

    • Change: Data Export rights (from the User Rights page) are now applied to *all* modules where data can be downloaded. In previous versions, it would correctly prevent users from downloading data in all places if they had "No Access" data export rights, but if the user has De-Identified data export rights, it would not apply such rights within certain data exports, such as PDF exports and report exports. This was known behavior and was not considered a bug, but was regarded merely as the Data Export rights being applied inconsistently thoughout REDCap. It now fully applies such rights and thus employs data de-identification on *all* data downloads if the user has "De-Identified" rights or "Remove all tagged Identifier fields" rights.

    • Change: "De-Identified" data export rights are now applied in PDF exports, in which any data for Notes fields, unvalidated Text fields (free-form text), and date/time fields will have their data values removed and replaced with the text [*DATA REMOVED*].

    • Change/improvement: More detail is now provided for data exports on the Logging page, includes API data exports. In addition to displaying the fields that were exported, it will now also note if the export was a "raw" or "label" export, it will note the export format (e.g., SPSS, CSV, SAS), if the Data Access Group field was exported, if survey timestamps and the survey identifier field were exported, if "De-Identified" or "Removed Identifiers" user rights were applied to the export, and if it is a report being exported, it will list the report ID number.

    • Change/improvement: Slight reorganization of user privilege options on User Rights page (in comprehensive user grid and in popup) for better user experience.

    • Changes to the API:

  • Change: For the "Export Records" API method when using "flat" type output while exporting the data as labels (i.e., when rawOrLabel=label), it now no longer defaults to exporting checkbox field values as their choice label (i.e., "Choice 1") as it did in previous versions, but instead it returns "Checked" or "Unchecked" as the checkbox values by default. So if any users depend upon checkbox values being exported as their choice label, they should add the new parameter "exportCheckboxLabels" to their script as exportCheckboxLabels=true to maintain continuity after the upgrade to REDCap 6.0 or higher.

  • Change: Data Export user rights are now applied to API data exports. In previous versions, the data export rights had no effect on API data exports. Now if a user has No Access export rights, they will not be able to export data from the API (this includes the "Export Records" API method, the new "Export Reports" API method, and also the "Export a File" API method). And if the user has either "De-Identified" export rights or "Remove all tagged Identifier fields" export rights, then fields will be removed from the export data set accordingly in the API export request. If a user attempts to use the "Export a File" API method on a File Upload field that has been tagged as an Identifier when that user has either "De-Identified" export rights or "Remove all tagged Identifier fields" export rights, then it will return an error.

  • Change: For the "Export Records" API method, "both" will no longer be an option for the "rawOrLabel" parameter. The only valid options for rawOrLabel will be "raw" and "label". This is also true for the new "Export Reports" API method.

  • Change: "eventName" will no longer be used as a parameter in API data exports. In previous versions, users could manually set whether an API data export would return the event name for longitudinal projects as the event label text or instead as the unique event name (generated automatically from the event label). It now simply returns the event label text if rawOrLabel=label, whereas it will return the unique event name if rawOrLabel=raw (or if rawOrLabel is not provided). If "eventName" is provided in the API request, it will be ignored.

  • Change: When doing an API data export where a list of fields or forms are explicitly provided in the API request to REDCap, the record ID field will now only be included in the exported result if the record ID field is explicitly specified in the list of fields or if its form is explicitly specified in the list of forms. In previous versions, if *any* form or field was explicitly provided in the API request, it would return the record ID field. So for users who depend upon the Record ID field to be returned in the exported data set, they should go ahead and add the Record ID to the "fields" array parameter in their API request to maintain continuity after the upgrade to REDCap 6.0 or higher.

  • Bug fix: When exporting data via the Export Records API method with rawOrLabel="label" (instead of "raw") for Yes/No or True/False fields, it would mistakenly return the label in all lower case (instead of with the appropriate label where the first letter is capitalized - e.g. "yes" instead of "Yes").

  • Change/improvement: The "Add/Edit Records" link on the left-hand menu of a project now points to the first data collection instrument to which the user has access. In previous versions, it would always point to the project's first instrument, to which the user might not have access and would display an "access denied!" message to the user if they clicked the link, which could be confusing.

  • Change/improvement: If a user does not have "Create Records" privileges, then the link on the left-hand menu of a project will not display "Add/Edit Records" but instead will display "View/Edit Records" to better convey their privileges.

  • Change/improvement: When exporting data to SAS, the SAS syntax file produced will no longer remove apostrophes contained in the option labels of multiple choice fields but instead will escape them as a double apostrophe. This allows for a more proper viewing of the option labels in SAS.

  • Bug fix: On the User Access Dashboard, if a user clicks the "fetch" link for a project to view the users' last time accessing that project, it might mistakenly display "never" for a user even though that user has indeed accessed the project before. This would often occur when the user's username in the project list contained a capital letter.

  • Bug fix: If using a relatively new /redcap/api/index.php file, which would come in a relatively new installation of REDCap, then if a new REDCap version directory from an upgrade package was added to the main "redcap" folder on the web server, then all API requests would mistakenly point to the API files in the new version folder even though the upgrade process had not yet been completed. This would mean that during the window of time where the version folder was added and the upgrade was completed, the API requests would mistakenly be routing to the wrong version, which could cause issues if the API behavior changed in the newer version.

  • Bug fix: The plots on the Stats & Charts view of a report would mistakenly not get displayed on the page if the field contained a multiple choice option with a non-numerical coding.

  • Bug fix: In older versions of Internet Explorer, if an inline image was displayed in a Descriptive field that was initially hidden by branching logic, then if that field became visible at some point due to branching logic, the image would mistakenly stay hidden.

  • Bug fix: When automated survey invitations are triggered due to a respondent completing a survey or due to a user setting a data collection instrument with Complete status, it would appear on the Logging page that the survey invitation for the next survey was scheduled before the first one was completed. However, both events have the same timestamp, in which the "Automatically schedule survey invitation" event happens to be listed first on the Logging page, which can be confusing to users. It now lists the invitation scheduling event last and also sets its "username" attribute as "SYSTEM" since in previous versions it would say "[survey respondent]", which is really who triggered the invitation scheduling but is confusing because it may seem to imply the the respondent performed some kind of action to trigger it, which is not the case.

  • Bug fix: When using the "Export Arms" API method, in which the "arms" parameter is explicitly supplied in the API request, it would mistakenly ignore that parameter. Thus it would not export only the arms supplied in the "arms" parameter as it should, but it would instead export all the arms in the project.

  • Bug fix: When using the Copy Project functionality for a project containing surveys, in which one or more surveys had a logo (via the Survey Settings page), then some or none of the surveys would get copied over to the new project successfully, in which the instruments in the new project would appear to only be data collection forms and would not be enabled as surveys.

  • Bug fix: When viewing the Survey Notifications popup for all surveys in a project on the Online Designer page, it would mistakenly not display the surveys in their correct order.

  • Bug fix: When using the "designated email field for invitations to survey participants" in a project containing surveys that is also a longitudinal project, it would mistakenly not display the record name next to the participant's email address in the Participant List on certain occasions.

  • Bug fix: When using the Secondary Unique Field in a project, there is a remote possibility that a duplicate value could mistakenly be entered successfully by a user into the Secondary Unique Field on a data entry form and then save the form's data before the popup error message could be displayed regarding the duplicate value issue. This can only occur within a very small window of time, although the window of time increases based upon the slowness of the REDCap server. It now halts all processes on the data entry form and waits for the duplicate value check to complete before allowing the user to perform any other actions on the page.

  • Bug fix: When uploading a Data Dictionary, it would mistakenly allow users to import fields with a field type of "attachment", which is not a valid field type. It now displays an error message if a user attempts this.

  • Improvement: For longitudinal projects, the record name on the Record Status Dashboard is now a link to that record's event grid page.

  • Major bug fix: If a field in a project has branching logic that utilizes a field from another data collection instrument (but within the same event), then if the saved data value for the field used in the logic contains an apostrophe, then if a user saves the data on the instrument containing the field with branching logic, it will mistakenly truncate the other field's data to the location of the apostrophe

  • Change: When reviewing production changes made in Draft Mode, if the Record ID field has been moved and is thus no longer positioned as the first field in the project, then it will now consider it to be a critical issue if one or more records exist in the project. This will also be the case when REDCap is determining whether or not to auto-approve any production changes that are submitted by a user. Previous versions did not consider this to be a critical issue.

  • Bug fix: When viewing a partial or completed survey response on a data entry form in a longitudinal project, it was mistakenly not displaying the current event name at the top of the page when not in "edit response" mode, which could make it difficult to quickly determine which event you are currently viewing. It now always displays the event name at the top of the form for longitudinal projects.

  • Bug fix: In a longitudinal project that contains surveys, if the first data collection instrument is enabled as a survey and is designated for at least one event but not the first event, then the Manage Participants page would mistakenly provide an incorrect Public Survey Link that would not point to the first event but instead to another event. (The Public Survey Link must always point to the first event.) It now does not display the Public Survey Link in a longitudinal project unless the first instrument has been designated for the first event, and instead displays an error to the user on how to fix this issue.

  • Bug fix: For some large tables where the "Enable floating table headers" button appears (e.g., Record Status Dashboard, reports), the "Loading..." progress message would display forever and would never finish after clicking the "enable" button.

  • Bug fix: The "Graphical Data View & Stats" page would mistakenly not display the Total Count and Missing values for a field if they field contained no data for any records but instead would display the message "This field cannot be displayed because no data exists for it".

  • Bug fix: If using multiple fields within the Custom Record Label in a project in which some (but not all) of the fields used in the Custom Record Label had blank/null values for a given record, then it would mistakenly display the variable name in square brackets on the page instead of just omitting that value in the displayed text.

  • Bug fix: When renaming a record in a longitudinal project, in which the new record name already exists, it mistakenly does not give any notice regarding why the record cannot be renamed but simply displays the "record successfully edited" message.

  • Bug fix: For longitudinal projects, the "Graphical Data View & Stats" page might display incorrect values for "Total Count (N)" and "Missing" on the fields displayed on the page.

  • Bug fix: If an "if()" function or exponent logic, e.g. ([field])^(3), was used in the branching logic of a field, it would mistakenly not parse it correctly when loading a data entry form or survey and instead display an error message. These work fine in calculated field equations, but only did not work in branching logic.

  • Major bug fix: If a user possesses an API token in a project and has also been assigned to a user role in that project and then copies the project while leaving the "copy all users and roles" option unchecked on the "Make a Copy of the Project" page, then if they request an API token for the new project, that new API token will mistakenly point back to the old project, which means that there could be an issue with regard to data being imported into the wrong project or exported from the wrong project in this specific scenario.

  • Bug fix: Survey invitations that were sent via Automated Survey Invitations and were triggered by the REDCap cron job would mistakenly not link that logged event to the project, thus the event "Automatically schedule survey invitation" would never show up on the project's Logging page, which might be confusing. It now gets logged properly in the project, and additionally, it lists the username as "SYSTEM" on the project Logging page, in which the username was missing/blank in previous versions for this scenario.

  • Bug fix: If attempting to utilize the PROMIS CATs functionality on a REDCap server that has SSL disabled (e.g., a test server), it might not function successfully but displays an error that it cannot communicate with the Vanderbilt CATs server.

  • Change: When attempting to use the PROMIS CAT functionality for a survey, it will now display an error on the page if the cURL library in PHP has not been enabled on the web server (since the CAT functionality utilizes cURL and cannot function without it).

  • Bug fix: The "Graphical Data View & Stats" page would mistakenly display a value of "0, 0%" for Counts/Frequency for a multiple choice option that had a non-numerical coding (e.g., "M" for "Male"), which could cause some confusion by providing incorrect statistics for multiple choice fields (radio, dropdown, yesno, truefalse, and checkbox fields).

  • Bug fix: Fixed typo in API documentation for the "Export Instruments" method.

  • Bug fix: Fixed typo in the "What is 'exclusion'?' popup on the Data Quality page.

  • Bug fix: If a project-level REDCap plugin that displays the project header/footer forces a user to log in to REDCap (because that is the first page they are accessing in their session), then if they click a Project Bookmark link on the left-hand menu, on certain occasions it would not redirect the user to that bookmark page but instead display a "woops" error. This only occurs when the first page they come to after logging in is a plugin page that displays REDCap's header/footer.

  • Bug fix: When viewing the Data History popup for a field on a data entry form, it would sometimes return no results if a space existed in the record name.

  • Bug fix: If a field on a survey had branching logic that utilized the Form Status field (e.g., form name + "_complete"), it would work fine on a data entry form, but it would mistakenly cause a branching logic error on the survey page.

  • Bug fix: When a user with "de-identified" data export rights is viewing the Advanced Data Export view of the Data Export Tool and the record ID field in the project had been tagged as an Identifier field, then the option to "Hash the Record ID field" at the bottom of the page would mistakenly not be checked. This would not affect anything during the export process because it would still correctly hash the Record ID field's value in the exported data file, but it could be confusing because that checkbox option was not originally checked.

  • Bug fix: When downloading a PDF containing saved data, any date/time fields with DMY or MDY date formatting would mistakenly be displayed in YMD format in the PDF. They now display in the PDF in their desired date format

  • Improvement: The Record Status Dashboard now displays options to view the lock status and/or e-signature status (if e-signatures are enabled) for any given record-instrument[-event] listed in the table.

  • Change/improvement: If the Survey Queue is enabled in a project and a survey participant returns to a survey that they have already finished (excluding public surveys), it now displays their Survey Queue directly below the message "Thank you for your interest, but you have already completed this survey", whereas before it simply stated the message without displaying the Survey Queue. This will make it easier for participants to return to the Survey Queue on occasions where they cannot find the link to the Queue itself or to their next survey.

  • Change: The ordering of records has been slightly changed in many places throughout REDCap where a list of all records is displayed so that records are now ordered using case insensitive natural ordering. This is to improve consistency because different places displayed a list of records in slightly different orders (e.g., case sensitive natural ordering). Reports are one of the few places that still displays records in case sensitive natural ordering, but this will change in future soon.

  • Bug fix: When a person copies a project, that person will not be in a role in the new project even if they were in a role in the original project. This mimics the behavior when a user creates a new project from scratch or from a template. In previous versions, a user assigned to a role that had Setup/Design privileges but no User Rights privileges could copy a project and then inadvertently end up with no User Rights privileges in the new project, which could be very confusing.

  • Bug fix: In the Scheduling Module, when changing the date of an event on a generated schedule or changing the date of an event on a saved schedule, after selecting a new date it would mistakenly determine the wrong day of the week to display next to the date text box, which could be confusing.

  • Bug fix: Made language correction due to spelling error in the "What is 'exclusion'?" popup on the Data Quality page.

  • Bug fix: On the API page in a longitudinal project, the list of unique events names displayed on the page would diverge slightly on certain occasions from the event list seen in other places, such as the Define My Events page. For example, if there existed more than 26 events all with a very similar name, the appended alphabetical characters on the unique event name would mistakenly get displayed as indecipherable characters (black diamonds with a question mark inside). Ultimately, this would prevent any users from importing data into those events using the API.

  • Bug fix: When uploading an attachment for a Descriptive field in the Online Designer, after the file has finished uploading, it provides a button that says "Cancel" to allow the user to close the popup, which could be confusing, when instead it should say "Close".

  • Bug fix: When using the User Access Dashboard to expire or delete a user from a project, the expiration/deletion action would not take place successfully if the user's username contained a period/full stop.

  • Major bug fix: For users that are able to access the User Access Dashboard, it might mistakenly display some projects on the UAD to which the user does not have User Rights privileges (i.e., access to the User Rights page in the project). This would only seem to occur if the user had access to the User Rights page in the project at one point but was then later added to a user role that itself did not have User Rights privileges. This bug would not allow the user to add or edit the user privileges in the project, but would simply mistakenly allow them to delete or expire users from the project when they should not be able to.

  • Major bug fix: For web servers running certain versions of PHP, users would not be able to access projects to which they had access, in which it would mistakenly display the "access denied!" message when attempting to access the project.

  • Bug fix: When piping data into a label on a data entry form when utilizing Double Data Entry, in which the current user is either DDE user 1 or 2, the piping would mistakenly not work when the page is loaded but instead would display a blank line where the piped data should be.

  • Bug fix: Occasionally, a survey that has question auto numbering enabled and also has a question on the survey with branching logic, it would not automatically disable the question auto numbering like it should (in order to prevent confusion due to question numbers not appearing on the page because they are hidden by the branching logic). It will now automatically disable question auto numbering if any questions on the survey contain branching logic.

  • Bug fix/change: Certain REDCap operations (e.g., uploading files into File Upload fields or adding/editing fields in the Online Designer) would fail to complete successfully if REDCap itself was hosted inside an iframe on another website. Attempting to perform such operations would cause JavaScript errors, which would cause it not to complete. It should now work fine even if a survey page or if all of REDCap is used inside an iframe on another website.

  • Bug fix: If a radio button field on a data entry form or survey page has only one multiple choice option to choose from, then the user's cursor would mistakenly not place focus on the radio button when tabbing through the page but instead would skip it (or more accurately the cursor would disappear between fields). And in addition, in some particular browsers (e.g., Firefox), it would allow a user to attempt to tab into the radio button (in which the cursor would actually disappear), and if the user entered text via their keyboard before clicking Tab again, it would mistakenly store the text entered as the radio button field's value, although it would never be displayed anywhere except in a report or data export.

  • Bug fix: If a user belongs to a Data Access Group in a project and is viewing a report, the "total number of records queried" at the top of the report would mistakenly always be reported as "0" rather than the correct number.

  • Bug fix: When executing a user-defined rule on the Data Quality page, in which a discrepancy is found and returns a field with no value, the link that points back to the data entry form for that record would not be visible because of the missing value. Now in such cases it simply displays "[no data]" as a gray link so that the user has something to click on to take them back to the data entry form when a value is missing.

  • Improvement: The buttons used in the dialog popup for survey Stop Actions (e.g., "End the survey now") have now had their language abstracted, so they can now be displayed in different languages.

  • Change: The following project-level settings will now only be explicitly utilized in a project when their value differs from their corresponding system-level values: project contact/email, production approval person/email, institution/organization name, grant name, and custom project logo. This will not change any behavior whatsoever in any projects. However, it will make it much easier to change these values for all projects at once by simply changing the system-level values, whereas in previous versions the only way to change these values for all projects was to execute SQL queries against the database directly, which is not ideal. In connection with this, the system-level counterparts of these fields are no longer listed on Default Project Settings page in the Control Center, but have now been moved to the General Configuration page.

  • Bug fix: When editing an individual participant schedule on the Scheduling page, in which the date value is being modified for a specific scheduled event for that participant, it would cause a JavaScript error in Internet Explorer 8 only when it attempted to calculate the number of days between the original date and the new date that the user just modified.

  • Bug fix: When viewing a single calendar event in the popup window in the Calendar module, in which the calendar event is attached to a record, on some occasions it may display an incorrect Form Status icon/value for certain data collection instruments.

  • Bug fix: When using record auto-numbering in a project with data access groups, in which a user in a DAG creates a record and then another user that is not assigned to a DAG un-assigns that record so that it is no longer assigned to any DAG, then when a user in a DAG then goes to create a new record, the data entry page goes into an infinite loop of redirecting itself.

  • Bug fix: If using very specific types of UTF-8 encoded special character sets (e.g., Icelandic characters) in a survey's instruction text or acknowledgment text, it would sometimes not render the text correctly on either the survey page or on the Modify Survey Settings page in the Online Designer but instead would display black triangle icons to denote that the browser could not interpret the character.

  • Improvement: When viewing the Edit Field popup in the Online Designer for Yes-No and True-False fields, it will now display a static, unmodifiable box of text below the Field Label text box where it will display both the coded value and label for the multiple choice options for those two field types (e.g., 1, True; 0, False). This will help make it more clear to users what the stored/coded values are for Yes-No and True-False fields, which is not really documented in many places.

  • Major bug fix: When using the "today" variable inside the datediff() function in the conditional logic of an Automated Survey Invitation, the invitation would mistakenly not get scheduled and would instead throw a PHP error when the process was executed by the cron job, which runs every 12 hours.

  • Bug fix: If an instrument is created in a project and then enabled as a survey, after which the instrument itself is deleted, then when copying a project it will mistakenly list the deleted survey instrument in the yellow "notice" box, which could be confusing.

  • Bug fix: When creating a new calendar event using the popup window in the Calendar module, a database query would silently fail in the background. This would not be displayed on the page or affect anything adversely though.

  • Change/improvement: All comments entered for the Field Comment Log and Data Resolution Workflow are now logged on the Logging page. In previous versions, the project Logging page noted the action performed and the record/event/field, but it did not explicitly display the comment entered.

  • Change: Users with read-only rights to a data entry form can now add, edit, and delete Field Comments for fields on that form. In previous versions, users with read-only form-level rights could only view Field Comments but could not add any new ones. (This does not affect users' ability to view or add comments in the Data Resolution Workflow, which has its own explicit user permissions for this. This change only affects projects using the Field Comment Log.)

  • Change: When a person copies a project, that person will now automatically have User Rights privileges in the new project, even if they did not have them in the original project. This mimics the behavior when a user creates a new project from scratch or from a template. In previous versions, a user with Setup/Design privileges but no User Rights privileges could copy a project (and thus all the user rights in the project, including theirs) and then inadvertently end up no User Rights privileges in the new project, which could be very confusing.

  • Major bug fix: If survey invitations were scheduled to be sent for a record using the Automated Survey Invitations and later a user renamed the record, the invitations that had been scheduled for that record would become disassociated with the record, and would then be triggered and scheduled again at that point, which might cause the invitations to now be scheduled to be sent at incorrect times. Because of this disassociation, it would also cause issues displaying the invitations in the Survey Invitation Log.

  • Bug fix: If the same survey invitation was sent one or more times to the same participant, in many cases all the invitations would mistakenly show up in the Survey Invitation Log with "[Email not listed]" in the Participant Email column with the except of the most recent invitation sent to that participant.

  • Bug fix: If a survey invitation was sent to a participant using the Compose button at the top of the data entry form, in many cases it would mistakenly show up in the Survey Invitation Log as having not been sent even if it had been sent to the participant.

  • Bug fix: "elements" was added to the illegal variable name list because it would prevent branching logic or calculations to function properly on data entry forms and survey pages in certain browsers.

  • Bug fix: Certain UTF-8 character sets (e.g., Icelandic) would mistakenly not display correctly on the webpage when used in survey instructions or survey acknowledgments.

  • Bug fix: In longitudinal projects in the Additional Customizations popup on the Project Setup page, users would seemingly be allowed to "enable" the "Order the records by another field" setting, despite the note that says it does not work for longitudinal projects. It would not really enable this setting but would appear as if it did since it displays a "Success" message after clicking the Save button. This settings is now completely disabled in that popup for longitudinal projects so that there is no confusion to users regarding whether or not it can be enabled.

  • Bug fix: If using conditional logic for Automated Survey Invitations in a longitudinal project, in which unique event names are explicitly used in the logic, then if an event is referenced where no data exists for any fields in that event yet, then the logic would never get fully evaluated and would thus prevent the survey invitation from being scheduled when it should. For example, if the logic is [screening_arm_1][email]<>"" and [visit_2_arm_1][visit_2_date]="", in which event "visit_2_arm_1" has no data collected for it yet, then the logic will not get fully evaluated even when "email" has a non-null value.

  • Bug fix: If importing a CSV data file on a longitudinal project's Data Import Tool page, in which the "Record format" is set to "Columns" and the record names in the CSV file are on the second row, it might mistakenly display an "invalid event name" error for some of the empty columns in the file.

  • Bug fix: When adding or modifying a checkbox field on the Online Designer or Data Dictionary Upload, if a coded value for a checkbox option contained a dot/period (e.g., "1.08"), it would mistakenly allow it to be saved. Having a dot/period in a checkbox's coded value causes several problems, including the ability to save data and export data to certain stats packages properly. Although it is fine for a dropdown or radio button field to have a dot/period in its coded values, it is not allowed for checkboxes, and thus it now displays an error to the user if a user attempts to do this on the Online Designer or when uploading a Data Dictionary.

  • Bug fix: The "Export Users" API method was not exporting the correct user privileges if the user had been assigned to a user role, but instead it was mistakenly exporting the privileges that the user had prior to being assigned to a role.

  • Bug fix: On a data entry form or survey page where the record has not been initially saved yet, it would make a query to the redcap_edocs_metadata table for each File Upload field, in which the query would always fail. However, once the record had been created, the query would no longer fail on that page or other data entry forms/survey pages. There was no error displayed on the page due to this failed query though. But now it no longer executes the query unless the record already exists.

  • Bug fix: When viewing the Data History of a field on a data entry form, if the username of the user is very long, it will mistakenly spill over into the next table column, which can make the text unreadable by having the username piled on top of the other text. It now wraps the username to another line if it is too long for the table cell.

  • Bug fix: When a user clicks on an email address a participant in the Participant List, on certain occasions it would not automatically pre-fill that email address into the editable text box that appears but instead would leave the text box blank.

  • Bug fix: The survey instructions and/or survey acknowledgment of some surveys might mistakenly display a black diamond character in some web browsers because a non-breaking space was invisibly added by the rich text editor on the Modify Survey Settings page, in which the non-breaking space character gets mangled before being output to the webpage.

  • Major bug fix: When using the Data Comparison Tool to merge records for a Double Data Entry project, it would mistakenly enforce YMD date format validation for the text box in the "New Value" column for any kind of date- or datetime-validated field, which could be confusing if the date field is defined with an MDY or DMY format. It now properly enforces the proper date format that has been specified for the field when validating the value entered into the text box on the Data Comparison Tool.

  • Major bug fix: If a project has a date or datetime field as the record ID field, it would mistakenly enforce only YMD date format validation when entering a new record name, even if the field had been defined with an MDY or DMY date format.

  • Bug fix: When creating a User Role that contains an apostrophe in its name, it would not save correctly if someone attempted to edit the role afterward.

  • Change: Slightly better handling of displaying matrixes of fields in the mobile survey view when the matrix column headers or question labels contain a lot of text, in which their text could overlap or get mashed together.

  • Bug fix: If Automated Survey Invitations have been set up for a survey on a project's Online Designer page, then when setting an ASI as "not active", it would mistakenly display error messages saying that it could not save the changes since not all the fields had been completed in the pop-up, which could be confusing if the user is simply deactivating it. It now does not display any error messages when setting an ASI as "not active" in this case.

  • Bug fix: If the record ID field in a project has min/max range validation, it would mistakenly display the popup warning message temporarily but then would quickly redirect the user to the "create record" data entry form page. Not only would the warning not prevent the user from creating the record, but the user would not even have time to view the validation warning when it was being displayed, which is only for a quick moment. If a range validation occurs for the record ID field, it now properly displays the warning popup and forces the user to enter another value inside the range before they can create a record.

  • Bug fix/change: If a user attempts to leave a field comment in the Field Comment Log popup on a data collection instrument, it would simply not display the textbox and "save" button for adding a new field comment if the user did not have form-level user privileges for the instrument. So no explanation was given as to why they could not add a new comment, which could be confusing. It now displays a note in the popup to explain this in this scenario.
1   2   3   4




The database is protected by copyright ©ininet.org 2024
send message

    Main page