[ckan-dev] API Search does not return deleted packages

Fri Jan 20 14:55:23 UTC 2012

Philipp,

Great to hear it - I'll do my best to get these in. You can track
progress in the tickets, or ask again here on the list.

David

On 20 January 2012 13:38, "Lämmel, Philipp"
<philipp.laemmel at fokus.fraunhofer.de> wrote:
> Hey David,
>
> thanks for this clarification and yes, this would suit our use case. It would be awesome if those API calls would get into CKAN 1.5.2!
>
> Thanks again and best regards,
> Philipp
>
> -----Ursprüngliche Nachricht-----
> Von: ckan-dev-bounces at lists.okfn.org [mailto:ckan-dev-bounces at lists.okfn.org] Im Auftrag von David Read
> Gesendet: Freitag, 20. Januar 2012 13:22
> An: CKAN Development Discussions
> Betreff: Re: [ckan-dev] API Search does not return deleted packages
>
> On 20 January 2012 09:42, Philipp Lämmel <philipp.laemmel at fokus.fraunhofer.de> wrote:
>> Hey David,
>>
>> Our use case is somehow similar to an additional draft state. But in
>> more detail, our use case is the following:
>>
>> Our platform separates two types of users : readers and so called
>> package owners. Package owners are allowed to add or edit datasets.
>> Additionally, package owners have the possibility to 'hide' a
>> (faulty) dataset and publish it later again. This is achieved by
>> setting the state of this particular dataset to 'deleted' / 'active'.
>
> Thanks very much for explaining your use case.
>
> We use deleted as a more permanent change. Rather like a file system, no-one in reality uses the wastebasket as a temporary storage area, although technically it can be used for that.
>
> I think using the permissions model would be more appropriate to stop people seeing these particular datasets temporarily.
>
>> We have to different API calls for readers and package owners: readers
>> use an API call without a key (that's why they don't see deleted
>> packages) and data owners used a call with an API key (therefore they
>> saw their own 'deleted' packages, too).
>>
>> On CKAN 1.5.1 this won't work anymore, since package owners don't see
>> deleted packages and can't republish them.
>>
>> A note on an additional draft state: This would be an elegant solution
>> to this use case. But I do think, that you have to reinsert a
>> distinction between a call with or without an API key.
>
> There is still a distinction - the user is identified, and what is listed is affected by permissions. For example, she will probably have the 'admin' permission for datasets she created. This means that she can remove the 'read' permission for other people and still see it in her list. This sounds like it suits your use case?
>
> If you want all the 'package_owners' to have access to all the 'hidden' packages too, then you could create a 'package_owners' role and give it edit/admin permissions for all the datasets.
>
> I note that we don't have any API calls to change the permissions - currently just the web API. That is a serious omission which I'll look at now. So if you wanted to 'hide' a dataset using permissions then the only current way is with the Web UI until this is implemented.
> There's a chance we can get this into 1.5.2 which is about 2/3 weeks away. http://trac.ckan.org/ticket/1688
>
> What I think would also be useful is if we extended the package_list API call to take a 'state' parameter, so that deleted (or 'draft' when we have this) datasets could be exposed in the API.
> http://trac.ckan.org/ticket/1689
>
> David
>>
>> Best,
>> Philipp
>>
>>
>> On 01/18/2012 05:52 PM, David Read wrote:
>>>
>>> Philipp,
>>>
>>> Yes this changed because it was confusing lots of people. We decided
>>> that deleted packages should be hived off into a 'trash can' area for
>>> administrators, rather than in the main list, search results etc..
>>> That's the way it's viewed in the front-end. Admittedly the trash can
>>> is not available (yet) in the API - no-one's asked for it yet but
>>> maybe this is what you're after.
>>>
>>> The whole concept of deleted packages is something we've gradually
>>> developed, as it's difficult to get right.
>>>
>>> Do tell us what you're using hidden packages for. Here are my guesses:
>>>
>>> * a sort of 'draft' state? We envision using the state field for
>>> this, but work needs to be done to achieve this - perhaps you can
>>> help spec it out.
>>>
>>> * Or is the intention to keep these datasets private to particular
>>> people? Maybe try removing the 'read' permission for the average user?
>>>
>>> David
>>>
>>> On 18 January 2012 16:36, Philipp Lämmel
>>> <philipp.laemmel at fokus.fraunhofer.de>  wrote:
>>>>
>>>> Hey all,
>>>>
>>>> I've updated my CKAN to 1.5.1 and noticed that there is no
>>>> difference anymore in the output of the call
>>>>
>>>> http://<ckan-instance>/api/rest/dataset
>>>>
>>>> for package owners (with API-Key) or anonymous users.
>>>>
>>>> In CKAN 1.4.2 this call showed all deleted packages for package
>>>> owners, too.
>>>> This was quite handy for us, because we used this for hiding datasets.
>>>>
>>>> So my question is (rather short and simple): Why did you drop this
>>>> distinction?
>>>>
>>>> Thanks and best regards,
>>>> Philipp
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ckan-dev mailing list
>>>> ckan-dev at lists.okfn.org
>>>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>>
>>>
>>> _______________________________________________
>>> ckan-dev mailing list
>>> ckan-dev at lists.okfn.org
>>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>
>>
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev