You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The domain_filter allows data modelers to limit the options in a foreign key input. This can be done by writing a static filter or using the currently selected values in the form. But since the "select all/some" input doesn't belong to any of the forms, we cannot support domain_filter in all the cases.
The simplest solution is disabling the "select all/some" button when the foreign key column has domain_filter. But that would be too limiting, and in this issue, we would like to explore ways to support both simultaneously. This would be useful for PDB, as we discussed here.
Details
I will focus on foreign key columns with domain_filter in the following. Foreign key columns without this annotation should continue to offer the "select all/some" feature without any changes.
As long as the computed domain_filter (or more generally the Reference.uri) in all the forms is the same, we should be able to support domain_filter in "select some/all" input. So, we could compute the domain_filter for all the forms and disable the "select some/all" toggle button if some forms had a different value. But that would mean we have to rerender the KeyColumn component on each user input, which would slow the page down.
After discussing this, we decided to show an error when users attempt to open the foreign key picker instead. We will only run this expensive operation when users click on the foreign key. We are also going to leave the error and only reevaluate when users click again (after each click, we're showing a spinner since calculating it might be slow).
Error message
We should add pattern_sources property to domain_filter so data-modelers can list the columns that are used in the pattern. And then use them to show an error like this:
This feature is constrained by "x", "y", and "z". Make sure all the records you want to set "Asym Id" for, have the same values for those fields. Try again after upadting those fields.
If this property is missing, the error should be:
This feature is constrained by other fields (hint: `domain_filter_string`). Make sure all the records you want to set "Asym Id" for, have the same values for those fields. Try again after upadting those fields.
P.S. While discussing this, we realized that even if users don't use the "select all/some", the final selected values might not match the domain_filters. So, as part of a separate task, we should also do similar checks before attempting to save (#2401).
The text was updated successfully, but these errors were encountered:
Summary
The
domain_filter
allows data modelers to limit the options in a foreign key input. This can be done by writing a static filter or using the currently selected values in the form. But since the "select all/some" input doesn't belong to any of the forms, we cannot supportdomain_filter
in all the cases.The simplest solution is disabling the "select all/some" button when the foreign key column has
domain_filter
. But that would be too limiting, and in this issue, we would like to explore ways to support both simultaneously. This would be useful for PDB, as we discussed here.Details
I will focus on foreign key columns with
domain_filter
in the following. Foreign key columns without this annotation should continue to offer the "select all/some" feature without any changes.As long as the computed
domain_filter
(or more generally theReference.uri
) in all the forms is the same, we should be able to supportdomain_filter
in "select some/all" input. So, we could compute thedomain_filter
for all the forms and disable the "select some/all" toggle button if some forms had a different value. But that would mean we have to rerender theKeyColumn
component on each user input, which would slow the page down.After discussing this, we decided to show an error when users attempt to open the foreign key picker instead. We will only run this expensive operation when users click on the foreign key. We are also going to leave the error and only reevaluate when users click again (after each click, we're showing a spinner since calculating it might be slow).
Error message
We should add
pattern_sources
property todomain_filter
so data-modelers can list the columns that are used in the pattern. And then use them to show an error like this:If this property is missing, the error should be:
P.S. While discussing this, we realized that even if users don't use the "select all/some", the final selected values might not match the
domain_filter
s. So, as part of a separate task, we should also do similar checks before attempting to save (#2401).The text was updated successfully, but these errors were encountered: