Fix @search GET

[cdevienne]

The @search GET implementation does not json-decode the "q" parameter, which makes it impossible to use.

[coveralls]

Coverage decreased (-0.006%) to 89.977% when pulling 27219bb on orus-io:fix-@search-get into c2ac0b3 on plone:2.5.x.

[vangheem]

I think we should then also change the permission from guillotina.SearchContent to guillotina.RawSearchContent

[cdevienne]

I guess it makes sens. But if we are to make a difference between a raw search (which depends on the search engine if I understand correctly) and a search that would be engine-agnostic (with a common query language), how about renaming @search to @rawsearch ?

[vangheem]

The GET endpoint was original designed to be this but implementation was never finished.

We can rename both POST and GET @rawsearch then too.

This is underdeveloped because we just don't use it. We have our own query builder and our own endpoint for doing querying.

I'm okay with negotiating solutions here. I just can't allow us to give reuse the guillotina.SearchContent here.

[cdevienne]

Will do that then.

[cdevienne]

I chose not to rename the service to @rawsearch because it would be an api breakage (hence not suitable for a maintenance release).

[vangheem]

Sorry, looking over this more, the correct functionality would be to connect it with this method: https://github.com/guillotinaweb/guillotina_elasticsearch/blob/master/guillotina_elasticsearch/utility.py#L144

https://github.com/plone/guillotina/blob/master/guillotina/catalog/catalog.py#L35

I don't think we should make assumptions like q = json.loads(q) if we're going to try and implement something generic.

If you need this, the endpoint is simple enough, I suggest implementing it in your add-on code.

We'd probably need to think about some generic query language to support.

[cdevienne]

Fair enough.
I will add my own endpoint then.