[ckan-dev] Harvesting of organizations

[Adrià Mercader]

Hi Stefan,

It's great that you are willing to implement this. One of the reasons
this wasn't implemented when support for creating remote groups was
added was that with organizations there is a much more implicit sense
of dataset ownership and permissions management. These won't be
transferred from the remote instance, so the documentation should be
very clear in that regard (ie users with permissions to edit a dataset
in the remote instance will most likely not be able to do so in the
local instance).

In terms of the actual implementation I suspect you can reuse lots of
the group related code to avoid duplication

On Thu, Aug 15, 2013 at 12:18 AM, Dave Caraway <dave at fogmine.com> wrote:
> the underlying question, should a typo in a name cause a new org to be created?
Remote orgs are obtained via the API from the remote dataset metadata,
so typos should not be an issue.

Looking forward to your pull request,

Adrià




On 15 August 2013 10:27, Stefan Oderbolz <stefan.oderbolz at liip.ch> wrote:
>> the underlying question, should a typo in a name cause a new org to be
>> created?
>
>
> I was planning to implement this feature similar to the remote_groups, where
> you have 2 options: "only_local" and "create".
> The first one only imports organizations that are already present on the
> instance, where the latter also creates new ones.
>
>
> On Thu, Aug 15, 2013 at 12:18 AM, Dave Caraway <dave at fogmine.com> wrote:
>>
>> i'm really interested in this capability. i would say with regard to
>> creating organizations automatically, might want to make it optional. the
>> underlying question, should a typo in a name cause a new org to be created?
>>
>>
>>
>> On Aug 14, 2013, at 11:51 AM, Stefan Oderbolz <stefan.oderbolz at liip.ch>
>> wrote:
>>
>> Hi there,
>>
>> I'm planning to implement the harvesting of organizations in the
>> ckanext-harvest extension. As the harvesting of groups (using the
>> remote_groups config option) is already implemented, I guess this shouldn't
>> be that hard.
>>
>> In the current code all I found was this:
>>
>> # Ignore remote orgs for the time being
>> package_dict.pop('owner_org', None)
>>
>> Are there already thoughts about this topic? Currently I'm planning to
>> just create the organizations that are not yet there and assign all datasets
>> to their corresponding owner organization (very similar to the
>> implementation of the remote_groups). The purpose is not to copy
>> users/permissions etc. but to simply allow all data owners to see their
>> datasets at a glance on the central instance and provide the functionality
>> to filter datasets of an organization.
>>
>> What do you think?
>>
>> Regards Stefan
>>
>> --
>> Liip AG  //  Feldstrasse 133 //  CH-8004 Zurich
>> Tel +41 43 500 39 80 // GnuPG 0x7B588C67 // www.liip.ch
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>>
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>>
>
>
>
> --
> Liip AG  //  Feldstrasse 133 //  CH-8004 Zurich
> Tel +41 43 500 39 80 // GnuPG 0x7B588C67 // www.liip.ch
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>