[jira] [Commented] (SOLR-13162) Admin UI development-test cycle is slow
[ https://issues.apache.org/jira/browse/SOLR-13162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16749166#comment-16749166 ] Upayavira commented on SOLR-13162: -- This sounds like a very simple idea that would have saved me a lot of time back in the day (when I was working on the UI a lot). > Admin UI development-test cycle is slow > --- > > Key: SOLR-13162 > URL: https://issues.apache.org/jira/browse/SOLR-13162 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jeremy Branham >Priority: Minor > > When developing the admin user interface, it takes a long time to rebuild the > server to do testing. > It would be nice to have a small test harness or the admin ui, so that 'ant > server' doesnt need to be executed before testing changes. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8207) Add "Nodes" view to the Admin UI "Cloud" tab
[ https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575965#comment-16575965 ] Upayavira commented on SOLR-8207: - If a shard is not active, then make it grey as well as labelling it? > Add "Nodes" view to the Admin UI "Cloud" tab > > > Key: SOLR-8207 > URL: https://issues.apache.org/jira/browse/SOLR-8207 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Reporter: Upayavira >Assignee: Jan Høydahl >Priority: Major > Fix For: master (8.0), 7.5 > > Attachments: SOLR-8207.patch, SOLR-8207_shardstate.patch, > SOLR-8207_shardstate.patch, SOLR-8207_underscores.patch, > SOLR-8207_underscores.patch, image-2018-08-10-10-33-08-290.png, > node-compact.png, node-details.png, node-hostcolumn.png, > node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png, nodes.png > > Time Spent: 10m > Remaining Estimate: 0h > > The various sub-tabs of the "Cloud tab" were designed before anyone was > making real use of SolrCloud, and when we didn't really know the use-cases we > would need to support. I would argue that, whilst they are pretty (and > clever) they aren't really fit for purpose (with the exception of tree view). > Issues: > * Radial view doesn't scale beyond a small number of nodes/collections > * Paging on the graph view is based on collections - so a collection with > many replicas won't be subject to pagination > * The Dump feature is kinda redundant and should be removed > * There is now a major overlap in functionality with the new Collections tab > What I'd propose is that we: > * promote the tree tab to top level > * remove the graph views and the dump tab > * add a new Nodes tab > This nodes tab would complement the collections tab - showing nodes, and > their associated replicas/collections. From this view, it would be possible > to add/remove replicas and to see the status of nodes. It would also be > possible to filter nodes by status: "show me only up nodes", "show me nodes > that are in trouble", "show me nodes that have leaders on them", etc. > Presumably, if we have APIs to support it, we might have a "decommission > node" option, that would ensure that no replicas on this node are leaders, > and then remove all replicas from the node, ready for it to be removed from > the cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11905) Input box for json.facet in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-11905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574867#comment-16574867 ] Upayavira edited comment on SOLR-11905 at 8/9/18 1:56 PM: -- A simple text area, with a link to some decent documentation? was (Author: upayavira): A simple text box, with a link to some decent documentation? > Input box for json.facet in Admin UI > > > Key: SOLR-11905 > URL: https://issues.apache.org/jira/browse/SOLR-11905 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Priority: Major > Labels: newdev > > We need an input box for JSON facet. I imagine to add another text-box that > appears when you click the "facet" checkbox in the Query tab of the Admin UI. > Alternatively it could be a separate checkbox for "JSON facet". > > The text box should be several lines high to facilitate easy copy/paste of > JSON. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11905) Input box for json.facet in Admin UI
[ https://issues.apache.org/jira/browse/SOLR-11905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574867#comment-16574867 ] Upayavira commented on SOLR-11905: -- A simple text box, with a link to some decent documentation? > Input box for json.facet in Admin UI > > > Key: SOLR-11905 > URL: https://issues.apache.org/jira/browse/SOLR-11905 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Priority: Major > Labels: newdev > > We need an input box for JSON facet. I imagine to add another text-box that > appears when you click the "facet" checkbox in the Query tab of the Admin UI. > Alternatively it could be a separate checkbox for "JSON facet". > > The text box should be several lines high to facilitate easy copy/paste of > JSON. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7767) Zookeeper Ensemble Admin UI
[ https://issues.apache.org/jira/browse/SOLR-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16569388#comment-16569388 ] Upayavira commented on SOLR-7767: - This pic looks great. My question is whether you can draw more summary out of it and present it visually. You have the "Status: green". Could that be a green bar across the top? You only show a single ZK host. How would multiples show up? Perhaps they could show up as tabs? Or a list of hosts on the left, can be clicked to reveal the data about that node. Could you draw out things about the nodes, such as whether it is standalone/follower/etc as that is important, then hide (collapsed?) the details such as data size, etc? Just some thoughts. > Zookeeper Ensemble Admin UI > --- > > Key: SOLR-7767 > URL: https://issues.apache.org/jira/browse/SOLR-7767 > Project: Solr > Issue Type: New Feature > Components: Admin UI, SolrCloud >Reporter: Aniket Khare >Assignee: Jan Høydahl >Priority: Major > Fix For: master (8.0), 7.5 > > Attachments: zk-status-error.png, zk-status-new.png, zk-status-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > For SolrCloud mode can we have the functionality to display the live nodes > from the zookeeper ensemble. So that user can easily get to know if any of > zookeeper instance is down or having any other issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7767) Zookeeper Ensemble Admin UI
[ https://issues.apache.org/jira/browse/SOLR-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16568522#comment-16568522 ] Upayavira commented on SOLR-7767: - The way zookeeper is handled in the backend of the admin UI is a mess. A simple API that returns data as the UI expects it would be a great improvement. > Zookeeper Ensemble Admin UI > --- > > Key: SOLR-7767 > URL: https://issues.apache.org/jira/browse/SOLR-7767 > Project: Solr > Issue Type: New Feature > Components: Admin UI, SolrCloud >Reporter: Aniket Khare >Assignee: Jan Høydahl >Priority: Major > Fix For: master (8.0), 7.5 > > Attachments: zk-status-error.png, zk-status-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > For SolrCloud mode can we have the functionality to display the live nodes > from the zookeeper ensemble. So that user can easily get to know if any of > zookeeper instance is down or having any other issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16567898#comment-16567898 ] Upayavira commented on SOLR-8207: - Yes, no const or let. Or, we add a transpile stage, which gets you the lot of it, and other benefits, and needs to be done at some point. It may help with Angular 2 migration too. > Modernise cloud tab on Admin UI > --- > > Key: SOLR-8207 > URL: https://issues.apache.org/jira/browse/SOLR-8207 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 5.3 >Reporter: Upayavira >Assignee: Jan Høydahl >Priority: Major > Fix For: master (8.0), 7.5 > > Attachments: node-compact.png, node-details.png, node-hostcolumn.png, > node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > The various sub-tabs of the "Cloud tab" were designed before anyone was > making real use of SolrCloud, and when we didn't really know the use-cases we > would need to support. I would argue that, whilst they are pretty (and > clever) they aren't really fit for purpose (with the exception of tree view). > Issues: > * Radial view doesn't scale beyond a small number of nodes/collections > * Paging on the graph view is based on collections - so a collection with > many replicas won't be subject to pagination > * The Dump feature is kinda redundant and should be removed > * There is now a major overlap in functionality with the new Collections tab > What I'd propose is that we: > * promote the tree tab to top level > * remove the graph views and the dump tab > * add a new Nodes tab > This nodes tab would complement the collections tab - showing nodes, and > their associated replicas/collections. From this view, it would be possible > to add/remove replicas and to see the status of nodes. It would also be > possible to filter nodes by status: "show me only up nodes", "show me nodes > that are in trouble", "show me nodes that have leaders on them", etc. > Presumably, if we have APIs to support it, we might have a "decommission > node" option, that would ensure that no replicas on this node are leaders, > and then remove all replicas from the node, ready for it to be removed from > the cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16567560#comment-16567560 ] Upayavira commented on SOLR-8207: - Because we don't transpile our sources, we need to use a very basic JavaScript. To use later stuff, we would need to add a transpile stage to our build process. That wouldn't be a bad thing, we could add modification too, but it would be a reasonable size task. > Modernise cloud tab on Admin UI > --- > > Key: SOLR-8207 > URL: https://issues.apache.org/jira/browse/SOLR-8207 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 5.3 >Reporter: Upayavira >Assignee: Jan Høydahl >Priority: Major > Fix For: master (8.0), 7.5 > > Attachments: node-compact.png, node-details.png, node-hostcolumn.png, > node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > The various sub-tabs of the "Cloud tab" were designed before anyone was > making real use of SolrCloud, and when we didn't really know the use-cases we > would need to support. I would argue that, whilst they are pretty (and > clever) they aren't really fit for purpose (with the exception of tree view). > Issues: > * Radial view doesn't scale beyond a small number of nodes/collections > * Paging on the graph view is based on collections - so a collection with > many replicas won't be subject to pagination > * The Dump feature is kinda redundant and should be removed > * There is now a major overlap in functionality with the new Collections tab > What I'd propose is that we: > * promote the tree tab to top level > * remove the graph views and the dump tab > * add a new Nodes tab > This nodes tab would complement the collections tab - showing nodes, and > their associated replicas/collections. From this view, it would be possible > to add/remove replicas and to see the status of nodes. It would also be > possible to filter nodes by status: "show me only up nodes", "show me nodes > that are in trouble", "show me nodes that have leaders on them", etc. > Presumably, if we have APIs to support it, we might have a "decommission > node" option, that would ensure that no replicas on this node are leaders, > and then remove all replicas from the node, ready for it to be removed from > the cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566528#comment-16566528 ] Upayavira commented on SOLR-8207: - You said above that you would keep the link as ~cloud. I would suggest that that is likely to create confusion in the future. How about change the active link to ~cluster, but make ~cloud work too, or make ~cloud a redirect to ~cluster? That way, anyone who expects the old URL to work won't be disappointed, yet at the same time the UI is consistent within itself? > Modernise cloud tab on Admin UI > --- > > Key: SOLR-8207 > URL: https://issues.apache.org/jira/browse/SOLR-8207 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 5.3 >Reporter: Upayavira >Assignee: Jan Høydahl >Priority: Major > Fix For: master (8.0), 7.5 > > Attachments: SOLR-8207-refguide.patch, node-compact.png, > node-details.png, node-hostcolumn.png, node-toggle-row-numdocs.png, > nodes-tab-real.png, nodes-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > The various sub-tabs of the "Cloud tab" were designed before anyone was > making real use of SolrCloud, and when we didn't really know the use-cases we > would need to support. I would argue that, whilst they are pretty (and > clever) they aren't really fit for purpose (with the exception of tree view). > Issues: > * Radial view doesn't scale beyond a small number of nodes/collections > * Paging on the graph view is based on collections - so a collection with > many replicas won't be subject to pagination > * The Dump feature is kinda redundant and should be removed > * There is now a major overlap in functionality with the new Collections tab > What I'd propose is that we: > * promote the tree tab to top level > * remove the graph views and the dump tab > * add a new Nodes tab > This nodes tab would complement the collections tab - showing nodes, and > their associated replicas/collections. From this view, it would be possible > to add/remove replicas and to see the status of nodes. It would also be > possible to filter nodes by status: "show me only up nodes", "show me nodes > that are in trouble", "show me nodes that have leaders on them", etc. > Presumably, if we have APIs to support it, we might have a "decommission > node" option, that would ensure that no replicas on this node are leaders, > and then remove all replicas from the node, ready for it to be removed from > the cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16469296#comment-16469296 ] Upayavira commented on SOLR-8207: - How about making it default for Solr 8.0? It is definitely a better panel than the graph one, but perhaps good to maintain consistency through minor versions? > Modernise cloud tab on Admin UI > --- > > Key: SOLR-8207 > URL: https://issues.apache.org/jira/browse/SOLR-8207 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 5.3 >Reporter: Upayavira >Assignee: Jan Høydahl >Priority: Major > Attachments: node-compact.png, node-details.png, node-hostcolumn.png, > node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > The various sub-tabs of the "Cloud tab" were designed before anyone was > making real use of SolrCloud, and when we didn't really know the use-cases we > would need to support. I would argue that, whilst they are pretty (and > clever) they aren't really fit for purpose (with the exception of tree view). > Issues: > * Radial view doesn't scale beyond a small number of nodes/collections > * Paging on the graph view is based on collections - so a collection with > many replicas won't be subject to pagination > * The Dump feature is kinda redundant and should be removed > * There is now a major overlap in functionality with the new Collections tab > What I'd propose is that we: > * promote the tree tab to top level > * remove the graph views and the dump tab > * add a new Nodes tab > This nodes tab would complement the collections tab - showing nodes, and > their associated replicas/collections. From this view, it would be possible > to add/remove replicas and to see the status of nodes. It would also be > possible to filter nodes by status: "show me only up nodes", "show me nodes > that are in trouble", "show me nodes that have leaders on them", etc. > Presumably, if we have APIs to support it, we might have a "decommission > node" option, that would ensure that no replicas on this node are leaders, > and then remove all replicas from the node, ready for it to be removed from > the cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7767) Zookeeper Ensemble Admin UI
[ https://issues.apache.org/jira/browse/SOLR-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467032#comment-16467032 ] Upayavira commented on SOLR-7767: - This is fantastic to see! Question - is it possible to show just the things we need to know, and then have an 'advanced' button to show all of those parameters? I'd say status, follower/leader/etc is really important, whilst the rest might be overwhelming. > Zookeeper Ensemble Admin UI > --- > > Key: SOLR-7767 > URL: https://issues.apache.org/jira/browse/SOLR-7767 > Project: Solr > Issue Type: New Feature > Components: Admin UI, SolrCloud >Reporter: Aniket Khare >Assignee: Jan Høydahl >Priority: Major > Attachments: zk-status-error.png, zk-status-tab.png > > > For SolrCloud mode can we have the functionality to display the live nodes > from the zookeeper ensemble. So that user can easily get to know if any of > zookeeper instance is down or having any other issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16465024#comment-16465024 ] Upayavira commented on SOLR-8207: - Great comments from Shawn. A few more after playing with that link * If you click on a node cell, it only opens up the first instance row, not all for that node. * If the window is too narrow, something odd happens with the text in the right-hand column Otherwise, loving the breadth of info that is presented there. > Modernise cloud tab on Admin UI > --- > > Key: SOLR-8207 > URL: https://issues.apache.org/jira/browse/SOLR-8207 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 5.3 >Reporter: Upayavira >Assignee: Jan Høydahl >Priority: Major > Attachments: node-compact.png, node-details.png, node-hostcolumn.png, > node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > The various sub-tabs of the "Cloud tab" were designed before anyone was > making real use of SolrCloud, and when we didn't really know the use-cases we > would need to support. I would argue that, whilst they are pretty (and > clever) they aren't really fit for purpose (with the exception of tree view). > Issues: > * Radial view doesn't scale beyond a small number of nodes/collections > * Paging on the graph view is based on collections - so a collection with > many replicas won't be subject to pagination > * The Dump feature is kinda redundant and should be removed > * There is now a major overlap in functionality with the new Collections tab > What I'd propose is that we: > * promote the tree tab to top level > * remove the graph views and the dump tab > * add a new Nodes tab > This nodes tab would complement the collections tab - showing nodes, and > their associated replicas/collections. From this view, it would be possible > to add/remove replicas and to see the status of nodes. It would also be > possible to filter nodes by status: "show me only up nodes", "show me nodes > that are in trouble", "show me nodes that have leaders on them", etc. > Presumably, if we have APIs to support it, we might have a "decommission > node" option, that would ensure that no replicas on this node are leaders, > and then remove all replicas from the node, ready for it to be removed from > the cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16462295#comment-16462295 ] Upayavira commented on SOLR-8207: - Looking great! A few thoughts. * You clearly have a table in there. Have you looked at making it responsive? * Rather than having a 'detail' check box, could you make clicking on a row expand that row's detail? * Are the references to collections and cores clickable? Would be great if they could take you to that collection or core on the relevant host directly Otherwise, looking really good! > Modernise cloud tab on Admin UI > --- > > Key: SOLR-8207 > URL: https://issues.apache.org/jira/browse/SOLR-8207 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 5.3 >Reporter: Upayavira >Assignee: Jan Høydahl >Priority: Major > Attachments: node-compact.png, node-details.png, nodes-tab-real.png, > nodes-tab.png > > Time Spent: 10m > Remaining Estimate: 0h > > The various sub-tabs of the "Cloud tab" were designed before anyone was > making real use of SolrCloud, and when we didn't really know the use-cases we > would need to support. I would argue that, whilst they are pretty (and > clever) they aren't really fit for purpose (with the exception of tree view). > Issues: > * Radial view doesn't scale beyond a small number of nodes/collections > * Paging on the graph view is based on collections - so a collection with > many replicas won't be subject to pagination > * The Dump feature is kinda redundant and should be removed > * There is now a major overlap in functionality with the new Collections tab > What I'd propose is that we: > * promote the tree tab to top level > * remove the graph views and the dump tab > * add a new Nodes tab > This nodes tab would complement the collections tab - showing nodes, and > their associated replicas/collections. From this view, it would be possible > to add/remove replicas and to see the status of nodes. It would also be > possible to filter nodes by status: "show me only up nodes", "show me nodes > that are in trouble", "show me nodes that have leaders on them", etc. > Presumably, if we have APIs to support it, we might have a "decommission > node" option, that would ensure that no replicas on this node are leaders, > and then remove all replicas from the node, ready for it to be removed from > the cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12276) Admin UI - Convert from "AngularJS" to "Angular"
[ https://issues.apache.org/jira/browse/SOLR-12276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16459700#comment-16459700 ] Upayavira commented on SOLR-12276: -- [~jdyer] I'm not following Solr much at the moment, but it is great to see this ticket! If there is anything you need explaining regarding the original Angular UI, feel free to ask. > Admin UI - Convert from "AngularJS" to "Angular" > > > Key: SOLR-12276 > URL: https://issues.apache.org/jira/browse/SOLR-12276 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: James Dyer >Priority: Minor > Labels: Angular, AngularJS, angular-migration > Time Spent: 10m > Remaining Estimate: 0h > > With SOLR-12196 it was noted the current Solr Admin UI runs AngularJS (1.x), > which is to be End-of-Life later this year. Various options were proposed > for what to do next. One option is to keep the existing functionality but > migrate to a newer UI framework. This ticket is to migrate the existing UI > to Angular (2+). > See [this readme > file|https://github.com/jdyer1/lucene-solr/tree/feature/angular-conversion-solr-admin/solr/webapp]. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12196) Prepare Admin UI for migrating to Angular.io
[
https://issues.apache.org/jira/browse/SOLR-12196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16439138#comment-16439138
]
Upayavira commented on SOLR-12196:
--
{quote}If I had the knowledge, I'd be interested in helping with a rewrite. I
just don't know enough about javascript or css to tackle a job like that.
{quote}
Then learn it :) It is great fun! I'm not a front-end developer by any means, I
just learned what a colleague pointed me at. And there is structure there in
the JavaScript land that wasn't there before that lends itself to back-end
developers.
Go do a react tutorial or two. The CSS stuff we would defer to a graphic
designer. In the end, it is just programming. I might be able to muster the
time to put together a framework and build system onto which others can hang
pages, especially if we already had a design put together.
> Prepare Admin UI for migrating to Angular.io
>
>
> Key: SOLR-12196
> URL: https://issues.apache.org/jira/browse/SOLR-12196
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Reporter: Jan Høydahl
>Priority: Major
> Labels: Angular, AngularJS, angular-migration
> Fix For: master (8.0)
>
>
> AngularJS is soon end of life, it [enters LTS in july
> 2018|https://docs.angularjs.org/misc/version-support-status], whereupon it
> will only receive fixes to serious bugs. Solr uses AngularJS 1.3 (the latest
> AngularJS will be 1.7).
> This issue is *not* for upgrading to Angular5/6, but to start preparing the
> existing UI for easier migration later on. See
> [https://angular.io/guide/upgrade].
> This JIRA will likely get multiple sub tasks such as
> * Change to [Folders-by-Feature
> Structure|https://angular.io/guide/upgrade#follow-the-angularjs-style-guide],
> i.e. mix html, css, js in a folder based on feature
> * Use a [Module
> Loader|https://angular.io/guide/upgrade#using-a-module-loader] like
> [Webpack|https://webpack.js.org/]
> * Use [Component
> Directives|https://angular.io/guide/upgrade#using-component-directives]
> (requires first move from AngularJS 1.3 to 1.5)
> The rationale for this lira is recognising how central the Admin UI is to
> Solr, not letting it rot on top of a dying framework. Better to start moving
> step by step and [perhaps write all new views in Angular
> 5|https://angular.io/guide/upgrade#upgrading-with-ngupgrade], than to fall
> further and further behind.
> This effort of course assumes that Angular.io is the path we want to go, and
> not React, VueJS or some other new kid on the block :)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI
[ https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16438866#comment-16438866 ] Upayavira commented on SOLR-8207: - Your third option seems best to me. You don't want to explicitly proxy. You want to ask your local node for information that it happens to need to get from other nodes, but that happens behind the scenes, based upon a node name. > Modernise cloud tab on Admin UI > --- > > Key: SOLR-8207 > URL: https://issues.apache.org/jira/browse/SOLR-8207 > Project: Solr > Issue Type: Improvement > Components: Admin UI >Affects Versions: 5.3 >Reporter: Upayavira >Assignee: Jan Høydahl >Priority: Major > Attachments: nodes-tab.png > > > The various sub-tabs of the "Cloud tab" were designed before anyone was > making real use of SolrCloud, and when we didn't really know the use-cases we > would need to support. I would argue that, whilst they are pretty (and > clever) they aren't really fit for purpose (with the exception of tree view). > Issues: > * Radial view doesn't scale beyond a small number of nodes/collections > * Paging on the graph view is based on collections - so a collection with > many replicas won't be subject to pagination > * The Dump feature is kinda redundant and should be removed > * There is now a major overlap in functionality with the new Collections tab > What I'd propose is that we: > * promote the tree tab to top level > * remove the graph views and the dump tab > * add a new Nodes tab > This nodes tab would complement the collections tab - showing nodes, and > their associated replicas/collections. From this view, it would be possible > to add/remove replicas and to see the status of nodes. It would also be > possible to filter nodes by status: "show me only up nodes", "show me nodes > that are in trouble", "show me nodes that have leaders on them", etc. > Presumably, if we have APIs to support it, we might have a "decommission > node" option, that would ensure that no replicas on this node are leaders, > and then remove all replicas from the node, ready for it to be removed from > the cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12196) Prepare Admin UI for migrating to Angular.io
[ https://issues.apache.org/jira/browse/SOLR-12196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16428448#comment-16428448 ] Upayavira commented on SOLR-12196: -- I don't have a major investment in Solr at this time, but I am certainly game to follow on and add what bits I might. Whilst I am far from a front-end developer, I have recently played with Webpack and React with some success. The transition from the old JS UI to Angular was made simpler because of how Angular manages its (whole page) templates. React breaks things down into smaller components, and whilst this could be better in the long run in terms of component reuse, it means that a conversion could be a substantial piece of work. I like your idea of breaking the task down into smaller steps. > Prepare Admin UI for migrating to Angular.io > > > Key: SOLR-12196 > URL: https://issues.apache.org/jira/browse/SOLR-12196 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Priority: Major > Labels: Angular, AngularJS, angular-migration > Fix For: master (8.0) > > > AngularJS is soon end of life, it [enters LTS in july > 2018|https://docs.angularjs.org/misc/version-support-status], whereupon it > will only receive fixes to serious bugs. Solr uses AngularJS 1.3 (the latest > AngularJS will be 1.7). > This issue is *not* for upgrading to Angular5/6, but to start preparing the > existing UI for easier migration later on. See > [https://angular.io/guide/upgrade]. > This JIRA will likely get multiple sub tasks such as > * Change to [Folders-by-Feature > Structure|https://angular.io/guide/upgrade#follow-the-angularjs-style-guide], > i.e. mix html, css, js in a folder based on feature > * Use a [Module > Loader|https://angular.io/guide/upgrade#using-a-module-loader] like > [Webpack|https://webpack.js.org/] > * Use [Component > Directives|https://angular.io/guide/upgrade#using-component-directives] > (requires first move from AngularJS 1.3 to 1.5) > The rationale for this lira is recognising how central the Admin UI is to > Solr, not letting it rot on top of a dying framework. Better to start moving > step by step and [perhaps write all new views in Angular > 5|https://angular.io/guide/upgrade#upgrading-with-ngupgrade], than to fall > further and further behind. > This effort of course assumes that Angular.io is the path we want to go, and > not React, VueJS or some other new kid on the block :) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7896) Add a login page for Solr Administrative Interface
[ https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16419281#comment-16419281 ] Upayavira commented on SOLR-7896: - Let's just be clear what we are talking about here. The Admin UI is a set of HTML and JS files. It makes use of a set of APIs, that are typically JSON over HTTP: the same APIs as end users use. So talking about one auth for the UI and one for the API doesn't entirely make sense. Serving the UI files up over a different auth scheme may be possible, but without the APIs they are pretty darn useless, no? So what are we actually talking about here? > Add a login page for Solr Administrative Interface > -- > > Key: SOLR-7896 > URL: https://issues.apache.org/jira/browse/SOLR-7896 > Project: Solr > Issue Type: New Feature > Components: Admin UI, security >Affects Versions: 5.2.1 >Reporter: Aaron Greenspan >Priority: Major > Labels: authentication, login, password > > Out of the box, the Solr Administrative interface should require a password > that the user is required to set. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11296) Spellcheck parameters not working in new UI
[
https://issues.apache.org/jira/browse/SOLR-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16146866#comment-16146866
]
Upayavira commented on SOLR-11296:
--
Not got a working setup nor time to investigate much, but I bet you the issue
is this:
Those values all look to me like booleans, and they are not initialised. So
going to this file:
https://github.com/apache/lucene-solr/blob/master/solr/webapp/web/js/angular/controllers/query.js
Go to line 30:
$scope.spellcheck = {spellcheck:"on"};
Replace this with:
$scope.spellcheck = {spellcheck:"on", "spellcheck.build": "off",
"spellcheck.reload": "off", "spellcheck.onlyMorePopular": "off", . for all
the above params
And then I suspect it will work.
> Spellcheck parameters not working in new UI
> ---
>
> Key: SOLR-11296
> URL: https://issues.apache.org/jira/browse/SOLR-11296
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 7.0, 6.6.0, 6.3.0
>Reporter: Shawn Heisey
>
> When these spellcheck options are chosen in the query interface in the new
> UI, they are not added to the query that gets executed:
> spellcheck.build
> spellcheck.reload
> spellcheck.onlyMorePopular
> spellcheck.extendedResults
> spellcheck.collate
> From what I could tell, the other spellcheck options *are* included in the
> query when they are configured in the query interface.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10042) Delete old deprecated Admin UI
[ https://issues.apache.org/jira/browse/SOLR-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16017204#comment-16017204 ] Upayavira commented on SOLR-10042: -- SOLR-10042_remove_commented.patch removes stuff that was meant to remind me of unimplemented features. I eventually stopped using that method, but failed to clean up. These comments are redundant and can be removed. > Delete old deprecated Admin UI > -- > > Key: SOLR-10042 > URL: https://issues.apache.org/jira/browse/SOLR-10042 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Fix For: master (7.0) > > Attachments: SOLR-10042.patch, SOLR-10042_remove_commented.patch > > > The old jQuery based Admin UI has been deprecated since 6.0. Let us clean up > the last known bugs in Angular UI and simply delete the old UI in master. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8138) Simple UI for issuing SQL queries
[ https://issues.apache.org/jira/browse/SOLR-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15947774#comment-15947774 ] Upayavira commented on SOLR-8138: - Is the isbn field multivalued? I think it becomes an array when it is. It is important to be able to handle that situation, even if you have to tidy up the data in JS afterwards > Simple UI for issuing SQL queries > - > > Key: SOLR-8138 > URL: https://issues.apache.org/jira/browse/SOLR-8138 > Project: Solr > Issue Type: New Feature > Components: Admin UI >Affects Versions: 6.0 >Reporter: Joel Bernstein >Priority: Minor > Attachments: SOLR-8138.patch > > > It would be great for Solr 6 if we could have admin screen where we could > issue SQL queries using the new SQL interface. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10201) Admin UI: Add Collection "creates collection", "Connection to Solr lost", when replicationFactor>1
[ https://issues.apache.org/jira/browse/SOLR-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15883133#comment-15883133 ] Upayavira commented on SOLR-10201: -- [~sarkaramr...@gmail.com] look at places where the doNotIntercept is set, and do the same. It seems it is set in the services, in services.js, so you could set it for certain tasks. [~erickerickson] JS is inherently async anyway so you could have a "request submitted" and a "request complete" feedback without any substantial change in the code. To add a 'check status' button would require the backend calls to be async, which would be considerably more work, if they aren't async already. > Admin UI: Add Collection "creates collection", "Connection to Solr lost", > when replicationFactor>1 > -- > > Key: SOLR-10201 > URL: https://issues.apache.org/jira/browse/SOLR-10201 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 6.2 >Reporter: Amrit Sarkar > Attachments: screenshot-1.png > > > "Add Collection" fails miserably when replicationFactor >1. > There must be a better way to handle the request we are making through JS. > PF screenshot. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10201) Admin UI: Add Collection "creates collection", "Connection to Solr lost", when replicationFactor>1
[
https://issues.apache.org/jira/browse/SOLR-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882965#comment-15882965
]
Upayavira commented on SOLR-10201:
--
The timeout is set for all components. See js/angular/app.js. see
.factory('httpInterceptor'). That's where the timeout is set.
Also note, in that same method, doNotIntercept. This is an example of how an
caller can signal a specific behaviour to the interceptor. So, you could have a
doNotTimeout option that simply avoids setting the "connectionStatusInactive"
timeout.
> Admin UI: Add Collection "creates collection", "Connection to Solr lost",
> when replicationFactor>1
> --
>
> Key: SOLR-10201
> URL: https://issues.apache.org/jira/browse/SOLR-10201
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: 6.2
>Reporter: Amrit Sarkar
> Attachments: screenshot-1.png
>
>
> "Add Collection" fails miserably when replicationFactor >1.
> There must be a better way to handle the request we are making through JS.
> PF screenshot.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10201) Admin UI: Add Collection "creates collection", "Connection to Solr lost", when replicationFactor>1
[ https://issues.apache.org/jira/browse/SOLR-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882667#comment-15882667 ] Upayavira commented on SOLR-10201: -- This is generally due to the timeout. If a request takes longer than the timeout, it is assumed to imply that the server is down, which for long running requests isn't necessarily the case. It would be great to add an option for certain HTTP requests to say "this may take a long time, don't set a timeout as you would normally". > Admin UI: Add Collection "creates collection", "Connection to Solr lost", > when replicationFactor>1 > -- > > Key: SOLR-10201 > URL: https://issues.apache.org/jira/browse/SOLR-10201 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 6.2 >Reporter: Amrit Sarkar > Attachments: screenshot-1.png > > > "Add Collection" fails miserably when replicationFactor >1. > There must be a better way to handle the request we are making through JS. > PF screenshot. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9969) Display new metrics on the UI
[ https://issues.apache.org/jira/browse/SOLR-9969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838566#comment-15838566 ] Upayavira commented on SOLR-9969: - [~tomasflobbe] one of the points of doing the conversion was to make the code more accessible to non-JS developers. I'm afraid I'm not doing Solr dev at the moment, but your patch looks simple - does it work? > Display new metrics on the UI > - > > Key: SOLR-9969 > URL: https://issues.apache.org/jira/browse/SOLR-9969 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Varun Thacker > Attachments: mbeans_handler.png, SOLR-9969.patch > > > The current Core Selector -> Core -> Plugin/Stats UI shows tabs for the new > metrics information we are adding but doesn't populate correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-10037) (non-original) Solr Admin UI > query tab > unexpected url above results
[
https://issues.apache.org/jira/browse/SOLR-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838528#comment-15838528
]
Upayavira commented on SOLR-10037:
--
There is a ticket that takes the /solr out of URLs used in the services.js
file, making them relative such that Solr might be deployed to a different URL.
It looks like this might be an inadvertent consequence of that change. See
SOLR-9584.
> (non-original) Solr Admin UI > query tab > unexpected url above results
> ---
>
> Key: SOLR-10037
> URL: https://issues.apache.org/jira/browse/SOLR-10037
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Christine Poerschke
>Priority: Minor
>
> To reproduce, in a browser run a search from the query tab and then notice
> the url shown above the results
> {code}
> # actual: http://localhost:8983techproducts/select?indent=on&q=*:*&wt=json
> # expected:
> http://localhost:8983/solr/techproducts/select?q=*%3A*&wt=json&indent=true
> {code}
> (We had noticed this when using the (master branch) Admin UI during the
> [London Lucene Hackday for Full
> Fact|https://www.meetup.com/Apache-Lucene-Solr-London-User-Group/events/236356241/]
> on Friday, I just tried to reproduce both on master (reproducible with
> non-original version only) and on branch_6_4 (not reproducible) and search
> for an existing open issue found no apparent match.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9584) The absolute URL path in server/solr-webapp/webapp/js/angular/services.js would make context customization not work
[
https://issues.apache.org/jira/browse/SOLR-9584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15814972#comment-15814972
]
Upayavira commented on SOLR-9584:
-
The original intention of SOLR-9000 still stands. We didn't bother supporting
non /solr paths, because Solr is moving away from being a webapp.
However, this particular patch is pretty innocuous, and doesn't appear to
change much, so just like [~janhoy], I think this would be a reasonable patch
to apply.
> The absolute URL path in server/solr-webapp/webapp/js/angular/services.js
> would make context customization not work
> ---
>
> Key: SOLR-9584
> URL: https://issues.apache.org/jira/browse/SOLR-9584
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UI
>Affects Versions: 6.2
>Reporter: Yun Jie Zhou
>Priority: Minor
> Labels: patch
>
> The absolute path starting from /solr in
> server/solr-webapp/webapp/js/angular/services.js would make the context
> customization not work.
> For example, we should use $resource('admin/info/system', {"wt":"json",
> "_":Date.now()}); instead of $resource('/solr/admin/info/system',
> {"wt":"json", "_":Date.now()});
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9732) Field dropdown in Schema Browser screen can overlap field name in smaller browser windows
[ https://issues.apache.org/jira/browse/SOLR-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15686656#comment-15686656 ] Upayavira commented on SOLR-9732: - A 'select' element uses the 'chosen' library. This library replaces the HTML select element with some HTML that constructs a prettier, and more functional, drop down. Thus, if you apply your sizing to the HTML select element, you are effectively sizing an invisible (hidden) element, which ain't gonna help. You will want to look for other uses of select with a 'chosen' attribute and see where the width has been applied. I can't remember where I have done it, but I know I have succeeded at setting widths on Chosen select elements before. > Field dropdown in Schema Browser screen can overlap field name in smaller > browser windows > - > > Key: SOLR-9732 > URL: https://issues.apache.org/jira/browse/SOLR-9732 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UI >Affects Versions: 6.3 >Reporter: Cassandra Targett >Assignee: Alexandre Rafalovitch >Priority: Minor > Attachments: FieldDropdown.png > > > If I make my browser window smaller than say 1200px wide, the field selection > dropdown on the Schema Browser stays the same width while the content moves, > making it so the dropdown will overlap the field name. > Probably easiest to see in the attached screenshot. > This happens in both Chrome and Safari (I didn't check FF), but is seen at a > larger screen width in Chrome. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6082) Umbrella JIRA for Admin UI and SolrCloud.
[ https://issues.apache.org/jira/browse/SOLR-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15503407#comment-15503407 ] Upayavira commented on SOLR-6082: - [~mkhludnev] please create a separate ticket. The two UIs should be using the same back-end so should exhibit the same behaviour. > Umbrella JIRA for Admin UI and SolrCloud. > - > > Key: SOLR-6082 > URL: https://issues.apache.org/jira/browse/SOLR-6082 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 4.9, 6.0 >Reporter: Erick Erickson >Assignee: Erick Erickson > > It would be very helpful if the admin UI were more "cloud friendly". This is > an umbrella JIRA so we can collect sub-tasks as necessary. I think there > might be scattered JIRAs about this, let's link them in as we find them. > [~steffkes] - I've taken the liberty of assigning it to you since you > expressed some interest. Feel free to assign it back if you want... > Let's imagine that a user has a cluster with _no_ collections assigned and > start from there. > Here's a simple way to set this up. Basically you follow the reference guide > tutorial but _don't_ define a collection. > 1> completely delete the "collection1" directory from example > 2> cp -r example example2 > 3> in example, execute "java -DzkRun -jar start.jar" > 4> in example2, execute "java -Djetty.port=7574 -DzkHost=localhost:9983 -jar > start.jar" > Now the "cloud link" appears. If you expand the tree view, you see the two > live nodes. But, there's nothing in the graph view, no cores are selectable, > etc. > First problem (need to solve before any sub-jiras, so including it here): You > have to push a configuration directory to ZK. > [~thetapi] The _last_ time Stefan and I started allowing files to be written > to Solr from the UI it was...unfortunate. I'm assuming that there's something > similar here. That is, we shouldn't allow pushing the Solr config _to_ > ZooKeeper through the Admin UI, where they'd be distributed to all the solr > nodes. Is that true? If this is a security issue, we can keep pushing the > config dirs to ZK a manual step for now... > Once we determine how to get configurations up, we can work on the various > sub-jiras. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-6082) Umbrella JIRA for Admin UI and SolrCloud.
[ https://issues.apache.org/jira/browse/SOLR-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira closed SOLR-6082. --- > Umbrella JIRA for Admin UI and SolrCloud. > - > > Key: SOLR-6082 > URL: https://issues.apache.org/jira/browse/SOLR-6082 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 4.9, 6.0 >Reporter: Erick Erickson >Assignee: Erick Erickson > > It would be very helpful if the admin UI were more "cloud friendly". This is > an umbrella JIRA so we can collect sub-tasks as necessary. I think there > might be scattered JIRAs about this, let's link them in as we find them. > [~steffkes] - I've taken the liberty of assigning it to you since you > expressed some interest. Feel free to assign it back if you want... > Let's imagine that a user has a cluster with _no_ collections assigned and > start from there. > Here's a simple way to set this up. Basically you follow the reference guide > tutorial but _don't_ define a collection. > 1> completely delete the "collection1" directory from example > 2> cp -r example example2 > 3> in example, execute "java -DzkRun -jar start.jar" > 4> in example2, execute "java -Djetty.port=7574 -DzkHost=localhost:9983 -jar > start.jar" > Now the "cloud link" appears. If you expand the tree view, you see the two > live nodes. But, there's nothing in the graph view, no cores are selectable, > etc. > First problem (need to solve before any sub-jiras, so including it here): You > have to push a configuration directory to ZK. > [~thetapi] The _last_ time Stefan and I started allowing files to be written > to Solr from the UI it was...unfortunate. I'm assuming that there's something > similar here. That is, we shouldn't allow pushing the Solr config _to_ > ZooKeeper through the Admin UI, where they'd be distributed to all the solr > nodes. Is that true? If this is a security issue, we can keep pushing the > config dirs to ZK a manual step for now... > Once we determine how to get configurations up, we can work on the various > sub-jiras. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6082) Umbrella JIRA for Admin UI and SolrCloud.
[ https://issues.apache.org/jira/browse/SOLR-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira resolved SOLR-6082. - Resolution: Fixed This ticket has served its purpose. > Umbrella JIRA for Admin UI and SolrCloud. > - > > Key: SOLR-6082 > URL: https://issues.apache.org/jira/browse/SOLR-6082 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 4.9, 6.0 >Reporter: Erick Erickson >Assignee: Erick Erickson > > It would be very helpful if the admin UI were more "cloud friendly". This is > an umbrella JIRA so we can collect sub-tasks as necessary. I think there > might be scattered JIRAs about this, let's link them in as we find them. > [~steffkes] - I've taken the liberty of assigning it to you since you > expressed some interest. Feel free to assign it back if you want... > Let's imagine that a user has a cluster with _no_ collections assigned and > start from there. > Here's a simple way to set this up. Basically you follow the reference guide > tutorial but _don't_ define a collection. > 1> completely delete the "collection1" directory from example > 2> cp -r example example2 > 3> in example, execute "java -DzkRun -jar start.jar" > 4> in example2, execute "java -Djetty.port=7574 -DzkHost=localhost:9983 -jar > start.jar" > Now the "cloud link" appears. If you expand the tree view, you see the two > live nodes. But, there's nothing in the graph view, no cores are selectable, > etc. > First problem (need to solve before any sub-jiras, so including it here): You > have to push a configuration directory to ZK. > [~thetapi] The _last_ time Stefan and I started allowing files to be written > to Solr from the UI it was...unfortunate. I'm assuming that there's something > similar here. That is, we shouldn't allow pushing the Solr config _to_ > ZooKeeper through the Admin UI, where they'd be distributed to all the solr > nodes. Is that true? If this is a security issue, we can keep pushing the > config dirs to ZK a manual step for now... > Once we determine how to get configurations up, we can work on the various > sub-jiras. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9000) New Admin UI hardcodes /solr context and fails when it changes
[
https://issues.apache.org/jira/browse/SOLR-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15445528#comment-15445528
]
Upayavira commented on SOLR-9000:
-
See here: https://wiki.apache.org/solr/WhyNoWar
Solr does not support being used as a war in a different servlet container. It
may work, it may not.
Therefore, as started above, the additional complexity required to support
multiple roots has not been added to the UI.
If someone took the time to make it work, i wouldn't object, but i would be
concerned if that led to people thinking Solr would work as a war. If it isn't
this preventing it, it may soon be something else. And that something else
could occur at any time.
I'd suggest you rearchitect your system to use the inbuilt jetty, as you will
be following Standard practice at that point. If that requires two JVMs, so be
it.
> New Admin UI hardcodes /solr context and fails when it changes
> --
>
> Key: SOLR-9000
> URL: https://issues.apache.org/jira/browse/SOLR-9000
> Project: Solr
> Issue Type: Bug
> Components: UI
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
> Attachments: solr-wrong-urls-screenshot.png
>
>
> If the solr context is changed from */solr* to any other value (e.g.
> */solr6_0/instance/solr1*), the new Admin UI does not work as it still tries
> to load resources from */solr* prefix:
> The context is changed by editing server/contexts/solr-jetty-context.xml:
> bq. default="/solr6_0/instance/solr1"/>
> and by changing redirect in the server/etc/jetty.xml
> {quote}
>
> ^/$
> /solr6_0/instance/solr1/
>
> {quote}
> This affects New Admin UI, as well as both links between the UIs.
> The old Admin UI seems to work with the changed context, once it is manually
> loaded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9358) [AngularUI] In Cloud->Tree file view area, collapse metadata by default
[ https://issues.apache.org/jira/browse/SOLR-9358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15401211#comment-15401211 ] Upayavira commented on SOLR-9358: - That plus sign looks good to me. I'd just like us to use something that is consistent with the existing UI. Go for it! > [AngularUI] In Cloud->Tree file view area, collapse metadata by default > --- > > Key: SOLR-9358 > URL: https://issues.apache.org/jira/browse/SOLR-9358 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Fix For: 6.2, master (7.0) > > Attachments: Metadata expanded.png, Metadata with arrow.png, Metadata > with plus.png, SOLR-9358-plusimg.patch, SOLR-9358.patch > > > Spinoff from SOLR-8379 > In Cloud->Tree UI, the metadata section on top of file content takes up > valuable space. Suggest to collapse that part by default and make it possible > to expand on demand by clicking. That will avoid scrolling on small screens. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9358) [AngularUI] In Cloud->Tree file view area, collapse metadata by default
[ https://issues.apache.org/jira/browse/SOLR-9358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15399073#comment-15399073 ] Upayavira commented on SOLR-9358: - Regarding the unicode arrows, go look in the codebase, you'll find an images directory full of icons. I'm sure you'll find appropriate arrows in there that will give a consistent styling with the rest of the UI. > [AngularUI] In Cloud->Tree file view area, collapse metadata by default > --- > > Key: SOLR-9358 > URL: https://issues.apache.org/jira/browse/SOLR-9358 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Fix For: 6.2, master (7.0) > > Attachments: Metadata expanded.png, Metadata with arrow.png, > SOLR-9358.patch > > > Spinoff from SOLR-8379 > In Cloud->Tree UI, the metadata section on top of file content takes up > valuable space. Suggest to collapse that part by default and make it possible > to expand on demand by clicking. That will avoid scrolling on small screens. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9358) [AngularUI] In Cloud->Tree file view area, collapse metadata by default
[ https://issues.apache.org/jira/browse/SOLR-9358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15399070#comment-15399070 ] Upayavira commented on SOLR-9358: - Absolutely. The metadata isn't something I've ever paid attention to - it is always the data that I want to see, so you have my blessing. > [AngularUI] In Cloud->Tree file view area, collapse metadata by default > --- > > Key: SOLR-9358 > URL: https://issues.apache.org/jira/browse/SOLR-9358 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: UI >Reporter: Jan Høydahl >Assignee: Jan Høydahl > Fix For: 6.2, master (7.0) > > Attachments: Metadata expanded.png, Metadata with arrow.png, > SOLR-9358.patch > > > Spinoff from SOLR-8379 > In Cloud->Tree UI, the metadata section on top of file content takes up > valuable space. Suggest to collapse that part by default and make it possible > to expand on demand by clicking. That will avoid scrolling on small screens. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4268) Admin UI - button to unload transient core without removing from solr.xml
[ https://issues.apache.org/jira/browse/SOLR-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15390027#comment-15390027 ] Upayavira commented on SOLR-4268: - [~erickerickson] I think you'll find that's already the case - the core admin tab doesn't appear if in cloud mode (on the new UI at least). Strictly, this ticket is about the core admin *API* not the UI specifically, as the UI doesn't have the ability to do anything that you are talking about. I'd suggest changing this to an API ticket rather than a UI one. > Admin UI - button to unload transient core without removing from solr.xml > - > > Key: SOLR-4268 > URL: https://issues.apache.org/jira/browse/SOLR-4268 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 4.0 >Reporter: Shawn Heisey > Fix For: 4.9, 6.0 > > > The core "unload" button in the UI currently will completely remove a core > from solr.xml. With the implentation of transient cores, there should be a > way to ask Solr to unload a core without removing it entirely. > This leads into a discussion about terminology. UNLOAD isn't a good > single-word description for what it does. A case could be made for having > REMOVE and DELETE actions for CoreAdmin, with confirmation prompts if you > click on those buttons in the UI. DELETE could simply be an option on REMOVE > - which I think you can actually currently do with UNLOAD. > Another idea, not sure if it needs its own issue or is part of this one: If a > core is mentioned in solr.xml but not actually loaded, it would be very cool > if it were listed, but with a different background color to indicate the > non-loaded state. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4157) Add more conventional search functionality to the Admin UI
[ https://issues.apache.org/jira/browse/SOLR-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15389344#comment-15389344 ] Upayavira commented on SOLR-4157: - This was intended to be a new feature, going beyond the /browse interface. I'm not likely to get to it in the forseeable future so reasonable to close it. > Add more conventional search functionality to the Admin UI > -- > > Key: SOLR-4157 > URL: https://issues.apache.org/jira/browse/SOLR-4157 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Upayavira >Priority: Minor > Attachments: SOLR-4157.patch > > > The admin UI has a 'query' pane which allows searching the index. However, > this is currently an 'expert' level feature, as you must specify exact > request parameters and interpret output XML or JSON. > I suggest we add simple versions of each. A simple query pane would give a > more conventional search interface for running queries. A simple results pane > would give HTML formatted results with features to nicely display > hightlighting, explains, etc. > To give an idea of what this might look like, I've attached a rudimentary > patch that gives an HTML option for wt which formats the query results as > (somewhat minimal) HTML. > The challenge will be in producing a search interface that is schema > agnostic, as to be really useful, it should work with any index, and not just > with the fields in the default schema (perhaps Erik Hatcher is right, this > should be backed by the velocityResponseWriter). > Thoughts welcome. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9315) SchemaSimilarityFactory should delegate queryNorm and coord to the default similarity
[ https://issues.apache.org/jira/browse/SOLR-9315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15384407#comment-15384407 ] Upayavira commented on SOLR-9315: - This patch did resolve my issue. How should we go about committing it? I'm happy to commit it, but I wouldn't know how to provide a test for it. > SchemaSimilarityFactory should delegate queryNorm and coord to the default > similarity > - > > Key: SOLR-9315 > URL: https://issues.apache.org/jira/browse/SOLR-9315 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Adrien Grand >Priority: Minor > Attachments: SOLR-9315.patch > > > This is a follow-up to the discussion with [~upayavira] on LUCENE-6590: > SchemaSimilarityFactory can easily build similarities that apply the idf > twice. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts
[ https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15384402#comment-15384402 ] Upayavira commented on LUCENE-6590: --- I applied your patch and my problems went away. Many thanks!! > Explore different ways to apply boosts > -- > > Key: LUCENE-6590 > URL: https://issues.apache.org/jira/browse/LUCENE-6590 > Project: Lucene - Core > Issue Type: Wish >Reporter: Adrien Grand >Priority: Minor > Fix For: 5.4 > > Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, > LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch > > > Follow-up from LUCENE-6570: the fact that all queries are mutable in order to > allow for applying a boost raises issues since it makes queries bad cache > keys since their hashcode can change anytime. We could just document that > queries should never be modified after they have gone through IndexSearcher > but it would be even better if the API made queries impossible to mutate at > all. > I think there are two main options: > - either replace "void setBoost(boost)" with something like "Query > withBoost(boost)" which would return a clone that has a different boost > - or move boost handling outside of Query, for instance we could have a > (immutable) query impl that would be dedicated to applying boosts, that > queries that need to change boosts at rewrite time (such as BooleanQuery) > would use as a wrapper. > The latter idea is from Robert and I like it a lot given how often I either > introduced or found a bug which was due to the boost parameter being ignored. > Maybe there are other options, but I think this is worth exploring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts
[
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383180#comment-15383180
]
Upayavira commented on LUCENE-6590:
---
I upgraded my Solr configs to match the 5.5, and the issue was still there. I
eventually tracked down this snippet in Solr's SchemaSimilarityFactory.java:
{{
*
* NOTE: Users should be aware that even when this factory uses a single
default
* Similarity for some or all fields in a Query, the behavior can
be inconsistent
* with the behavior of explicitly configuring that same
Similarity globally, because
* of differences in how some multi-field / multi-clause behavior is defined in
* PerFieldSimilarityWrapper. In particular please consider
carefully the documentation
* & implementation of {@link Similarity#coord} and {@link
Similarity#queryNorm} in
* {@link ClassicSimilarity} compared to {@link PerFieldSimilarityWrapper}
*
}}
which suggests that adding a SchemaSimilarityFactory will *change* the scoring,
even if you continue to use the ClassicSimilarityFactory.
> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
> Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch,
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to
> allow for applying a boost raises issues since it makes queries bad cache
> keys since their hashcode can change anytime. We could just document that
> queries should never be modified after they have gone through IndexSearcher
> but it would be even better if the API made queries impossible to mutate at
> all.
> I think there are two main options:
> - either replace "void setBoost(boost)" with something like "Query
> withBoost(boost)" which would return a clone that has a different boost
> - or move boost handling outside of Query, for instance we could have a
> (immutable) query impl that would be dedicated to applying boosts, that
> queries that need to change boosts at rewrite time (such as BooleanQuery)
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either
> introduced or found a bug which was due to the boost parameter being ignored.
> Maybe there are other options, but I think this is worth exploring.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7871) Platform independent config file instead of solr.in.sh and solr.in.cmd
[
https://issues.apache.org/jira/browse/SOLR-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15359337#comment-15359337
]
Upayavira commented on SOLR-7871:
-
If you make this look both in your config file, and also in environment
variables, you will be able to take the functionality out of bin/solr, but
maintain backwards compatibility. Also, I suspect that more and more
applications will be expecting to be configured with environment variables
given that is how Docker apps expect to be configured, so having both
capabilities is valuable.
> Platform independent config file instead of solr.in.sh and solr.in.cmd
> --
>
> Key: SOLR-7871
> URL: https://issues.apache.org/jira/browse/SOLR-7871
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
>Affects Versions: 5.2.1
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Labels: bin/solr
> Fix For: 6.0
>
> Attachments: SOLR-7871.patch
>
>
> Spinoff from SOLR-7043
> The config files {{solr.in.sh}} and {{solr.in.cmd}} are currently executable
> batch files, but all they do is to set environment variables for the start
> scripts on the format {{key=value}}
> Suggest to instead have one central platform independent config file e.g.
> {{bin/solr.yml}} or {{bin/solrstart.properties}} which is parsed by
> {{SolrCLI.java}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9194) Enhance the bin/solr script to perform file operations to/from Zookeeper
[
https://issues.apache.org/jira/browse/SOLR-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15348012#comment-15348012
]
Upayavira commented on SOLR-9194:
-
Just a thought - am happy to be ignored:
Is Zookeeper essential to Solr? Should we be naming this option after
Zookeeper, or rather are we uploading the configs to *Solr*, which happens to
store them in ZK?
Thus:
{code}
solr config upload -d -n -z zkHost
solr config cp schema.xml solr:schema.xml
etc
{code}
> Enhance the bin/solr script to perform file operations to/from Zookeeper
>
>
> Key: SOLR-9194
> URL: https://issues.apache.org/jira/browse/SOLR-9194
> Project: Solr
> Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-9194.patch, SOLR-9194.patch
>
>
> There are a few other files that can reasonably be pushed to Zookeeper, e.g.
> solr.xml, security.json, clusterprops.json. Who knows? Even
> /state.json for the brave.
> This could reduce further the need for bouncing out to zkcli.
> Assigning to myself just so I don't lose track, but I would _love_ it if
> someone else wanted to take it...
> I'm thinking the commands would be
> bin/solr zk -putfile -z -p -f
> bin/solr zk -getfile -z -p -f
> but I'm not wedded to those, all suggestions welcome.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts
[ https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15328467#comment-15328467 ] Upayavira commented on LUCENE-6590: --- It seems a previous test I did was flawed (I thought I was pushing updated configs, but suspect that I was actually pushing old ones). Scoring is now working correctly, the main change being an update of the Lucene match version from 4.6 to 5.5. > Explore different ways to apply boosts > -- > > Key: LUCENE-6590 > URL: https://issues.apache.org/jira/browse/LUCENE-6590 > Project: Lucene - Core > Issue Type: Wish >Reporter: Adrien Grand >Priority: Minor > Fix For: 5.4 > > Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, > LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch > > > Follow-up from LUCENE-6570: the fact that all queries are mutable in order to > allow for applying a boost raises issues since it makes queries bad cache > keys since their hashcode can change anytime. We could just document that > queries should never be modified after they have gone through IndexSearcher > but it would be even better if the API made queries impossible to mutate at > all. > I think there are two main options: > - either replace "void setBoost(boost)" with something like "Query > withBoost(boost)" which would return a clone that has a different boost > - or move boost handling outside of Query, for instance we could have a > (immutable) query impl that would be dedicated to applying boosts, that > queries that need to change boosts at rewrite time (such as BooleanQuery) > would use as a wrapper. > The latter idea is from Robert and I like it a lot given how often I either > introduced or found a bug which was due to the boost parameter being ignored. > Maybe there are other options, but I think this is worth exploring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts
[ https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15328413#comment-15328413 ] Upayavira commented on LUCENE-6590: --- It is quite possibly something in my setup. I figured because someone else reported the same issue it might be more global, but I think now it is time for me to assume I've done something stupid. Apologies and thanks. > Explore different ways to apply boosts > -- > > Key: LUCENE-6590 > URL: https://issues.apache.org/jira/browse/LUCENE-6590 > Project: Lucene - Core > Issue Type: Wish >Reporter: Adrien Grand >Priority: Minor > Fix For: 5.4 > > Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, > LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch > > > Follow-up from LUCENE-6570: the fact that all queries are mutable in order to > allow for applying a boost raises issues since it makes queries bad cache > keys since their hashcode can change anytime. We could just document that > queries should never be modified after they have gone through IndexSearcher > but it would be even better if the API made queries impossible to mutate at > all. > I think there are two main options: > - either replace "void setBoost(boost)" with something like "Query > withBoost(boost)" which would return a clone that has a different boost > - or move boost handling outside of Query, for instance we could have a > (immutable) query impl that would be dedicated to applying boosts, that > queries that need to change boosts at rewrite time (such as BooleanQuery) > would use as a wrapper. > The latter idea is from Robert and I like it a lot given how often I either > introduced or found a bug which was due to the boost parameter being ignored. > Maybe there are other options, but I think this is worth exploring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts
[ https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15328207#comment-15328207 ] Upayavira commented on LUCENE-6590: --- Any ideas [~jpountz] > Explore different ways to apply boosts > -- > > Key: LUCENE-6590 > URL: https://issues.apache.org/jira/browse/LUCENE-6590 > Project: Lucene - Core > Issue Type: Wish >Reporter: Adrien Grand >Priority: Minor > Fix For: 5.4 > > Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, > LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch > > > Follow-up from LUCENE-6570: the fact that all queries are mutable in order to > allow for applying a boost raises issues since it makes queries bad cache > keys since their hashcode can change anytime. We could just document that > queries should never be modified after they have gone through IndexSearcher > but it would be even better if the API made queries impossible to mutate at > all. > I think there are two main options: > - either replace "void setBoost(boost)" with something like "Query > withBoost(boost)" which would return a clone that has a different boost > - or move boost handling outside of Query, for instance we could have a > (immutable) query impl that would be dedicated to applying boosts, that > queries that need to change boosts at rewrite time (such as BooleanQuery) > would use as a wrapper. > The latter idea is from Robert and I like it a lot given how often I either > introduced or found a bug which was due to the boost parameter being ignored. > Maybe there are other options, but I think this is worth exploring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts
[
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15324676#comment-15324676
]
Upayavira commented on LUCENE-6590:
---
Here's an example for 4.10 and the same query against 5.5 - note, it is a
different doc though:
{code}
4.10 score
"2937439": {
"match": true,
"value": 5.5993805,
"description": "weight(description:obama in 394012)
[DefaultSimilarity], result of:",
"details": [
{
"match": true,
"value": 5.5993805,
"description": "fieldWeight in 394012, product of:",
"details": [
{
"match": true,
"value": 1,
"description": "tf(freq=1.0), with freq of:",
"details": [
{
"match": true,
"value": 1,
"description": "termFreq=1.0"
}
]
},
{
"match": true,
"value": 5.5993805,
"description": "idf(docFreq=56010, maxDocs=5568765)"
},
{
"match": true,
"value": 1,
"description": "fieldNorm(doc=394012)"
}
]
}
]
5.5 score
"2502281":{
"match":true,
"value":28.51136,
"description":"weight(description:obama in 43472) [], result
of:",
"details":[{
"match":true,
"value":28.51136,
"description":"score(doc=43472,freq=1.0), product of:",
"details":[{
"match":true,
"value":5.339603,
"description":"queryWeight, product of:",
"details":[{
"match":true,
"value":5.339603,
"description":"idf(docFreq=31905,
maxDocs=2446459)"},
{
"match":true,
"value":1.0,
"description":"queryNorm"}]},
{
"match":true,
"value":5.339603,
"description":"fieldWeight in 43472, product of:",
"details":[{
"match":true,
"value":1.0,
"description":"tf(freq=1.0), with freq of:",
"details":[{
"match":true,
"value":1.0,
"description":"termFreq=1.0"}]},
{
"match":true,
"value":5.339603,
"description":"idf(docFreq=31905,
maxDocs=2446459)"},
{
"match":true,
"value":1.0,
"description":"fieldNorm(doc=43472)"}]}]}]},
{code}
> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
> Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch,
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to
> allow for applying a boost raises issues since it makes queries bad cache
> keys since their hashcode can change anytime. We could just document that
> queries should never be modified after they have gone through IndexSearcher
> but it would be even better if the API made queries impossible to mutate at
> all.
> I think there are two main options:
> - either replace "void setBoost(boost)" with something like "Query
> withBoost(boost)" which would return a clone that has a different boost
> - or move boost handling outside of Query, for instance we could have a
> (immutable) query impl that would be dedicated to applying boosts, that
> queries that need to change boosts at rewrite time (such as BooleanQuery)
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either
> introduced or found a bug which was due to the boost parameter being ignored.
> Maybe there are other options, but I think this is worth exploring.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8993) New UI can't show DIH
[ https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15324668#comment-15324668 ] Upayavira commented on SOLR-8993: - I have a serious lack of spare time at the moment, and on top of that, I've never used the DIH. Please feel free to try and provide a patch, in the meantime. > New UI can't show DIH > - > > Key: SOLR-8993 > URL: https://issues.apache.org/jira/browse/SOLR-8993 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0 >Reporter: Buğra Yıldırım >Priority: Critical > Attachments: SOLR-8993.patch, SOLR6.png, screenshot-1.png, > screenshot-2.png, screenshot-3.png, screenshot-4.png, screenshot-5.png, > screenshot-6.png > > > New UI can't show DIHs when more than one DIH exists. I switch to old UI for > importing from database. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts
[ https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15324317#comment-15324317 ] Upayavira commented on LUCENE-6590: --- My schema explicitly specifies the ClassicSimilarity. My Lucene match version was 4.6. I increased it to 5.5 and the behaviour was the same (this is using a Solr 5.5 system). I could try and knock up a test case, but to-date I've avoided coding in Java on Solr/Lucene, so not yet familiar with the various test frameworks. > Explore different ways to apply boosts > -- > > Key: LUCENE-6590 > URL: https://issues.apache.org/jira/browse/LUCENE-6590 > Project: Lucene - Core > Issue Type: Wish >Reporter: Adrien Grand >Priority: Minor > Fix For: 5.4 > > Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, > LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch > > > Follow-up from LUCENE-6570: the fact that all queries are mutable in order to > allow for applying a boost raises issues since it makes queries bad cache > keys since their hashcode can change anytime. We could just document that > queries should never be modified after they have gone through IndexSearcher > but it would be even better if the API made queries impossible to mutate at > all. > I think there are two main options: > - either replace "void setBoost(boost)" with something like "Query > withBoost(boost)" which would return a clone that has a different boost > - or move boost handling outside of Query, for instance we could have a > (immutable) query impl that would be dedicated to applying boosts, that > queries that need to change boosts at rewrite time (such as BooleanQuery) > would use as a wrapper. > The latter idea is from Robert and I like it a lot given how often I either > introduced or found a bug which was due to the boost parameter being ignored. > Maybe there are other options, but I think this is worth exploring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts
[ https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15324150#comment-15324150 ] Upayavira commented on LUCENE-6590: --- My code in this case is just Solr, so it seems that in this change, the "normalize based on the value of getvalueForNormalization" wasn't done in Solr. I've looked briefly at the SolrIndexSearcher, which subclasses IndexSearcher, but it doesn't seem to mess with normalization. Any chance you could take a look at SolrIndexSearcher and see if something was missed there? I'm definitely seeing scores which are tf*tf*idf in Solr results. > Explore different ways to apply boosts > -- > > Key: LUCENE-6590 > URL: https://issues.apache.org/jira/browse/LUCENE-6590 > Project: Lucene - Core > Issue Type: Wish >Reporter: Adrien Grand >Priority: Minor > Fix For: 5.4 > > Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, > LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch > > > Follow-up from LUCENE-6570: the fact that all queries are mutable in order to > allow for applying a boost raises issues since it makes queries bad cache > keys since their hashcode can change anytime. We could just document that > queries should never be modified after they have gone through IndexSearcher > but it would be even better if the API made queries impossible to mutate at > all. > I think there are two main options: > - either replace "void setBoost(boost)" with something like "Query > withBoost(boost)" which would return a clone that has a different boost > - or move boost handling outside of Query, for instance we could have a > (immutable) query impl that would be dedicated to applying boosts, that > queries that need to change boosts at rewrite time (such as BooleanQuery) > would use as a wrapper. > The latter idea is from Robert and I like it a lot given how often I either > introduced or found a bug which was due to the boost parameter being ignored. > Maybe there are other options, but I think this is worth exploring. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts
[
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15324070#comment-15324070
]
Upayavira commented on LUCENE-6590:
---
[~jpountz] this commit made this change:
{{
@Override
-public void normalize(float queryNorm, float topLevelBoost) {
- this.queryNorm = queryNorm * topLevelBoost;
- queryWeight *= this.queryNorm; // normalize query weight
+public void normalize(float queryNorm, float boost) {
+ this.boost = boost;
+ this.queryNorm = queryNorm;
+ queryWeight = queryNorm * boost * idf.getValue();
value = queryWeight * idf.getValue(); // idf for document
}
}}
Looking at this, before, the queryWeight was just the queryNorm* boost. Now, it
is qeueryNorm* boost * IDF.
This means I'm seeing scores which instead of being TF * IDF are now TF * IDF *
IDF.
Was this an intentional change?
> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
> Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch,
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to
> allow for applying a boost raises issues since it makes queries bad cache
> keys since their hashcode can change anytime. We could just document that
> queries should never be modified after they have gone through IndexSearcher
> but it would be even better if the API made queries impossible to mutate at
> all.
> I think there are two main options:
> - either replace "void setBoost(boost)" with something like "Query
> withBoost(boost)" which would return a clone that has a different boost
> - or move boost handling outside of Query, for instance we could have a
> (immutable) query impl that would be dedicated to applying boosts, that
> queries that need to change boosts at rewrite time (such as BooleanQuery)
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either
> introduced or found a bug which was due to the boost parameter being ignored.
> Maybe there are other options, but I think this is worth exploring.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9100) Add version-identifier to all files loaded by Admin UI
[ https://issues.apache.org/jira/browse/SOLR-9100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15278738#comment-15278738 ] Upayavira commented on SOLR-9100: - You will probably want to include the 'partials' files which are listed in solr/webapp/web/js/angular/app.js. > Add version-identifier to all files loaded by Admin UI > -- > > Key: SOLR-9100 > URL: https://issues.apache.org/jira/browse/SOLR-9100 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 5.5, 6.0 >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Fix For: master (7.0) > > Attachments: SOLR-9100.patch > > > The Angular UI added a bunch of javascript files to the base html, given that > we had some problems w/ users getting cached files in their Brower when using > a new release, i suggest we add those identifier (back) for those files as > well. > [~upayavira] mind looking if i missed a reference? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9100) Add version-identifier to all files loaded by Admin UI
[ https://issues.apache.org/jira/browse/SOLR-9100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15278595#comment-15278595 ] Upayavira commented on SOLR-9100: - [~steffkes] absolutely no objection - go for it! > Add version-identifier to all files loaded by Admin UI > -- > > Key: SOLR-9100 > URL: https://issues.apache.org/jira/browse/SOLR-9100 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 5.5, 6.0 >Reporter: Stefan Matheis (steffkes) >Assignee: Stefan Matheis (steffkes) >Priority: Minor > Fix For: master (7.0) > > Attachments: SOLR-9100.patch > > > The Angular UI added a bunch of javascript files to the base html, given that > we had some problems w/ users getting cached files in their Brower when using > a new release, i suggest we add those identifier (back) for those files as > well. > [~upayavira] mind looking if i missed a reference? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6688) There should be no error about a non-required file admin-extra.html
[
https://issues.apache.org/jira/browse/SOLR-6688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277060#comment-15277060
]
Upayavira commented on SOLR-6688:
-
The new admin UI, which is the default on 6.0+, does not implement the
admin-extra functionality, for want of a good reason to implement it.
I agree with [~hossman_luc...@fucit.org] above, we should have a separate "we
won't implement admin-extra" ticket, and mark this one as "not a problem for
6.0+.
> There should be no error about a non-required file admin-extra.html
> ---
>
> Key: SOLR-6688
> URL: https://issues.apache.org/jira/browse/SOLR-6688
> Project: Solr
> Issue Type: Bug
>Reporter: Arkadiusz Robiński
>Priority: Minor
>
> I am using SOLR 4.10.1. I have a simple configuration with 2 cores. Every
> time I open the SOLR admin interface, I get the following errors:
> {noformat}
> Can not find: admin-extra.html
> Can not find: admin-extra.menu-top.html
> Can not find: admin-extra.menu-bottom.html
> {noformat}
> As far as I know, the files are optional. Therefore I should not get any
> error, not even a warning.
> I do not want to create the files because I do not need them. The error
> should simply not be there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8993) New UI can't show DIH
[ https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15272236#comment-15272236 ] Upayavira commented on SOLR-8993: - Please try the patch attached here. I never use DIH, so cannot really test it in earnest. If it works, I'll commit it and it can be a part of 6.0.1 or 6.1, which ever comes first. > New UI can't show DIH > - > > Key: SOLR-8993 > URL: https://issues.apache.org/jira/browse/SOLR-8993 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0 >Reporter: Buğra Yıldırım >Priority: Critical > Attachments: SOLR-8993.patch, screenshot-1.png, screenshot-2.png, > screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png > > > New UI can't show DIHs when more than one DIH exists. I switch to old UI for > importing from database. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9054) The new GUI is using hardcoded paths
[ https://issues.apache.org/jira/browse/SOLR-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15266966#comment-15266966 ] Upayavira commented on SOLR-9054: - Yes, it is a duplicate. When I implemented the new UI, I deliberately did NOT support diverting away from /solr. The location where Solr is mounted is not to be considered a user-configurable value - this, really, is a part of the move away from Solr being a War distributable to being an application in its own right. Why do you want to replace the /solr portion of the URL? > The new GUI is using hardcoded paths > > > Key: SOLR-9054 > URL: https://issues.apache.org/jira/browse/SOLR-9054 > Project: Solr > Issue Type: Bug > Components: web gui >Affects Versions: 6.0 >Reporter: Valerio Di Cagno > > If Apache Solr 6.0 is started without using the default context root "/solr" > every admin service will not work properly and is not possible to use the > provided links to go back to the old GUI. > In the javascript files sometimes the parameter config.solr_path is ignored > or replaced with the value /solr returning 404 on access. > Affected files: > solr-webapp/webapp/js/services.js > Suggested solution: > Complete the integration with /js/scripts/app.js -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9032) Alias creation fails in new UI
[ https://issues.apache.org/jira/browse/SOLR-9032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15264285#comment-15264285 ] Upayavira commented on SOLR-9032: - Thx for spotting, [~ctargett] > Alias creation fails in new UI > -- > > Key: SOLR-9032 > URL: https://issues.apache.org/jira/browse/SOLR-9032 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0 >Reporter: Upayavira >Assignee: Upayavira > Fix For: 6.0.1 > > Attachments: SOLR-9032.patch > > > Using the Collections UI to create an alias makes a call like this: > http://$HOST:8983/solr/admin/collections?_=1461358635047&action=CREATEALIAS&collections=%5Bobject+Object%5D&name=assets&wt=json > The collections param is effectively [object Object] which is clearly wrong, > and should be a comma separated list of collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9032) Alias creation fails in new UI
[ https://issues.apache.org/jira/browse/SOLR-9032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira updated SOLR-9032: Attachment: SOLR-9032.patch The aliasCollections object is an array of objects, not strings. This patch correctly constructs a list of collection names when creating an alias. > Alias creation fails in new UI > -- > > Key: SOLR-9032 > URL: https://issues.apache.org/jira/browse/SOLR-9032 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0 >Reporter: Upayavira >Assignee: Upayavira > Fix For: 6.0.1 > > Attachments: SOLR-9032.patch > > > Using the Collections UI to create an alias makes a call like this: > http://$HOST:8983/solr/admin/collections?_=1461358635047&action=CREATEALIAS&collections=%5Bobject+Object%5D&name=assets&wt=json > The collections param is effectively [object Object] which is clearly wrong, > and should be a comma separated list of collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9002) New Admin UI's File screen cannot display JSON files
[
https://issues.apache.org/jira/browse/SOLR-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Upayavira updated SOLR-9002:
Attachment: SOLR-9002.patch
Another try
> New Admin UI's File screen cannot display JSON files
>
>
> Key: SOLR-9002
> URL: https://issues.apache.org/jira/browse/SOLR-9002
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>Assignee: Upayavira
> Attachments: SOLR-9002.patch, SOLR-9002.patch, SOLR-9002.patch,
> SOLR-9002.patch, json file blank screen.png
>
>
> Default cloud example. Looking at the *params.json* file in the New Admin UI
> shows empty screen and an Angular stack trace in the console.
> {noformat}
> "Error: [$sce:itype] Attempted to trust a non-string value in a content
> requiring a string: Context: html
> http://errors.angularjs.org/1.3.8/$sce/itype?p0=html
> minErr/<@http://localhost:6001/solr/libs/angular.js:86:12
> trustAs@http://localhost:6001/solr/libs/angular.js:15167:1
> @http://localhost:6001/solr/libs/angular.js:15918:16
> $parseFilter@http://localhost:6001/solr/libs/angular.js:12168:14
> regularInterceptedExpression@http://localhost:6001/solr/libs/angular.js:12855:21
> expressionInputsWatch@http://localhost:6001/solr/libs/angular.js:12783:24
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14240:34
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14511:13
> timeout/timeoutId<@http://localhost:6001/solr/libs/angular.js:16237:25
> completeOutstandingRequest@http://localhost:6001/solr/libs/angular.js:4925:7
> Browser/self.defer/timeoutId<@http://localhost:6001/solr/libs/angular.js:5305:7
> "
> {noformat}
> The same functionality works in the old Admin UI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9002) New Admin UI's File screen cannot display JSON files
[
https://issues.apache.org/jira/browse/SOLR-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Upayavira updated SOLR-9002:
Attachment: SOLR-9002.patch
Better now?
> New Admin UI's File screen cannot display JSON files
>
>
> Key: SOLR-9002
> URL: https://issues.apache.org/jira/browse/SOLR-9002
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>Assignee: Upayavira
> Attachments: SOLR-9002.patch, SOLR-9002.patch, SOLR-9002.patch, json
> file blank screen.png
>
>
> Default cloud example. Looking at the *params.json* file in the New Admin UI
> shows empty screen and an Angular stack trace in the console.
> {noformat}
> "Error: [$sce:itype] Attempted to trust a non-string value in a content
> requiring a string: Context: html
> http://errors.angularjs.org/1.3.8/$sce/itype?p0=html
> minErr/<@http://localhost:6001/solr/libs/angular.js:86:12
> trustAs@http://localhost:6001/solr/libs/angular.js:15167:1
> @http://localhost:6001/solr/libs/angular.js:15918:16
> $parseFilter@http://localhost:6001/solr/libs/angular.js:12168:14
> regularInterceptedExpression@http://localhost:6001/solr/libs/angular.js:12855:21
> expressionInputsWatch@http://localhost:6001/solr/libs/angular.js:12783:24
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14240:34
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14511:13
> timeout/timeoutId<@http://localhost:6001/solr/libs/angular.js:16237:25
> completeOutstandingRequest@http://localhost:6001/solr/libs/angular.js:4925:7
> Browser/self.defer/timeoutId<@http://localhost:6001/solr/libs/angular.js:5305:7
> "
> {noformat}
> The same functionality works in the old Admin UI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9002) New Admin UI's File screen cannot display JSON files
[
https://issues.apache.org/jira/browse/SOLR-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Upayavira updated SOLR-9002:
Attachment: SOLR-9002.patch
Patch that fixes JSON syntax highlighting
> New Admin UI's File screen cannot display JSON files
>
>
> Key: SOLR-9002
> URL: https://issues.apache.org/jira/browse/SOLR-9002
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>Assignee: Upayavira
> Attachments: SOLR-9002.patch, SOLR-9002.patch, json file blank
> screen.png
>
>
> Default cloud example. Looking at the *params.json* file in the New Admin UI
> shows empty screen and an Angular stack trace in the console.
> {noformat}
> "Error: [$sce:itype] Attempted to trust a non-string value in a content
> requiring a string: Context: html
> http://errors.angularjs.org/1.3.8/$sce/itype?p0=html
> minErr/<@http://localhost:6001/solr/libs/angular.js:86:12
> trustAs@http://localhost:6001/solr/libs/angular.js:15167:1
> @http://localhost:6001/solr/libs/angular.js:15918:16
> $parseFilter@http://localhost:6001/solr/libs/angular.js:12168:14
> regularInterceptedExpression@http://localhost:6001/solr/libs/angular.js:12855:21
> expressionInputsWatch@http://localhost:6001/solr/libs/angular.js:12783:24
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14240:34
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14511:13
> timeout/timeoutId<@http://localhost:6001/solr/libs/angular.js:16237:25
> completeOutstandingRequest@http://localhost:6001/solr/libs/angular.js:4925:7
> Browser/self.defer/timeoutId<@http://localhost:6001/solr/libs/angular.js:5305:7
> "
> {noformat}
> The same functionality works in the old Admin UI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-9032) Alias creation fails in new UI
Upayavira created SOLR-9032: --- Summary: Alias creation fails in new UI Key: SOLR-9032 URL: https://issues.apache.org/jira/browse/SOLR-9032 Project: Solr Issue Type: Bug Components: UI Affects Versions: 6.0 Reporter: Upayavira Assignee: Upayavira Fix For: 6.0.1 Using the Collections UI to create an alias makes a call like this: http://$HOST:8983/solr/admin/collections?_=1461358635047&action=CREATEALIAS&collections=%5Bobject+Object%5D&name=assets&wt=json The collections param is effectively [object Object] which is clearly wrong, and should be a comma separated list of collections. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8715) New Admin UI's Schema screen fails for some fields
[
https://issues.apache.org/jira/browse/SOLR-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253556#comment-15253556
]
Upayavira commented on SOLR-8715:
-
patch looks fine, but couldn't you just do: {code}if (!row.flags){code} rather
than creating a new variable, rowFlags?
> New Admin UI's Schema screen fails for some fields
> --
>
> Key: SOLR-8715
> URL: https://issues.apache.org/jira/browse/SOLR-8715
> Project: Solr
> Issue Type: Bug
> Components: UI
>Affects Versions: 5.5, 6.0
> Environment: mac, firefox
>Reporter: Alexandre Rafalovitch
>Assignee: Upayavira
> Labels: admin-interface
> Attachments: Problem shown in the released 5.5 version.png
>
>
> In techproducts example, using new Admin UI and trying to load the Schema for
> text field causes blank screen and the Javascript error in the developer
> console:
> {noformat}
> Error: row.flags is undefined
> getFieldProperties@http://localhost:8983/solr/js/angular/controllers/schema.js:482:40
> $scope.refresh/http://localhost:8983/solr/js/angular/controllers/schema.js:76:38
>
> {noformat}
> Tested with 5.5rc3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8918) Add Streaming Expressions to the admin page
[ https://issues.apache.org/jira/browse/SOLR-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249473#comment-15249473 ] Upayavira commented on SOLR-8918: - You are right, globals suck. That's js not angular. You could add the subcontroller to the scope, that'd make it local. > Add Streaming Expressions to the admin page > --- > > Key: SOLR-8918 > URL: https://issues.apache.org/jira/browse/SOLR-8918 > Project: Solr > Issue Type: New Feature > Components: UI, web gui >Reporter: Dennis Gove > Attachments: SOLR-8918.patch, SOLR-8918.patch, SOLR-8918.patch, > SOLR-8918.patch, SOLR-8918.patch, sample-display.png, sample-display.png > > > Add to the admin page an ability to work with and view Streaming Expressions. > This tab will appear under the Collection selection section and will work > similarly to the Query tab. On this page the user will be able to enter a > streaming expression for execution. The user can then execute the expression > against the collection and view all the results as they are returned from the > Stream handler. Along with this the user will be able to view the structure > of the expression in a graph-like layout. > If the user wishes to only view the expression structure without executing > the expression the user will be able to click an "Explain" button which will > show the structure. Included in the structure will be information about each > node (the expression for that node). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8990) UI: query links from the "Top Terms" table on the Schema Browser page should use the "term" parser
[
https://issues.apache.org/jira/browse/SOLR-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15248313#comment-15248313
]
Upayavira commented on SOLR-8990:
-
[~hossman_luc...@fucit.org] heck, you're getting good at this! :-) Patch looks
good to me
> UI: query links from the "Top Terms" table on the Schema Browser page should
> use the "term" parser
> --
>
> Key: SOLR-8990
> URL: https://issues.apache.org/jira/browse/SOLR-8990
> Project: Solr
> Issue Type: Bug
> Components: UI
>Reporter: Hoss Man
> Attachments: SOLR-8990.patch
>
>
> If you are using a StrField, or a TextField with a Keyword tokenizer then
> it's very possible your indexed terms will include white space.
> But the links created by the Schema Browser UI screen to serach for a term
> in the "Top Terms" list assume that just prepending hte term with the
> fieldname (ie: {{$fieldname + ":" $term}}) will be valid -- and instead they
> don't match the correct term.
>
> Example:
> Load the {{example/films}} data into a "films" collection, and then load the
> Schema Browser page for the "genre" field...
> http://127.0.1.1:8983/solr/#/films/schema?field=genre
> The "Top Terms" list includes terms such as {{Rommance Film}} but clicking on
> this term takes you to this URL...
> http://127.0.1.1:8983/solr/#/films/query?q=genre:Romance%20Film
> ...which is just doing a search for "genre:Romance" OR "Film" (in the default
> field)
> Instead it should link to...
> http://127.0.1.1:8983/solr/#/gettingstarted/query?q=%7B!term+f=genre%7DRomance+Film
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9010) Query tab - allow using browser "previous", "next" buttons to load previous/next queries in the form
[ https://issues.apache.org/jira/browse/SOLR-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15248138#comment-15248138 ] Upayavira commented on SOLR-9010: - [~jzak] yes, that's the idea > Query tab - allow using browser "previous", "next" buttons to load > previous/next queries in the form > > > Key: SOLR-9010 > URL: https://issues.apache.org/jira/browse/SOLR-9010 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 5.5 > Environment: Lucene Solr for Linux (downloaded as an archive) >Reporter: Jakub Zakrzewski > > Hi guys, > I'm new here, however I have been using solr web admin interface for some > weeks now. > My problem is that I often would like to access my previous queries loaded in > the form. However it is not possible now. > I'd like to have an url that opened will load the values to the form fields. > Now the web gui displays an url which is a solr request url and not web admin > query url. > I could implement this feature or create a web page that will use this > feature. Are you interested? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9010) Query tab - allow using browser "previous", "next" buttons to load previous/next queries in the form
[ https://issues.apache.org/jira/browse/SOLR-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15247709#comment-15247709 ] Upayavira commented on SOLR-9010: - I'm gonna assume for now that we're talking about the new UI (from Jan's index.html reference, he is too). The issue if I recall it is that, in Angular, changing the URL triggers a reload of the controller. This changes the workflow of the page substantially - when executing a query, rather than building a Solr URL to pass to a service, you need to build an Angular URL, then, when the controller starts up again, parse that angular URL into the $scope, then build a Solr URL and execute it. Certainly not impossible, just a rather different way of doing it from how it was initially coded. I'm certainly game for reviewing [~jzak]'s work if he wants to give it a go. I'd say, pretty much the entire work will be in js/angular/controllers/query.js. > Query tab - allow using browser "previous", "next" buttons to load > previous/next queries in the form > > > Key: SOLR-9010 > URL: https://issues.apache.org/jira/browse/SOLR-9010 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 5.5 > Environment: Lucene Solr for Linux (downloaded as an archive) >Reporter: Jakub Zakrzewski > > Hi guys, > I'm new here, however I have been using solr web admin interface for some > weeks now. > My problem is that I often would like to access my previous queries loaded in > the form. However it is not possible now. > I'd like to have an url that opened will load the values to the form fields. > Now the web gui displays an url which is a solr request url and not web admin > query url. > I could implement this feature or create a web page that will use this > feature. Are you interested? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-9002) New Admin UI's File screen cannot display JSON files
[
https://issues.apache.org/jira/browse/SOLR-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Upayavira reassigned SOLR-9002:
---
Assignee: Upayavira
> New Admin UI's File screen cannot display JSON files
>
>
> Key: SOLR-9002
> URL: https://issues.apache.org/jira/browse/SOLR-9002
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>Assignee: Upayavira
> Attachments: SOLR-9002.patch, json file blank screen.png
>
>
> Default cloud example. Looking at the *params.json* file in the New Admin UI
> shows empty screen and an Angular stack trace in the console.
> {noformat}
> "Error: [$sce:itype] Attempted to trust a non-string value in a content
> requiring a string: Context: html
> http://errors.angularjs.org/1.3.8/$sce/itype?p0=html
> minErr/<@http://localhost:6001/solr/libs/angular.js:86:12
> trustAs@http://localhost:6001/solr/libs/angular.js:15167:1
> @http://localhost:6001/solr/libs/angular.js:15918:16
> $parseFilter@http://localhost:6001/solr/libs/angular.js:12168:14
> regularInterceptedExpression@http://localhost:6001/solr/libs/angular.js:12855:21
> expressionInputsWatch@http://localhost:6001/solr/libs/angular.js:12783:24
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14240:34
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14511:13
> timeout/timeoutId<@http://localhost:6001/solr/libs/angular.js:16237:25
> completeOutstandingRequest@http://localhost:6001/solr/libs/angular.js:4925:7
> Browser/self.defer/timeoutId<@http://localhost:6001/solr/libs/angular.js:5305:7
> "
> {noformat}
> The same functionality works in the old Admin UI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-9002) New Admin UI's File screen cannot display JSON files
[
https://issues.apache.org/jira/browse/SOLR-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Upayavira updated SOLR-9002:
Attachment: SOLR-9002.patch
AngularJS by default detects JSON and parses it. Thus, anything else
(XML/HTML/text/etc) would come through as a string, but JSON would be parsed
into Javascript objects, causing this error.
The attached patch prevents Angular's JSON parsing functionality, meaning JSON
files are now displayed correctly in the Files tab.
> New Admin UI's File screen cannot display JSON files
>
>
> Key: SOLR-9002
> URL: https://issues.apache.org/jira/browse/SOLR-9002
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
> Attachments: SOLR-9002.patch, json file blank screen.png
>
>
> Default cloud example. Looking at the *params.json* file in the New Admin UI
> shows empty screen and an Angular stack trace in the console.
> {noformat}
> "Error: [$sce:itype] Attempted to trust a non-string value in a content
> requiring a string: Context: html
> http://errors.angularjs.org/1.3.8/$sce/itype?p0=html
> minErr/<@http://localhost:6001/solr/libs/angular.js:86:12
> trustAs@http://localhost:6001/solr/libs/angular.js:15167:1
> @http://localhost:6001/solr/libs/angular.js:15918:16
> $parseFilter@http://localhost:6001/solr/libs/angular.js:12168:14
> regularInterceptedExpression@http://localhost:6001/solr/libs/angular.js:12855:21
> expressionInputsWatch@http://localhost:6001/solr/libs/angular.js:12783:24
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14240:34
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14511:13
> timeout/timeoutId<@http://localhost:6001/solr/libs/angular.js:16237:25
> completeOutstandingRequest@http://localhost:6001/solr/libs/angular.js:4925:7
> Browser/self.defer/timeoutId<@http://localhost:6001/solr/libs/angular.js:5305:7
> "
> {noformat}
> The same functionality works in the old Admin UI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-8715) New Admin UI's Schema screen fails for some fields
[
https://issues.apache.org/jira/browse/SOLR-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Upayavira reassigned SOLR-8715:
---
Assignee: Upayavira
> New Admin UI's Schema screen fails for some fields
> --
>
> Key: SOLR-8715
> URL: https://issues.apache.org/jira/browse/SOLR-8715
> Project: Solr
> Issue Type: Bug
> Components: UI
>Affects Versions: 5.5, 6.0
> Environment: mac, firefox
>Reporter: Alexandre Rafalovitch
>Assignee: Upayavira
> Labels: admin-interface
> Fix For: 6.0
>
> Attachments: Problem shown in the released 5.5 version.png
>
>
> In techproducts example, using new Admin UI and trying to load the Schema for
> text field causes blank screen and the Javascript error in the developer
> console:
> {noformat}
> Error: row.flags is undefined
> getFieldProperties@http://localhost:8983/solr/js/angular/controllers/schema.js:482:40
> $scope.refresh/http://localhost:8983/solr/js/angular/controllers/schema.js:76:38
>
> {noformat}
> Tested with 5.5rc3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-8987) UI: Schema Browser doesn't show details for field names that start with underscore?
[
https://issues.apache.org/jira/browse/SOLR-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Upayavira reassigned SOLR-8987:
---
Assignee: Upayavira
> UI: Schema Browser doesn't show details for field names that start with
> underscore?
> ---
>
> Key: SOLR-8987
> URL: https://issues.apache.org/jira/browse/SOLR-8987
> Project: Solr
> Issue Type: Bug
> Components: UI
>Affects Versions: 6.0
>Reporter: Hoss Man
>Assignee: Upayavira
> Attachments: SOLR-8987.png
>
>
> * {{bin/solr -e cloud -noprompt}}
> * http://127.0.1.1:8983/solr/#/films/schema?field=_text_
> "Field Type:" and "Flags:" show nothing, and none of the analyzer info is
> visible.
> work arround: use the old ui...
> http://127.0.1.1:8983/solr/old.html#/gettingstarted_shard1_replica2/schema-browser?field=_text_
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9002) New Admin UI's File screen cannot display JSON files
[
https://issues.apache.org/jira/browse/SOLR-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15246762#comment-15246762
]
Upayavira commented on SOLR-9002:
-
Where are you looking at the "params.json" file? I'm not aware of such a file
in Solr. Which tab are you using that throws the error?
> New Admin UI's File screen cannot display JSON files
>
>
> Key: SOLR-9002
> URL: https://issues.apache.org/jira/browse/SOLR-9002
> Project: Solr
> Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>
> Default cloud example. Looking at the *params.json* file in the New Admin UI
> shows empty screen and an Angular stack trace in the console.
> {noformat}
> "Error: [$sce:itype] Attempted to trust a non-string value in a content
> requiring a string: Context: html
> http://errors.angularjs.org/1.3.8/$sce/itype?p0=html
> minErr/<@http://localhost:6001/solr/libs/angular.js:86:12
> trustAs@http://localhost:6001/solr/libs/angular.js:15167:1
> @http://localhost:6001/solr/libs/angular.js:15918:16
> $parseFilter@http://localhost:6001/solr/libs/angular.js:12168:14
> regularInterceptedExpression@http://localhost:6001/solr/libs/angular.js:12855:21
> expressionInputsWatch@http://localhost:6001/solr/libs/angular.js:12783:24
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14240:34
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14511:13
> timeout/timeoutId<@http://localhost:6001/solr/libs/angular.js:16237:25
> completeOutstandingRequest@http://localhost:6001/solr/libs/angular.js:4925:7
> Browser/self.defer/timeoutId<@http://localhost:6001/solr/libs/angular.js:5305:7
> "
> {noformat}
> The same functionality works in the old Admin UI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-9000) New Admin UI hardcodes /solr context and fails when it changes
[
https://issues.apache.org/jira/browse/SOLR-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15244161#comment-15244161
]
Upayavira commented on SOLR-9000:
-
It is my impression that, since the switch to Solr being a standalone app, this
prefix is not intended as a user configurable thing. Therefore, no effort has
gone into making it configuable within the admin UI.
> New Admin UI hardcodes /solr context and fails when it changes
> --
>
> Key: SOLR-9000
> URL: https://issues.apache.org/jira/browse/SOLR-9000
> Project: Solr
> Issue Type: Bug
> Components: UI
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
> Attachments: solr-wrong-urls-screenshot.png
>
>
> If the solr context is changed from */solr* to any other value (e.g.
> */solr6_0/instance/solr1*), the new Admin UI does not work as it still tries
> to load resources from */solr* prefix:
> The context is changed by editing server/contexts/solr-jetty-context.xml:
> bq. default="/solr6_0/instance/solr1"/>
> and by changing redirect in the server/etc/jetty.xml
> {quote}
>
> ^/$
> /solr6_0/instance/solr1/
>
> {quote}
> This affects New Admin UI, as well as both links between the UIs.
> The old Admin UI seems to work with the changed context, once it is manually
> loaded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8993) New UI can't show DIH
[ https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15242958#comment-15242958 ] Upayavira commented on SOLR-8993: - This patch is against trunk, but should work against other versions also. Apply it against the root of a Solr source checkout, then run 'ant server'. Once you've done that, you'll be able to use the normal bin/solr commands. > New UI can't show DIH > - > > Key: SOLR-8993 > URL: https://issues.apache.org/jira/browse/SOLR-8993 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0 >Reporter: Buğra Yıldırım >Priority: Critical > Attachments: SOLR-8993.patch, screenshot-1.png, screenshot-2.png, > screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png > > > New UI can't show DIHs when more than one DIH exists. I switch to old UI for > importing from database. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-8993) New UI can't show DIH
[ https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira updated SOLR-8993: Attachment: SOLR-8993.patch Patch that: * fixes the dataimport service to use the correct URL for non /dataimport named handlers * doesn't set hasHandlers=false if the config isn't XML > New UI can't show DIH > - > > Key: SOLR-8993 > URL: https://issues.apache.org/jira/browse/SOLR-8993 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0 >Reporter: Buğra Yıldırım >Priority: Critical > Attachments: SOLR-8993.patch, screenshot-1.png, screenshot-2.png, > screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png > > > New UI can't show DIHs when more than one DIH exists. I switch to old UI for > importing from database. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8993) New UI can't show DIH
[ https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15242909#comment-15242909 ] Upayavira commented on SOLR-8993: - the underlying Angular service connects to /solr/$COLLECTION/dataimport, rather than /solr/$COLLECTION/$YOUR_DATAIMPORT_HANDLER. That's a bug. Also, if it can't parse the XML, it fails, setting hasHandlers = false, showing the 'now handlers found' message. That's a bug also. > New UI can't show DIH > - > > Key: SOLR-8993 > URL: https://issues.apache.org/jira/browse/SOLR-8993 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0 >Reporter: Buğra Yıldırım >Priority: Critical > Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, > screenshot-4.png, screenshot-5.png, screenshot-6.png > > > New UI can't show DIHs when more than one DIH exists. I switch to old UI for > importing from database. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8956) Highlight missing in Analysis View
[
https://issues.apache.org/jira/browse/SOLR-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15242077#comment-15242077
]
Upayavira commented on SOLR-8956:
-
[~steffkes] is it simply that if a term appears in both sides (query/index) it
gets highlighted? Is this represented in the underlying data, or something you
do client-side?
> Highlight missing in Analysis View
> --
>
> Key: SOLR-8956
> URL: https://issues.apache.org/jira/browse/SOLR-8956
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis, web gui
>Affects Versions: 5.4, 5.5, master
>Reporter: Stefan Matheis (steffkes)
>Assignee: Upayavira
> Attachments: Solr+Admin+2016-04-06+12-03-36.png,
> Solr+Admin+2016-04-06+12-09-23.png
>
>
> the new analysis view is missing the highlighting for matches. screenshots
> appended to show the difference.
> this was reported by user {{mloeb}} on #solr yesterday. initially he asked
> about highlighting in general - questioning a few things has gotten us to the
> analysis view for debugging purposes. not seeing any highlights given the
> index/query data - i've asked him to try the very same in the old admin ui
> where it worked.
> i haven't dived in the code yet, probably [~upayavira] can give a hint where
> / at what to look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-8956) Highlight missing in Analysis View
[
https://issues.apache.org/jira/browse/SOLR-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Upayavira reassigned SOLR-8956:
---
Assignee: Upayavira
> Highlight missing in Analysis View
> --
>
> Key: SOLR-8956
> URL: https://issues.apache.org/jira/browse/SOLR-8956
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis, web gui
>Affects Versions: 5.4, 5.5, master
>Reporter: Stefan Matheis (steffkes)
>Assignee: Upayavira
> Attachments: Solr+Admin+2016-04-06+12-03-36.png,
> Solr+Admin+2016-04-06+12-09-23.png
>
>
> the new analysis view is missing the highlighting for matches. screenshots
> appended to show the difference.
> this was reported by user {{mloeb}} on #solr yesterday. initially he asked
> about highlighting in general - questioning a few things has gotten us to the
> analysis view for debugging purposes. not seeing any highlights given the
> index/query data - i've asked him to try the very same in the old admin ui
> where it worked.
> i haven't dived in the code yet, probably [~upayavira] can give a hint where
> / at what to look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-8991) UI: Ping option doesn't update menu with response time
[ https://issues.apache.org/jira/browse/SOLR-8991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira reassigned SOLR-8991: --- Assignee: Upayavira > UI: Ping option doesn't update menu with response time > -- > > Key: SOLR-8991 > URL: https://issues.apache.org/jira/browse/SOLR-8991 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0 >Reporter: Hoss Man >Assignee: Upayavira > > The ping menu option for a core doesn't provide any useful feedback to hte > user what it's doing (if anything). > In the old UI it would display the #ms that the ping command took, but in the > new UI it seems to do the query i nthe background, but never indicate that it > succeeded. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8991) UI: Ping option doesn't update menu with response time
[ https://issues.apache.org/jira/browse/SOLR-8991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15242052#comment-15242052 ] Upayavira commented on SOLR-8991: - It had ng-show="pingMS", i.e. show the time if pingMS resolves to "true". If pingMS=0, it would resolve to false, and thus not show the time, which is wrong. I've fixed it so that whenever it does a ping, it will show the time regardless of what the numerical value is. Does this resolve your issue? > UI: Ping option doesn't update menu with response time > -- > > Key: SOLR-8991 > URL: https://issues.apache.org/jira/browse/SOLR-8991 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0 >Reporter: Hoss Man > > The ping menu option for a core doesn't provide any useful feedback to hte > user what it's doing (if anything). > In the old UI it would display the #ms that the ping command took, but in the > new UI it seems to do the query i nthe background, but never indicate that it > succeeded. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8989) UI: Query screen can't handle query params that contain "=" (big problem trying to create link to pages that uses local params)
[
https://issues.apache.org/jira/browse/SOLR-8989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15242022#comment-15242022
]
Upayavira commented on SOLR-8989:
-
AngularJS is a bit more precise and thorough in what it expects when parsing a
URL. The second equals isn't intended to be a URL component, rather a part of a
parameter value. If you URL encode it (to a %3D), everything will work as you
expect.
> UI: Query screen can't handle query params that contain "=" (big problem
> trying to create link to pages that uses local params)
> ---
>
> Key: SOLR-8989
> URL: https://issues.apache.org/jira/browse/SOLR-8989
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>
> * {{bin/solr -e cloud -noprompt}}
> * http://127.0.1.1:8983/solr/#/gettingstarted/query
> * if you type either of these into the "q" param box, both queries works:
> {noformat}
> {!lucene}foo
> {!lucene f=foo_s}foo
> {noformat}
> * if however you try to create a link to the UI page, only the first query
> works, the second gets confused by the equal sign and ignores everything
> after "f="
> ** http://127.0.1.1:8983/solr/#/gettingstarted/query?q=%7B!lucene%7Dfoo
> *** works
> **
> http://127.0.1.1:8983/solr/#/gettingstarted/query?q=%7B!lucene+f=foo_s%7Dfoo
> *** breaks
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8982) UI: Cloud -> Dump option isn't working
[ https://issues.apache.org/jira/browse/SOLR-8982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15240297#comment-15240297 ] Upayavira commented on SOLR-8982: - Or delete the functionality. What benefit does it give you? In what way is it useful to you? > UI: Cloud -> Dump option isn't working > -- > > Key: SOLR-8982 > URL: https://issues.apache.org/jira/browse/SOLR-8982 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: 6.0 >Reporter: Hoss Man > > the "Dump" option on the (new) angular UI Cloud screen doesn't seem to be > working. the "pre" tag where all the data is suppose to appear is empty... > http://127.0.1.1:8983/solr/#/~cloud > Work around: use the older deprecated UI, it does appear to be working... > http://127.0.1.1:8983/solr/old.html#/~cloud -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8918) Add Streaming Expressions to the admin page
[ https://issues.apache.org/jira/browse/SOLR-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15234990#comment-15234990 ] Upayavira commented on SOLR-8918: - This is great! Will really help folks learn the streaming API. Some questions: Would it make sense to add two tabs at the top, one for streaming expressions, and the other for SQL? The second suggestion is a lot more substantial. Given that the streaming API is essentially a programming language, would it be possible to add support for autocomplete or code suggestions to the editor? There's a list of Javascript editors here, some of which support "code suggestions": https://en.wikipedia.org/wiki/Comparison_of_JavaScript-based_source_code_editors Thoughts? > Add Streaming Expressions to the admin page > --- > > Key: SOLR-8918 > URL: https://issues.apache.org/jira/browse/SOLR-8918 > Project: Solr > Issue Type: New Feature > Components: UI, web gui >Reporter: Dennis Gove > Attachments: SOLR-8918.patch, SOLR-8918.patch, sample-display.png > > > Add to the admin page an ability to work with and view Streaming Expressions. > This tab will appear under the Collection selection section and will work > similarly to the Query tab. On this page the user will be able to enter a > streaming expression for execution. The user can then execute the expression > against the collection and view all the results as they are returned from the > Stream handler. Along with this the user will be able to view the structure > of the expression in a graph-like layout. > If the user wishes to only view the expression structure without executing > the expression the user will be able to click an "Explain" button which will > show the structure. Included in the structure will be information about each > node (the expression for that node). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8967) UI should not show the replication tab in the core selector panel in cloud mode
[ https://issues.apache.org/jira/browse/SOLR-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15234918#comment-15234918 ] Upayavira commented on SOLR-8967: - Looks good to me > UI should not show the replication tab in the core selector panel in cloud > mode > --- > > Key: SOLR-8967 > URL: https://issues.apache.org/jira/browse/SOLR-8967 > Project: Solr > Issue Type: Improvement >Reporter: Varun Thacker > Attachments: SOLR-8967.patch > > > When running Solr in cloud mode, the UI has a 'Replication' tab under 'Core > Selector' . > I think we should not display this when Solr is running in cloud mode. It > doesn't add any value as this is useful for master-slave setups. It could > also be harmful if someone accidentally clicks on 'Disable Replication' in > the UI. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8957) Query view generates incorrect param names
[
https://issues.apache.org/jira/browse/SOLR-8957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231008#comment-15231008
]
Upayavira commented on SOLR-8957:
-
Please check trunk/6.0. I think you'll find this has been fixed already.
> Query view generates incorrect param names
> --
>
> Key: SOLR-8957
> URL: https://issues.apache.org/jira/browse/SOLR-8957
> Project: Solr
> Issue Type: Bug
> Components: web gui
>Affects Versions: 5.4, 5.5, master
>Reporter: Stefan Matheis (steffkes)
>
> Following SOLR-8956 we discovered that options within a section are leading
> to incorrect param-names.
> enabling {{hl}} and furthermore setting "something" for {{hl.fl}} (just
> below) lead to a query containing {{hl=true&fl=something}} obviously missing
> the {{hl.}} prefix, same was true for {{hl.simple.pre}} as well as
> {{hl.simple.post}}
> i didn't try but i guess that's true for all sections and not specific to the
> highlighting. again, [~upayavira] might know where to look?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8870) AngularJS Query tab breaks through proxy
[
https://issues.apache.org/jira/browse/SOLR-8870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203431#comment-15203431
]
Upayavira commented on SOLR-8870:
-
Looks good to me (not tried it though)
> AngularJS Query tab breaks through proxy
>
>
> Key: SOLR-8870
> URL: https://issues.apache.org/jira/browse/SOLR-8870
> Project: Solr
> Issue Type: Bug
> Components: UI
>Affects Versions: 5.5
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Minor
> Labels: 404-error, angularjs, encoding, newdev
> Attachments: SOLR-8870.patch
>
>
> The AngularJS Query tab generates a request URL on this form:
> http://localhost:8983/solr/techproducts%2Fselect?_=1458291250691&indent=on&q=ram&wt=json
> Notice the urlencoded {{%2Fselect}} part.
> This works well locally with Jetty, but a customer has httpd as a proxy in
> front, and we get a 404 error since the web server does not parse {{%2F}} as
> a path separator and thus does not match the proxy rules for select.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-8210) Admin UI menu does not scroll
[ https://issues.apache.org/jira/browse/SOLR-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira resolved SOLR-8210. - Resolution: Fixed Fix Version/s: 5.4 This was resolved for 5.4 > Admin UI menu does not scroll > - > > Key: SOLR-8210 > URL: https://issues.apache.org/jira/browse/SOLR-8210 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 5.3 >Reporter: Upayavira >Assignee: Upayavira >Priority: Minor > Fix For: 5.4 > > > When you view the UI on a projector - or a small screen (e.g. with dev tools > open), some menu options might be obscured at the bottom of the screen. The > menu doesn't scroll though, meaning the only way to get to these entries is > to use another screen, or change the text size in the browser temporarily. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-8210) Admin UI menu does not scroll
[ https://issues.apache.org/jira/browse/SOLR-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira closed SOLR-8210. --- > Admin UI menu does not scroll > - > > Key: SOLR-8210 > URL: https://issues.apache.org/jira/browse/SOLR-8210 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 5.3 >Reporter: Upayavira >Assignee: Upayavira >Priority: Minor > Fix For: 5.4 > > > When you view the UI on a projector - or a small screen (e.g. with dev tools > open), some menu options might be obscured at the bottom of the screen. The > menu doesn't scroll though, meaning the only way to get to these entries is > to use another screen, or change the text size in the browser temporarily. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-8199) Text specifying which UI a user is looking at is incorrect
[ https://issues.apache.org/jira/browse/SOLR-8199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira resolved SOLR-8199. - Resolution: Fixed This was resolved before release > Text specifying which UI a user is looking at is incorrect > -- > > Key: SOLR-8199 > URL: https://issues.apache.org/jira/browse/SOLR-8199 > Project: Solr > Issue Type: Bug > Components: UI >Reporter: Youssef Chaker >Assignee: Upayavira >Priority: Trivial > Attachments: Screen_Shot_2015-10-24_at_10_21_08_AM.png, > Screen_Shot_2015-10-24_at_10_21_41_AM.png > > > In the top right corner of the admin UI, a text is available to indicate > whether the user is looking at the original UI or the new one. > But it currently says "New UI" for http://localhost:8983/solr/#/ and > "Original UI" for http://localhost:8983/solr/index.html#/ when it should be > the other way around. > This issue is tied to #SOLR-7666 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-7857) Update CHANGES.txt to mention angular UI changes
[ https://issues.apache.org/jira/browse/SOLR-7857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira closed SOLR-7857. --- > Update CHANGES.txt to mention angular UI changes > > > Key: SOLR-7857 > URL: https://issues.apache.org/jira/browse/SOLR-7857 > Project: Solr > Issue Type: Bug > Components: web gui >Reporter: Upayavira >Assignee: Upayavira >Priority: Minor > Fix For: 5.5, master > > > Many tweaks to AngularUI made since 5.2.1 - CHANGES.txt should describe the > nature of those changes and set expectations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7857) Update CHANGES.txt to mention angular UI changes
[ https://issues.apache.org/jira/browse/SOLR-7857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira resolved SOLR-7857. - Resolution: Fixed Either this was done, or it is now irrelevant. Either way, it is resolved > Update CHANGES.txt to mention angular UI changes > > > Key: SOLR-7857 > URL: https://issues.apache.org/jira/browse/SOLR-7857 > Project: Solr > Issue Type: Bug > Components: web gui >Reporter: Upayavira >Assignee: Upayavira >Priority: Minor > Fix For: master, 5.5 > > > Many tweaks to AngularUI made since 5.2.1 - CHANGES.txt should describe the > nature of those changes and set expectations. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-7666) Umbrella ticket for Angular JS post-5.2.1 issues
[ https://issues.apache.org/jira/browse/SOLR-7666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira closed SOLR-7666. --- > Umbrella ticket for Angular JS post-5.2.1 issues > > > Key: SOLR-7666 > URL: https://issues.apache.org/jira/browse/SOLR-7666 > Project: Solr > Issue Type: New Feature > Components: UI >Affects Versions: 5.3, master >Reporter: Erick Erickson >Assignee: Upayavira > Attachments: SOLR-7666-3.patch, SOLR-7666-4.patch, SOLR-7666-5.patch, > SOLR-7666-part2.patch, SOLR-7666-part2.patch, SOLR-7666.patch, > admin-ui-7666.zip > > > As of Solr 5.2.1, there's a new admin UI available that has been written > almost entirely by Upayavira (thanks!) over the last several months. It's > written in Angular JS with an eye towards enhancement/maintainability. The > default UI is still the old version, but you can access the new version by > going to http:///solr/index.html. There are a couple of fixes > between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or > 5.2.1 > The expectation is that in Solr 5.3, the new code will become the default > with the old UI deprecated and eventually removed. > So it would be a great help if volunteers could give the new UI a spin. It > should look much the same as the current one at the start, but evolve into > something much more interesting and more cloud-friendly. Of course all the > new UI code will always be available on trunk/6.0 too, and the up-to-date > code will always be on both the trunk and 5x branches. > Please provide feedback on the user's (or dev) lists about anything you find > that doesn't work, or enhancements you'd like to see (or, even better, > contribute). If you raise a JIRA, please link it to this one so I can keep > track of what needs to be committed. If linking JIRAs is a mystery just add a > comment to this JIRA referencing the new JIRA and we can take care of it. > Please do _not_ attach patches to this JIRA, it'll be much easier to keep > track of everything if the patches are attached to sub-JIRAs. > And a big thanks to Upayavira for this work! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7666) Umbrella ticket for Angular JS post-5.2.1 issues
[ https://issues.apache.org/jira/browse/SOLR-7666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira resolved SOLR-7666. - Resolution: Fixed As Erick says, this ticket is rather long, any new issues should be in new tickets. > Umbrella ticket for Angular JS post-5.2.1 issues > > > Key: SOLR-7666 > URL: https://issues.apache.org/jira/browse/SOLR-7666 > Project: Solr > Issue Type: New Feature > Components: UI >Affects Versions: 5.3, master >Reporter: Erick Erickson >Assignee: Upayavira > Attachments: SOLR-7666-3.patch, SOLR-7666-4.patch, SOLR-7666-5.patch, > SOLR-7666-part2.patch, SOLR-7666-part2.patch, SOLR-7666.patch, > admin-ui-7666.zip > > > As of Solr 5.2.1, there's a new admin UI available that has been written > almost entirely by Upayavira (thanks!) over the last several months. It's > written in Angular JS with an eye towards enhancement/maintainability. The > default UI is still the old version, but you can access the new version by > going to http:///solr/index.html. There are a couple of fixes > between 5.2.0 and 5.2.1, so please use either a fresh 5x checkout, trunk, or > 5.2.1 > The expectation is that in Solr 5.3, the new code will become the default > with the old UI deprecated and eventually removed. > So it would be a great help if volunteers could give the new UI a spin. It > should look much the same as the current one at the start, but evolve into > something much more interesting and more cloud-friendly. Of course all the > new UI code will always be available on trunk/6.0 too, and the up-to-date > code will always be on both the trunk and 5x branches. > Please provide feedback on the user's (or dev) lists about anything you find > that doesn't work, or enhancements you'd like to see (or, even better, > contribute). If you raise a JIRA, please link it to this one so I can keep > track of what needs to be committed. If linking JIRAs is a mystery just add a > comment to this JIRA referencing the new JIRA and we can take care of it. > Please do _not_ attach patches to this JIRA, it'll be much easier to keep > track of everything if the patches are attached to sub-JIRAs. > And a big thanks to Upayavira for this work! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-8839) Angular admin/segments display: display of deleted docs not proportional
[ https://issues.apache.org/jira/browse/SOLR-8839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira reassigned SOLR-8839: --- Assignee: Upayavira > Angular admin/segments display: display of deleted docs not proportional > > > Key: SOLR-8839 > URL: https://issues.apache.org/jira/browse/SOLR-8839 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 >Reporter: Luc Vanlerberghe >Assignee: Upayavira >Priority: Minor > > In the /segments portion of the admin site, the segments are displayed as a > bar graph with the size of each bar proportional to the logarithm of the > segment size. > Within each bar the number of deleted documents is shown as a dark-gray > portion at the end. > Before the angular version, the size of this part was directly proportional > to the number of deleted documents with respect to the total number of > documents in the segment > In the angular version, the dark-gray portion is way too large. > In the previous version, the result was odd as well since it displayed a > proportional percentage within in a logarithmic graph. > I'll add a PR shortly that changes the calculation so the dark-gray part > looks approximately proportional to the size the segment would shrink if > optimized. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-8730) Experimental UI, the hl.fl is not properly set doing queries
[ https://issues.apache.org/jira/browse/SOLR-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira resolved SOLR-8730. - Resolution: Fixed Fix Version/s: 6.0 Fixed, thanks for the report! > Experimental UI, the hl.fl is not properly set doing queries > > > Key: SOLR-8730 > URL: https://issues.apache.org/jira/browse/SOLR-8730 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 > Environment: Debian wheezy x64, 4 processors, 4gb memory, 4 SOLR > clouds servers >Reporter: Jean-Renaud Margelidon >Assignee: Upayavira >Priority: Minor > Fix For: 6.0 > > > When using the experiment UI and doing searches on collection, when > populating the hl.fl field, the value is used for the fl instead. > URL generated: > http://127.0.0.1/solr/collection/select?fl=content&hl=on&indent=on&q=html&wt=json > URL Expected: > http://127.0.0.1/solr/collection/select?hl.fl=content&hl=on&indent=on&q=html&wt=json -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7858) Make Angular UI default
[ https://issues.apache.org/jira/browse/SOLR-7858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira resolved SOLR-7858. - Resolution: Fixed > Make Angular UI default > --- > > Key: SOLR-7858 > URL: https://issues.apache.org/jira/browse/SOLR-7858 > Project: Solr > Issue Type: Bug > Components: web gui >Reporter: Upayavira >Assignee: Upayavira >Priority: Minor > Fix For: 6.0 > > Attachments: SOLR-7858-2.patch, SOLR-7858-3.patch, SOLR-7858-4.patch, > SOLR-7858-fix.patch, SOLR-7858.patch, new ui link.png, original UI link.png > > > Angular UI is very close to feature complete. Once SOLR-7856 is dealt with, > it should function well in most cases. I propose that, as soon as 5.3 has > been released, we make the Angular UI default, ready for the 5.4 release. We > can then fix any more bugs as they are found, but more importantly start > working on the features that were the reason for doing this work in the first > place. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7858) Make Angular UI default
[ https://issues.apache.org/jira/browse/SOLR-7858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Upayavira updated SOLR-7858: Fix Version/s: 6.0 > Make Angular UI default > --- > > Key: SOLR-7858 > URL: https://issues.apache.org/jira/browse/SOLR-7858 > Project: Solr > Issue Type: Bug > Components: web gui >Reporter: Upayavira >Assignee: Upayavira >Priority: Minor > Fix For: 6.0 > > Attachments: SOLR-7858-2.patch, SOLR-7858-3.patch, SOLR-7858-4.patch, > SOLR-7858-fix.patch, SOLR-7858.patch, new ui link.png, original UI link.png > > > Angular UI is very close to feature complete. Once SOLR-7856 is dealt with, > it should function well in most cases. I propose that, as soon as 5.3 has > been released, we make the Angular UI default, ready for the 5.4 release. We > can then fix any more bugs as they are found, but more importantly start > working on the features that were the reason for doing this work in the first > place. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7913) Add stream.body support to MLT QParser
[ https://issues.apache.org/jira/browse/SOLR-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15178757#comment-15178757 ] Upayavira commented on SOLR-7913: - [~smolloy] Looking at this patch, there's quite a lot of reformatting in it, which makes it hard to distinguish between substantive changes and layout changes. Could you provide a patch that is purely substantive changes? Whilst I won't (yet) promise to commit it, I'd certainly like to see if we can get it to that point. > Add stream.body support to MLT QParser > -- > > Key: SOLR-7913 > URL: https://issues.apache.org/jira/browse/SOLR-7913 > Project: Solr > Issue Type: Improvement >Reporter: Anshum Gupta > Attachments: SOLR-7913.patch, SOLR-7913.patch > > > Continuing from > https://issues.apache.org/jira/browse/SOLR-7639?focusedCommentId=14601011&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14601011. > It'd be good to have stream.body be supported by the mlt qparser. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8766) remove the deprecated tag from solrconfig.xml
[
https://issues.apache.org/jira/browse/SOLR-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15173795#comment-15173795
]
Upayavira commented on SOLR-8766:
-
See no issue with that
> remove the deprecated tag from solrconfig.xml
>
>
> Key: SOLR-8766
> URL: https://issues.apache.org/jira/browse/SOLR-8766
> Project: Solr
> Issue Type: Bug
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Trivial
>
> thisis not used anymore anywhere
> {code:xml}
>
>
> *:*
>
> {code}
> [~upayavira] do you think it's OK to nuke it
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8713) New UI points to the wiki for Query Syntax instead of the Reference Guide
[ https://issues.apache.org/jira/browse/SOLR-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171197#comment-15171197 ] Upayavira commented on SOLR-8713: - It would be great to have online, per release snapshots of the wiki, but in lieu of that, this patch looks good to me. > New UI points to the wiki for Query Syntax instead of the Reference Guide > - > > Key: SOLR-8713 > URL: https://issues.apache.org/jira/browse/SOLR-8713 > Project: Solr > Issue Type: Bug > Components: UI >Affects Versions: master >Reporter: Tomás Fernández Löbbe >Priority: Trivial > Labels: newdev > > Old Admin UI points to > https://cwiki.apache.org/confluence/display/solr/Query+Syntax+and+Parsing but > the new one points to http://wiki.apache.org/solr/SolrQuerySyntax -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8730) Experimental UI, the hl.fl is not properly set doing queries
[ https://issues.apache.org/jira/browse/SOLR-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15166998#comment-15166998 ] Upayavira commented on SOLR-8730: - Fix should be trivial, will get to it when i can. > Experimental UI, the hl.fl is not properly set doing queries > > > Key: SOLR-8730 > URL: https://issues.apache.org/jira/browse/SOLR-8730 > Project: Solr > Issue Type: Bug >Affects Versions: 5.4.1 > Environment: Debian wheezy x64, 4 processors, 4gb memory, 4 SOLR > clouds servers >Reporter: Jean-Renaud Margelidon >Assignee: Upayavira >Priority: Minor > > When using the experiment UI and doing searches on collection, when > populating the hl.fl field, the value is used for the fl instead. > URL generated: > http://127.0.0.1/solr/collection/select?fl=content&hl=on&indent=on&q=html&wt=json > URL Expected: > http://127.0.0.1/solr/collection/select?hl.fl=content&hl=on&indent=on&q=html&wt=json -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
