New Features - Wiki UMN

jaspersugarlandΛογισμικό & κατασκευή λογ/κού

14 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

87 εμφανίσεις

New Features



Piping
-

The Piping feature allows users to
inject previously collected data into text on a data collection
form or survey
, thus providing greater precision and control over question wording. It can also be used in
other ways, such as for customizing survey invitations (e.g. by including the respondent's name in the
email) or survey acknowledgments (e.g. thanking your respond
ent by name after completing a survey). See
the full documentation on Piping at

http://tinyurl.com/redcappiping
. To see Piping in action, you may
view a live demo of Piping on a survey at

https://redcap.vanderbilt.edu/surveys/?s=ph9ZIB
. Also, a new
project template (named "Piping Example Project") has been added to the Project Templates.



User Roles
-

User roles can now be created in projects in

order to
group users according to their specific
role in the project
. Roles are especially useful when you have several users who will have the exact same
privileges in a project, in which roles allow you to easily add many users to a role in a much faste
r manner
than setting their user privileges individually. Roles are also a nice way to categorize users within a project.
You may still add new users with custom rights (just as before), but now you have the extra option to
create roles (e.g. data entry pe
rson, project manager, etc.) and then assign users to those roles. Any user
assigned to a role will assume the user privileges of that role. Users can be assigned, reassigned, or
unassigned to roles at any time. There is no limit to how many roles that can

be created per project nor a
limit on how many users can be assigned to a given role.



Real
-
time execution of Data Quality rules on data entry forms
. Users may now enable any of their custom
Data Quality rules to be executed in real
-
time whenever the Save

button on a data entry form is clicked.
This will allow users to catch data errors in real
-
time as data is being entered for an individual record. The
DQ real
-
time execution functionality can be thought of as an advanced type of field validation in which
it
will be vigilantly watching all data entered to ensure that the DQ custom rules are not violated. Real
-
time
execution is completely optional and may be enabled for any given DQ custom rule you have created. By
default, it will be disabled.



Field Commen
t Log

o

All projects will have the Field Comment Log enabled by default (but it can be disabled for a
project on the Additional Customizations pop
-
up on the Project Setup page). A balloon icon will
appear next to all fields on all data entry forms, and afte
r being clicked, it will open a pop
-
up to
allow a user to enter comments about the field
.

o

Field comments can serve as a way to have
field
-
level annotations about your data
, similar to
posting sticky notes on the margins of a piece of paper. Having this fe
ature can prove very useful if
you need to add any notes or comments about a data value entered. There is no limit to how many
comments can be left per field.

o

All the field comments in a project can also be accessed on the
new "Field Comment Log" page
see
n on the project's left
-
hand menu, which allows users to easily find existing field comments by
filtering through them by record, event, field, user, data access group (if applicable), and also by a
keyword search.



Data Resolution Workflow
(i.e Data Queri
es module)

o

The Data Resolution Workflow module (also known as the Data Query module)
provides a nice
workflow for certifying the validity of data values
and also enabling users to
open "data queries"
(i.e. report an error),
which is a common term used in
clinical trials/studies. Opening a data query
initiates a well
-
documented process of investigating a possible error in a data value and then
ultimately resolving the error.

o

The Data Resolution Module is *not* enabled by default but
can be enabled in the A
dditional
Customizations pop
-
up
on the Project Setup page. Users must be given new user privileges
specific to this module on the User Rights page, in which you can set any given user with the
following: No access (default), View only access, Respond only
to opened queries, and
Open/Close/Respond to queries.

o

When the module is enabled, on any given data entry form one will see a gray balloon icon next to
the field, and when clicked, it will open the Data Resolution Workflow pop
-
up where users can
either va
lidate the data value for that field OR open a data query if there is an issue with the data
value (if one has user privileges to do so). Once a data query is opened, a user with "respond to
query" privileges can come and investigate the issue, correct the

issue (if applicable), and leave a
documented response. After this, a user with "close query" privileges will come and close the data
query, thus leaving the query's status as "resolved". This entire process gets recorded and
documented from beginning to
end.

o

Data queries can also be opened from the
discrepancy results pop
-
up in the Data Quality module
when discrepancies are returned for a given Data Quality rule. This also includes the discrepancy
pop
-
up when a DQ rule is violated on a data entry form vi
a the DQ "real
-
time execution" feature.
Note: If a custom DQ rule contains more than one field in its logic, the data query gets associated
with the rule, whereas data queries initiated for single
-
field DQ rules get associated with the field
(not the rule)

just as if the query was initiated for that field on the data entry form.

o

The Data Resolution Workflow provides
a new "Resolve Issues" page
that can be seen on the
project's left
-
hand menu. The Resolve Issues page provides a nice dashboard to help manage

all
the data queries as they are opened and resolved. There also exists a Resolution Metrics section
on that page for viewing useful statistics and visual charts for viewing the progress and activity of
opening, responding, and closing queries in the proj
ect.

Improvements



Enhancements for Data Entry

o

When a user puts focus on a field on a data entry form or survey, it will add
a subtle green
highlight

to the row to make it easier to note the field on which they are currently focused.

o

When a data entry f
orm loads, it now automatically
moves the user's cursor to the first field
to
help speed up data entry.

o

At the top right of all data entry forms, users will now see
a floating box of "Save" buttons
, which
will always stay visible even as one scrolls up an
d down the page. This should be very helpful for
long forms and will prevent users from having to scroll all the way to the bottom of the

page in
order to save their data.



Improvements to
Survey Invitation Log page

o

New option to
edit the "send time"
for a scheduled survey invitation that has not been sent yet.

o

New option to
delete a scheduled survey invitation
that has not been sent yet.



New "execute" buttons for rules in Data Quality module. Now has 3 buttons to execute "All", "All except
A &

B", and "All custom".



Improvement for process of
approving Draft Mode changes

o

On the page for viewing a summary of all Draft Mode changes, it now
only considers an issue to
be "critical" if the field has data
. In previous versions, if a field was delete
d, or had its field type
changed to an incompatible field type, or had its multiple choice options deleted or re
-
coded, it
would be considered a critical issue, whereas now it only gets flagged as critical under those
circumstances if it has data saved for

it. More specifically,
for multiple choice questions it is more
granular, in which it does not consider it a critical issue unless the specific option that is being
deleted or re
-
coded has data
.

o

This also affects whether a user's Draft Mode changes get a
pproved automatically if the Control
Center option "Allow production Draft Mode changes to be approved automatically under certain
conditions?" is set so that approval by an admin is required when critical issues exist. This means
that more requests will b
e automatically approved since the issue is only considered to be
"critical" if the field has data.



30
-
day delay when deleting projects

o

Deleted projects may now be restored at any time within 30 days of their "deletion". When a user
deletes a project, it

now no longer permanently deletes it at that moment, but instead hides the
project from the user and does not delete it until 30 days have passed after the user "deleted" it. It
can be accessed by a REDCap admin in the Control Center when viewing a user's

projects, in which
it can also be restored so that it does not get permanently deleted at the set time in the future.

o

If a project truly needs to be deleted immediately from the system (rather than in 30 days), a
REDCap admin can view the project on a us
er's Browse Projects list in the Control Center, and click
the "Delete it now" link beside the project to permanently delete it.



It has always been the case that the "simultaneous user prevention" feature is activated whenever a user
tries to access the s
ame record on the same instrument (on the same event, for longitudinal projects) as
another user. This has been changed/improved slightly so
that if the second user has "read
-
only" rights
on that particular instrument, then they *will* be able to view the
same record
-
form[
-
event] while the
first user is accessing it.

Since they have "read
-
only" privileges, there is no chance of them causing data
from the other user to be overwritten, which is the purpose of the simultaneous user prevention feature.
So this
change does not take anything away from the existing functionality of the feature, and it adds more
flexibility for users.



The
Data Quality module now operates up to five times faster
than before when executing the data
quality rules.



Stricter error catc
hing (i.e. extra security protection) now exists when adding/modifying branching logic or
calculated field equations either on the Online Designer or via the Data Dictionary upload. REDCap is now
much more strict and will
no longer allow normal users to us
e improper syntax when adding/modifying
branching logic or calculations
. In previous versions, it would allow incorrect syntax (e.g. "[age]>30 and
and [age]<60" or "[age]+6+") or custom JavaScript methods/constants (e.g. [age].length, Math.PI) or even
ille
gal or unrecognized functions (e.g. $(function(){ }, eval()). For security reasons, it now prevents normal
users from utilizing those kinds of improper syntax and instead will only allow normal boolean expressions,
mathematical operations, and allowed func
tions that are prescribed in the REDCap inline documentation
or on the REDCap Help & FAQ page. However, super users *will* be able to override this and will still be
able to utilize incorrect syntax (e.g. JavaScript methods/constants) if desired as a speci
alized customization
for a project. Also, if a normal user has already saved a field with syntactically incorrect branching logic or
calculation in the past (or if a super user did), then it will still allow the normal user to upload their Data
Dictionary
successfully or edit the field in the Online Designer *so long as* they have not modified the
existing branching logic/calculation. But if they have modified it in any way, it will not allow them to
change it (although a super user can).



When copying a pr
oject, there is now an option (if desired) to
copy all Data Quality rules
.



The Custom Record Label and Secondary Unique Field values (if either are enabled) are now displayed next
to the record name in the Data Quality module's results, in the Scheduling
module, and in the Calendar
module in the calendar event pop
-
up.



The
My Projects page now has

a new column in the project list to specify if the project is
using "classic" or
"longitudinal"
data collection. It also has another new column that displays th
e number of data collection
instruments within each project, including a breakdown of number of forms and number of surveys (if
any).



The
titles of projects on the My Projects page are no longer truncated

but are now fully displayed. The
names of data col
lection instruments in the Online Designer are also no longer truncated but fully
displayed.



Better memory management on the web server for when users download files from the File Repository,
File Upload fields, Send
-
It files, and API file export. Also, t
his
allows users to download very large files

(>512MB) from REDCap without having to increase their memory_limit setting in PHP (although one's
upload_max_filesize and post_max_size settings must be high enough to allow files of a given size to be
uploaded

first). In previous versions, one would have to increase the memory_limit on the web server in
order to allow such large downloads, but increasing the memory_limit can pose the risk of the web server
running out of memory if the amount of available RAM is

not very high. In summary, file downloads from
REDCap no longer consume RAM from the web server. (Note: This improvement excludes REDCap setups
that utilize the WebDAV option for file storage.



When utilizing the
survey notifications
feature, which automa
tically sends an email to designated users
whenever someone has completed the survey, it
now states the name of the survey in the email subject

to help clarify from which survey the email originated without having to open the email.



Significant
performance improvement when opening a multi
-
page survey

that contains a large number of
questions (i.e. several hundred or more). In previous versions, very long surveys would load very slowly
even when very few questions were displayed on each page. The
load time of each survey page should
now be more proportional to the number of questions on that particular page. For very long multi
-
page
surveys, there should be a significant improvement in load time per page. (Note: One
-
page surveys will
*not* see a pe
rformance improvement from this.)



When a survey participant completes a survey, it now displays a
"Close survey" button
at the top of the
acknowledgement page so that users may more easily close the survey without confusion of how to
navigate to a previou
s browser tab and also reduce the risk of participants accidentally clicking the Back
button in their browser, which can lead to confusion as well.



For multi
-
page surveys, it will now skip any survey pages where ALL questions on the page will be
hidden
du
e to branching logic (excluding the first and last page of a survey, in which a user must still
manually decide to begin or end the survey, respectively). Having REDCap skip survey pages automatically
prevents confusion for participants when the survey pag
e loads with no questions.



When exporting a
PDF
of a single record (on a form) or of all records (on the Data Export Tool page), it now
displays the Secondary Unique Field value at the top right of each page

in the PDF.



For large tables that scroll off t
he page on the Record Status Dashboard, longitudinal Event Grid, or
reports, it will now keep the table's first column and headers visible at all times so that they can be seen
even when scrolling off the page.



Users now have the option to
view all their
survey participants on the same page
in their Participant List
rather than having to view only 50 participants at a time per page. This can be done by selecting the "All"
option (i.e. the first option) in the drop
-
down list of "pages" to choose from in the

Participant List.



On the My Projects page, users by now
find specific projects more easily by typing keywords

from the
project title into a text box in the My Projects table.



Better detection of mobile web browsers

to distinguish them from desktop and t
ablet browsers. Some
newer tablets were being mistaken for mobile devices (i.e. phones), and thus survey pages would not
display correctly for them.



If using a Project Bookmark inside a longitudinal project, in which the option "append record info to URL"

is enabled, it now appends the record info to the bookmark URL when the user is on the event grid page
for a record. In previous versions, it only did this on the data entry forms.



The
Record Status Dashboard
now has the option to
display all records
at

once (rather than 100 at a time)
by selecting "ALL" from the record drop
-
down list.



The
red and green icons

that indicate the complete status of a record for an instrument in a project were
very difficult to distinguish from one another for users that ha
ve color blindness. The red icon now has a
small white dot

in the center to make it more distinguishable from the green icon.

O
ther
Changes



The word
"super" has now been added to the list of
reserved variable names
that cannot be used as the
variable name

of a field because it is a reserved keyword used in older versions of Internet Explorer.



On the Online Designer, although the "Add Question" buttons would correctly appear for the first data
collection instrument (if enabled as a survey), it would mistake
nly display the "Add Field" buttons (i.e. with
different text on those buttons) for any other instruments in the project that are enabled as surveys. So
instead of merely fixing this issue, it has been changed to always
display "Add Field" for those button
s
(rather than "Add Question")
in order to provide more consistency through REDCap for
surveys and non
-
survey instruments alike.



The
Help & FAQ page was updated
.



More information about the REDCap Shared Library has been added to the "Design your data col
lection
instruments" step on the Project Setup page when projects are in development status. This provides a
more upfront introduction to the Shared Library, and it allows the user to go to the library directly from
the Project Setup page.



API examples

fo
r PowerShell, Visual Studio 2003, and SAS were added to the API examples zip file.



Whenever a user creates a new instrument in the Online Designer, it no longer displays a confirmation
pop
-
up after each time this is done because it was considered to be to
o many unnecessary clicks if creating
many instruments at once.



For survey participants that are invited via the Participant List who click the "
Save & Return Later
" button
on the survey page, which then automatically emails them a notification about par
tially completing the
survey, it now also includes an extra sentence in that email
letting them know that they can contact their
survey administrator
who originally sent them the invitation if they need to retrieve their return validation
code.



A
clarifyi
ng note

has been added to the "
Add Matrix of Fields
" pop
-
up in the Online Designer, in which it
states that adding text for the matrix section header will force a new page on a survey if the data collection
instrument is enabled as a multi
-
page survey. Som
e users where unaware that the matrix header text is
just a normal section header.



A
link to the Data Access Groups page is now displayed on the project's left
-
hand menu
(if the user has
privileges to access that page).



Videos were updated
for the Online

Designer and Data Dictionary.



The
Data History

pop
-
up now displays data changes listed in chronological
ascending order
. In previous
versions, it sorted them in descending order.



When using the Data Export Tool to export data into Stata
, it now adds an extra command in the Stata
syntax file that automatically causes
Stata to scroll to the bottom of the output
rather than making the
user page through it manually, which is an added convenience.



The Project Setup page in each project now c
ontains a
step titled "Test your project thoroughly"
right
above the step to move the project to production. This new step serves as a simple reminder to the user to
test all essential aspects of their project before moving it to production.



If a project
is utilizing
surveys and data access groups
together and a user belongs to a DAG, now in the
Participant List it only
displays the participants that belong to that user's DAG
. In previous versions, it
would display all participants regardless of whether th
e user was in a DAG. Note: In the initial survey, it still
displays participants that have not yet begun their survey (i.e. their record has not been created yet),
which is the same behavior as in previous versions.



On
PDFs

of data entry pages,
Descriptiv
e fields now have their line breaks preserved in the text
in the
same way that line breaks in Section Header text is preserved in PDFs.



For
archived or inactive projects
,
users could

navigate to data entry forms via reports
that had a link to
records list
ed in the report. Since users should not be able to navigate to the data entry forms for projects
that are inactive or archived, it now still allows users to access reports but no longer provides a link to
individual records in the reports in order to prev
ent access to data entry forms.



The

link
to navigate to the "
Check For Identifiers
" page has been returned to the Design step on the
Project Setup page for development projects. It was removed in version 5.2.0.



A more clear error message is displayed to
a
Double Data Entry

user i
f they are restricted from accessing a
page that should not be accessed by DDE user

#1 or #2
.



If using
Double Data Entry
, DDE user

#1 or #2

would mistakenly be able to access certain pages within the
project that display data fro
m multiple records at once (e.g. reports, Field Comment Log, Data Quality).
DDE users should not have access to these types of pages. They will now not be able to access those pages,
and if they do, it will display an error message telling them why their a
ccess is restricted.



When a longitudinal project is moved to production, the "
Define Your Events" step

on the Project Setup
page now gets
repositioned

to the second
-
to
-
last step on the page (right above the "Draft Mode" step) to
imply that events may stil
l be modified once in production. It will do this if the system setting is enabled
which allows users to add, edit, or designate events while in production, but if not enabled, the "Define
Your Events" step will remain near the top of the page where it was

located while in development status.



A new section of text was added on the page where users can
share
/upload
a data collection instrument

to the REDCap Shared Library. This section provides several bullet points to help clarify to the user what it
is th
ey are doing by sharing their instrument to the Shared Library. This is done in order to cut down on
accidental or unintentional submissions to the library.



New section named "
API Security: Best Practices
" was added to the API Help page and to the API pag
e in
each project. This section discusses the most secure ways of communicating with the REDCap API, such as
always validating the REDCap server's SSL certificate.



When viewing the Participant List for a follow
-
up survey (i.e. any survey that is not an "i
nitial survey"
-

not
the first instrument), it now displays a pop
-
up tooltip if the user clicks a cell in the Participant Identifier
column in an attempt to add or edit an identifier. The
tooltip

explains that
participant identifiers can only
be added or e
dited *prior* to the record/response being created
. Thus, a participant's identifier can
never be added or edited for a follow
-
up survey but only for the initial survey and only before the
participant begins the initial survey. This does not change any fun
ctionality at all but merely displays this
tooltip to explain this, which is often misunderstood or confusing to users.



For
projects with multiple surveys
, it was previously impossible to keep a response completely
anonymous
when using the Participant Lis
t because the respondent's email address could be viewed in the
"Compose survey invitation" pop
-
up on an incomplete data entry form when viewing an individual record.
This has been changed so that when participant identifiers have been disabled and when th
e designated
survey email field has not been enabled, the respondent's email address from the Participant List will not
be displayed in the "Compose survey invitation" pop
-
up on data entry forms but instead it will say
"[undisclosed email address]" in orde
r to maintain anonymity while still allowing the user to email the
respondent, if needed. In addition, this has also been done on the Survey Invitation Log so that it displays
"[undisclosed email address]" instead of the respondent's email address under th
ese same conditions in
order to maintain anonymity since there is the possibility of identifying a respondent's record by looking at
the survey invitation send time and response status in the Invitation Log and cross
-
checking those values
with the status o
f completed surveys on the data entry forms (this is more difficult to do but definitely
possible).



When an existing user's or role's
privileges are being modified

in the popup on a project's User Rights
page, the save button now says "
Save Changes
" rather than "Edit User"/"Edit Role" to prevent confusion
about what clicking the button does.



Passwords
for table
-
based user accounts
no longer have a upper limit on their length
. They can be as long
as desired. In previous versions, the password could
be no longer than 15 characters.



Added a

new "Types of Projects" video
, which is seen on the Training Resources page and in the Video
Tutorials section of each project's left
-
hand menu. Also, the existing "Traditional Project", "Longitudinal
Project", and

"Longitudinal + Scheduling Project" videos were updated.



Bug fixes



When defining a
limiter

for a field in the
Report

Builder
, setting the limiter operator to
"="
while leaving
the limiter text box
empty

would presumably return a data set in which that field is blank/null, but
mistakenly it does not work correctly in this way.
It now will return the expected results if the limiter field
is set to return results where the specified field is blank/null.




Wh
en
deleting the first data collection instrument

using the Online Designer's "delete" button, it was
mistakenly
not preserving the first field

(i.e. record ID field) but deleting it, making it impossible to re
-
add
that field using the Online Designer (coul
d only be done via Data Dictionary). It now preserves the record
ID field in the first position if a user deletes the first instrument.



There were issues with the
Data Search utility

on data entry forms, in which it w
ould sometimes not work
at all.



There
were issues with the
Data Search utility

on data entry forms when viewing it in
Internet Explorer 7,

in which the suggestions box, which appears as the user types, was not wide enough and thus prevented
users from seeing the results fully on some occasions
.



When uploading a
data dictionary

while in
development

status in which the
first instrument

has been
enabled as a
survey
, if the user
modified the instrument name

in column B of the data dictionary, the
survey might mistakenly not load correctly on the s
urvey page. It now prevents this, and if this has
occurred for projects in the past, it will auto
-
fix it when the survey page loads.



File Upload fields

were mistakenly not being displayed
in

downloaded
PDF files

for data collection
instruments/surveys.



I
f setting the
secondary unique field

on the Project Setup page, it would mistakenly not set it if record
auto
-
numbering was not enabled. Bug emerged in version 5.0.0.



If a project had enabled record
auto
-
numbering
, and then a user opened the
Additional
Customizations

pop
-
up on the Project Setup page and clicked Save, it would mistakenly disable the auto
-
numbering
(unless the first instrument in the project was enabled as a survey). Bug emerged in version 5.0.0.



Data Quality module: Several fixes for Rul
e A, B, and F
, in which sometimes it would not report
discrepancies that existed, and other times reported di
screpancies that did not exist
.



When
deleting a checkbox field

in the Online Designer, in which that field is
used in the branching logic or
calcu
lation

of another field in the project, it was mistakenly
not displaying the prompt

to the user to
notify them of the dependent fields that will be affected by the field's deletion. This only affects checkbox
field types.



If a user inserted
HTML

into the
field label of a Section Header, then the HTML would not render correctly
on the Online Designer if the user added the HTML tag's attributes
using single quotes

(as opposed to
double quotes), although it would render correctly on surveys and data entry for
ms. Example: <span
style='color:red;'>would not display in red</span> vs. <span style="color:red;">display in red</span>



On the project
Logging page
, some
HTML tags

might mistakenly get displayed in the "List of Data Changes
or Fields Exported" column of
the logging table.



On the project
Logging page
, it was mistakenly not denoting that a record was updated or created via the
Data Import Tool

(as opposed to via API or via data entry on data entry form/survey). It now appends
"(import)" in the Action colum
n if imported via the Data Import Tool.



If participant identifiers have been disabled for a survey's Participant List, it would mistakenly display the
record name next to the email address in the list. It should never display the record name unless the
pa
rticipant identifier functionality has been enabled *and* when the participant has an identifier defined.



When creating/editing a
matrix

of fields in the Online Designer when using
Internet Explorer 7 or 8
,
clicking the "Add another row" button would copy

the row correctly but would mistakenly also copy the
contents of the Field Label and Variable Name text boxes (if any text had been entered into them by the
user). This only affects IE7 and IE8.



If a user adds a
section header to the first field in the d
ata dictionary
, it would cause it to appear above
the first field on the first data collection instrument in the Online Designer, in which it would mistakenly
display an "Add Field" button right above it. This is a problem since the Online Designer does no
t allow
users to add fields before the first field. This has been changed so that the section header above the first
field will no longer be displayed in the Online Designer, which should not affect anything because this
section header does not get display
ed anywhere else (not even on data entry forms or surveys).



If a
survey participant

from the Participant List
opened their survey link in two or more tabs/
windows in
their web browser at the same time before starting the survey, then they could incidental
ly create multiple
independent responses/records that would all get attributed to the same participant. This can only occur
for the first data collection instrument, as opposed to other instruments enabled as surveys. This has been
fixed so that if the par
ticipant now opens multiple tabs for the survey, it will not create a new separate
response/record but will continue on the same record, in which it will overwrite any existing values from
the original tab with new values submitted in the second tab. And i
f the survey has been completed in one
tab, then when the participant clicks the Submit button in the other tab, it will not save the data but
instead give the participant a message notifying them that they cannot continue because the survey has
already be
en completed.



When downloading a
PDF

of an instrument, if a field has
right
-
horizontal

(RH)
alignment

and the field
contains a Field Note, the
Field Note

would mistakenly not display in the PDF.



When downloading a
PDF

of an instrument, if a field has
lef
t
-
horizontal

(VH) or left
-
vertical (LV) alignment
and the field contains a
Field Note
, the Field Note would mistakenly be displayed on the same line as the
Field Label in the PDF, rather than on a separate line beleow the Field Label.



If the
Data Entry
Trigger

had been enabled for a project, then it would mistakenly not fire if the project
had
Double Data Entry

enabled, in which a user was merging a pair of records on the Data Comparison
Tool page. It is now triggered when merging DDE records. However, t
he Data Entry Trigger does not send a
value for the instrument name or the instrument status to the specified URL since those values are not
applicable on the Data Comparison Tool page.



Although the Data Dictionary upload did not allow checkbox fields to
have raw coded values for their
choice options that contained an underscore
, the Online Designer was mistakenly allowing it. So if this
was done using the Online Designer, then data would not correctly save for any checkbox fields containing
any underscore
s in their raw coded values for their multiple choice options. Now both the Online Designer
and the Data Dictionary upload will allow checkbox fields to have underscores in their raw coded values for
their multiple choice options.



If any
calculated

fields

or fields with
branching logic

on a survey were dependent upon a
checkbox field

option
that contained a Stop Action
, then if the Stop Action was triggered and the participant decided to
undo that option (rather than ending the survey), then it would mista
kenly not trigger the calculations and
branching logic immediately after deselecting that checkbox option, which could have major effects on all
fields that are dependent upon it.



If
cross
-
event logic was used in a custom rule

in the Data Quality Module (
longitudinal projects only), it
might mistakenly display data from one record in the discrepancy results of another record, or it could
display data from one event within a record for anothe
r event within the same record
. As a natural
byproduct of this fix
, the Data Quality module now operates up to five times faster than before when
executing the data quality rules.



When editing the

Primary Key

field (first field in a project
-

e.g. Study ID) in the Online Designer, it was
mistakenly not displaying the op
tion to mark the field as an
Identifier
.



If a project is utilizing the
designated email field to use for invitations

to survey participants, and that field
is modified so that it is no longer an email
-
validated field, then it was mistakenly still function

as the
designated email field. In this situation, the field will now no longer be regarded as the designated email
field (unless its email
-
validation is re
-
applied).



When
copying a project

that contains one or more surveys, in which a survey has a
Survey

Expiration
date/time set, it was copying the expiration time to the surveys in the new project. This can be confusing
to users if they do not remember that the original had a survey expiration set, and so the survey(s) in the
new project might expire with
out the user even realizing that the survey(s) had an expiration time set.
Now when copying a project, it no longer copies the survey expiration time for any surveys in order to
prevent that kind of situation.



When
viewing a survey response

on a data entr
y page, if the Custom Record Label is enabled, it would
mistakenly not display the
Custom Record Label

value at the top of the response at first but only *after*
the "Edit response" button is clicked (assuming the user has user privileges to edit survey re
sponses).



For a
user
-
defined rule

in the Data Quality module, if
"<>"
was entered in either the rule name or rule
logic, it would mistakenly get
removed

from the name/logic both when saving the rule and also when
executing the rule, thus leading to incorr
ect results.



The
Record Status Dashboard

page was mistakenly not displaying the
Custom Record Label

or
Secondary
Unique Field
values next to the record name in the table if either the Custom Record Label or Secondary
Unique Field were enabled in the project.



For longitudinal projects containing
more than one arm
, the Record Status
Dashboard

page was
mistakenly displaying a red s
tatus icon for events belonging to arms on which the record did not exist,
which can be confusing and make it mistakenly appear as if the record exists on all arms. If the record
exists on one arm and not any other, it will only display a colored status ic
on for events on that arm and
not on the others.



When two fields are adjacent on a form/survey and both have field validation, then if the first field displays
the validation error pop
-
up after entering a value for it but then has its value corrected, and

then the
second field displays the validation error pop
-
up after entering a value for it, then the pop
-
up message will
be incorrect and will mistakenly display the error message for the previous field.



If a
data dictionary

is uploaded in which the
record

ID field

(the first variable) contains a value for the
section header
, then it would
mistakenly display both the section header and record ID field on the
survey

page (assuming the first instrument is enabled as a survey). It should not display either. It

now
removes the section header value (if a value exists) from the record ID field when uploading the data
dictionary.



When creating/editing a report in the
Report

Builder, if a field selected to be in the report had a field
validation of
date
, datetime,
or datetime w/ seconds and was in either MDY or DMY format, then the
validation would not work for that field's
Limiter

text box when entering a value as a limiter for that field.



When clicking the "Erase all data" button on a project's Other Functionalit
y page, it was mistakenly not
logging that action after all data had been erased.



When loading an exported data set into
SAS

using the SAS syntax file provided on the Data Export Tool, it
was mistakenly
storing the SAS formats in a temporary library

when
executing the syntax file, which can
cause issues if the user attempts to move the dataset to a permanent library within SAS. It
now stores
both the dataset and formats to a permanent library called REDCAP

in the same directory on the user's
local computer
.



On the "
E
-
signature and Locking Management" page

in a longitudinal project, it would mistakenly display
all instruments for all events, even when the instrument had not been designated for the event.



If a user
deleted a

data collection instrument that
was enabled as a
survey
, it would permanently delete
the survey, thus causing a cascading deletion that also deletes all survey
-
related metadata (participants,
response timestamps, automated invitations). This could cause major problems if the instrument w
as
deleted accidentally, thus causing permanent loss of a great deal of survey
-
related functionality. From now
on, it no longer deletes the survey from the back
-
end but maintains it there as orphaned and invisible, thus
allowing the survey to reappear if t
he instrument were re
-
added after the deletion.



For some
non
-
U.S. users

who were exporting data from REDCap and loading it into
SPSS
, it would give an
error message because of the assumption that the LOCALE was "en_us". The LOCALE variable for SPSS is
now

explicitly set in the SPSS syntax file in order to prevent that error from occurring for those non
-
U.S.
users.



When attempting to
mark a partial survey response as complete

on a data entry form by clicking the
"Save and Mark Response as Complete" button
in which a required field exists on the page but whose
value is left blank, then when the page reloads and displays the "Some fields are required" pop
-
up notice,
it would mistakenly
redisplay that pop
-
up

notice again on the page if the user clicked the "Ed
it response"
button in order to make more changes (prior to clicking the Save button).



Due to a limitation in PHP's str_shuffle() function on certain Windows platforms, the REDCap function that
randomly created
survey hashes

to be used in survey links
might

begin to actually
reproduce the same
random hashes

that already existed for existing survey participants, thus possibly causing the function to
go into a long loop and eventually a potentially infinite loop. The function has now been modified so this

might no longer occur on those particular Windows platforms that are affected.



If the first data collection instrument of a project was enabled as a survey but somehow got disassociated
from its survey information on the back
-
end, it would not correctly
reconnect the disassociation.



The
API Help page

documentation was missing an explanation of how to obtain the filename, file
extension, or MIME type of an exported file in the section "Export a File" on that page.



When a user sends a file to a recipient
using the
Send
-
It

utility, the email sent would not have the
download URL explicitly specified as an HTML link within the email message, which would cause it to
display only as text (rather than as a clickable link) in certain email clients. It now explici
tly creates it as a
proper
HTML link

in the email message so that it will always be clickable by the recipient regardless of the
email client used.



When deleting a survey by clicking the "
Delete Survey
" button at the bottom of the "
Survey settings
"
page,
it
did not

explain

anything about what deleting a survey entails before one clicks the button, thus
causing users to not click the button out of fear (although the implications are thoroughly explained in a
pop
-
up *after* clicking the button). It now expla
ins the important things to know about deleting surveys in
a paragraph to the right of the button so that users do not necessarily have to click the button before
seeing the full explanation.



When creating/editing a report in the
Report Builder
, fields th
at have a validation of
Number or Integer

only have the "=" or "not =" operators for Limiters, so some
options are missing from the operator drop
-
down li
st
.




When creating/editing a report in the
Report Builder
, a
Limiter value could not be successfully s
aved for

the following field types:
slider, calc, integer
-
validate
d text, number
-
validated text
.




On a project's
Graphical Data View & Descriptive Stats

page, it
would not display a bar chart

if one or
more multiple choice labels for that field contained a
tab
-
space character
, which would most likely have
been copy and pasted from another application outside REDCap.



On the
login page
, it mistakenly lists the default project contact person giv
en as the
contact

for logging
-
in
issues when it should instead list home page co
ntact.




If using the
Public Survey links for multiple arms

in a longitudinal project, after the survey participant
clicks the Submit button on the first page of the survey, it

would mistakenly give the error message that
the person had already complete
d

the survey (which is incorrect), thus preventing them from completing
the survey.



When utilizing
randomization

for a project, once a record has been randomized and a data entry

form is
locked, in which the form contains a field involved in the randomization process, then pressing the "
Unlock
form
" button on the page would inadvertently
re
-
enable any fields involved in the randomization process

when it should instead keep those f
ields disabled (since their value should never change after
randomization occurs). However, those fields are only editable until the user leaves that form after
unlocking it, after which those fields are never able to be modified again (unless the form is
locked
-
>unlocked again in the same way).



When using the
API

to
export

records, metadata, users, events, or arms in
JSON

format, then it would not
correctly escape certain JSON control characters (e.g. backslash, line breaks) to JSON specifications, thus
r
esulting in an error if the user tried to decode the JSON
-
formatted response.



When using the
API

to
import

records in
EAV

type format, if any
checkbox

fields

were being imported, in
which their value was being set as "0" (unchecked), it would instead set
the field's value to "1" (checked) if
its value was already "0" (unchecked). If the checkbox option was already checked, then it would correctly
uncheck it. This bug only occurs when importing checkbox fields and only in EAV type format.



If the
Data Quali
ty

module was used in a project, in which a user
excluded

some of the
results

by clicking
the "exclude" link next to a DQ result, then if a user later
erased all the project's data

by clicking the
"Erase all data" button on the Other Functionality page, th
en it would mistakenly not remove the exclusion
data on the back
-
end, which could inadvertently cause old exclusion data to be attributed to a new record
if a record is created with the same name as a record that existed prior to erasing all records, espec
ially if
using auto
-
numbering for records. This could cause some results in the Data Quality module to be
inadvertently hidden in this particular scenario.



If the
Data Quality

module was used in a project, in which a user excluded some of the results by c
licking
the "exclude" link next to a DQ result, then if a user later
deleted a record

that had results excluded for
Data Quality, then it would mistakenly not remove the exclusion data on the back
-
end, which could
inadvertently cause old exclusion data to
be attributed to a new record if a record is created with the same
name as the deleted record, especially if using auto
-
numbering for records. This could cause some results
in the Data Quality module to be inadvertently hidden in this particular scenario.



When a project's language is set to "
Japanese
" and a user exports a PDF of a data entry form that contains
Japanese (SJIS
-
encoded) characters in a field label, note, or option label (or in the data of a text/notes
field), then it would not output those ch
aracters correctly in the PDF.



Whenever an API request is made, it was mistakenly
not logging the API request

information in the
redcap_log_view table (although it was correctly logging in the redcap_log_event table for any actions
made).



If
surveys

have

become orphaned due to the
deletion of a data collection instrument

that had been
enabled as a survey, it would still mistakenly display these orphaned instruments on the
project's left
-
hand menu
, although they appear invisib
le except for the status icon.




For installations utilizing table
-
based authentication, if a user entered the answer to
their password
recovery question

as non
-
ASCII encoding multi
-
byte string (e.g.
Japanese
), then it may have mistakenly
saved their answer as blank text on the back
-
end
. This would inadvertently allow someone to easily
recover that user's password by leaving the text box blank when asked the user's security question after
clicking the "Forgot your password?"
link on the REDCap login page.




Projects in the
My Project lis
t
were

not sorting correctly

when sorted by Type or Status.



When a user is making
production changes

to a project, it may on certain rare occasions
mistakenly think
that a critical issue exists

due to a field with data being deleted when in fact no fields

are being deleted,
thus causing confusion for the user and/or REDCap admin.



For a project that utilizes surveys, in which the project was
previously longitudinal

and had one or more
Automated Invitations defined
, if the project was
changed to a classic p
roject
, then the Automated
Invitations button(s) on the Online Designer page would mistakenly still show that they were enabled,
even though they might only be enabled for an event that is now orphaned since the project is no longer
longitudinal. It now ig
nores any Automated Invitations that have been defined for orphaned events.



On the Data Dictionary Upload page for a project in production status, the link "
Download Data Dictionary
with drafted changes
" would
mistakenly

be
displayed

all the time, including
even when the project is not
in Draft Mode
. This would result in confusion if a user clicked the link before enabling Draft Mode, in
which the data dictionary would download as an empty file (aside from the header row). This downlo
ad
link now only displays when the project is in Draft Mode.



For certain operating systems for the database server,
uploading a file

on a form/survey, Send
-
It, or in the
File Repository
would fail if the file extension of the file was longer than six
characters
. It now accepts up
to twenty characters for a file's file extension.



Several PHP files within REDCap were found to have been mistakenly encoded as UTF
-
8 (rather than
properly encoded as ANSI), which would cause certain functionality not to beha
ve correctly or at all. This
includes
performing checks for duplicate values for a Secondary Unique Field

on forms/surveys,
performing the
auto
-
complete feature when typing a new record name in a project
, and performing a
data search on the data entry form

of a project. Many of these files have been affected as far back as
version 4.0. These issues apparently only affect certain web server configurations (details of which are
unknown), so only a small minority of servers running REDCap will be affected by t
hese issues.



If utilizing
Data Access Groups

in a project and the current user belongs to a DAG, then it would mistakenly
not display the number of records

in the Project Statistics table on the Project Home page.



When composing
survey invitations

on the

Participant List page, if the user specifies a
time in the future

for the emails to be sent,
in which the year is a later year than the current year but the month
-
day occur
before the month
-
day of today's date
, then it would mistakenly give a pop
-
up error

saying that the
invitations cannot be sent at that time because that date/time exists in the past, which is incorrect.



If a project has more than 1000 fields and a user attempts a data export on the
Data Export Tool

page, if
they use the Advanced Options

for export and then select one or more instruments to export from the list
of instruments, then it will
mistakenly add the variables of any Descriptive fields

in the syntax files
produced for the statistical analysis packages. Since Descriptive fields hav
e no data, they should not be
included. This behavior does *not* occur if the user simply pushes the "Export all data now" button or if
they select individual fields to export on the Advanced Options page, but only when they are presented
with individual f
orms to export, which only occurs when more than 1000 fields exist in the project.



Survey pages will not display correctly if using Internet Explorer 10
. It now automatically forces IE10 to
emulate IE9 in order for the page to render correctly.



If using
the randomization module in a project, if any f
ields involved in the randomization have a section
header immediately before them and the user attempts to delete the section header

in the Online
Designer, then it would mistakenly prevent them from deleting
the section header and give an incorrect
error message about attempting to

delete a randomization field.




If a
record had already

been
created

in a longitudinal project that had scheduling enabled and a user
navigated to the
Scheduling

module and entered
that existing record name in the "
add a new record
" field
as if to schedule that participant but inadvertently entered the record name
in a different case

than
originally created (e.g. "tom" vs. "TOM"), then it would mistakenly schedule the participant und
er the
different case value, thus ultimately causing the record to be bifurcated with some of its data stored under
one case and the rest under the other case. This bifurcation of the record could cause issues during data
exports and in reports.



When perf
orming an
API data import

on a
longitudinal

project, it would mistakenly
not trigger
Automated Survey Invitations
(if set up) on the occasion when they should be triggered. This does not
affect classic
-
style projects, and this bug only occurs when importin
g data via the API.



When utilizing Automated Survey Invitations or the Real Time Execution functionality for custom Data
Quality rules, they would not get triggered/executed correctly if the rule's logic referenced a field and its
blank/null value (e.g. [
field] = "") or if it referenced a checkbox field's or Form Status field's default value
(e.g. [checkbox(2)] = "0", [form_status_complete] = "0"). This would cause Automated Invitations not to be
emailed and would cause Data Quality not to return valid res
ults, respectively. NOTE: Referencing field
default values in DQ rule logic has worked for the main Data Quality page ever since version 5.1.3, but it
has never worked in the Automated Survey Invitations or Real Time Execution functionality for Data
Qualit
y rules.



If performing an API data import, in which the "returnContent" parameter is set to "count" and the "type"
parameter is set to "eav", it would mistakenly return an incorrect count of the number of records being
added/updated during the import.



If

any drop
-
down, radio, or checkbox field on a data collection instrument has one or more options in
which one has a coded value that is the exact same as another option but with leading zeros (e.g. 1 and
001), it would not always pre
-
select the correct opt
ion again when revisiting the page after having saved a
value for the field. So if a user revisits the page and clicks Save, it will mistakenly overwrite the old value
with a new incorrect value if the wrong option happened to get pre
-
selected as a result
of this bug.



On certain rare occasions, if a user clicks the "move field" icon in the Online Designer, the pop
-
up dialog
would mistakenly not display but instead do nothing.



If a user deletes an individual record in a project in which the record contains

uploaded files for Upload File
fields, it was mistakenly not marking those files for deletion but instead leaving them orphaned to take up
space on the server.



On certain older versions of PHP, a string of text (e.g. "object id #5") would mistakenly get
displayed at the
bottom of the API page within a project.



If Automated Survey Invitations have been set up for a data collection instrument that is enabled as a
survey in a project, and then the instrument is deleted, it would mistakenly still continue to

send
automated invitations (when triggered) for the deleted instrument to the survey participants, thus
presenting them with a blank survey page.



On certain versions or configurations of PHP, some pop
-
up dialogs would not load, and the project counts
(re
cords, fields, etc.) on the My Projects page would not load. This was due to incorrect JSON encoding by
REDCap.



For the Data History pop
-
up on data entry forms, if a field's variable name exists as the suffix of another
variable name on that same form (e.
g. event_category and sub_event_category), then the table of the
Data History pop
-
up will incorrectly report extra rows for the field with the shorter variable name, in which
those extra rows actually belong to the field with the longer variable name. This

could lead to confusion
regarding the field's past data values.



When using the Custom Record Label and performing a PDF export of all records on the Data Export Tool
page, it would not always display the Custom Record Label value correctly at the top rig
ht corner of each
page in the PDF.



If a user is adding or editing a calculated field in the Online Designer, it would mistakenly report that there
is an error in the calc field's equation if the equation contained the <= operator. This would prevent norma
l
users from saving their calculated field, although super users would be able to save it but with a warning
tha
t the syntax may be incorrect.




When doing a PDF export of all records on the Data Export Tool for a longitudinal project, it would
mistakenly include undesignated instruments in the PDF, which would never have any data. It now only
includes designated instruments in the PDF for longitud
inal projects.



If a user was given access to a project but had never accessed REDCap before and they navigated directly
to a project page without beginning with REDCap's Home page or My Projects page, then it would display
an incorrect error message telli
ng them that an incorrect authentication method exists for that project,
which would not be true. This excludes Table
-
based authentication users and thus only occurs for external
authentication methods (e.g. LDAP, Shibboleth).



When using the Data Search f
eature on a data entry form, it would sometimes mistakenly return a
previous search result if the user changed the field upon which to search but entered the same search
query text from a previous search while on that page. This is due to a caching issue i
n the search
mechanism.



If using Shibboleth authentication or another kind of server
-
level imposed authentication (i.e performed
outside of REDCap) and have surveys with the option enabled to display plots of aggregate survey results
after a respondent ha
s completed the survey, then the plots would mistakenly not be displayed on the
page.



If a user uploads a data dictionary using a program that stores dates in MM/DD/YY format (e.g. Microsoft
Excel on a Mac) rather than in MM/DD/YYYY format, in which the u
ser used a minimum or maximum
validation range for a date or datetime field in their data dictionary, then it would not correctly save the
min/max validation values when uploading the data dictionary, thus leading to possible erroneous
validation errors on

the data entry form or survey page where that field gets displayed.



For installations where users must request that their project be moved to production (rather than doing it
themselves), if they send the request to the admin but then delete their projec
t before the admin moves it
to production, it will mistakenly still allow the admin to move it to production even though it is "deleted".



For projects utilizing Double Data Entry, if any user uploads a file onto a File Upload field on a data entry
form, t
hen DDE person 1 or 2 would mistakenly not be able to download the file because of an erroneous
error message.



When viewing an incomplete survey response on a data entry form and then clicking the "Edit response"
button at the top, in some browsers the fl
oating Save buttons would spill out of the black box at the top
right of the page.



If a Secondary Unique Field is set within a project (longitudinal only), and that field is used in a calculated
field in which the calculated field exists on a separate eve
nt from the Secondary Unique Field, then the
Secondary Unique Field's value would get mysteriously erased (with no trace in the logging) whenever the
calculated field's value is saved.



If using Double Data Entry and a DDE user

#1 or #2

renames a record on

a data entry form, it would
mistakenly create a new record with only part of the original record's data and would leave the original
record intact.



If using Double Data Entry and DDE user

#1 or #2
opens a field's Data History popup on a data entry form,
it would mistakenly not display anything for the field even if there is a data history to display.



A unique data access group name or unique event name would not be automatically generated but instead
left blank if the entire name of the group/event was c
omposed of multi
-
byte characters (e.g. Japanese).



When modifying the name of an existing data access group by clicking on its name in the DAG table, it
would not save the new group name correctly if it contained any multi
-
byte characters (e.
g. Japanese).




When exporting the PDF of a data collection instrument, on random occasions for multiple choice fields
that had right
-
vertical (RV) alignment and also had a long Field Note that would cause the text to wrap
onto the second line in the PDF, it would mista
kenly display a checked checkbox in the PDF for the second
line of the Field Note rather than the Field Note text itself.



When using an "sql" field type that returns a value containing an apostrophe, double quote, or comma, it
would not always display or
save correctly in the field drop
-
down on forms/surveys. And when
downloading the PDF of a data collection instrument, it would mistakenly display the HTML character code
for a comma (&#44;) instead of the comma itself in the option label of an "sql" field
in th
e PDF.




If the Secondary Unique Field is enabled for a longitudinal project containing multiple arms, then the
Record Status Dashboard would mistakenly display any given record as if it contained data for all arms (i.e.
displays red circle icons for a
ll events on all arms) even though it may contain data on only one arm.



When downloading the data dictionary or exporting it via the API, it was mistakenly replacing any line
breaks inside section headers with a single space. It now keeps the line breaks
intact for section headers.



After performing a data export in the Data Export Tool and then downloading the CSV Labels data file, it
would mistakenly log the action on the Logging page as if the user had downloaded
the CSV Raw data file
instead.




On REDCa
p's login page, a user could accidentally submit the login form multiple times in a row if the user
is using Internet Explorer and holds down the Enter key on their keyboard (or hit the Enter key multiple
times in quick succession) after placing the cursor

on the "Log In" button on the page. In a high majority of
cases, this would not cause any issues at all. Although in the case where a user is on a data entry form and
creating a new record in a project where record auto
-
numbering is enabled and somehow th
eir
authenticated session disappears while on the form without it giving them the 2
-
minute and 30
-
second
warning (although it is not sure how this could happen), then it could cause the record to get created twice
in a row as two duplicate records when the
y are forced to log in again after clicking the Save button on the
data entry form.



When deleting a document for a File Upload field on a given record via the API, it was mistakenly not
marking the document for deletion on the back
-
end, thus would remain
stored in the file system instead of
finally deleting it from the server 30 days after being marked for deletion.



When viewing the Data History popup on a data entry form for a File Upload field for a given record, it
would mistakenly not display anything

for the field's data history.



For projects that utilize surveys and also utilize data access groups, in which the current user is assigned to
a group, the Survey Invitation Log would mistakenly display all survey invitations sent for *all* participants
r
ather than just participants assigned to their group or participants not assigned to any group. Now the
Survey Invitation Log will no longer display participants that belong to other data access groups if the
curren
t user is assigned to a group.




Corrected

an issue with user's time of first activity not being correct. If they had used the password
recovery tool (Table
-
based authentication only), the time of them recovering their password would
mistakenly become their "first activity" timestamp.



When export

a data entry form as a PDF, it would take an abnormally long time or even timeout before
outputting the PDF (even for PDFs without data).



The "My Projects" page would mistakenly denote in the Instruments column that surveys existed for a
project when the "use of surveys" in the project was not enabled. This would occur if a user had enabled
"use of surveys" in the project and enabled one or
more surveys, and then disabled "use of surveys".



When a user deletes a record in a project, it would mistakenly display the colored icons next to the
instrument names on the left
-
hand menu, which when clicked would take you to the instrument again to
rec
reate that record. This could be confusing to some users and cause them to accidentally recreate a
record that they had intended to delete.



When downloading a PDF of a survey that contains a matrix of fields, the PDF would mistakenly not display
the quest
ion number next to the fields in the matrix.



When viewing the event grid on the Designate My Instruments page or when accessing a record's events in
a longitudinal project, it might mistakenly not display the first column of the event grid when using
Inte
rnet Explorer 7 or other older versions o
f IE.




When using Table
-
based authentication in a project, if a user was assigned to a role when that username
did not exist in REDCap as a user yet, it would mistakenly allow it to be added, even though it would
di
splay an error that it could not be added.



Fixed CSS issue, in which a random border was displaying on bottom of each row in a matrix of
fields on data entry forms and surveys.



Data History Widget on data entry forms would not display the logged event fo
r when a field's
value was set to a blank/null value.



In custom reports when setting a field's limiter equal to blank/null, the report would mistakenly not
return records where that field had a value entered but then was later erased. It instead would onl
y
return records where a value was never entered for the field.



When using the "Japanese" language file in a project and exporting a PDF of a form/survey
containing record data, in which a particular field on the form/survey had right custom alignment
and contained a field note in SJIS
-
encoded Japanese text, then that
field note would not display
properly in the PDF but would appear scrambled.



When using the "Japanese" language file in a project and exporting data that is SJIS encoded
Japanese text, it was mistakenly adding a byte order mark (BOM) to the beginning of t
he CSV file
when it should only be doing that for UTF
-
8 encoded text. This could cause the file to not be read
properly when opened.



When using the "Japanese" language file in a project and exporting the PDF of a form/survey, it
would mistakenly not displ
ay matrix headers correctly if they contain Japanese text. Also, if the
record ID field label or record name contained Japanese text, they would also not display correctly
at the top right corner of the PDF.



Typos fixed on a couple pages.



When using the
Scheduling module in a longitudinal project, if an existing record had ad
-
hoc
calendar events but had not been scheduled yet, then it would mistakenly prevent users from
scheduling the record by not displaying the record in the "unscheduled records" drop
-
d
own list on
the Scheduling page.



When copying a project that contains data access groups, in which the user elects to copy all
records/responses, it was mistakenly not assigning the records to the data access groups in the
newly created project after bein
g copied.



The Project Revision History page might mistakenly say that production changes were approved by
the same person that submitted them when it was actually approved automatically by REDCap.
While it is not possible to fix this for previously approv
ed changes, the issue should no longer
occur in the future.



When a survey response that has not been completed is viewed by a user on a data entry form, in
which the user clicks the "Compose survey invitation" button at the top of the page to send an
invi
tation, it would sometimes display an erroneous error saying that the "send time" specified for
the invitation exists in the past when it does not.



When downloading the PDF of a form or survey with saved record data in a longitudinal project
(excludes cla
ssic projects), then it might mistakenly hide some fields in the PDF that should be
displayed. Bug emerged in version 5.6.1.



When downloading the PDF of a form or survey with saved record data, if branching logic dictates
that a field be hidden in the PDF

but the field actually contains data, then it would mistakenly hide
the field in the PDF. It now will always display a field in the PDF if the field contains data. Bug
emerged in version 5.6.1.



When viewing the Graphical Data View & Stats page in a longi
tudinal project, it would not always
calculate the "Total (N)" value correctly because it counted the total records rather than the total
record/event pairs. This would cause other values (e.g. "Missing" count) to be miscalculated as
well.



When entering t
he Start Date for a new schedule in the Scheduling module or editing the date of an
ad hoc calendar event in the Calendar module, the date value was mistakenly not being validated
when entered/changed, which could allow a user to enter a date in an incorre
ct date format if hand
-
entering the date value rather than using the datepicker widget.



If a user edits their instrument
-
event designations on the "Designate Instruments for My Events"
page in a longitudinal project when the event grid is so wide or long
that it scrolls off the page
vertically or horizontally (thus enabling the floating headers for the grid as the user scrolls), then
the grid would mistakenly no longer have floating headers after the user clicked the Save button.



On pages where a table us
es a floating header or floating first column to keep the header/first
column on the page even when scrolling off the page (e.g., reports, event grid page), the table
header would sometimes mistakenly cover part of the first row, thus making it unviewable.