[dicom archive] Fix dicom archive details links

[maximemulder]

Brief summary of changes

Replace the obsolete link patches for the dicom-archive/view-details page by proper links.

The first patch in view_details_link.js looks like it is supposed to patch the current links, but its mode of action is obsolete.
The second patch refers to an HTML class that currently does not exist in Loris, and is therefore very likely dead code.

Testing instructions (if applicable)

1. Go to the dicom-archive/view-details and click the links. They should send the user to the MRI violations page with the corresponding filters applied, which can lead to an empty result.

Links to related issues

• Resolves [dicom archive] Acquisition ID link not working correctly #9080

[nicolasbrossard]

I think we should redefine where the link takes you. With this PR, the link will take you to the violations module and show all violations that have the same patient name as the archive that is displayed on the DICOM archive page. Problem is, there can be more than one archive with the same patient name since there can be more than one upload for a given session. Consequently, you might see in the MRI violations module records that are not associated to the archive in the DICOM archive module. @cmadjar @driusan Thoughts?

If we choose to leave the behavior as is, I'll approve the PR since it works as expected on my VM.

[cmadjar]

@nicolasbrossard I agree with you that the ideal behaviour would be to filter by StudyUID, unfortunately, there is no StudyUID filter in the MRI violation module at the moment. Could be nice to add it though!

In the meantime, I think the proposed fixed will at least allow users to filter for PatientName instead of having all the MRI violation displayed.

I had no idea this link even existed, lol.

@driusan thoughts? Should we modify the MRI violation module to add a StudyUID filter that could be used for that link or can we consider that that fix is already much better than current behaviour?

[driusan]

If this is the current behaviour we should just fix the bug here and discuss / possibly change the link elsewhere.

(I believe the reason it uses patient name is because of the case where the scan is mislabeled. StudyUID might work, but would need to think it through whether there are cases where it doesn't...)