1. Visitor starts editing a package (or creates a new package)
2. Visitor logs in before previewing or committing
3. Visitor is an admin (or sysadmin)
4. Preview or commit fails

Reason (conjecture): the form we use for package editing is now dependent on whether you have admin privileges (we allow editing of state by admins). When you login the old form is now incorrect and this results in the formalchemy fieldset breaking.

Based on number of views.

Related to ticket:143.

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.

Have a news section (suggest as a sidebar item).

News section will link to latest 3/4 blog posts on CKAN from blog.okfn.org.

Details:

• Suggest pulling via rss or similar.
• Will want to cache this ...

Cost: 4h?

• Generic text box for markdown about the user 'About'

Model's user table reflects these:

• 'about' attribute
• 'created' attribute is a default=datetime.now() - so when user was created

Need edit page for this.

Only user should be able to edit it.

Follows on from ticket:136 and ticket:142

Cost: 2h

A user's 'home page' is at: user/<user.id> e.g. user/28394723982-03849472

Step 1:

• Current user home page with recent edits

Step 2: Readonly

• Number of edits
• Number of Packages they are admin of

How do we do a nicer URL for the home page - can we use their openid login?

Follow on tickets: ticket:138 and ticket:142

Using REST interface you can list packages and groups without authorization being checked.

Can be fixed using more advanced query to check authz.

As a

User

I want to

Create a new group via the WUI

Details

• locate at /group/new/
• You must be logged in to create a group
• Group creator is automatically given role of group admin
• Edit screen is same as edit screen ...

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

Cost: 30m

As a Package Admin I want to change the state of the package. In particular I wish to delete and undelete it.

(NB: this is quite separate from "purging" objects which is the term we shall use for irrevocable removal of an object from the domain model).

• Only Package Admins (and sysadmins) should be able to change state

Implementation Suggestions

• 'delete' action should be renamed to 'change-state' (NB: this requires a db migration ...)
• Have new package formalchemy form (created via inheritance?) to incorporate state attribute. Suggest this is rendered as a dropdown (and may be simple object rendering of state, i.e. do NOT need to change it to a single name such 'active').
• This form should then be used when the user satisfies is_authorized(..., model.Action.CHANGE_STATE) instead of the usual fieldset

Split out from ticket:43

Look for all places where model is accessed and check authorization is checked.

Document holes (and, as necessary, suggestions for fixes) as new tickets. Likely areas that need looking at:

• search i/f
• package WUI commit

Write holes are obviously much more significant to us than read holes.

Take out import of paginate in setup.py. Use paginate in webhelpers instead. Make changes to take account of any i/f changes.

Based on a section of AccessControl design: WUI gives controls to user and administrator to change permissions on a package.

Create in the model basic operation of Access Control.

roles table

name | context | action
-----------------------
admin| package | edit
admin| package | edit-permissions
admin| package | read
editor| package | update
editor| package | read
reader| package | read
This data is set-up on db init and will have no interface.

user-roles table:

username | context_type | objectid | role
rgrp     | system  | n/a | admin
visitor  | package | * | reader
bob      | package | geonames | admin
visitor  | package | geonames | editor
visitor  | package | geonames | reader
john     | group | ukgov | admin
dread    | group | ukgov | editor
visitor  | group | ukgov | reader
This data will be added when someone is given permissions for the system, a package or a group.

Pseudo code:

class Package

def is_allowed(name, action):

is_allowed(name, action, context=self)

class Group

def is_allowed(name, action):

is_allowed(name, action, context=self)

def is_allowed(name, action, context=None): name: string - a username or IP for 'visitor'

action: string - 'read', 'edit', 'delete', 'edit-permissions' context: object - a Group or a Package or None (which means system)

'paster db upgrade' should result in the same database as 'paster db create' on a clean system. In particular, all tests should pass.

Note: equivalent of paster db upgrade isn't being run from tests at the moment (we haven't been able to get this to work).

1. Package needs a groups property (backref Group.packages).
2. Put groups in the search api.
3. Display them on the package, but not editable. (Only editable from the group page.)

Follow up to ticket:105 (Groups).

Cost: 1d

Add package search facility in the rest api at /api/search

Queries can be provided as for the normal package search either by posting to that url or by performing a get with a query string.

E.g. .../api/search/package?q=xyz

Query parameters:

• q is keyword string (searches name, title, tags by default)
  • split by words and ANDed
• additional parameters for specific fields
• qjson is alternative to q for Searching by specific fields (in addition to keyword string). Payload to json is a JSON-encoded dict which is a dictionary with a q field for free text (keywords) and additional key/value pairs for specific fields
  • if q and qjson specified ignore q and just process qjson value

Additional parameters in addition to query ("q" or "qjson") are:

• limit
• offset
• fullinfo=0/1 - return full record for each result (default=0)
• order_by=field_name
• search_notes=0/1 (default 0) do we search notes field in a keyword search

Return value is json encoded dictionary with keys:

• 'results': list of results
• 'count': total number of results

Extras (for the future)

• Prioritisation is not part of this ticket (requires fulltext support in DB or in external app such as Xapian)

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)

As a user i want to see a package at "version" X (NB: not revision X).

• When I visit e.g. /package/read/xyz?version=0.7 I should be shown package at version 0.7 (or a message saying no such version)
• Implementation:
  • Find revision for this version (search revision history for when version field was last 0.7)
  • Show pacakge at that revision (as in ticket:103)
• On history page also shows versions in list of revisions associated with the package

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?)

(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

Replace use of pastescript templates in PythonDistribution? (write) with of something simpler (allowing us to remove dependency on pastescript).

(2008-09-10) at present when setup.py is edited info command may not give up to date information if pkg-info (in egg.info) is not rebuilt.

Suggest: info command needs to rebuilds pkg-info in python-type distributions.

Details of how to go about this here <​http://www.rufuspollock.org/2009/07/27/sqlalchemy-migrate-with-pylons/>

Cost: 2h

We should link to representations on semantic.ckan.net

• Each package page could link to its RDF representation
  • "Alternative formats" near star rating. Has logo for RDF (link to RDF) and JSON (link via CKAN REST i/f).
  • Some instances of ckan won't need this, so have option in ini file for this. rdf_store_url=xyz
  • Include machine-readable link to the RDF:

    <meta http-equiv=... />
    

  • 303 redirect to RDF when content negotiation requires RDF. Test:

    curl -I -H "Accept: application/rdf+xml" http://localhost:5000/package/warandpeace
    

Cost: 3h

Future

• Search page to link to SPARQL interface: ​http://semantic.ckan.net/sparql
• License/dump page could link to full RDF dump.

Support for download metadata (file size, file formats, version information).

See also: ticket:87 (multiple download links)

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).

Basic revert in the classic wiki form is already support by purging a Revision. However may wish to support:

1. Cases where multiple objects changed in a revision but only want to revert 1 (low priority)
2. Want to revert but have reversion as a new revision of that object.

Seems low priority at present.

Cost: ?

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)

Get rid of modes in the RESTful API. Do json stuff directly in controllers.

• package will have to_dict and from_dict methods (called by rest controller) which provide and consume JSON friendly dictionaries representing the object. from_dict - class_method. stuff in forms for tags as_string, maybe factor out. reuse validation stuff.

When you login you get given a cookie but it is very short (life of your browser session I think).

Work out how to extend to something reasonable (30 days or perhaps forever with logout unsetting cookie).

1. A quick investigation to see whether this is possible
2. If possible do it

Cost: ?

Current form stuff is not very good (uses formencode). Switch to formalchemy would improve this, especially on validation.

As an extra we could utilize the formalchemy pylons admin interface (pretty much for free).

Cost: 12h

Details

1. Replace htmlfill and formencode extract in controllers/templates with formalchemy
   1. Crude and simple
   2. Suppress unwanted fields (revision, state, all revisions) and sort out ordering to be similar to before.
   3. Sort out tag field with a special renderer
2. Validation - testing definitely required.
3. Fix up description and pretty css etc

On each package page in the openness field if the package is not open provide a link to is it open create enquiry page.

Details:

• may want to add to the url a query parameter indicating which package this relates to e.g. ?ckan-package=...
• ​http://isitopen.ckan.net/enquiry/create/?ckan-package=...
• do we provide link even if package is open (e.g. so that people can make enquiries about e.g. adding open data/content buttons ...)

Cost: 0.5h

Integrate new logo from ​http://wiki.okfn.org/ckan/logo into site:

• In title

Also can do favicon (separate ticket:48)

Cost: 1h

Cost: 1h

When listing revisions (at /revision/ or in atom feed) show affected packages. Minor but v. useful UI improvement.

Cost: 1h

1. Link at top should say "Your Account" when you are logged in
   • when not logged in should say: "Log in via openid"
   • Open Id info on /account/ should move to /account/login/ or be deleted
   • Going to /account/ when not logged in should redirect to /account/login/

2. When logged in the basic account index page should not give generic information but should reflect fact you are logged in by:

• Saying something like: "You are logged in as: ..."
• Showing your apikey or a link to apikey
• Giving you a logout link

We can think of a bunch of other stuff that could go on their (recent edits, packages you own etc) but these will be separate tickets.

Switch to repoze.who + openid plugin for authentication from authkit.

Already did this in microfacts so should be fairly easy.

Requires us to url encode the tag names when displaying them ...

1. List in sidebar 3 latest created/updated packages.

2. Put package search box on front page (might also want to move some of front page content into an about page).

3. Similarly might want package creation box on front page.

Make bookmarklet to enable easy package registration on CKAN

Details

1. This requires redoing web interface to allow 1-step package creation/editing (as opposed to name then everything else approach at the moment)

As A

User or Visitor

I Want To

See simple icons (e.g. tick/cross) next to packages (in lists or on main page) indicating openness status of package.

So That

It is easy to see the openness status of a package.

Details

• Suggested by Liz Turner
• Openness = open license at present (no easy way to determine whether accessible)
• Have separate tick for downloadability (i.e. existence of download url)
• Could do more stuff in future (e.g. money where tag price- exists, etc etc)

As a

Sysadmin

I want to

Dump (serialize) CKAN data to a simple transport format (e.g. JSON) and be able to load it again.

Details

• Already have simple db dump. However dumping to JSON has various advantages, particularly where changes to the data need to be made upon reloading (e.g. during a migration).
• Dump should include *all* CKAN data (i.e. all the data in the CKAN db tables)

1. Tag results could/should show number of associated packages
2. Package results should show title (and be in list)
3. Pagination should be able to be applied to other result sets than simply register listing (e.g. search results ...)
4. Revisions should be listed in a table with full details

Research apt-get especially wajig and python wrappers for apt-get. Post results on the wiki.

Because CKAN's worth it!