Forms, visits, and rules

Fixed issue	Fixed in	Description
39940668	26.3.0.1	Deleting repeating forms no longer create duplicate records Duplicate records are no longer generated when repeating forms are deleted. Previously, deleting a repeating form could sometimes create duplicate records for the REMOVED operation. The duplicate records could show on different reports, Oracle Clinical One Analytics, and other downstream applications.
39791172	26.3.0.1	The skipped-visit processing no longer generates incorrect Not Answered data flag records for repeating forms When a visit is skipped, the asynchronous processing no longer generates system-user Not Answered records that could lead to duplicate downstream records. Processing is now limited to eligible non-repeating standard forms; repeating forms are skipped before data elements are created or cleared. Typically, for an item in a repeating form, if data was entered and then cleared, the cleared record remains associated with its repeat context. Previously, during skipped-visit processing, that repeat context was not retained or recognized and the process created a separate current Not Answered record with all repeat fields null. During downstream processing, these records could resolve to the same reporting key and result in duplicate-record failures. This fix prevents new incorrect records from being created through this flow. Existing affected records are not automatically removed and may require separate data remediation. For more information, please reach out to your Oracle point of contact.
39865250	26.3.0.1	Rule clearing event completes successfully when multiple calculation rules have the same target When multiple calculation rules target the same read-only item, clearing a triggering item now completes correctly, the updated form saves and rules run with no errors. Previously, concurrent rule-driven clear requests for the same target could result in duplicate clear actions. The failed duplicate rule clear created an invalid, system-generated data-element row with reason RULES_ERROR, leaving the item in a conflicting state. Subsequent save attempts could then fail, and the form could intermittently be unavailable to open. Existing invalid records are not automatically removed and may require separate data remediation. For more information, please reach out to your Oracle point of contact.
39995001	26.3.0.1	Choice options with blank labels are properly handled in form design Choice options with blank labels are now removed from the form’s options array and excluded from form save requests. With this, when a newly added answer option with a blank label is deleted, the update is saved correctly .Previously, Clinical One Cloud Service could persist active choice options without a label source, causing form updates save requests to fail with an Update form failed error message. This also prevented form retrieval and caused the draft container to display no forms with a continuous loading indicator.
39835084	26.3.0.1	Copy forms that contain conditional actions on choice questions When updating the choice options of a question with conditional actions, the action rule configuration is now properly managed, ensuring that updates of this nature do not result in broken rules that may cause issues when trying to copy the form and save subsequent changes on it. With this, users are able to edit and save copied forms successfully, without any server side errors. Previously, an error was thrown when trying to save a copied form with a specific combination of configuration history: a choice question with conditional actions, with prior changes to that question’s option configuration.
38478544	26.3.0.1	Rules running on repeating form data no longer result in incorrect duplicate auto queries Rules that are processed on repeating form instances are now assigned a unique condition index which ensures that duplicate auto-queries are not generated. Previously, a data synchronization issue could lead to multiple auto-queries being created if multiple instances were updated in quick succession.
39870079	26.3.0.1	Visit status updates calculate correctly when parallel requests update multiple forms in the same visit Form status now persists directly, enabling the visit status calculation to successfully identify the current visit status. Previously, as form status was saved asynchronously, if multiple forms were updated at the same time then the visit status calculation could happen before the asynchronous form update save completed. This could result in stale form-status data being used for the visit-status calculation, and so the visit could remain In Progress even when all forms were Complete.
39844133	26.3.0.1	Visits can now be skipped after data is cleared via rule execution You can now successfully skip visits that were already started and cleared, when at least one data point is cleared via a rule. Previously, when clearing a form item via rule execution, the visit status was not properly updated to New, therefore the visit could not be skipped.
39355195	26.3	Overall sign status is correctly calculated for forms and visits Visit and form level signatures are now handled correctly, showing the visit and form as SIGNED when all the valid trigger conditions are already signed. This means that when no other configurations apply, signing at the casebook level properly signs the unsigned visits and forms. Previously, UNSIGNED records were being incorrectly created on the form and visit levels that could not be resigned as no signature configurations were really applied on that form.
39401563	26.3	Inline repeating forms display validation messages consistently when entering more characters than allowed Now, inline repeating forms display the appropriate validation message when text entered in a field does not meet the configured requirements. This behavior is consistent with other form-entry views.
33608035	26.3	Freeze Data button displays correctly for visits Now, Clinical One Cloud Service displays the Freeze Data button only when visit data is eligible to be frozen. When all applicable visit data is already frozen, Clinical One Cloud Service hides the button.
38874915	26.3	Log visit names display correctly Now, Clinical One Cloud Service displays the visit name defined in the latest study version for log visits instead of displaying the default Adverse Event name.
37294319	26.3	Query List page loads faster Now, the Query List page loads more quickly, especially for studies with a large number of queries or sites.
39550865	26.3	Ready to Verify selections verify only displayed data points Now, when users apply the Ready to Verify filter and select all displayed data points for verification, only the displayed data points are verified. Data points that are not displayed by the Ready to Verify filter are not verified.
39736339	26.3	Auto-assigned queries can be reassigned from retired roles Now, users can reassign auto-assigned form or visit queries from a retired role to an active role. Previously, when an auto-assigned query was assigned to a retired role, users could not select a new active role from the reassignment list.
39601486	26.3	Subject visit actions no longer result in intermittent errors Now, users can open subject visits, load forms, enter data, save data, and view subject lists without intermittent errors.
39620170	26.3	Clinical One Cloud Service prevents duplicate form-status records after study version updates Now, when a site or bulk study version update triggers form-status processing, Clinical One Cloud Service scopes the processing to the applicable site. This prevents duplicate form-status records for the same form. Note: This fix prevents new duplicate form-status records. Existing duplicate records may still exist from previous study version updates.