Forms, visits, and rules

Rule re-run fails due to changes for notification rules

Rule designers: Now, rule re-run completes successfully when publishing a rule in Testing mode and re-running the rule in Active mode. In both cases, no errors are encountered in the UI and the Rule re-run complete emails are received. Previously, rule re-run and debugging would encounter failures when rule re-run and debugging were null.

Retracted workaround: None. (Issue 34151802)

Signing subject visit fails when data is captured for the same visit under different study versions

Sponsor and Site users: Now, you no longer encounter the error, Due to an unexpected error, subject xxxxxx couldn’t be signed, when signing a subject visit where data entry occurs prior to and after a new study version is applied. Previously, the error would be encountered in those cases where data entry was started at a visit and additional data was entered after a new study version was applied to a site.

Retracted workaround: None. (Issue 34098859)

Dynamic section of a two-section form cannot be saved (former known issue)

Site users: Now, when you enter data using the dialog and not by inline editing of the repeating table of a two-section form, you can save all data. Previously, when you attempted to save data that was added in the dynamic section of a two-section form, you could not save the data. This occurred when data was entered using the dialog and not by inline editing a repeating table of a two-section form.

Retracted workaround: You no longer have to fill out and save the questions before the table, then enter and save data for the second section (the questions in the repeating table). (Issue 34052489)

Visit details are not returned as expected by the getValues JavaScript expression (former known issue)

Rule designers: Now, when you run a rule using the getValues JavaScript expression, you will see visit data returned according to the visit schedule. The issue was originally caused by the presence of dynamic visits in a visit schedule.

Retracted workaround: None. (Issue 33088502)

You cannot assign a locked form to a visit

Study designers: Now, you can assign a locked form to a visit in a study. Previously, while a form was edited and locked by one study designer, another study designer could not assign that form to a visit in the study. (Issue 33773027)

A copied study’s title is truncated (former known issue)

Study designers: Now, when you copy a design from one study to another, and the study's name is too long, an ellipses is displayed to indicate that there is additional text that is not shown. Previously, after copying a study's design, the study’s title was truncated on the Home page.

Retracted workaround: You can still hover over the study title and you’ll see the complete study title. (Issue 33605369)

Another study designer can delete a locked form (former known issue)

Study designers: Now, you can no longer delete a locked form, as expected. Previously, you could delete a locked form while another study designer was editing that form. After deleting the locked form, when the other study designer attempted to save their changes, an error message was displayed.

Retracted workaround: None. (Issue 33664784)

Questions are not properly ordered in a lab form (former known issue)

Study designers: Now, in a lab form, when you re-order questions in the repeating form table, questions preserve the order you just created and are also numbered consecutively, as expected. Previously, when you attempted to re-order questions in a lab form repeating table, upon saving your changes, you may have noticed that those questions were not properly numbered in the table.

Retracted workaround: None. (Issue 33699473)

A Show Form dynamic rule is still effective despite being removed (former known issue)

Study designers: Now, when you remove a Show Form rule from a question and you apply that change to a live study version, the form that was previously displayed dynamically is now displayed all of the time, as a static form. Previously, in Draft mode, when you removed a Show Form rule from a question for a live study version, you may have noticed that the dynamic form was still displayed dynamically, when it should have been displayed as a static form.

Retracted workaround: None. (Issue 33736682)

Getvalues helper function does not work for flat forms (former known issue)

Rule designers: In a standard form (a form that is not repeating), whenever you run a Getvalues rule on an empty field, the rule returns the expected null value. Previously, running the Getvalues rule helper function only returned a null value when the field was specifically cleared.

Retracted workaround: None. (Issue 33067140)

A question is removed from a question group when dynamic rules are added

Study designers: Now, when the determining question of a dynamic form is placed within a question group, the question preserves its place within the group when you move the study from Draft to Testing. Moreover, all questions in the respective question group are properly ordered. Previously, the determining question of a dynamic form, if placed in a question group, was removed from the group whenever you moved the study from Draft to Testing. (Issue 33821413)

GetCurrentCycle helper function does not retrieve the proper result

Rule designers: Now, when you attempt to modify an operand for a GetCurrentCycle custom rule for cycle visits, the appropriate result is displayed. Previously, upon modifying the rule's operand, you may have noticed that the rule was retrieving data for another cycle than the one that you just indicated. (Issue 33825640)

The Visit Status API is not working properly (former known issue)

API users: Now, when attempting to configure a Show Visit dynamic rule and running a POST API command, you may notice that the API is working as expected. This fix is also available for inserting visits into the schedule of a live study. Previously, when a site user answered the determining question in a way that did not display the dynamic visit, and you ran the API command, you may have noticed that the response indicated a successful command. Instead, the API should have returned an error response because the determining question was not answered in a way that would display the dynamic visit.

Retracted workaround: None. (Issue 33615686)

Associated form does not properly display data (former known issue)

Site users: Now, when you associate two forms in study design, all details of the question generating the link between the two forms are displayed, as expected. Previously, in Testing mode, when answering the determining question that would link a repeating form to another, you may have noticed that only the row number and visit label were displayed.

Retracted workaround: None. (Issue 33856160)

Dynamic form does not work when assigned to cycle visit (former known issue)

Site users: Now, when you assign a dynamic form to a specific visit cycle, that dynamic form is working as expected and the status of the impacted visit is properly updated. Previously, in Testing mode, whenever a dynamic form was displayed as associated with a visit cycle, the status of the impacted visit was not updated properly in the selected cycle.

Retracted workaround: None. (Issue 33733658)

API returns empty array instead of returning null when study design includes at least two items in a repeating form

API users: Now, when a study design includes a repeating form with two or more items, and data is only entered for the first item, null data-elements are being created for the second item as part of the API response. Previously, null data-elements were not being created as part of the API response when there was no data entered for the second item.

Retracted workaround: None. (Issue 34036119)

API returns extra records when study design includes a repeating form and data is entered in a specific manner

API users: Now, when a study design includes a repeating form and data is entered in a specific manner, the correct records are returned in the API response. Previously, the API response would include extra records in the return. This was addressed by adding additional conditions to ensure there is no duplication.

Retracted workaround: None. (Issue 34056494)