{22} Trac tickets (2647 matches)

Simple widgets in pure JS. For example:

• Count of datasets in a group (could generalise to a query but not sure how useful that is ...)
• Embeddable list of top X (5) datasets for a given query
• Embeddable list of *my* datasets

Either these live at: {site}/widgets and we have some kind of generator (form where I choose my group, or my query).

Or: we have this attached to areas of site where relevant.

Can combine the 2 so that the latter links to the former. Think first will be easier to do and possibly more useful long-term (e.g. can just link people to that page).

Cf. ​http://okfnlabs.org/ckanjs/

JavaScript? needs to be able to insert html templates into the document.

There are three common solutions to templating at the moment.

1. Insert the html into <script> tags at the bottom of the page and pull them in using the DOM and innerHTML. This is a very simple solution but not very portable.
2. Request the HTML snippets as plain text/html using XHR. This adds an extra HTTP request per template but is very clean. It would also be possible to inline the HTML into the JS at the minification stage for production.
3. Include the HTML in JavaScript? strings (horrible to maintain and bloats the js)

It makes sense to keep these with the other templates so that we can take advantage of localisation where possible. This indicates 1 or 2.

​http://localhost:5000/dataset/new_metadata/dataset

Controller : package Action : new_metadata

template package/snippets/package_metadata_form.html

It still contains the old build_search_index_synchronously which no longer works

Whilst the error messages returned from the dataproxy are informative, they aren't particularly human readable. It isn't clear to the user whether they should retry, or whether the format of their data is causing the problem etc...

Would be lovely if the error messages returned contained a human readable version of the error.

• created repo for final list of instructions: ​http://github.com/okfn/ecportal-server-setup

The related tab on the dataset page doesn't change its appearance when selected like the other tabs do

Unless explicitly told by the source web server the dataproxy should not assume that the content it has can be encoded as UTF-8. Even though the chars from 128 - 255 overlap an attempt to decode some byte array as utf8 will fail whenever a latin1 char whose bitpattern has the MSB set.

This will mean that the UTF8Recoder can be more rigid in its acceptance of data, Postel aside.

Looks like some of the style has been updated/changed on the group read page but the changes haven't been applied to the organizations read page.

If you change the language to one where the word for 'Search' is longer than the English word (e.g. fr) then the search button wraps onto the next line, below the text field, which looks bad.

There are some areas where the documentation could use some improvement and it would be good to have it available for 1.7.1.

• Add an introduction to harvesting support
• Add an introduction to CSW support
• Better upgrade docs: Some users suggested improvements to the upgrade docs on the list [1]. Also we should mention how the upgrade would work for point point releases
• Source install: see #2406

[1] ​http://lists.okfn.org/pipermail/ckan-dev/2012-May/002178.html

For example:

Creating a template in ckanext-demo/templates/base.html containing something like

{% ckan_extends "base.html" %}

Will extend ckan/templates/base.html

New form should allow three steps.

1. Add basic fields to create a dataset
2. Add a data resource to the dataset (this can be repeated multiple times using "Save and add another"
3. Add final metadata to the dataset.

It should be possible to jump backward through the steps by clicking the arrows at the top. Errors in fields should be validated for each step when the next button is clicked.

Implementation:

​http://s031.okserver.org:2375/dataset/new

There's no docs for setting up the internal analytics, nor what it provides.

Setup

Add: ckan.tracking_enabled = true to .ini file

Run: paster tracking -c dev.ini

Related links

​http://trac.ckan.org/ticket/2251

if not logged in then go to add dataset url the language is lost

check if this is a ckan 1.7 issue

​http://datahub.io/stats

templates/error_document_template.html

I've converted the 404 page to the new style but we probably want to serve this as a 'full page' ie content is 100% page width not sidebar and primary content

just go to a non-existant url to see

Discusion:

​https://okfn.basecamphq.com/projects/9558659-demo-ckan-front-end/posts/63374042/

Implementation:

​http://s031.okserver.org:2375/404

The following pages are missing complete breadcrumbs.

Add related page:

​http://s031.okserver.org:2375/dataset/adur_district_spending/related/new

Needs to look like.

Dataset > {dataset_title} > Related > Create Related

Template here: ​https://github.com/okfn/ckan/blob/feature-2375-demo-theme/ckan/templates/related/pages/form_page.html#L6

Same deal with Edit related.

​http://s031.okserver.org:2375/dataset/adur_district_spending/related/edit/5f9e665b-3e3c-428f-88b1-8554189cf14a

Needs to look like.

Dataset > {dataset_title} > Related > Edit Related

​https://github.com/okfn/ckan/blob/feature-2375-demo-theme/ckan/templates/related/edit.html#L5

When clicking 'add dataset' on a publisher/group page, the new dataset form should select the appropriate group.

Quite a few of the current test dataset resources have their format incorrectly specified as text/html. Attempting to preview these results in the browser trying to automatically download the resource, so for now we will not preview this format.

CKAN has memory leaks. They can be contained by limiting the time-to-live of a ckan process. An easy way to achieve this is to limit the number of requests a ckan server process can serve before it gets killed and replaced.

One should ...

• research ways to limit requests-per-process with the different web servers (see below for a start);
• explain these safeguards in the CKAN documentation and encourage users to apply them;
• consider the helper script ​ckan-create-instance to generate Apache configs with WSGIDaemonProcess ... maximum-requests=XY being active instead of ​commented out. Or at least let it warn the user to use MaxRequestsPerChild;
• Investigate current CKAN deployments whether they suffer from mem leaks, and if so contain them.

How to limit requests-per-process

• Apache:
  • Use WSGIDaemonProcess with maximum-requests=50 or whatever limit is appropriate. We did this sucessfully on ​datahub.io and the ​ckan farm
  • (This need to be verified) Without WSGIDaemonProcess, MaxRequestsPerChild 50 should achieve the same.
• nginx/supervisord: to be researched.

At present, a resource which is just a URL link to an external resource has a 'Download' button on the resource page. This gives the misleading impression that the resource is stored locally.

This is related to another small UI issue: I think the URL of a resource should be much more prominent, not buried in the 'Additional Information' table.

Suggested fix:

• Put the URL prominently at the top of the resource page (above the preview) (and make it link to the resource)
• Disable the Download button unless the resource is stored locally.

CKAN's default schema has fields for Author ('The name of the main contact, for enquiries about this particular dataset') and 'Maintainer ('another important contact person'). The distinction is not clear. Also the fields are often left blank.

The roles that seems most important are those of the original owner/publisher of the data, and the person maintaining the CKAN record/copy of it. So I suggest:

(1) Rename the fields 'Owner' and 'Maintainer'.

(2) Change the explanatory text for the relevant fields:

Owner: 'The person or organisation who create/collect/publish the data in this dataset.' Owner e-mail: 'E-mail address for enquiries to the Owner named above.' Maintainer: 'The person maintaining this dataset on [name of CKAN instance], if different from the above.' Maintainer e-mail: 'E-mail address for enquiries to the Maintainer named above.'

(3) When a logged-in user creates a new dataset, the main form should have a checkbox, checked by default, marked 'I am the maintainer of this dataset'. If checked, the Maintainer name and e-mail fields are populated from the user's profile.

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

This is not trivial, requires a database upgrade. But 0.12.3 has some nice new features (multiple vcs repository support, ticket comment editing and nicer preview) and the latest spam filter plugin requires 0.12.

​http://trac.edgewall.org/wiki/ChangeLog

Recline views should have a default table order, being the same as the csv that was imported.

If you go to http://ckan.org/features/geospatial/ there is a problem with the pop up tag shown (and zoomed in) - missing status and description.

We want a much quicker and easier way of deploying multiple CKAN instances to the same or multiple servers and managing them (e.g. configuration, themes, extensions, upgrades, and adding new instances). Currently we just deploy and manage each instance separately, which doesn't scale.. We'd also want to have (as far as possible) one single way of deploying CKAN that works across different situations, e.g. deployment server, demo server, jenkins, local deployment for development, these should share the same tools for installing CKAN and its dependencies.

Components that this might include:

Virtualenv bootstrap script ​https://gist.github.com/2206132

Ansible ​http://ansible.github.com/

CKAN deb package

After moving to Bootstrap the tables on the frontend look broken.

I believe this is to be merged in with site activity.

Discussion:

​https://okfn.basecamphq.com/projects/9558659-demo-ckan-front-end/posts

Implementation:

​http://s031.okserver.org:2375/en/revision

• the facet tags should only show free (non-vocab) tags
• decide on what fields to include in search facet list

This includes the tag page as well for now.

Discussion:

​https://okfn.basecamphq.com/projects/9558659-demo-ckan-front-end/posts/62998445/comments

Implementation:

​http://s031.okserver.org:2375/en/tag

Discussion:

​https://okfn.basecamphq.com/projects/9558659-demo-ckan-front-end/posts/62998362/comments

Implementation:

​http://s031.okserver.org:2375/en/user/register

Discussion:

​https://okfn.basecamphq.com/projects/9558659-demo-ckan-front-end/posts/62268474/comments

Implementation:

​http://s031.okserver.org:2375/user/edit

Discussion:

​https://okfn.basecamphq.com/projects/9558659-demo-ckan-front-end/posts/62268474/comments

Implementation:

​http://s031.okserver.org:2375/user

Discussion:

​https://okfn.basecamphq.com/projects/9558659-demo-ckan-front-end/posts/61911712/comments

Implementation:

​http://s031.okserver.org:2375/group/test-group

Discussion:

​https://okfn.basecamphq.com/projects/9558659-demo-ckan-front-end/posts/62234769/comments

Implementation:

​http://s031.okserver.org:2375/dataset/new ​http://s031.okserver.org:2375/dataset/new_resource

Discussion:

​https://okfn.basecamphq.com/projects/9558659-demo-ckan-front-end/posts/62821386/comments

Implementation:

​http://s031.okserver.org:2375/dataset/adur_district_spending/related/new

Needs a new endpoint at /dataset/DATASET/related/new this should have a form containing the following fields.

• Title (required)
• Type of item (Application|Visualisation)
• Description
• URL (required)
• Image URL

When submitted if an item is created it should redirect (303) back to /dataset/DATASET/related with a flash message saying "Related item was successfully created".

If failed to create it should redirect (303) back to the form and populate the error messages, see add dataset for examples (​https://github.com/okfn/ckan/blob/feature-2375-demo-theme/ckan/templates/package/new_package_form.html)

Discussion:

​https://okfn.basecamphq.com/projects/9558659-demo-ckan-front-end/posts/62308209/comments

Implementation:

(to be added once test server is working)

Discussion:

​https://okfn.basecamphq.com/projects/9558659-demo-ckan-front-end/posts/61906351/comments

Implementation:

​http://s031.okserver.org:2375/dataset/

tag_search and tag_autocomplete: The fields argument is not available when accessing this action with a GET request.

• [ ] 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).

see ​https://github.com/okfn/ckan/pull/5