Ian Ward

With discussions around generalizing search we should consider making https://github.com/okfn/ckanext-sitesearch a core feature.  search all the things!

I'd like to see a small core extension that adds a notice to the top of any page visited by a sysadmin account when a new patch release is available....

@smotornyuk mentioned that current jinja2 now has an `{% include … without context %}` that we could have our snippet tag emit instead of calling render and inserting the contents....

I like the idea of adding the jsonschema generated by qsv to the resource as a "schema" metadata field like the way ckanext-validation does. This way there's a clear method...

ckanext-validation stores the jsonschema as a resource metadata field so it can be edited as part of the form or via the API. I'm not sure what you mean by...

So a resource that appears next to the others in the dataset? Or just some tables in the datastore db with corresponding table names? We are using ckanext-validation in production...

If they're regular resources I can see issues with users: - wanting them displayed differently or hidden from the form/UI - reordering them so it's not clear which system resource...

just the branch I started a while ago where you can see some of the data dictionary overrides: https://github.com/ckan/ckan/compare/6118-table-designer#diff-9de4be8179eb39da879b2e19646f874128c85c2d673d277735c709405d706eac

async is great but it does mean you need to structure your application around it, and it comes with its own challenges in debugging because of the way execution order...

Worth a try. I'd keep `datastore_active = true` for any resource that has a datastore table and use a separate field to indicate that the data is being loaded though.