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

Should do this sooner rather than later to avoid 'clear water' opening up and need to deploy then asap onto production machine to avoid 'clear water' between trunk and production (which then prevents pushing from trunk to production).

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

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 IP address is used to identify non-logged in users (for example on create and editing of packages) it is always 127.0.0.1 when using a reverse proxy (standard deployment configuration on a production machine and used e.g. on ​http://www.ckan.net).

This could be corrected by using HTTP_X_FORWARDED_FOR when available.

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

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)

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

As A

User

I want To

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

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.

See ticket:16 (update a file)

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

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

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

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

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

Title

Visitor visits service

As a

Visitor (general web user)

I want to

Visit the website of the service (frontpage)

So that

• See the front page and discover information about the service
• Perform various activities related to the service such as registering and finding packages, registering as a user and logging in