The problem is described well in this open issue for JIRA: https://jira.atlassian.com/browse/JRASERVER-38511. Note that the only mentioned workaround is to set Security Level = "Public" issues to "None". The issue has been around for a long time and doesn't appear ready to be resolved anytime soon.
What I would guess is happening is that the search either isn't assuming an anonymous user should see Security Level = Public issues, or is adding Security Level = None to the anonymous user's query behind the scenes. If we had access to the JIRA logs we'd be able to see the exact query and know which it is, but that also doesn't really matter - somewhere the query isn't working, and what INFRA is attempting to say is *we have no control over that*. The only solution is to possibly come up with some other workaround no one else in the JIRA community has come up with, and tell INFRA what to change in our projects. But based on the comments in that JIRA issue above, I'm reasonably sure we're stuck with it. On Tue, Jun 6, 2017 at 10:00 AM, Alexandre Rafalovitch <[email protected]> wrote: > Ok, makes sense to have it. That probably means we did request it > somehow (PMC?). > > But then our group/search settings are not configured properly. > > How would we go about fixing it? > > Regards, > Alex. > ---- > http://www.solr-start.com/ - Resources for Solr users, new and experienced > > > On 5 June 2017 at 15:52, Mike Drob <[email protected]> wrote: >> I think the issue security level has to be around in order to keep some >> issues private. For example, >> https://issues.apache.org/jira/browse/SOLR-10031 before the 5.5.4 release. >> >> Not sure if there's an alternative model that will still allow for >> responsible disclosure of security issues. >> >> Mike >> >> On Mon, Jun 5, 2017 at 2:46 PM, Alexandre Rafalovitch <[email protected]> >> wrote: >>> >>> Because: https://issues.apache.org/jira/browse/INFRA-13729 >>> >>> TLDR: some GSOC 2017 issues were not visible to non-logged-in users >>> for multiple Apache projects. INFRA thinks we opted in to the "Issue >>> Secruity" field that is causing it, and perhaps deliberately picked >>> non-optimal defaults/configuration. >>> >>> Any insight would be appreciated to see whether it is worth chasing >>> this further. >>> >>> Regards, >>> Alex. >>> ---- >>> http://www.solr-start.com/ - Resources for Solr users, new and experienced >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
