package_search include_private flag #3191
Conversation
|
This needs some more tests covering include_private as a normal parameter. We could also add a config option to default to showing private datasets in the normal search page here too. |
|
Spoke to @amercader about this on Tuesday and we decided to enable display of private datasets on the default search page as part of this PR. There will be a new option |
|
Question - would having the search results set to (true) include_private datasets affect if private datasets are indexed by google... (currently they are not)? |
|
anonymous users (like google) shouldn't be able to see private datasets. If you can see private datasets without logging in with these changes please let me know! |
| super(cls, cls).setup_class() | ||
| helpers.reset_db() | ||
| search.clear_all() | ||
|
|
There was a problem hiding this comment.
Why getting rid of these class setup methods?
There was a problem hiding this comment.
They're duplicating code already in the base class
|
@wardi looks great, some minor comments |
|
Thanks @wardi. We should make sure that users with customised package_show will be informed about this change in advance as it might cause trouble for them. This includes of course careful documentation in the release notes. Any other suggestion where to place a notice? |
|
@nibecker yes, we'll need to include the new parameters to package_search in the changelog, however If you've customised package_show you should know you're going to have trouble with upgrades. Overriding a core action is pretty much the same as monkey-patching CKAN code. edit: parameters are new on package_search, not package_show |
|
@wardi is that ready to go or did you want to add more tests? |
|
@amercader I was just looking at that. Are there cases that aren't covered by the current tests? |
|
Maybe "sysadmin can search private datasets" and "user from org1 can not see private datasets from org2"? I know auth testing of the underlying actions should cover that but just in case :) |
|
@amercader sure, but I'd like to do those tests at the action level because there's no custom code for either of those cases in the controller |
|
But this should be just a matter of setting the appropriate |
|
@amercader ok, added those too |
|
PEEEEEEEEEEP 8 🎱 💀 |
|
@wardi fixed that myself, merged now |
[all][l]: Rework the CKAN Explorer to provide new features - Single dataset operation: supply dataset in the URL and we go directly to that resource - Support grabbing data from CKAN user's private datasets (requires a very recent version of CKAN) - Don't append resource views but rather replace them so that ckan explorer becomes more of a single-page SQL tool; for opening multiple resources there are buttons to open them in new tabs - Minor formatting changes (code and appearance) See also: ckan/ckan#3191 rufuspollock-okfn/ckan.js#25
Proposed fix for #3176
Stop using a context variable in package_show to return private datasets (only works from inside ckan), instead allow users to pass
include_private=Trueto have all datasets they have permission to see returned.This is essentially what is already allowed when users browse to the organzation search page unless there's a customised package_show auth function. In that case we might be exposing more information than was available earlier (users can get the whole dataset metadata not just what's seen in search results). We'll have to change the way permissions on datasets are defined to fix that issue, see: #3192 for next steps.