-
-
Notifications
You must be signed in to change notification settings - Fork 17.9k
Description
Check Existing Issues
- I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.
Verify Feature Scope
- I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
Problem Description
At the moment, in Admin Settings Models, I have to open the edit screen for each model and click the Access button to discover whether the model is public or private.
Desired Solution you'd like
It would be useful if the Model screen:
- could filter based on Public / Private (in the same way as Hidden / Visible, etc)
- perhaps highlight Public / Private state (e.g. put a lock icon/switch next to models, after the enable switch) ( 🔓 / 🔒 )
- and if that Public / Private state is shown with a switch, have the state editable directly
Alternatives Considered
- Leaving things as they are
Advantages: it's done already
Disadvantages: it continues to hide the public/private state behind two layers of UI - Use just some form of styling to indicate public/private state
Advantages: less overall change to the UI than suggested approach, no need to implement state change code
Still need to determine state when displaying the page, though
Additional Context
What got me here was trying to get title icon generation working and the frustrating "This model is not publicly available. Please select another model." message. Actually finding where to change the model or what it was talking about without a web search -- which found a bug report as the top hit on Google -- proved beyond me, so it argues the UI is not yet sufficiently intuitive.
I'm hoping, given the UI infrastructure for the filter already exists, at least that part can be done. Similarly, the UI infrastructure for the Hide/Show and Enable/Disable are already present. So long as this attribute is in the same part of the metadata, I'd expect it to be a straightforward change to support editing in the UI.