[ckan-dev] Independent plugins (two or more) which extends dataset metadata fields

Mon Oct 9 12:50:05 UTC 2017

Thanks for explanatin (y) but I have one more question.
If I fill "extended" metadata with enabled "extras" plugin, what should
happen, if I open the dataset form again but with disabled plugin?
I supposed that "extra field" should appears as "Custom Field" but it
doesn't. (You can try it with eg. example_idatasetform.) Is it correct?

;?

On 6.10.2017 13:50, Ian Ward wrote:
> In ckan core we've discussed a general approach to supporting metadata
> from multiple extensions "plugin extras"
> https://github.com/ckan/ckan/pull/3072 (starting with users, but later
> extending to datasets, resources etc.) I'd love to see that work
> completed but it's fallen down on our list of priorities for now. If
> someone would like to help finish this off it would be greatly
> appreciated.
>
> On Fri, Oct 6, 2017 at 7:40 AM, Ladislav Nesnera <nesnera at email.cz
> <mailto:nesnera at email.cz>> wrote:
>
>     May be it could be useful. I described this issue for specific
>     case here
>     <https://github.com/aptivate/ckanext-syndicate/issues/8#issue-261978146>.  
>     ;?
>
>
>     On 6.10.2017 12:41, Ladislav Nesnera wrote:
>>
>>     Hi Matt,
>>
>>     thanks for your reaction (y)
>>
>>       * Syndicate extension
>>         <https://github.com/aptivate/ckanext-syndicate> writes into
>>         dataset metadata
>>           o ckan.syndicate.flag
>>           o and ckan.syndicate.id <http://ckan.syndicate.id>
>>       * our plugin
>>         <https://github.com/sorki/ckanext-redmine-autoissues> (based
>>         on previous)
>>           o URL of Redmine ticket
>>       * (third plugin
>>         <https://github.com/jakubklimek/ckanext-odczdataset> extends
>>         metada fields as is requier by national open data catalog
>>         <https://opendata.cz/en/>)
>>
>>
>>     We want have all thees "extra" fileds as "first-class metadata
>>     fields
>>     <http://docs.ckan.org/en/latest/extensions/adding-custom-fields.html>",
>>     not between "Custom Fiels" where users can damage them. All
>>     plugins works well separately, but not together. I suppose the
>>     problem is in how thees new fields are handled.
>>
>>     ;?
>>
>>
>>     On 6.10.2017 08:18, Matthew Fullerton wrote:
>>>     Hi Ladislav,
>>>     What do you actually want to /do/ to the datasets with the two
>>>     extensions?
>>>
>>>     -Matt
>>>
>>>     On 6 October 2017 at 05:17, Ladislav Nesnera <nesnera at email.cz
>>>     <mailto:nesnera at email.cz>> wrote:
>>>
>>>         Not yet any suggestion :( OK. I'll try explain it in use case.
>>>
>>>         1) We have two CKAN instances. Internal for all datasets and
>>>         external with open datasets only. I need preserve
>>>         information about tied dataset couple. (syndicate extension
>>>         <https://github.com/aptivate/ckanext-syndicate>)
>>>         2) We use Redmine <http://www.redmine.org/> as a tool for
>>>         managing tasks (data preparing, publication process, ..). It
>>>         requires bidirectional information task <> dataset. (own
>>>         extension)
>>>         3) Different functionality would be fine hold in different
>>>         independent extensions but booth need to write into the same
>>>         datasets.
>>>
>>>         Is it possile? How to realize it?
>>>
>>>         ;?
>>>
>>>
>>>         On 3.10.2017 02:28, Ladislav Nesnera wrote:
>>>>
>>>>         Hi,
>>>>
>>>>         I'd like to have two independent plugins which extends
>>>>         dataset metadata fields. I need to allow them separately or
>>>>         together.
>>>>         They could be derived from this example
>>>>         <https://github.com/ckan/ckan/blob/d73326ad4beb3743cb4a347b15c04dace8c8654b/ckanext/example_idatasetform/plugin.py>.
>>>>         I've tried it but I have no idea how to solve collisions
>>>>         is_fallback() and package_types() functions. Is it
>>>>         possible? Any suggestions?
>>>>
>>>>         LN   ;?
>>>>
>>>
>>>
>>>         _______________________________________________
>>>         ckan-dev mailing list
>>>         ckan-dev at lists.okfn.org <mailto:ckan-dev at lists.okfn.org>
>>>         https://lists.okfn.org/mailman/listinfo/ckan-dev
>>>         <https://lists.okfn.org/mailman/listinfo/ckan-dev>
>>>         Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>>         <https://lists.okfn.org/mailman/options/ckan-dev>
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     ckan-dev mailing list
>>>     ckan-dev at lists.okfn.org <mailto:ckan-dev at lists.okfn.org>
>>>     https://lists.okfn.org/mailman/listinfo/ckan-dev
>>>     <https://lists.okfn.org/mailman/listinfo/ckan-dev>
>>>     Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>>>     <https://lists.okfn.org/mailman/options/ckan-dev>
>>
>
>
>     _______________________________________________
>     ckan-dev mailing list
>     ckan-dev at lists.okfn.org <mailto:ckan-dev at lists.okfn.org>
>     https://lists.okfn.org/mailman/listinfo/ckan-dev
>     <https://lists.okfn.org/mailman/listinfo/ckan-dev>
>     Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev
>     <https://lists.okfn.org/mailman/options/ckan-dev>
>
>
>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20171009/1a2584a4/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20171009/1a2584a4/attachment-0003.sig>