Feature request: retain extra fields about ckanext-scheming

[CarlQLange]

Just in case someone wants this (and I think lots do), here's a copy-pastable solution:

In ckanext-scheming/ckanext/scheming/templates/scheming/package/snippets/package_form.html

from

{% block metadata_fields %}
{% endblock %}

to

{% block metadata_fields %}
  {% block package_metadata_fields_custom %}
    {% block custom_fields %}
      {% snippet 'snippets/custom_form_fields.html', extras=data.extras, errors=errors, limit=3 %}
    {% endblock %}
  {% endblock %}
{% endblock %}

[wardi]

Just not yet implemented.

The way I'm using scheming I don't want free-form extras, but many users would like to still offer support and the combining schema extras and free-form extras should work with the latest ckan master. We should have a way to specify if free-form dataset extras should be allowed with a schema.

[florianm]

Cool, no worries. I've got some prod data in extra fields which is tricky to migrate as any edit to a dataset with scheming fields deletes any extra fields. Would be great to choose from displaying extra fields or not, and retaining them (or not). Had a look in the code but couldn't figure out where the magic needs to happen :-)

[florianm]

@wardi as scheming disables free-form extra fields, and harvesting requires them, what's the path of least resistance to ckan_harvest between two ckan instances with (easy: the same, harder: different) custom dataset schemas?

[wardi]

@florianm free-form extras should work if we just add the edit fields back to the template. Care to give that a try?

The only problem is: how do we handle free-form extras with names that match the ones in the schema?

[NicolaiLolansen]

@CarlQLange Thanks a lot, this works just fine (y)

[GordianDziwis]

@wardi There is already logic which checks if a key is defined in the root or under extras.