Open volodymyrss opened 2 years ago
This should be related to #156 and #154 . So I presume the list of accepted parameters has to be further extended
Did some more investigation locally:
use_scws
is an accepted parameter if this is provided with the instruments isgri
or jemx
This behavior started when the check over the parameters, passed with the url, was implemented at frontend level. So, as a behavior, this is expected.
If there are no objections, I would close this.
It is somehow not determined correctly what should be accepted. And/or the wrong parameters are encoded in the URL, in different cases.
Try this:
It seems that also the parameters image_scale_max
and image_scale_min
are not currently accepted (selected_catalog
is now accepted and indeed it is not listed in the error message in the staging instance).
I guess they're supposed to be accepted...?
I'll add them now ...
It seems that also the parameters
image_scale_max
andimage_scale_min
are not currently accepted (selected_catalog
is now accepted and indeed it is not listed in the error message in the staging instance).
Do also try this with different instruments - the list of problematic parameters changes.
To fix this issue permanently, there is a need from the back-end to provide the full list of parameters that may appear in the "Share" url. Who can provide such a list, @dsavchenko or @volodymyrss ?
To fix this issue permanently, there is a need from the back-end to provide the full list of parameters that may appear in the "Share" url. Who can provide such a list, @dsavchenko or @volodymyrss ?
This list is provided by the dispatcher, e.g. like that:
https://www.astro.unige.ch/mmoda/dispatch-data/api/meta-data?instrument=isgri
The form in which it is provided is somewhat convoluted. The exact output can be modified, e.g by @burnout87 (if this is decided).
However, the problem which lead to this issue was that parameters which do not have matching frontend form fields will not be sent even if they are known to the dispatcher. Or is there a way to send them?
If these additional "invisible" parameters can not be sent, what matters is that frontend knows the parameters, not the dispatcher. It's not sufficient and indeed dangerous to silently allow some parameters unknown to frontend.
But I agree it would be great if frontend read the list of allowed parameters from the dispatcher (following the above-mentioned endpoint, perhaps after some adaptation of it's response), keep track of these parameters if provided in the URL and send them with the request. This would be a step to dynamically configuring frontend tab.
Does this make sense, @motame ?
This should be closed, given #170 isn't it ?
Ok so I am getting this now, with default request:
This should be allowed. Perhaps we could add a list of parameters which will be sent even if frontend does not know them?