Ideas: new feature requests & ideas

Instructions: Add new feature requests and ideas that are not already on the roadmap here!

Please include a title, description and some use cases. For larger features, it would be worth starting a discussion on the ckan dev mailing list to get feedback before we add this to the roadmap board.

Suggestions:

• make the API multilanguage too, especially for the metadata - from Philipp Küng (@philippkueng)
• Provide a field during install(?) to enter a URL under which portal provider will offer the source code of their CKAN instance to fulfill requirements of AGPL, clause 13. (Marcus Dapp @digisus, 2013-06-28)
• Option for disabling avatars
• CUSTOMISABLE ORGANISATION LABEL/TERMINOLOGY: the ability to rename "Organisation" with your own word (label) - functionality of organisations (or whatever they were labelled) would stay the same. For an institutional repository (ie a single organisation in the usual sense) a different terminology would likely be more intuitive to our researchers i.e. in our use case the whole research institute is the 'Organisation', but we might like to use 'Research Team' or some other word(s) in place of the CKAN generic 'Organisation'.
• Parse an extended void file for gathering all dataset (meta) data instead of manual updates using forms. This feature would allow a provider to manually paste in a link to a void file once. CKAN would then import all recognized meta data into CKAN and automatically update this depending on the stated update frequency of the file. (Especially desired for the datahub.io)
• Provide a bit more help when looking at the resources in a dataset:
• Require names for resources.
• Require resource names within a dataset to be distinct.
• When creating a new resource, suggest a default name by munging the file name or last part of the URL path, e.g. "crime-stats-xml".
• Remove "extras" fields from Org creation screen. It's very obscure to need extra key-value pairs. If a particular field is needed in this instance, change the metadata schema and add it to the form. Org creators should not be inventing their own fields. At least hide it unless enabled in the config file.
• Create an OData connector for CKAN. Would be great if I can point the free Tableau Public to a CKAN-powered portal and do vizzes without being an R/Processing wizard (Tableau Public is like the Excel of Visualization).
• Integrate R processing/visualisation: e.g. somehow connecting to (or enabling r scripts stored alongside the data) to interact with the likes of http://www.rstudio.com/shiny
• Add support for CAS authentication - As a city, we really only want our city employees to have user accounts, which will be created by sysadmin. Then, we would use CAS to authenticate our users. No passwords would need to be stored in ckan. Members of the public would still be able to browse, search and download datasets.
• Add support for DCAT-AP (https://joinup.ec.europa.eu/asset/dcat_application_profile/description). DCAT-AP specification is based on the Data Catalogue vocabulary (DCAT) for describing public sector datasets in Europe and its basic use case is to enable cross-data portal search for data sets and make public sector data better searchable across borders and sectors