"Cluster" is a word not frequently used in Solr, we normally use the word "Cloud"
"cloud" could be confused with the Solr mode "SolrCloud", the section however refers to the physical architecture view and therefore "cluster" was chosen initially
The sections "Collections" and eventually "ConfigSets" could be considered the logical architecture view
Old UI uses "Cloud", so we may simply rename it to "Cloud"
Queries & Operations seems not be obvious, requested to be "Queries & Indexing" instead
"Index & Query" may be considered instead, for shorter title
The curl copy command in Queries was requested and already included, but collapsed and overseen
We may reconsider the default collapsed state of specific areas
The interaction with the "Queries and Operations" section was a bit confusing
In the designs it is not obvious how the forms are updated / behave
FYI: By choosing the according request handler, the form in the screen updates accordingly
There is potentially the need to use the same mask from one known request handler with other request handlers
How could this be realized? Eventually with one more selection field for the form selection?
How would custom request handlers be shown / What form would be used there?
The word "deamon" seems to be confusing and may be an unwanted "wording"
Consider alternative naming or ways for deploying a "deamon", perhaps not provide this feature at all?
The deamon stream decorator may be confused with the request field "commitWithin", which are two different things
Filter list should be field list (fixed)
Playground was a bit hidden and its content (empty atm) not obvious, it can be a top level section called Analysis
Analysis tool is a very frequently used tool in the current UI
Some clusters may have thousands of collections / cores
This could affect the performance of the drop-down collection / core seleciton fields
Admin UI is currently focusing only in baisc auth and role based access control
Other combinations for AuthX and AuthZ are possible
We may limit it to basic auth and role-based access control for now, but it may be subject to change in future
Delaying auth implementation might be reasonable
Google Sign in and Microsoft sign in options seem questionable
The background of these options is the Auth plugin for OAuth / JWT with OIDC
Google and Microsoft Identity Providers are often used in companies (via OAuth/OIDC)
How does it look in our Solr community?
The initial idea of the sign in options (like Google and Microsoft) were simply using the issuer configuration name
The Sign In options is subject to change based on our experience and the implementaiton details of the AuthX/AuthZ in the AdminUI
There is a concern about having "too much power" in the new Admin UI
The Admin UI should reflect the access level in all screens / elements
Elements where the user is not authorized to use and blocked by the API will be hidden / disabled
Requests should fail anyway
The ConfigSets is an example of a "highly privileged" section
If the API is not properly blocking unauthorized requests, it is not the Admin UI's problem to limit that, as the frontend can be easily be bypassed
In the environment section some values (like JVM STOP.KEY) may be sensitive and should not be displayed
Can the API distinguish them?
Is there any access control?
Should the Admin UI be responsible for hiding specific fields? Who is defining them?
The screens in ConfigSets are not optimal and may be further improved
It would be great if the schema manipulation is not done by "raw manipulation", using forms for manipulating the schema could be an improvement
Individual areas may provide more help / information
This could be realized with hint buttons and short descriptions for sections
References to the documentation would also be helpful
"A good UI should be self-explanatory"
Metrics screen made an interesting impression, but is missing important values
Y axis has no scale
The time of the longest request should be displayed somehow
Perhaps in combination with the Y axis max?
Network tools from browsers could be used for inspiration
Multiple metrics screens are not designed yet
Metrics section is postponed for later implementation
Slack link in footer was questioned
It references to the community-driven Slack group of Solr, not ASF (that is for devs only)
Since the current UI already links to the community Slack, this should not be a problem to include in the New UI as well
Many places in our API have dynamic fields
This could affect predefined filters and tables (for example in "Logging - Logs")