With the latest template, css and js changes in 2.0, there are a number of things that need preparation prior to a production deployment. One of these is:

• the less files should be compiled to css (main.css, not just main.debug.css)

This ticket is to provide a paster command which will compile the .less into the main.css file. The idea of the paster command is that it will be run by developers, and they will check in the resulting .css files. It will also provide a convenient mechanism for production scenarios with node.js installed on the production server, as they will be able to compile the .less there as well.

## Background

The .css files that need to be served are built using less. The css files that are generated *are* checked-in to the repo; but they are a build artifact. So the general workflow is:

• commit changes to the less files
• build the main.css file and commit

This paster command slots into the above workflow for convenience.

## Notes

• doc/frontend-development.rst
• bin/less

to run this paster command, Node will be required. So that dependency should be checked.

## The paster command

This is the proposed behaviour of the paster command:

• ensure custom.less does not exist
• for each colour in{fuchsia,green,maroon,red}:
  • generate a custom.less file for $colour. There's a paster command that does this already: `paster color <color name>.
  • generate the css from the less files. ie - the equivelant of running bin/less --production.
    • this will generate a main.css file, which should be renamed to $color.css.

• ensure custom.less does not exist
• generate the css from the less files. This will create a main.css with the default colour scheme.

• call the paster command that minifies css and js files. (This command does not exist yet, see #2950)

The GRANT SELECT ON ALL and ALTER DEFAULT PRIVILEGES are not available in Postgres prior to version 9.0.

Repro:

• Create a new Group, named "test-group".
• Add a dataset to it.
• Verify the dataset belongs to the group by visiting the Group's read-page
• Update the Group through the action api (group_update), using the uid in the "id" field, and a new name in the "name" field.
• Visit the group's read-page. The list of datasets will be empty.

This was an issue when editing a Group through the web interface, which was fixed in [1]. However it only fixes the issue in the group controller.

[1] ​https://github.com/okfn/ckan/commit/dbe25d8b8d7fabfc40c5d794a920b91cec349335

Could be done by:

• using the solr distributed search
  • difficult set up
• merging result sets from apis
  • make sure that results can be merged properly (score, facets, ...)

If you are the only admin of an organization you can edit the organization's members and demote yourself, then the org has no admins and no one (except sysadmins maybe) can edit it.

Last admin should not be able to remove or demote herself.

Also applies to groups.

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: remove the config from jinja2 templates get all such stuff via g. (before 2.0)

From Toby: c) refactor lib/base.py to remove the circular import issues (render functions to lib/render.py - would fix much of that)

From Toby: make lib/helpers more template specific and less generally shared with none template uses (some functions are shared but many shouldn't be) - again help avoid circular imports

From Toby

'Add dataset to organization' button, when you get through to the third stage of the new dataset form the organization you came from is not selected.

I don't see any option to choose the group when adding or updating a dataset, but if I add a dataset via the "Add dataset to group" button on a group's page, then the dataset seems to get added to that group. (And I can also add/remove existing datasets by editing the group.) I wonder if organizations should work the same way, instead of having an Organization drop-down when creating or updating a dataset. The add dataset page needs to somehow indicate that you're adding a dataset to a certain group or organization though, doesn't currently.

Currently if you want to customise the header.html template you have to copy the whole thing, it isn't broken up into blocks like other templates are.

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

Just to track @tauberer patch on Github. Probably going to 1.8.1

There are some new translations already on the CKAN 1.8 resource on Transifex already (e.g. 100% Norwegian translation I think). We should at least pull these from Transifex for 1.8.1, and may as well do a call for translations too.

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.

Deleting extras in the web interface is broken

Extension hooking into the edit and create methods of the IPackageController interface receive the package object. This may not include all the fields that came from the form. The new extension points will pass the validated data_dict so extensions can have access to it

nav_named_link won't include the nice icon even when passing the icon keyword param.

​https://github.com/okfn/ckanext-pdeu/issues/13

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

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