{22} Trac tickets (2647 matches)

For example, after deleting a dataset old activity stream events will still hyperlink to that dataset.

Right now is quite difficult to get the most current version of a package via the harvest objects, and the queries involved are prone to errors. A new "current" field will be added which will identify unequivocally the most recent harvested object. Unfortunately this will involve some major changes:

• Model update (See #1726)
• Update queries for getting harvest sources' datasets
• Update ckanext-csw queries for getting the objects
• Update inspire and ckan harvesters
• Document new field

• Ensure you can add/change/delete extra fields from packages using the REST API.
• Update API docs to cover this.

On Package get, ensure separation of extra attributes from other attributes.

What is the meaning of posting an incomplete dictionary (updating a package)? Option 1 - if field not present, leave field alone

• Delete field if field value is None

Option 2 - user must supply all fields

• Delete field if field absent

Prefer option 1. Document this.

Follows on from ticket:152

EU27 option seems to have been removed at some point, needs to be added back to geographical coverage vocabulary and tested.

Since we now require email addresses, it's sensible to request users' gravatars to add a little flavour to their user profile (and, potentially, other places eg. comments threads?)

Need to add way for extensions to trigger based on resource change and just resource url change.

The JavaScript? just isn't going to work without it. Look into either the newer JSON3:

​http://bestiejs.github.com/json3/

or the old faithful:

​https://github.com/douglascrockford/JSON-js/

RDFa can be used as a simple way to expose linked data or at least sameAs the API version of the data but we need to make sure we do not expose anything different from the "official" representation.

Requests (​http://python-requests.org) is really useful to deal with http requests and saves a lot of time.

I propose we include it as a requirement for the tests for the time being, and even for core if necessary at a later stage.

We need a way to group resources by various different factors. The most important of which is timeseries.

The model will look like

Package <o2m> resource_group <o2m> resource

The use cases to this are outlined in this email. ​http://lists.okfn.org/pipermail/ckan-discuss/2011-February/000887.html

Add tables described in ​http://ckan.okfnpad.org/notifications

This requires adding a logic function for emitting an activity stream event, and then editing the logic functions for creating or updating users and making them call the new emit event function. This same emit event function can later be used to emit activity stream events for other types of object as well.

Before we do this we should implement smarter group activity streams (i.e. what activities should appear in a group's activity stream?) and following of groups.

Currently rendering of activity stream events to HTML works by looking up a rendering function in a dictionary that maps activity types ('new package', 'changed group', etc.) to rendering functions that take an activity stream event and return the rendered HTML.

There needs to be an extension point where extensions can register their own rendering functions for particular activity types.

Super #1669

As groups need to be authorised in some cases, particularly publisher profiles, we need a field to denote how this is managed.

We should add an 'approval_status' field that will be used to denote its status. By default this will be "approved" but this will allow us to override it with a "pending" or "denied" status. The latter should also change the main status of the Group.

Add the following attributes to package:

• author, author_email
• maintainer, maintainer_email

Gives us full compatibility to: ​http://docs.python.org/distutils/setupscript.html#additional-meta-data

Column ordering - should come after name, title, url, download_url.

Ideally the ./bin/less command would be run when the server is started.

• Also it would be good to have a paster command to build the production CSS with {{{ ./bin/less --production }}
• The command could also detect missing node binaries and redirect to the documentation.

Need to add capacities to member tables.

Add ckan_url attribute to REST JSON representation of a Package pointing to the (read) url of package on CKAN.

Cost: 30m

• [ ] Write up python coding standards as discussed at dev-meetup into CKAN docs. (Mostly written-up as part of dev-meetup notes.)

• [ ] Collate frontend coding standards (​http://aron.github.com/ckan-style/styleguide/) into same doc(s).

If you hover the mouse over a dataset or user in an activity stream, you now get a popover with some info about that dataset or user and a follow/unfollow button.

These popovers should appear wherever datasets or users are listed, throughout the site.

I think it couldn't hurt for this module to have a docstring at the top of the file explaining what the module is for. I know from setup.py that it's there to provide the extract_ckan() string extractor function for Babel, but I think looking at the file on its own it's not so obvious.

Also a couple of other small fixes:

jinja2_cleaner looks like a helper function only meant to be used by extract_ckan(), might make things clearer if it was called _jinja2_cleaner(), just so it doesn't look like a public function the module wants to export.

jinja_extensions seems to be a module-level variable that is only used in one function, could be moved into the function, unless you think there might be more functions that want it in future.

The default config file should contains examples (maybe commented out) for all config variables. Makes it easier to edit the config. For example openid_enabled is not in there.

Revision tables need expired_id to make querying history AND pending changes more efficient.

This involves making a session extension and a large table migration.

Need a central up to date place for currently supported extensions (closest we have is ​http://wiki.ckan.org/List_of_Extensions) & their documentation. I suggest this gets added to a dedicated section of docs.ckan.org

add extra fields to resource as outlined in

​http://wiki.ckan.net/Domain_Model/Resource

Specifically (all unicode strings except for those noted):

• name: a name for this resource (could be used in a ckan url)
• type: the type of the resource. One of: file | api | service | listing
• mimetype: standard mimetype (e.g. for zipped csv would be application/zip)
• mimetype_inner: mimetype of innermost object (so for example would be text/csv)
• size: [integer] size of the resource (content length) in bytes. Usually only relevant for resources of type file.
• last_modified: [datetime] the date when this resource's data was last modified (NB: not the date when the metadata was modified).
• cache_url: url for cache of object in ckan storage
• cache_last_updated: [datetime] timestamp when cached version was created
• webstore_url:
• webstore_last_updated: [datetime] timestamp when webstore was last updated

Similar to publicdata.eu, want to have themed areas such as finance, environment, census, etc and country tags

This optional method is supported when creating or updating groups and packages and is used in DefaultGroupForm? and DefaultPackageForm?, but seems to be missing from the interfaces. Should be added with docstring.

Add generator=ckan tag in head of templates to identify site as generated by CKAN

Decide which extensions are important.

Add image attribute for Dataset and Group which would be shown in prominent place.

For dataset this could be a relevant image and for Group this would be more of a logo.

I think this has very high value from a UX point of view.

Issues

• Do we need to support uploading and storing the image (or do users store elsewhere)
  • Could use something like transloadit service
  • Use our own storage facility with a reserved directory
• Do we need to do resizing etc?
  • Maybe. Perhaps can prefer this in reasonably small size and then just size down in css for thumbnails etc.

A link to the “register new package” page would be handy somewhere on the front page. As a frequent editor, I often go to ​http://ckan.net in order to create a new package. I don't want to hunt around for the link to the “new package” form.

The link could go into the bar next to “About / Statistics”. Or into the “More information” sidebar. Neither of these truly make sense, but it's a frequently accessed link and that's reason enough to put it somewhere onto the frontpage.

It is necessary to add a helper method to Group for adding members to that group so that

• nobody needs to work with the Member model
• It handles existing membership and existing membership with a different capacity

A new table with 3 columns should be added. term, term_tranlastion, language_code. This table will be used for all translations, including tags. The table should have indexs on both the term and (term, language_code) combination.

Probably use ansible to do this. To create an instance, create a dir at /etc/ckan/MYSITE, and put MYSITE.wsgi, MYSITE.ini and who.ini files in it. Also put a MYSITE file in /etc/apache2/sites-available. See the example files already present in ckanbuild. Booting a new site should be a single command.

May not handle the postgres/solr/elastic-search side of things yet, could just require the user to set these up herself first and then pass them as args to the create-instance command.

Datasets should have a field that specifies the language used in the dataset, this should be a two character ISO 639-1 code (see ​http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes for list) . Also make sure all tests and migrations are resolved. [2d]

Determine the best approach to having 'translation_of' references to show which dataset the current one is a translation of. This may be a translation of field, or a 'copied from' field or another form of package relationship. [2d]

We want some extensions from outside of CKAN core to be included in ckanbuild. These would be pip installed into the virtualenv before packaging the debian package. Decide which extensions to include.

Revision history information is not accessible, dgu want this.

can we add in the breadcrumb navigation to qa pages so that you can go back to ​http://s031.okserver.org:2375/qa from sub pages such as ​http://s031.okserver.org:2375/qa/dataset/five_stars

Because yes please