Closed Bug 928098 Opened 11 years ago Closed 11 years ago

Resubmitted Super Search query converts/escapes/decodes = to %3D (and adds extra params), which kills results

Categories

(Socorro :: Webapp, task, P1)

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: stephend, Assigned: adrian)

References

()

Details

(Whiteboard: [qa+])

Assignee: nobody → adrian
Priority: -- → P1
Here is what's happening: the page loads with a set of parameters that say "dump has xxx". However, the "has" operator is not allowed for strings, and the dynamic_form lib will thus fall back to using the default "is exactly" operator. When you click "Search", it changes the URL to what it should indeed be, and adds an encoded = in the URL, as that is the operator for "is exactly". 

My solution is here: https://github.com/mozilla/socorro/pull/1603

It simply changes what the default operator is when a not-allowed one is used. For strings, it will be "contains", which is the closest to what users would expect by typing "dump=xxx".
Commit pushed to master at https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/03e2118a3a8832a2e07c7c8e48d8f936cf0eae2f
Fixes bug 928098 - Made default operator an allowed one instead of "has" when it is missing. r=peterbe
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 64
Whiteboard: [qa+]
I can't actually verify this until bug 872547 is fixed, so I've set that dependency.  Should we move this bug's milestone and/or reopen, Adrian?
(In reply to Stephen Donner [:stephend] from comment #3)
> I can't actually verify this until bug 872547 is fixed, so I've set that
> dependency.  Should we move this bug's milestone and/or reopen, Adrian?

Spoke with rhelmer, and I'm reopening and retargetting for 65, so this can be fixed and re-tested/verified then.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: 64 → 65
Target Milestone: 65 → 66
I believe we can mark this as resolved already. Here is a way to verify it:

1. Go to https://crash-stats.allizom.org/search/?signature=hang
2. I shows data that have the term "hang"
3. Click the search button, it now shows data containing the string "hang" 

Note that the latest result is slightly different, for example "Change" will be returned in step 3 whereas it wasn't in step 2. 

I believe this is a good solution for this at the moment. The reason for this difference is as follow: the URL for the search page is generated by a javascript script, based on the search form. However, if a user enters a URL manually, then that user can use values or operators that would not have been accepted by the JS script. At the moment, we do not pass that manually generated URL to the script first, and send it to the webapp right away. It results in queries being performed while it would not have been possible through the UI only. And thus leads to different results being displayed after pushing the Search button (and going through the JS validation). 

I don't think we want to change that behavior, because it would need adding some overhead in the page load and making it slower. This should be an exceptional case enough that we can afford not to make the normal behavior slower.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Target Milestone: 66 → 65
Thx Adrian, the explanation makes sense to me.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.