468090 - kb search on the sumo front page only works when logged in

Status: RESOLVED WONTFIX

(support.mozilla.org :: Knowledge Base Software, task)

Description

[Marien Zwart]

When I go to kb search on http://support.mozilla.com/en-US/kb/Firefox+Support+Home+Page and enter some search terms I get a not very helpful "Error: You do not have permission to use this feature" page. After logging in the search works. This is probably not intentional (and should be made a bit more obvious if it is).

Comment 1

[Nelson Ko [:nkoth]]

Tried it when logged in. Switched the newsearch off in tiki-admin_newsearch.php and it works, but need cache flushing for fix to show for public users.

It could be that an admin turned on the "newsearch redirect" to test the newsearch (which is accessible only to admins)

And during that time, a public user went to the site and cached the page that had the redirect turned on.

Comment 2

[Laura Thomson :laura]

Seems to have gone away.

Comment 3

[[:Cww]]

Verified!

Comment 4

[Michael Köhler [:Coce]]

The problem seems to have reappeared, when I use the search on the SUMO main page, the error message "Error: You do not have permission to use
this feature" is displayed. When I'm logged in, the search function works as expected.

Comment 5

[Laura Thomson :laura]

Nelson, if you can't work out why this keeps happening, you're going to have to patch the template file and we'll do an off schedule push.  I'd say just take the logic out until we get search finalized.  

Interestingly, I note the homepage is *not* getting served from the NS so there's more than one strange thing going on.

Comment 6

[Laura Thomson :laura]

Attachment: Don't ever use newsearch.

Comment 7

[Laura Thomson :laura]

Comment on attachment 351689 [details] [diff] [review]
Don't ever use newsearch.

Requesting add'l review from morgamic in case nelson isn't around.

Comment 8

[Matthew Middleton (:zzxc)]

I added temporary javascript to Firefox+Support+Home+Page to fix this bug until this can be pushed to production.  When this bug is fixed, my edit to the home page should be reverted.

Comment 9

[Nelson Ko [:nkoth]]

Comment on attachment 351689 [details] [diff] [review]
Don't ever use newsearch.

Is <input type="hidden" name="where" value="f" />
 part needed?

Comment 10

[Chris Ilias [:cilias]]

I can't reproduce this anymore.

Comment 11

[Justin Wood (:Callek)]

(In reply to comment #10)
> I can't reproduce this anymore.

see c#8, there was temp JS added to the front page as a stopgap for the broken UX that resulted.

Comment 12

[Laura Thomson :laura]

Attachment: revised patch

Comment 13

[Laura Thomson :laura]

Attachment: doh, correct revised patch

Comment 14

[Nelson Ko [:nkoth]]

Comment on attachment 351868 [details] [diff] [review]
doh, correct revised patch

I have a better idea. See patch in https://bugzilla.mozilla.org/attachment.cgi?id=352096

Comment 15

[Laura Thomson :laura]

This is temporarily fixed by zzxc's js, and will be obsolete after we push 0.8.