{"action":"created","issue":{"url":"https://api.github.com/repos/ckan/ckan/issues/3192","repository_url":"https://api.github.com/repos/ckan/ckan","labels_url":"https://api.github.com/repos/ckan/ckan/issues/3192/labels{/name}","comments_url":"https://api.github.com/repos/ckan/ckan/issues/3192/comments","events_url":"https://api.github.com/repos/ckan/ckan/issues/3192/events","html_url":"https://github.com/ckan/ckan/issues/3192","id":169709179,"number":3192,"title":"Dataset permission labels (take 2)","user":{"login":"wardi","id":153258,"avatar_url":"https://avatars.githubusercontent.com/u/153258?v=3","gravatar_id":"","url":"https://api.github.com/users/wardi","html_url":"https://github.com/wardi","followers_url":"https://api.github.com/users/wardi/followers","following_url":"https://api.github.com/users/wardi/following{/other_user}","gists_url":"https://api.github.com/users/wardi/gists{/gist_id}","starred_url":"https://api.github.com/users/wardi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wardi/subscriptions","organizations_url":"https://api.github.com/users/wardi/orgs","repos_url":"https://api.github.com/users/wardi/repos","events_url":"https://api.github.com/users/wardi/events{/privacy}","received_events_url":"https://api.github.com/users/wardi/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/ckan/ckan/labels/To%20Discuss","name":"To Discuss","color":"eb6420"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2016-08-05T22:37:40Z","updated_at":"2016-08-18T13:58:19Z","closed_at":null,"body":"This is a suggested change to the dataset view permissions.\r\n\r\nAt the moment we return only public datasets from `package_search` #3176 and `package_list`. Private datasets are visible from the front end on the organization page if you're a member of the organization (unless the controller has been overridden). If you know the dataset names or ids with `package_show` (unless the package_show auth function has been overridden).\r\n\r\nUsers might never find out about datasets they have permission to view e.g. if they only use the API, if they don't know the correct org to search or if search controller is overridden. Users might see datasets listed in an organization search page that they are prevented from viewing if the package_show auth function doesn't match logic in search controller.\r\n\r\nLet's deprecate customizing the package_show auth function and replace it with permission labels in the search index.\r\n\r\nWe implement our current permissions by adding `permission_labels = [pkg.owner_org]` to the search index for private datasets, and `permission_labels = ['public']` for public datasets. For non-sysadmins `package_search` will call a new plugin interface to get a list of permission labels for the search. By default that interface will return `'public'` and the UUID of organizations the current user is a member of.\r\n\r\nCKAN plugins would be able to implement that new interface and override before_index to set their own permission labels. This scheme should cover many types of permission business logic, including full 1:1 user permissions for viewing datasets."},"comment":{"url":"https://api.github.com/repos/ckan/ckan/issues/comments/240731006","html_url":"https://github.com/ckan/ckan/issues/3192#issuecomment-240731006","issue_url":"https://api.github.com/repos/ckan/ckan/issues/3192","id":240731006,"user":{"login":"wardi","id":153258,"avatar_url":"https://avatars.githubusercontent.com/u/153258?v=3","gravatar_id":"","url":"https://api.github.com/users/wardi","html_url":"https://github.com/wardi","followers_url":"https://api.github.com/users/wardi/followers","following_url":"https://api.github.com/users/wardi/following{/other_user}","gists_url":"https://api.github.com/users/wardi/gists{/gist_id}","starred_url":"https://api.github.com/users/wardi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/wardi/subscriptions","organizations_url":"https://api.github.com/users/wardi/orgs","repos_url":"https://api.github.com/users/wardi/repos","events_url":"https://api.github.com/users/wardi/events{/privacy}","received_events_url":"https://api.github.com/users/wardi/received_events","type":"User","site_admin":false},"created_at":"2016-08-18T13:58:19Z","updated_at":"2016-08-18T13:58:19Z","body":"We can implement almost any permissions scheme on top of `permission_labels` if\r\n1. we allow overriding the value indexed in solr from IPackageController `before_index` (don't apply the default permission labels when `permission_lables` is present in the dict returned from `before_index`)\r\n2. we allow overriding the permission_labels fq filter in package_search.\r\n\r\nFor (2) I'm not sure where we should do that overriding. We could do it in `before_search`. That would be consistent with populating `permission_labels` in `before_index`. My reservations are that this isn't the obvious place to do auth-related changes, and we're mixing user-supplied parameters in a dict with critical privacy-enforcing parameters. On the plus side it doesn't involve creating a new interface.\r\n\r\nI could make an entirely new interface with methods just for creating permission labels from a dataset and choosing permission labels for a package_search query (don't use a value from `before_index`). This option would make replacing the `package_show` IAuthFunction cleaner (I can just call these methods for the dataset and user and compare their return values directly). I'm leaning towards this approach.\r\n\r\n"}}
{"actor":{"display_login":"wardi"}}