From the google doc: When I move between grid, graph and map view mode (or click on filters) the whole data explorer flickers (jumps up & down slightly) for a few moments before settling. This is happening on all resources for me and when you initially open launch the page: ​http://demo.ckan.org/dataset/afghanistan-election-data/resource/f6331f99-51f6-44d9-95b9-b20f3b74f360. Only in Chrome, working fine in Firefox.

On the edit dataset page... there needs to be a way for users to be able to see all the resources associated to the dataset and edit them individually.

Users could write ckan extensions that offer previews for a certain datatype.

Advantages:

• We can say that you can add your own previews
• Every preview would have to define it's own dependencies
• External development (community creates new extensions?)

Questions to answer:

• Specification of the interface
• Precedence of previews for the same data types
• Plugins only define the datatype that they are responsible for or do we call a function that returns whether the extension is responsible.

As far as I can see, this should be fairly easy to implement by following these instructions: ​http://docs.ckan.org/en/latest/writing-extensions.html#writing-a-plugin-interface

e.g. if I just changed a member's capacity I am not adding anything 'save' is better maybe

The button will not show if you are not authorized but browse to /organization/members/foo and you can edit the members, it does stop you when you try to save your changes, but you shouldn't be able to get to the page at all

e.g. it the 'Members' button links to /organization/members/0a44... instead of /organization/members/foobar

it is no longer used

From Toby:

A general cleanup of all auth functions (in logic/auth) to check their fitness, error messages, etc.

From Toby: A little polish to the member pages and probably a little hardening of the controller and logic actions

From Toby: checking the logic around the who can do what from the user stories - via some tests may be a good approach

From Toby: add the functionality to legacy templates

From Toby: strip more functionality from controllers and add via template helpers eg activity streams

From Toby: make the context auto-populated with things like user/model/session if not user supplied - especially for extensions (pre 2.0) maybe via a helper or else a decorator on the action - helper seems nicer maybe done via get_action()

From Toby: make lib/base.py be more like it was originally intended eg defines stuff that is shared eg _ but maybe try to include stuff like render/get_action if the circular import stuff can be solved - which should be doable if hard and likely needs an extra file or two for the externals _ etc

Afaik the new CKAN 2.0 frontend has no functional tests

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.

It would be nice to add similar popovers for other types of object in CKAN, e.g. resources, groups, organizations, tags...

Add an activity stream tab to dataset pages, like we have on user profile pages. Dataset activity streams are already implemented in the backend.

Before we do this we need to merge the organizations branch into master, we need to implement smarter activity streams for organizations, and we need to implement following of organizations.

Enable the multilingual plugins:

ckan.plugins = stats synchronous_search multilingual_dataset multilingual_group multilingual_tag

and set your default language to one not supported by the multilingual plugin, e.g.

ckan.locale_default = cs_CZ

now run CKAN and try to add a dataset:

File '/home/seanh/Projects/ckan171/ckan/ckanext/multilingual/plugin.py', line 141 in before_index

text_field_items+ default_lang?.extend(all_terms)

KeyError?: 'text_cs_CZ'

It doesn't matter what language you are viewing the site in in your browser, the default language setting in the ini file determines whether it crashed or not.

A number of supported languages are defined at the top of ckanext/multilingual/plugin.py. I think if the default language is not one of these it crashes.

I think this affects all versions of CKAN since the multilingual plugin was added so at least 1.7, 1.8 and 2.0

We need to test that only logged in users can see their own dashboard activity streams, and they can only see their own dashboard activity streams not those of other users.

When minified files are in use (set debug = false in ini file) the pin images for points don't show up in the data explorer map view when viewing a resource with geolocation data.

set debug = true will fix the problem by using unminified files instead but also turns on a bunch of debug stuff you wouldn't want on a production site.

middleware.py, around line 73, is where the decision to turn minified files on or off based on the debug setting is made. This can be hacked on a production site to run with unminified files but otherwise run on production mode thereby getting around the issue with the pins. But that doesn't fix the underlying bug.

From Knud Möller:

when I try to delete a non-empty tag vocabulary via the API (through HTTP), I get an internal server error. Checking the logs, this turns out to be a consistency error raised by sqlalchemy:

Error - <class 'sqlalchemy.exc.IntegrityError?'>: (IntegrityError?) update or delete on table "vocabulary" violates foreign key constraint "tag_vocabulary_id_fkey" on table "tag" DETAIL: Key (id)=(21421955-7560-467c-af30-9f790b73e6ae) is still referenced from table "tag".

'DELETE FROM vocabulary WHERE vocabulary.id = %(id)s' {'id': u'21421955-7560-467c-af30-9f790b73e6ae'}

URL: ​http://33.33.33.10:5000/api/action/vocabulary_delete

The error makes sense, but I'm wondering if it would be useful to extend the API to also allow the deletion of non-empty vocabularies, possibly via a parameter (not sure what best practice in API design is). At the very least, it would be cool if the error message coming back in the response had more information in it.

Just a ticket to keep track of a few suggested template changes.

Activity streams should be able to load more than 15 items within them. Suggest the default amount of loading is around 30 and then click to load more.

On the package controller the package_type is not passed to the lookup function, so the setup_template_variables defined on the extensions is never called

See Update a release (ticket 14) for more information on what should be shown.

As a

Authenticated user

I want to

Create a release associated with a package

So that

The package has a new release

Notes

• Permissions are as for updating a package ticket:10
• for details of release attributes see: updating a release ticket:14

As a

Authenticated user

I want to

Update a release

So that

The release details are amended. Attributes of a release are:

• name (may include '.' and '-'
• nickname
• date
• description

Notes

• permissions: as for updating a package (ticket:10)

As a

Authenticated user

I want to

Update a file associated with a release

So that

The file attributes are changed. File attributes are:

• (internal) id
• description
• source: (url usually)

Notes

• Permissions are as for package updating

As a

Registered user

I want to

Add a comment to a package

Notes

• The comment should be tagged with the username of the person making the comment
• Should we allow comments per release as well as per package? No for the time being.
• Comments will be 'flat' and not threaded (at least for the present)
• Comments should be plain text and so html should be escaped (in the future we might look to use some kind of formatter such as markdown)

As A

sysadmin

I Want To

Have revisions to the CKAN data filtered in order to reduce the spam in the system.

Details

In the long run this is a quite a generic problem common across several OKF systems and probably can become a general component in the okfmisc repo. For time being focus on a well-factored CKAN-specific solution.

Suggest we follow path of trac: ​http://trac.edgewall.org/wiki/SpamFilter

Could have a general engine that aggregates spam scores from many different 'plugins' and then marks spam appropriately (actions should be configurable depending on spam level from 'purge' to 'delete' (mark revision as inactive) to 'flag' to 'do nothing').

Main initial plugins would be:

• regex filter (this would seem very useful here, e.g. do not allow urls in commit messages ...)
  • could augment using the badcontent list approach (can find list on e.g. moinmoin)
• spambayes and/or akismet

Currently stored in the python controller file. This is not the right place and putting it in db will allow editing by admins.

May also want to do this for the footer (also in the controller file).

Details:

• Will need to create a new domain object/db table. Suggest called miscellaneous and consist of key value pairs utilizing JSON type for values.

Cost: 2h.

Should have function/facility to get a diff of a version object between 2 revisions. Function should return a dictionary of fields with diffs.

Details:

• Do we deal with m2m relationships (and m2one on the many side)?
• What is diff?
  • For text fields output of python diff command
  • For non-text field guess just simple +/- for what was there before and now

Cost: 4h (don't think this is a huge request)

Already support stateful list-like collections and should extend this to dict-like collections.

(This is prerequisite for implementing versioned "extra" (key/value) attributes on packages in CKAN and elsewhere).

Should not be hard to do (lots of existing libraries) but not sure that this is very important.

Support for listing files (manifest) contained within a package.

Traditional manifests just list the files. Suggest in addition we have support for optional metadata in form of key, value pairs.

(2009-03-09) Do not create a distribution at path X if path X already exists and contains material (unless forced via a force option).

Cost: 1h

(2008-10-29) convert existing directory on disk to a datapkg distribution (PythonDistribution? by default). This would be presented in the CLI as a convert command.

Details:

• Add a metadata file (setup.py), perhaps prompting for input
• List all existing data in that directory

Cost: 4h

This is better for long term sustainability, especially if we want to "push and pull" from unrelated repositories in the future.

Details:

• May wish to retain a number field updated in the usual incremental way (what's the cost/benefit here?)

Sister to ticket:90 (Link to RDF version of CKAN data on Talis Connected Commons).

Talis have already kindly done an initial conversion. We should repeat this process regularly and re-upload the data to Talis CC.

In the long run may wish to only re-convert packages changed since the last upload. However given relatively smaller size of full dataset this optimization is probably not yet required.

Attached is the ruby script used by Talis for conversion

Cost: ? (1d+ depending on e.g. how easy integration with Talis CC is)

Similar to ticket:108 but for tags:

/api/search/tag?q

For tags search is extremely simple since you can only search by name.

Possible Extras

• Allow "exotic" ordering of results e.g. ordering by number of packages with that tag.
• Return this number with tag list.

Using WUI or REST interface you can search packages and groups without authorization being checked.

On the REST interface you can also read all the attributes of the packages using the 'all-fields' option.

Can be fixed using more advanced query to check authz.

Suggested fields:

• id, name (username/profile name), openid, email, password, extras (JsonType?)
  • + current items: apikey, about, created)
  • current contents of name is usually openid and should migrate to openid field (could match based on starting with ​http://)
• May also want a fullname field (or perhaps that can

just go in extras - may be better to have its own field as useful to search on this )

Related changes (probably separate tickets):

• Improve user home page to include this additional information (and have it be editable)
• Use user 'name' (username) for home page links (rather than current user/<id>)
• Where we show lists of revisions, each revision author is now a link to the author's user page.

Related to ticket:136 and ticket:138.

Because people might try and do "tags:gov sweden" when "tag:gov sweden" makes more sense (sweden is searched for in all fields in these cases).

But in REST i/f search allow "tag"="gov" OR "tags"="gov sweden" in parameters.