Subjects assigned to wrong branch visit

Study designers and rule developers: Now, the treatment arm assigned to a subject and the answer to a branching question determine a subject’s subsequent visits. Previously, only the answer to a branching question determined the next visits, even when the subject was assigned to a treatment arm.

Retracted workaround: None. (Issue 35037630)

JavaScript custom rules may not work with Adverse Events (former known issue)

Study designers: Now, in a study's draft, you can configure a successful JavaScript rule for all questions in a form assigned to an Adverse Event. Previously, when a form contained many questions, configuring a custom rule for each question caused the API endpoint behind the rule to possibly fail.

Retracted workaround: Study designers are no longer discouraged from configuring custom rules for each question in a form, even if the form contains a high number of questions. (Issue 34775012)

Study version issues can be encountered after moving a study version to the Approved container if the browser is closed prematurely (former known issue)

Study designers: Now, when you move a study version from the Testing container to the Approved container and you accidentally close your browser before this action is completed in the backend, this won't affect your study design anymore. Previously, if you closed your browser before the action was complete, you may have encountered issues with associating randomization lists to a study version or when randomizing a subject.

Retracted workaround: None. (Issue 34324333)

Clearing a rule's variable determines the clearing of its target

Rule designers and testers: When a custom rule's variable is cleared, the rule's mechanism is updated to determine whether the target field should be cleared or updated. Previously, after a rule ran, its target field was automatically cleared every time a variable was cleared, as well. For example, if you cleared another question's answer in a form, and that question was used as variable in a Date/ Time helper function, the read-only Date/ Time field was also cleared. Instead, the target field should have been updated with the current date when the latest update in the form was performed. (Issue 34873328)

Rule targets are not automatically updated for a DateTime rule

Rule designers and testers: Now, when a DateTime rule is configured for a Date/ Time field in a form, the target field of that rule is automatically updated whenever a data change occurs in the form. For example, if all fields in a form are completed, the rule automatically updates the Date/ Time field to the current date. If a field is left empty or cleared, the rule then clears the Date/ Time field, as well. Previously, the rule did not automatically refresh its target field. This issue occurred when the Date/ Time field was read-only. (Issue 34877289)

An error occures for a custom rule built with the getCurrentCycle helper function

Rule designers and testers: Now, when you create a custom rule using the getCurrentCycle helper function, and its target is part of a two-section form, the rule is running as expected and no errors occur. Previously, the getCurrentCycle helper function returned the current event instance number of the rule variable, instead of the current event instance number of the rule target. (Issue 34956461)

Automated query rules cannot run

Rule designers: Now, when you create, test, and then publish rules for automated queries, the rules work as expected. Previously, custom rules for automated queries, when published in a live study version, started failing although they passed the testing phase. (Issue 34869167)

The getDateDMTFormat () helper function is returning an incorrect time

Rule designers: Now, the getDateDMYFormat () helper function returns the time in the format of "HH::mm:ss", as expected. Previously, the time was displayed incorrectly using this helper function.

For example, if a site user entered the time as "10:10", the helper function would return a "10:10" value. If a site user entered the time as "10:00", the helper function would return a "10" value. Now, when a site user enters the time as "10:00", for example, the helper function returns a "10:00:00" value, counting the hour, the minutes, and the seconds. (Issue 34867905)

The Rule Editor takes several minutes to load variables in a drop-down (former known issue)

Rule designers: Now, on the Rule Editor dialog, when you attempt to select a visit from the Variable drop-down,values in the drop-down load immediately, as expected. Previously, it took around 2.7 minutes for the variables to load in the drop-down. This used to be a performance issue caused by the high number of visits configured in a larger study.

Retracted workaround: None. (Issue 34789014)

A validation rule for a partial date does not work (former known issue)

Study designers: Now, when you create a Date/ Time question with a Minimum Allowed Answer of YYYY and an On or After validation rule (specifying that the date must not be earlier than the year 2022), site users can complete that Date/ Time question without running into any issues.

Previously, because the validation rule used the date of its creation as the time reference, whenever a site user did not enter the complete date of when the validation rule was created, an error message was displayed in the form. This issue was fixed by modifying certain parameters in the backend of the application to ensure that site users can successfully complete a Date/Time question in this particular use case.

Retracted workaround: None. (Issue 34734551)