Version : 89.3
Released : 2026-08-15
Changes in this Release
Issue |
Type |
Module(s) |
Description |
|---|---|---|---|
5128 |
Bug |
A Test Case run whose browser crashes or stops responding is now recovered as soon as the problem occurs, on both Veeva and Rave. Previously some browser operations, such as taking a screenshot of a form or opening a page after data entry, hid the failure, so the run carried on issuing commands to a browser that was no longer there. Each of those commands waited for the full timeout before failing, and runs could continue in this state for several hours before finishing or being cancelled. The browser is now relaunched and the run resumed at the point it was interrupted. |
|
5017 |
Bug |
When Medidata Rave shows a temporary error page, Test Case runs no longer fill the run log with thousands of repeated messages. The runner checks many times a second whether the page it wants has appeared, and each check recorded that the error page was showing — one minute of a temporary error produced over seven thousand log entries. The error page is now reported once when it appears rather than on every check, and the runner pauses briefly between checks instead of retrying as fast as the browser can answer. |
|
5072 |
Bug |
A Test Case step that finds itself on an unexpected page now gives up after a short time instead of running for the best part of an hour. Each check for an element on the page waits up to a set time before giving up, and a page in the wrong state made every check wait the full time, one after another. Steps could take fifty minutes this way. The step now stops once too much time has been lost to checks that found nothing; the browser is restarted and the step tried once more, and if the page is in the same state again the step fails and reports which elements it was looking for. The rest of the Test Case still runs. Checks that find what they are looking for reset the count, so a long step doing real work is unaffected. |
|
5154 |
Bug |
Test run logs now report why a Rave page visit forced a restart - a role-restricted data page, another Rave error page, or a page that did not render - instead of reporting every case as a logged-out session. A role-restricted data page is now reported and failed immediately rather than retried, since the restriction cannot clear within the run. |
|
5155 |
Bug |
A data page that is restricted to a role the test run does not hold now fails the step immediately, naming the restriction, instead of being retried and re-running the whole test case. |
|
5148 |
Bug |
Test runs on the new Rave EDC now require the iMedidata Client and Study Group, which identify which study to test, and show them on the run and its report. Existing new Rave EDC test runs must be opened in the Run wizard once to set them before they can run again. Where more than one study still matches, the run now stops and names where they were found, rather than testing whichever Rave returned first. |
|
5160 |
Bug |
Screenshots of a Subject in the site list no longer fail when Vault is showing a service announcement. The runner moves announcement banners out of the way before clicking, but it was checking a point half a pixel away from the one the click actually uses, so a banner overlapping the target by a single pixel was left in place and intercepted the click. The check now uses the same point as the click. |
|
5017 |
Bug |
When Medidata Rave shows a temporary error page, Test Case runs no longer fill the run log with thousands of repeated messages. The runner checks many times a second whether the page it wants has appeared, and each check recorded that the error page was showing — one minute of a temporary error produced over seven thousand log entries. The error page is now reported once when it appears rather than on every check, and the runner pauses briefly between checks instead of retrying as fast as the browser can answer. |
|
5072 |
Bug |
A Test Case step that finds itself on an unexpected page now gives up after a short time instead of running for the best part of an hour. Each check for an element on the page waits up to a set time before giving up, and a page in the wrong state made every check wait the full time, one after another. Steps could take fifty minutes this way. The step now stops once too much time has been lost to checks that found nothing; the browser is restarted and the step tried once more, and if the page is in the same state again the step fails and reports which elements it was looking for. The rest of the Test Case still runs. Checks that find what they are looking for reset the count, so a long step doing real work is unaffected. |
|
5128 |
Bug |
A Test Case run whose browser crashes or stops responding is now recovered as soon as the problem occurs, on both Veeva and Rave. Previously some browser operations, such as taking a screenshot of a form or opening a page after data entry, hid the failure, so the run carried on issuing commands to a browser that was no longer there. Each of those commands waited for the full timeout before failing, and runs could continue in this state for several hours before finishing or being cancelled. The browser is now relaunched and the run resumed at the point it was interrupted. |
|
5148 |
Bug |
Test runs on the new Rave EDC now require the iMedidata Client and Study Group, which identify which study to test, and show them on the run and its report. Existing new Rave EDC test runs must be opened in the Run wizard once to set them before they can run again. Where more than one study still matches, the run now stops and names where they were found, rather than testing whichever Rave returned first. |
|
5128 |
Bug |
A Test Case run whose browser crashes or stops responding is now recovered as soon as the problem occurs, on both Veeva and Rave. Previously some browser operations, such as taking a screenshot of a form or opening a page after data entry, hid the failure, so the run carried on issuing commands to a browser that was no longer there. Each of those commands waited for the full timeout before failing, and runs could continue in this state for several hours before finishing or being cancelled. The browser is now relaunched and the run resumed at the point it was interrupted. |
|
5160 |
Bug |
Screenshots of a Subject in the site list no longer fail when Vault is showing a service announcement. The runner moves announcement banners out of the way before clicking, but it was checking a point half a pixel away from the one the click actually uses, so a banner overlapping the target by a single pixel was left in place and intercepted the click. The check now uses the same point as the click. |