{22} Trac tickets (2647 matches)

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/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/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/61911712/comments

Implementation:

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

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/62268474/comments

Implementation:

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

Discussion:

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

Implementation:

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

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

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

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

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

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.

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

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

If a dataset has no resources the resources list currently says '(none)'.

Here is a suggested improvement, provided that a maintainer is named: 'There are no data resources here yet. For information about this data, contact the dataset maintainer.'

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.

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.

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

Submit the form to see broken formatting.

eg. [u'Missing value']

Example

​http://s031.okserver.org:2375/not-here

Should show the 404 template.

stacktrace

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

For example:

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

{% ckan_extends "base.html" %}

Will extend ckan/templates/base.html

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

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.

Instead of pointing to /tags/{tagname} all tag links should just point to a dataset search filtered by that tag.

Examples are on the homepage and the dataset pages.

On the group read page ​http://s031.okserver.org:2375/group/nhs the add dataset button goes to the edit group page instead of the add dataset url.

It's in the tab bar (maybe not the right place for a button? but I wanted it to be next to the follower tab and count) and doesn't like very much like a button

there's a setting for this

• branch from 1.7.1
• apply CKAN patches that are current part of installation instructions
• create i18n patch so custom i18n directories can be specified via a config option

the user pic should be square on the user read page

If a user selects a language there are no mo files for then an error is raised. Revert to default language instead.

Implementation:

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

Implementation:

​http://s031.okserver.org:2375/dataset/edit/5b451cab-8671-4513-91c4-257784c1f484

See ​http://datahub.io/ckan-admin/trash and try to purge revisions (*not* datasets). It will fail on some of the revisions with errors like:

Problem purging revision 391db9e8-df57-4e0e-8fe6-d4e0c2318344: (IntegrityError?) update or delete on table "revision" violates foreign key constraint "group_extra_revision_revision_id_fkey" on table "group_extra_revision" DETAIL: Key (id)=(391db9e8-df57-4e0e-8fe6-d4e0c2318344) is still referenced from table "group_extra_revision". 'DELETE FROM revision WHERE revision.id = %(id)s' {'id': u'391db9e8-df57-4e0e-8fe6-d4e0c2318344'}

We should allow the user activity stream to be accessible with no js by passing a param or something. Need to agree how we hide/show basically agree what classes we use.

This should be a generalised solution that we can use in other places as needed.

I think this just needs discussion

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.

When there are multiple ckan sites installed on a single server via ckanbuild, there needs to be some way of upgrading them all to a new ckan version at once.

It should run the script to create the debian package, boot a VM, install the debian package on the VM, boot a CKAN instance, then run the tests.

Not all solr facet parameters are available through the pcakage_search action. In particular, facet.sort has been asked for; but this ticket should check to see if there are other parameters that would be easy to add too.

See: ​http://wiki.apache.org/solr/SimpleFacetParameters#facet.sort

Requirements

We need to be able to easily determine who the owner of a dataset or group is. Datasets and Groups should have an Owner, who may change over time but is a specific user within the CKAN instance. It should be easy for CKAN components to determine the user and for the initial version we should ignore the can of worms labelled 'ownership transfer'.

At this point migration is likely to be the biggest issue, and would suggest that it is acceptable that the last user to edit a dataset be set as the current owner.

More tickets should arise as a result of this work where we may be able to optimise some queries to use the new feature.

Interface

None

User Stories

None

Tasks

[ ] Analysis/Clarification?

[ ] Tests

[ ] Migration

[ ] Code/Schema? changes

[ ] Documentation

Estimates

Requirements

In the data hub plugin we require the ability to differentiate users between those that have paid for a service, and those that haven't. The distinction isn't boolean as there may be levels of service for paid users, so it may be that we need a 'type' of user where there are various grades of 'paid' which are likely to be strings (specific to the data hub).

Required interface

Once changes have been made to the user schema, for a given user we want to be able to:

• determine if they have a paid or a free account, and
• get a string name of the type of paid account.

Care should be taken to ensure that the 'paid' status of the user cannot be set through the API and only by the datahub plugin.

User Stories

User stories related to the management, setting and changing of a user's payment level, as well as historical information on payments should be done as part of the work that includes actually allowing purchases. For now it is adequate that we can manually control these things through paster commands.

Payments types should be linear as I don't believe for this type of service a pick-and-mix modular model would work well. Organizations will inherit the payment level of their owner, so currently there is no requirement for it to affect organizations at all.

• As a sysadmin I would like to be able to use a paster command to manually set a user's payment level, or remove it entirely.

• As a sysadmin I would like to be able to run a paster command to view a list of users who have a payment plan, grouped by the plan that they have.

• As a sysadmin I would like to be able to use the API to change the payment status of a specific user through user_create and user_update. This shouldn't be available to anybody else.

• As a user, and only if I have one, I'd like to see my current payment level on my user profile page.

Tasks

[x] Tests

[x] Plugin based migration

[x] Code

[x] Model

[x] API

[x] Documentation

Estimates

Requirements

To provide a freemium service it is necessary to be able to provide differing levels of functionality based on the type of user (see #2550). These levels can be specific to the data hub but may require overriding functionality from core to provide these checks.

Initial implementation should focus on limiting access to datastore disk space.

Interface

These changes are currently only for the data hub and should be kept as much as possible within the data hub extension.

User Stories

• As a system component I want to find out if the current user has access to a feature (i.e. storage) and if so to what extent (xMb, xGb or unlimited).

• As a system administrator I don't expect to need to manage the levels of users or the features that this applies to.

Tasks

[ ] Clarification of requirements/analysis

[ ] Tests

[ ] Code

[ ] Model

[ ] API

[ ] UI

[ ] Documentation

Estimates

Look into writing a cartridge for importing CKAN data into a Virtuoso quadstore

​http://virtuoso.openlinksw.com/dataspace/dav/wiki/Main/VirtSponger#How Does It Work?

They've become inconsistent as the design has changed.

• Remove white stripe
• Make text sizes consistent
• Make white space around text boxes consistent

• Needs tags
• Needs groups
• Needs slug
• Licenses links to something
• Needs tooltips (Ira to write some tooltips)