Use VirtualStudy service from public VS controller

[forus]

Summary

Submitting dynamic virtual studies without explicitly defined sample IDs previously resulted in a NullPointerException. This behavior was incorrect, as dynamic studies are designed to derive their sample IDs dynamically from filters, not require them upfront.

Root Cause

The issue was traced to the public Virtual Study controller, which was invoking the session service directly. That service assumed precomputed sample IDs and therefore failed for dynamic studies.

Fix

• Updated the public VS controller to use the ** VirtualStudy service**.
  • When handling public dynamic virtual studies, the controller now reuses the same computation from the virtualStudyService that is already implemented for regular virtual studies to compute sample IDs dynamically based on the provided filters.
• This aligns the implementation with the intended design and prevents null-related failures.
• Sample counts are now calculated dynamically as well, ensuring they stay in sync with the underlying filters.

Result

• Public dynamic virtual studies can now be submitted safely without specifying sample IDs, as expected.
• Landing page sample counts are no longer stale and reflect the current filter-based computation.

Please merge the fix to the v6 version as well #11891

[pieterlukasse]

Thanks @forus .
Can you please clarify the issue description? I'm not sure I understand this part:

The controller now computes sample IDs dynamically based on the provided filters when handling public dynamic virtual studies.

Does this mean that computation of "sample IDs dynamically based on the provided filters" has not been occurring yet? Or is this an issue specifically with the public virtual studies controller? If it is just this controller, why would it now need compute the sample IDs dynamically instead of just reusing the same computation already implemented for the regular virtual studies? Or is that what you meant?

[forus]

@pieterlukasse Thanks for the review!

Find my answers below.

Does this mean that computation of "sample IDs dynamically based on the provided filters" has not been occurring yet? Or is this an issue specifically with the public virtual studies controller?

Indeed, the computation has not been running for the public virtual studies controller only, which lists public virtual studies on the landing page. However, the calculation has been occurring for the session service endpoints, which are used everywhere else for virtual studies.

If it is just this controller, why would it now need compute the sample IDs dynamically instead of just reusing the same computation already implemented for the regular virtual studies? Or is that what you meant?

It reuses the same computation in the virtualStudyService that is already implemented for regular virtual studies. That is precisely the point.

[pieterlukasse]

Thanks @forus , I see now. Basically the code is adjusted to correctly use getUserVirtualStudies instead of just sessionServiceRequestHandler.getVirtualStudiesAccessibleToUser(ALL_USERS)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
5.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud