[history] Complex types are not (or poorly) supported in the data history display.

[servoz]

Working on mia_processes.bricks.stat.spm.Level1Design(), it is observed that complex type parameters are not displayed correctly in the data history display.
The pipeline:

The data history display:

In fact we have for this case:
dict4runtime == {'sessions': [{'scans': '/data_2/populse_mia_project/test/data/derived_data/swralej-IRMFonct_+perfusion-2016-03-17083444-05-BOLD_CVR_7_53sl_ModeratePNSSENSE-FEEPI-001212_000.nii', 'multi_reg': [[['/data_2/populse_mia_project/test/data/downloaded_data/regressor_physio_EtCO2_ctl.mat']], [['/data_2/populse_mia_project/test/data/derived_data/rp_alej-IRMFonct_+perfusion-2016-03-17083444-05-BOLD_CVR_7_53sl_ModeratePNSSENSE-FEEPI-001212_000.txt']]], 'hpf': 427.2}]}
and
sess_multi_reg == [['/data_2/populse_mia_project/test/data/downloaded_data/regressor_physio_EtCO2_ctl.mat', '/data_2/populse_mia_project/test/data/derived_data/rp_alej-IRMFonct_+perfusion-2016-03-17083444-05-BOLD_CVR_7_53sl_ModeratePNSSENSE-FEEPI-001212_000.txt']]

We need to rework the relevant part of the scripts.

I don't have time to work on this at all at the moment. I open this ticket to keep in mind that we will have to work on ASAP.

The dict4runtime parameter is a special parameter (acting as a messenger between initialisation and runtime). As already mentioned in tickets, I think it should not appear in the history display (userlevel =1). When fixing this ticket, it would be nice to handle parameters with userlevel=1 in the history display.

[servoz]

There's a feature that lets we switch from a file in the history window to the same file in the data browser (if the file is indexed in the database).

The idea is simple, but it's not so easy to code, as we have to take into account all the type possibilities.
To avoid wasting time on cases that don't exist, only the list and list of lists types are implemented for now.
It may be necessary to extend this to dictionary , set, list of dictionaries, etc...
The number of cases could be virtually infinite.
We'll see if the need arises, and if so, there's always time to code an enhancement.

Another simplification is currently being implemented: if an element of the list or list of lists is not an indexed file in the database, we currently consider that all elements are not indexed.
I don't yet have an example in mind like [notIndexed, Indexed, ...], which is why it's currently coded this way, as it simplifies things considerably.
Similarly, if the need arises, we'll code in that direction.

[servoz]

Fixed.