As a

Visitor

I want to

Login to the service

So that

I am now an authenticated user and may perform the actions that only authenticated users may perform

Notes

• Login by providing username and password
• Login screen should also include a link or information about registration
• If username do not match (or the username does not exist) a login failure is noted and the visitor is re-presented with the login screen as well as information on how to register

As a

Visitor

I want to

Browse a list of packages resulting from a search or browse request (see other use cases)

So that

I can select one of the packages to view in more detail (-> viewing an individual package ticket:6)

Notes

• When browsing a list of packages you should be able to see summary information about the package such as title (though this may be shortened in order to conveniently fit the list
• The list should be broken up into pages so that the number of packages per page should be kept to a reasonable number (<= 50). Response time should be kept reasonable

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

As a

Authenticated User

I want to

Create/register a package

So that

The package will be listed in the system and visible to users

Notes

• Full package registration process may be broken down into:
  1. Creating a package by provision of minimal attributes:
     1. name: unique and web-usable
     2. auto-generation of default values such as:
        1. date-registered (today's date)
        2. first owner (one owner should be created corresponding to the authenticated user performing this action)
     3. (?) auto-generate a default release
  2. updating the created package -> ../UseCase12

As a

Authenticated user

I want to

Delete a package

So that

So that the package is no longer displayed for visitors of the site

Notes

• The permissions for this action are the same as for updating the package details (see ticket:10)
• When a package is deleted it is put in an inactive state and is invisible to users and vistors of the service. However its name remains reserved and it may be undeleted or purged by the service administrator

As a

Authenticated user

I want to

Create a file associated with a release

So that

The release has a new file associated with it

Notes

• Permissions are as for package updating (see ticket:10)
• file attributes are described in file updating: ticket:16)
  • there are no attributes that are required to be supplied to create a file

See ticket:16 (update a file)

Notes

• Currently have a text box where users can add space separated tags
• Tags should auto-complete in a manner similar to delicious
• would also be good to have a list of suggested tags. This could either be:
  • [simpler] a list below the tag box chosen by existing popularity or
  • [more complex] a list of suggestions that updates as you add tags (based again on popularity but 'filtered/reranked' to reflect choices so far).
  • For first attempt to should probably just go for the simpler option.

As A

User

I want To

Create/register and update a package via a web api.

1. install documentation (currently source:trunk/INSTALL is empty)
2. improve ckan-admin as necessary
3. create default data (such as licenses)

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

Visitor

I want to

View a list of the tags on the system and search for a tag by name

Notes

• As for a search of packages should search for tags that contains a given search string (or could use a glob approach allowing wildcards).

Spam entries have started to occur on ckan.net in the last few months. It would be useful to be able to purge these revisions -- that is permanently delete all changes to domain objects associated with those revision (one might also permanently delete that revision -- or alternatively simply mark it as purged).

In addition to providing this facility from the shell it would also be useful to be able to do this from the web interface (with associated restrictions on usage via an authorization controller of some sort).

When a package listing is shown (as on ​http://ckan.net/package/list) more information than just name should be shown. For example package titles should be shown as well as names (could also list tags and other stuff but simplest is just title).

Cost: 1

As A

User

I Want To

Add arbitrary named attributes to packages (an attribute being a name, type, value triple).

Details

• We will do this using a dedicated (versioned) table associated to Package
• Do we allow multiple attributes of the same name?
  • For the present: No (since we will key by attribute name)
  • Could allow for single attribute but with multiple values using json list ...
• What types do we allow or do we just rely on JSON to take care of this?

Questions (Original)

• How complex is this to implement?
• What would an arbitrary user be able to edit? Possibilities:
  1. 'create new attribute' and setting the value (so name and type would be chosen from predefined list).
  2. 'create', setting of name and value (but not type -- type already set in predefined list)
• Could just use (machine) tags -- though this could be seen as a bit of a hack.
• Would solve having to create special file/url attributes (though I think that perhaps file stuff is important enough to merit first class support in the domain model -- though, that said, since one won't want to have a file limit adding unlimited file support is very similar to unlimited attributes of arbitrary type).

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

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

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)

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)

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)

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.

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

It is essential packages have a version attribute to assist in tracking releases etc (and to allow compatibility with other packaging systems e.g. distutils which is being used by datapkg).

cost: 2h

Additional feature related to ticket:66.

cost: 2h

Switch from license domain object to a simple license field and use license list from new centralised license repo:

<​http://knowledgeforge.net/okfn/licenses/>

• This will require a migration

Cost: 4h (plus migration ...)

Cost: 2h

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.

• Number of package page visits on ckan (can we get this straight from google analytics)
• Number of times url or download url is used - now ticket:937 (Record download stats for resoures)

How do we do this?

• Google analytics will miss a lot of this usage (and how do we get that data out anyway)
• Could use javascript but again misses usage.
• One option is to redirect link but that is kind of nasty (but may be only option ...)

As a User or Visitor

I wish to rate a package in some way. On the package view, below Openness, there is a 'Rating' heading with the star rating which is selectable.

Rating out of 5. One user or IP, one vote.

package_rating table:

package | user | rating annakarenina | joe.bloggs.openid.com | 4 annakarenina | 154.2.5.47 | 1

Several things:

• Default package search (used e.g. on front page) should deal well with multiple items: "abc xyz" means search for both abc and xyz (as separate searches)
• Should automatically display a list of matching tags in a line at top with number of associated packages
• have an option to only search for fully open material (or openly licensed material ...)

Since we should be moving to a more sophisticated search solution anyway (to allow prioritisation etc) maybe we should cautious as to what we do now.

Allow 'ignored' fields on versioned objects (i.e. attributes which are not 'versioned'). This is not hard to do as we already have most of the necessary mechanisms set up in the Revisioner object.

Cost: 2h

No real benefit of having State object as opposed to a simple text field with enumerated values and this second option is both simpler and more flexible.

Main hassle here is that it requires migration in all projects that use vdm.

If we're going to do this we should do it sooner rather than later.

Cost: 2h (+ 1h for a conversion method)

Multiple download links, including links to mirrors and multiple formats/versions

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

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.

Should be able to limit ability to a user's ability to do things with packages (read, edit etc). This is a big ticket (it may required splitting) and full details are in separate wiki page: AccessControl.

Cost: 8d

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.

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

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

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

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)

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)