-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop attributes_exclude
and keep attributes_include
#2154
Comments
Another minor downside of this idea: If I have a very large number N of possible values for a given attribute, the resulting JSON when I export an object with filters has:
Depending on typical N values and on how frequent this scenario is, it may make some histories less readable. Note that handling a large number N of options would clearly not work in the current plan for the UI, as we would never show a dropdown menu with N=1000 options. |
Will need to read more carefully. Quick comment on typical Ns: |
I'd be fine with not adding exclusion filters for now |
attributes_exclude
and keep attributes_include
attributes_exclude
and keep attributes_include
This issue was a design discussion and it requires no further action. Closing. |
As of fractal-analytics-platform/fractal-web#678 (comment), we are not anymore defining attribute filters for workflow tasks. This introduces a strong simplification, because attribute filters are only ever defined in relation to a dataset, and then the list of possible values is already known - based on the image list.
This prompts us (with @mfranzon) to propose a further simplification, that is, to drop
attributes_exclude
. In the UI the presence of both include/exclude is made redundant by a button like "select all", as in:The advantages of this simplification are many:
In terms of downside, we can only think about a single edge case, namely the one where new images are added to the dataset after some processing already took place. Here is how it would look like with/without the exclude filter:
With exclude filter:
Without exclude filter:
We deem this edge case an acceptable trade-off. The user is going back to a "conversion" run, and then they are likely aware that something will have to change in the processing as well. This issue does not appear at all e.g. if all conversion is done in advance, before any processing.
The text was updated successfully, but these errors were encountered: