Note: I'm pretty sure this is a backend change, not a frontend one. Since 1.7.7, having scan data types browseable is a supported configuration (and indeed required for proper functioning of the batch launch plugin to act upon scans). However, the listings for scans aren't great. If I add the xnat:segScanData data type as "Segmentations", then go to Browse > Data > Segmentations, the SEG scan listing has columns for the scan ID and session ID. However, neither of those are clickable. Wouldn't it be much more useful if those were both clickable to take you to the scan report page (yes, we have one!) and session report page? For the xnat:mrScanData data type, it looks like the session link is clickable, but not the scan ID. So, would that mean that this behavior is controlled in the display documents? (hence why I think this is a backend change)
Environment
None
Steps to Reproduce
None
Summary of Technical Changes
None
Root Cause Analysis
None
QA Notes
None
Attachments
2
Activity
Show:
Charlie Moore December 2, 2021 at 7:09 PM
Great, thanks!
I didn't check every single scan data type (I don't think I even have test data for some of them), but I did check a lot of the most used ones and it all looks good. I also made a ticket and closed it for the data type sorting issue: .
William Horton November 30, 2021 at 10:35 PM
Okay, scan listing tables now use REST URLs for both the session and scan links. I've also addressed the display of session labels for mismatched scan modalities. Also found that Segmentation scans hadn't been improved, so those now are updated to match the rest of the scan type displays.
I also got frustrated (for the nth time) trying to add scan modalities in the Administer Data Types console, so added code to core XNAT to sort the list of xsitypes alphabetically in the modal dialog select menu.
Charlie Moore November 22, 2021 at 4:47 PM
Edited
This format of URL for scans doesn't work because scan IDs are not unique. Could we use REST URLs instead? Linking to /data/experiments/$SESSIONID/scans/$SCANID would produce a much cleaner URL and also be uniquely identified. The current URL format only links (for each scan ID), 1 scan on the system (e.g. /app/action/DisplayItemAction/search_value/0-OT1/search_element/xnat:otherDicomScanData/search_field/xnat:otherDicomScanData.ID)
William Horton November 19, 2021 at 3:22 PM
I've enabled links to scan pages, and fixed several instances of broken links to the parent session in the search listings as well. Links from the scan back to parent sessions with multiple scan modalities (i.e. a CT scan within a PET-CT session) can be problematic, but that's a separate issue.
moore.stephen.m December 15, 2020 at 8:28 PM
Force DB change.
Fixed
Pinned fields
Click on the next to a field label to start pinning.
Note: I'm pretty sure this is a backend change, not a frontend one. Since 1.7.7, having scan data types browseable is a supported configuration (and indeed required for proper functioning of the batch launch plugin to act upon scans). However, the listings for scans aren't great. If I add the
xnat:segScanDatadata type as "Segmentations", then go to Browse > Data > Segmentations, the SEG scan listing has columns for the scan ID and session ID. However, neither of those are clickable. Wouldn't it be much more useful if those were both clickable to take you to the scan report page (yes, we have one!) and session report page? For thexnat:mrScanDatadata type, it looks like the session link is clickable, but not the scan ID. So, would that mean that this behavior is controlled in the display documents? (hence why I think this is a backend change)