Custom Query (2152 matches)


Show under each result:

Results (58 - 60 of 2152)

Ticket Resolution Summary Owner Reporter
#667 wontfix API is slow thejimmyg dread

Reported by dread, 4 years ago.


See message and script:

1500 requests shouldn't take hours.

#1798 fixed API search in non-q fields has exception for unicode characters dread

Reported by dread, 2 years ago.


You get an exception if you use the API to search packages and specify a non-ascii character in a field other than q.

For example:

This "N-dash" (Unicode character 2013) causes this exception:

Module ckan.controllers.api:460 in search
<<                      if ver in u'12':
                               # Otherwise, put all unrecognised ones into the q parameter
                               params = convert_legacy_parameters_to_solr(params)
                           query = query_for(model.Package)
                           results =
>>  params = convert_legacy_parameters_to_solr(params)
Module in convert_legacy_parameters_to_solr
<<      for search_key in non_solr_params:
               value_obj = legacy_params[search_key]
               value = str(value_obj).replace('+', ' ')
               if search_key == 'all_fields':
                   if value:
>>  value = str(value_obj).replace('+', ' ')
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2013' in position 30: ordinal not in range(128)

This problem affects CKAN 1.5 and 1.5.1 only.

#1001 fixed API should use normal user credentials if available rgrp rgrp

Reported by rgrp, 3 years ago.


When using the API 'locally' i.e. from the CKAN instance (as would be the case with an ajax interface) the API, especially that allowing READ requests should use the normal user credentials if they are available prior to looking for an API key.

The key change appears to be to change _get_user_for_apikey method in lib/ BaseController? to check the c.user attribute (may wish to rename as the name may now be a bit misleading ...).

This is critical to incorporating any ajax editing into the frontend.

As part of this ticket we should do a general consolidation of the identification system in lib/ so that both api_key and normal user auth lead to the same set of auth-related objects being available (suggest c.user and c.userobj and

Note: See TracQuery for help on using queries.