First review

[amercader]

@nigelbabu I didn't know where to put this

This is looking good, really good start. Some comments (I know some are copied from pages, I don't like them there either :) )

• Let's drop the ckanext_ suffix on action / auth functions names
• No need to import and add the model and user here, get_action will add them automatically if you pass an empty dict as context.
• I think actions should not abort things, as they might be called eg via the command line. Just let the exception propagate and it will be catch by the controllers, helpers, etc.
• I will probably use after_search, as this will ensure we record what was actually requested to Solr, and extensions can modify the params before.
• I'd rename the content field to params and store the whole search_params dict, otherwise storing just q is a bit limited. Examples,
  • We might want to check what sorting does people use
  • Check popular facets
  • Store bounding boxes for spatial queries
• We need to decide what we consider a "user search". As it is now, the extension will log any call to package_search, including any loading of the home page, dataset page, org page, etc. At the first stage, we probably only want to record them when the user enters something on the search box (both on dataset page and the site wide on the navbar). Also when clicking on facets on the search page. The only way I can think right now of doing this is doing these checks:

      if (tk.c
            and tk.c.user
            and tk.c.controller == 'package'
            and tk.c.action == 'search'
            and (
                (q is not None and not q in ('', '*:*'))
                or fq != '+dataset_type:dataset')
            ):  

This still misses stuff like spatial queries, but we can polish it later

• Let's put a hard limit on _list just in case.

Next step is start thinking in how to make this accessible to extensions. I'm thinking a h.get_search_history(user_id) helper function which just returns a list of search_params, and maybe another one that formats the output nicely, eg:

{"q": "rabbits", "fq": "topic-category:environment"}

to

Search Term: "rabbits", Filters: "topic-category:environment"

or similar

What do you think?

[nigelbabu]

Instead of a helper function, we should just have a JS module for it and action API (which we already do). Users can just add data-module="search-autocomplete" or some such and have it work on the searchbox.

[KrzysztofMadejski]

I've created views for showing search history on user dashboard. If you're interested check DanePubliczneGovPl/ckanext-danepubliczne@baa97cd

I'm thinking about config option that would store search into history only when user accessed any dataset from it. That would drop all the searches when user is just narrowing the result.. What do you think?