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
{{ message }}
Repository navigation
Selection and configuration additional settings #3
A user may need extra settings on configurations and selections :
Configuration settings :
visible [boolean] : hides a configuration from the configuration selection menu. Useful to allow some pre-defined selections without allowing the user to add it himself.
unique [boolean] : allow to had a configuration to selections list. Once added, should be hidden from the menu Localizable components #7
Preselection settings :
visible [boolean] : hides a selection from the inputs list, but it's considered for output
forced [boolean]: prevents user to remove a selection from the input list (implicit if matching configuration has visible=false, see additional notes)
readonly : prevent user to change value and open dropdown (focus should still be available for deletion if allowed). Is not duplicate of a flag configuration.
Forced : additional notes :
If a user can remove (or add) a selection, I must be available to do the opposite action to prevent some "irreversible" action.
Use case : if a configuration is not visible from menu and a pre-defined selection is provided, the user should not be able to remove it, because he can't add it afterwards. The "forced" option would be implicit.
Sound mostly good to me. So that would mean something like that for the selection:
exportinterfaceBasicConfiguration{// Old stuffdisplay: string;field: string;transform?: (Selection)=>Selection;// New stuffvisible: boolean=true;unique: boolean=isFlag();}
But I am a bit confused about forced and readonly. I'd say that a preselection is always readonly. If you want to make it editable, then you must must make the configuration visible, and thus allow adding, removing and editing. And if you want to be non-editable, then you hide the configuration (and thus automatically force the preselection). I don't see a reasonable use-case where the preselection must editable, but the configuration hidden...
But I am a bit confused about forced and readonly. I'd say that a preselection is always readonly
Forced prevent the selection to be removed, but allow edition.
Readonly prevent to change the value, but allow removal.
Take dilps/tiresias usecase : we will add a default selection "databaseSource" with default value on dilps/tiresias. User can change and can remove the filter. It's a preselection that is not forced, neither readonly.
readonly : prevent user to change value and open dropdown (focus should still be available for deletion if allowed). Is not duplicate of a flag configuration.
Maybe I was wrong, it seems a duplicate for flagged facet. Don't remember the difference.
Use case : if a configuration is not visible from menu and a pre-defined selection is provided, the user should not be able to remove it, because he can't add it afterwards. The "forced" option would be implicit.
I don't see a reasonable use-case where the preselection must editable, but the configuration hidden...
Neither do I, but it's an implementation remark, not a feature. It's a combination we have to manage to prevent blocked situations.
Activity
PowerKiKi commentedon Jul 4, 2018
Sound mostly good to me. So that would mean something like that for the selection:
See https://github.com/Ecodev/natural-search/issues/15#issuecomment-402357359 for the preselection.
But I am a bit confused about
forcedandreadonly. I'd say that a preselection is always readonly. If you want to make it editable, then you must must make the configurationvisible, and thus allow adding, removing and editing. And if you want to be non-editable, then you hide the configuration (and thus automaticallyforcethe preselection). I don't see a reasonable use-case where the preselection must editable, but the configuration hidden...sambaptista commentedon Aug 23, 2019
Forced prevent the selection to be removed, but allow edition.
Readonly prevent to change the value, but allow removal.
Take dilps/tiresias usecase : we will add a default selection "databaseSource" with default value on dilps/tiresias. User can change and can remove the filter. It's a preselection that is not forced, neither readonly.
Maybe I was wrong, it seems a duplicate for flagged facet. Don't remember the difference.
Neither do I, but it's an implementation remark, not a feature. It's a combination we have to manage to prevent blocked situations.