RE security; disabling it would suffice and if I recall is already supported.
On Tue, Jul 9, 2024 at 3:09 PM Gus Heck <gus.h...@gmail.com> wrote: > > Also +1 ... "in the same repo and alongside" is how the last migration was > done IIRC. The big plus of this is as it's developed to a point of partial > utility you can put a link in the old UI to try out the new UI and get > feedback and make testing much easier. > > One thing that might be nice if we can do it, is to make the UI more > pluggable, and allow those who have no desire to test it to start solr with > it fully uninstalled. (i.e because they don't want to account for its > security in production) > > Also it would be very good if we carefully understood how we want to > achieve security (including information exposure, and role based > access/display) before we put it in a release. > > On Tue, Jul 9, 2024 at 10:40 AM Houston Putman <hous...@apache.org> wrote: > > > I agree with Jason on everything. > > > > Thank you so much for putting this much work into something with so much > > baggage in the community! > > > > I'm a huge +1 here, and love the things I saw in your screenshots on Slack. > > > > - Houston > > > > On Mon, Jul 8, 2024 at 2:23 PM Jason Gerlowski <gerlowsk...@gmail.com> > > wrote: > > > > > Hey Christos, > > > > > > Sorry for the delay responding here - lots of context to read up on! > > > > > > Firstly, thanks for the huge effort you've put into writing this all > > > up! Quite the thorough job, and it's really helpful to enable us > > > non-UI folks to follow along haha. > > > > > > If I understand things correctly, there's a few distinct aspects to > > > your proposal: > > > > > > 1. New UI would live alongside the existing one (for a time) > > > 2. The code for the new UI would live in the main repository. > > > 3. Development would be piece-meal (i.e. not one big code-dump) > > > > > > Overall, this sounds like a reasonable approach to me. > > > > > > I think a big concern with putting code in the main repo is that it's > > > pretty far from the (current) PMC's/community's wheelhouse to > > > maintain. I definitely share that concern. But IMO we're already > > > sortof at a "worst case" in that regard with our existing Admin UI > > > code. Doing the "refresh" in the main repo gives us a forcing > > > function (i.e. the review process itself) to ensure that at least a > > > few community members will understand the code to at least some > > > extent. That'll be a huge improvement over where we are today. > > > > > > Anyway, I'm a cautious '+1' based on these details at least. To quote > > > a message from Jan in Slack: "I'd rather see some imperfect movement > > > than a perfect plan never realized." > > > > > > (Here's hoping my reply will bump this to the top of folks' Inboxes, > > > and get you some more feedback.) > > > > > > Best, > > > > > > Jason > > > > > > On Mon, Jul 1, 2024 at 12:25 PM Christos Malliaridis > > > <c.malliari...@gmail.com> wrote: > > > > > > > > Hello everyone, > > > > > > > > In regards to SIP-7 > > > > < > > > > > https://cwiki.apache.org/confluence/display/SOLR/SIP-7+Updated+Solr+Admin+UI > > > > > > > > and SIP-10 > > > > < > > > > > https://cwiki.apache.org/confluence/display/SOLR/SIP-10+Improve+Getting+Started+experience > > > > > > > > I would like to add my perspective and address the current concerns > > about > > > > implementing a new UI, so that we can take some actions and improve the > > > > overall quality and experience of Solr Admin UI. > > > > > > > > There are many discussions and opinions about the UI and how to resolve > > > the > > > > current issues, but they all led to the topic becoming stale. In my > > > > opinion, developing and introducing a new UI into the main repository > > > piece > > > > by piece without replacing the current UI until feature-complete could > > > > > > > > - address all the issues currently reported (and not), > > > > - add new features, > > > > - replace the EOL framework and > > > > - improve the overall user experience. > > > > > > > > And the maintenance, which is one of the most important parts, could be > > > > addressed with the right choice of framework. > > > > > > > > I created a detailed writeup > > > > < > > > > > https://docs.google.com/document/d/14F1QARdkIrmKXQ4zuWUuOXduH4v_XwZ_Zrd0d2jE468/edit?usp=sharing > > > > > > > > for those who are interested, where I also write about the alternative > > > > approaches proposed in the past and listing the pros and cons of each > > one > > > > individually. > > > > > > > > I also started to improve this part by simply designing a new UI > > > > < > > > > > https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept > > > > > > > > and addressing multiple issues at once. I have already received some > > > community > > > > feedback > > > > <https://apachesolr.slack.com/archives/C01GVPZSSK0/p1718289047297999>, > > > but > > > > it is far from production-ready and needs more input. I think this > > could > > > be > > > > further refined and moved to development if there is consensus on that > > as > > > > the initial approach. > > > > > > > > What's your opinion about this approach and do you have any concerns > > that > > > > have not been addressed? > > > > > > > > Best regards, > > > > Christos > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > > > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
