mantidproject / mantid

Main repository for Mantid code
https://www.mantidproject.org
GNU General Public License v3.0
211 stars 124 forks source link

Empty group row on ISIS Reflectometry Table #38023

Open adriazalvarez opened 1 month ago

adriazalvarez commented 1 month ago

Describe the bug

This was found during manual testing of ISIS Reflectometry interface #37994 , and can be reproduced by following the Search by Experiment section of the testing instructions. https://developer.mantidproject.org/Testing/ReflectometryGUI/ReflectometryGUITests.html

When data from searched runs is transfered to the reflectometry table, there is an empty group row on the table that does not disappear, the data transferred gets added below the empty group row.

image To Reproduce

Follow Search by Experiment part of manual testing: https://developer.mantidproject.org/Testing/ReflectometryGUI/

Expected behavior

When transferring data, the initial row should be overridden when it is empty by the new data. This is the behaviour that is found when data is loaded from a .json file: image

Platform/Version (please complete the following information):

Additional context

rbauststfc commented 1 month ago

Thanks for creating an issue for this. Just to add some more context, I think the behaviour has always been this way (you can reproduce it as far back as 6.8, and I expect long before that). It differs from what you see when loading the example batch/json file from the manual tests because loading a file is intended to recreate the GUI (data and settings) as it was at the point the file was saved. If you save a batch file from the interface with an empty first group and then re-load it you will find it also re-loads with the empty first group.

I definitely agree that it would be more intuitive/tidier to remove the empty first group if something is transferred in (although note the empty first group has no functional effect on performing the reduction). Given current capacity in LSS and the fact that users have never commented on this, despite it being like this for some time, I have removed the 6.12 milestone and marked as low priority. It's one we can keep in our backlog in case we ever have a good opportunity to look at it, or if it becomes higher priority at any point.