Many actions in the Action API require parameters. What params are needed should be listed and checked. Because currently, if you get them wrong you simply get a useless 500 error.

Currently they are listed in the docs, extracted from the code manually.

So you could GET /action/api/package_list to receive not only the help text, but a list of arguments.

And if you send an extra or missing argument then an intelligent error message can be returned.

implementation

How about some sort of decorator on the action function:

@logic_params(id, offset, limit)
def get_package_list(context, data_dict):
    ...

This would do the param checking, and is there a way to extract these params from the function? Or do a registration of the logic function?

I'd certainly like to keep the list of the list of params for the function with the function, for ease of reading the code.

Another good thing would be to pass in the params named as themselves, rather than having them contained in the data_dict.

Super ticket: #1032

• Locate at: /dataset/{dataset}/resource/{id}

See: ​http://wiki.ckan.org/Dataset_View_Page

Implemented in branch feature-1445-resource-view.

Still to do:

• Add inline data explorer to page

Celery is awkward to deply, need to find a way to do it more simply. i.e using celery-pylons and supervisor. A modified version of celery-pylons may be the best solution. 1d

See ​http://wiki.ckan.org/Dataset_and_Resource_Pages_Proposal

• Create a collapsible section for the README
• Reduce the number of things on the page
• Tidy up groups and tags in the sidebar
• Resource view becomes a list of search results

(additional)

• Resource navbar item links to first resource
• Resource navbar has a dropdown menu of all resources in the dataset
• Edit and Authz navbar items should be in a separate logical group to the right

Very rough summary: create more info section and move stuff out (relayout page e.g. README, tags etc)

There are issues with setting the site's language according to the browser detection:

• Many browsers have the language setting incorrectly set. e.g. people who download US versions of Mozilla, pirated US copies in the far east.

• Although thedatahub.org has a worldwide audience, many CKAN instances are designed for a particular country's citizens. So Open Berlin should probably be in German as default for all.

I suggest the site should have a default language saved in the config. The browser language *should* be detected, and that prompts a flash message offering to change to that language. And if you change language that is saved in the cookie (as we currently do).

Then do some testing to see if this suits people.

We made SOLR the main and only supported way to do CKAN search three months ago (#1275), but I notice that we still have remnants of the postgres full-text search hanging around:

• model code (ckan/model/search_index.py)
• table in the database (package_search)

The presence of these still create sqlalchemy warnings and add to our db, (& db backups etc), so it would be good to get rid of them if we are not using them. John says this can probably be removed

Super ticket: #1151 (viewing geo data)

E.g. preview of ​http://thedatahub.org/dataset/louisvillecrime should bring up a map

Current extensions documentation needs some work: ​http://docs.ckan.org/en/latest/plugins.html

• Queue extension section may now be out of date (?)
• Think about how it integrates with ​https://github.com/okfn/ckanext-example (especially tutorial and example extension)
• Document all plugin points (auto-extract from CKAN source??)

At the moment most of the harvesting functionality is only available to sysadmins. This is fine for most cases but going forward we will need to grant each publisher access to their own sources, harvest objects and harvest object errors. This will probably be done based on the groups refactor.

One more pressing concern is giving DGU publishers the ability to make calls to /harvest/object/id. We want them to be able to see documents that faild validation and also to see *all* errors in each document.

Now that we have a geospatial search API, we should build a front-end that integrates with the existing search for displaying results.

This will comprise of the following steps.

• model migration.
• simplify revisioning
• Remove any sqlalchemy relations from groups.
• change logic functions

estimate 2d

We want to be able to change form depending on package type or group type.

This is dependent on a type field being added to the Package and the Group.

Add the list of extensions install (config's ckan.plugins) to status_show logic action (See #1087)

Right now, the two logic functions that return a list of packages (package_search [1] and group_packages_list [2])use custom functions to generate the output dict. That's suboptimal because:

• The template function that renders the package listing (package_list_from_dict) could end up receiving different dicts.
• Not all package properties are available at the template level (e.g extras, tags...). These can be really useful to customize the listing from an extension.

In general only the functions present in lib/dictization/model_dictize.py should be used to build the output of a logic function, in that case package_dictize. If necessary, they can be modified to include missing properties, like on this particular case the "isopen" property, needed by the template renderer.

[1] ​https://github.com/okfn/ckan/blob/master/ckan/logic/action/get.py#L685 [2] ​https://github.com/okfn/ckan/blob/master/ckan/logic/action/get.py#L442

An API call that returns a user's public activity stream in JSON format.

We really shouldn't have lots of benign stuff printed on stderr when we run every command. It confuses users and hides important stuff.

It would be useful to be able to manipulate packages using the paster command-line interface. In particular listing, reading and deleting packages. Seeing which packages were deleted too.

Group edit dataset add form needs some work

• Dataset name is not cleared when you add
• No way to remove item from list of datasets to be added if I make a mistake
• (2nd Apr 2012) It now seems that option to add multiple datasets at once has disappeared (perhaps during the CSS/HTML refactor ...)

See '### Task 2' in this etherpad: ​http://ckan.okfnpad.org/notifications

I have no idea yet about how to do this or how long it might take me.

We want to add "activity streams" (chronological lists of activities) to CKAN.

Activity streams standard: ​http://activitystrea.ms/

Super branch where the feature was initially developed (this has now been merged into master): ​https://github.com/okfn/ckan/tree/feature-1515-activity-streams

Etherpad: ​http://ckan.okfnpad.org/notifications (most relevant parts inlined here)

Friedrich's mockup: ​http://datahub.pudo.org/pudo

Tasks

Strikethrough means the task is done.

• New domain objects Activity and ActivityStream? [2d] #1298

• Migrate existing data into activity streams model [3.5d] #1510

• Generate activities when objects are saved [4d] #1298

• Get the activity stream for a given user as a JSONifiable list of dictionaries [1d] #1511

• API call for getting a user's public activity stream as JSON [0.5d] #1495

• API call for getting a user's public activity stream as rendered text, HTML, etc. [5d] #1494

• Render a user's activity stream on her user page [3d] #1496 (needs review/page design work)

• Generate activities for other types of objects besides users (e.g. packages, groups, tags, extras, and save them in the database.

• Logic functions for getting activity streams for packages, groups, and users.

• API calls for getting activity streams of packages, groups, and users as JSON.

• Rendering activity streams for packages and groups etc. into their pages. (done but disabled pending page design work)

• API calls for inserting events into activity streams. (Still need to handle activity details in the API, ticketed).

• Conform to activitystrea.ms standard

• Enable users to subscribe to and unsubscribe from activity streams, see an aggregated activity stream on their dashboard page.

• Generate aggregated activity streams for arbitrary sets of multiple activity sources/streams

• Email notifications

• Extension point for extensions to register themselves as renderers for different types of activity

• Deploy to UAT [0.5d]

• Docs and announce [1d]

Various UX and UI improvements to groups.

Etherpad: ​http://ckan.okfnpad.org/feature-1521-groups-ux

Improved groups

From Richard Cyganiak.

This is a set of proposals to make the groups feature more powerful. As a result, currently separate CKAN instances such as ​http://ie.ckan.net/ could be turned into a simple group on the ​Data Hub without losing their separate identity.

• Group homepages: Make the group pages more attractive and welcoming as homepages. The main Data Hub homepage does a great job at this now – can the group pages be made more like that? They're quite uninformative and bland right now.
• Subdomains for groups: Enable subdomains such as ie.thedatahub.org as aliases for thedatahub.org/group/ireland
• Search within the group: Have a big search box that searches just within the group on the group page, with a look like on ​http://thedatahub.org/dataset
• Have an Add a dataset to this group link on the group page, perhaps in the sidebar.
• Navigation within the group: Have some more navigation starting points on the group page, e.g., the Tags + Resource Format sidebar from ​http://thedatahub.org/dataset
• Group documentation: Add the ability to add more “About this group” text, or pages like “FAQ” and “Extra field conventions”.
  • The only place where one can currently put group-specific text is before the dataset list. Putting much text there is bad as it moves the datasets below the fold.
  • Can the top-level sections of a group's description be automatically turned into separate pages that are linked from the sidebar? With headlines About, Frequently Asked Questions and How to get involved, we'd then get three links in the sidebar that point to datahub.org/group/ireland/about, datahub.org/group/ireland/frequently-asked-questions, datahub.org/group/ireland/how-to-get-involved
    • RP: WONTFIX this is being considered for future (generally useful) but cost/benefit here was low particularly as it wasn't clear what optimal implementation was.

Additional

• Display members of a group as well as admins (if less than 10? If more than 10 display count only ...?)
• Better group index page (sort by number of dataset, allow searching ...) - #1403
  • Add search to groups: ​http://thedatahub.org/group
  • Way to filter by activity, number of datasets
• #1597 Tag search, filtered by group
  • RP: not worth it in terms of benefit/cost IMO

Steps

• "Add Dataset" button on action bar
  • Make it a dropdown? -> New Dataset / Existing Dataset
  • Redirect Add Existing -> Edit
  • Check permissions
• Expandable "about this group" box
• Implement simplest search-this-group box
  • turn the list of datasets into a dynamic list of search results
    • pagination
  • Matching set of facets in the sidebar (matches 'real' search page)
    • Deleteable, displayed facets

Nice-To-Have

• Get rid of the old group_package_show action (confirm with team)
• Tabbed "about this group" box (extract headers?)
• Scrollable group members widget in the sidebar

Form refactor.

New create/edit package form wizard for DGU. See attached spec.

Form refactor. New create/edit package form wizard for DGU.

Etherpad: ​http://ckan.okfnpad.org/dgu-package-form

Tasks:

• #1526 : Simple one-page form.
• #1527 : Tab-ify the form using JS. No validation between steps.
• #1541 : Setup server for the DGU form-refactor.
• #1537 : Package create form wizard
• #1538 : Store partially-filled in package form data as a draft.
• #1539 : Package forms auto-save

How the rest of the work is carried out is up for discussion, as it depends on the approach taken. Whether to continue with validation using AJAX queries, or whether to break the form down into multi pages. ​Google doc outlining design(s)

• use javascript to selectively hide/show parts of the form
• there's no validation between steps at this stage. It's still a "big save button at the end".

Currently when you log in it says "logged-in". Most sites show your user-name and this is helpful when you have more than one account or human using the computer.

The use of username is problematic because username's can change.

• Change all revision creation code to use user id (simplest is to change c.author field in lib/base.py (?))
  • (?) Add a field ipaddr for ip address of anonymous users? (or just keep putting this in author field on Revision and then acception that those won't match when we do a look up against user table)
• Change user view page to look up against user id rather than name
• Perform migration on existing Revision objects
  • Match should probably be against both openid and username when searching Revisions' author field (especially true on CKAN where some people have already changed their username from being their openid)

Create the form wizard for the package-new form.

Each section of the form will be a separate page as this was decided to be simpler than the alternative of making AJAX calls for validation at each stage. (*)

• separate pages for each section of the form
• validation carried out at each stage against the whole schema. Each section/page declares a list of schema keys that need to validate for that section to validate, and thus move onto the next section.
• no draft saving to be performed in this ticket.

(*) - although the javascript alternative will probably provide better UX (each step would require a page-load in the wizard approach), it was decided that:

• with the javascript approach it would be harder to test the workflow.
• with the javascript approach there would be additional work displaying validation correctly. Although not that complicated, it was felt to add another point of failure.
• the multi-page wizard is quicker and easier to implement, and if it provided poor UX, then the javascript approach would be used instead.
• the multi-page wizard wouldn't preclude a javascript-tabbing create-form for other cases (where the wizard workflow wasn't such a good match, eg on the hedatahub.org)
• the multi-page wizard wouldn't preclude a javascript-tabbing edit-form.

Using the saved-draft feature, we enable auto-save for the package-new and package-edit forms.

An AJAX call is made every N seconds, and the auto-saved blob is updated.

note - we don't want to overwrite a previously save draft, but we will want to overwrite the last autosave.

CKAN is pulling a number of resources from external locations. This causes problems when connectivity is limited and you have to work locally. Maybe some of them cold be moved to CKAN source to avoid external requests.

Quick search:

./ckan/templates/layout_base.html:            <img src="http://assets.okfn.org/images/logo/okf_logo_white_and_green_tiny.png" id="footer-okf-logo" />
./ckan/templates/layout_base.html:            <a href="http://opendefinition.org/"><img alt="This Content and Data is Open" src="http://assets.okfn.org/images/ok_buttons/od_80x15_blue.png" style="border: none ; margin-bottom: -4px;"/></a>
./ckan/templates/package/resource_read.html:                <img src="http://assets.okfn.org/images/ok_buttons/od_80x15_blue.png" alt="[Open Data]" />
./ckan/templates/package/read.html:          <img src="http://assets.okfn.org/images/ok_buttons/od_80x15_blue.png" alt="[Open Data]" /></a>
./ckan/templates/_util.html:                    <img src="http://assets.okfn.org/images/ok_buttons/od_80x15_blue.png" alt="[Open Data]" />
./ckan/templates/_util.html:                  <img src="http://assets.okfn.org/images/ok_buttons/od_80x15_blue.png" alt="[Open Data]" />
./ckan/public/scripts/vendor/ckanjs/1.0.0/ckanjs.js:      this.$dialog.html('<h2>Loading results...</h2><img src="http://assets.okfn.org/images/icons/ajaxload-circle.gif" />');
./ckan/public/scripts/vendor/ckanjs/1.0.0/ckanjs.js:          self.setMessage('Uploading file ... <img src="http://assets.okfn.org/images/icons/ajaxload-circle.gif" class="spinner" />');
./ckan/public/scripts/vendor/ckanjs/1.0.0/ckanjs.js:      self.setMessage('Checking upload permissions ... <img src="http://assets.okfn.org/images/icons/ajaxload-circle.gif" class="spinner" />');
Binary file ./ckan/lib/app_globals.pyc matches
./ckan/lib/app_globals.py:                                  'http://assets.okfn.org/p/ckan/img/ckan.ico')
./ckan/config/deployment.ini_tmpl:ckan.favicon = http://assets.okfn.org/p/ckan/img/ckan.ico

It's hard to understand what's going on with the functional tests because there is so much going on in inherited classes. Would be better to be explicit in constructors, even if it involves cut & paste.

It should be possible to pass userid/username and api key and obtain a response from CKAN for external services that use CKAN auth. Those services shouldn't be talking to the DB directly.

(instead of using the prompt) - needed for deployment

Summarise final set of requirements for this and finish development and test. Estimated 10 working days.

Estimate 2 days to finish dev and test.

David can you add any info needed here?

Estimated 4 weeks of Adria's time. I guess this will need to be broken down into more tickets. This feature is being requested by a number of potential customers and we have some ideas of requirements between Rufus and Jilly for this. This is the most popular new feature we talk about to new clients.

Basic websotre exists but this may be not what is described yet.

CKAN provides a rich API for the data itself, allowing users to query retrieve and use data instantly from datasets in CKAN without needing to download or process it first.

• (Deploy it)
• Integrate with stats plugin (now that is in core) - #1101
• Blog about it #1581
• (Other tickets re upgrading for v1.5.1 - done but where are tickets?)

Can this be released as a standard CKAN feature?

Is this ready for release? What needs to be done?

Need to write custom harvesters for each client. Is it worth having one for data hub?

Allow uploading of files to push the data into webstore. Initially we were going to suggest changes to ckanext-storage but after further analysis we arrived at the conclusion that this should be implemented by ckanext-archiver as it already handles archiving of data from various sources and would be the best place to 'archive' to webstore.

1. A user wants to upload a file to CKAN, and so chooses the file upload option as they do currently with ckanext-storage. The file upload itself should be handled by this code internal to core (see #1608) but still using ofs [5d]

2. The user is provided the link to the file as currently.

3. The archiver's update task will check configuration to determine if it should upload some mime-types (tabular formats) to webstore. Configuration should also determine where webstore is. (see #1609) [5d] - took 6

• It should be stored in webstore using {username}/{resource-id} where {username} is the name of the user uploading the original file.

4. The archiver will continue to move the file into permanent storage as per current practice.

Tickets

• #1608 Merge storage into Core [5d]
• #1609 Celery task for ckanext-archiver to write to webstore. [5d] (took 6)
• #1687: Deploy to datahub [1d]
• #1681: Core storage documentation [1d?]
  • Internal (perhaps in README somewhere or wiki): how does process work, where does data end up and in what order etc
  • External: here's how to configure it and here's what you get ... (goes in main sphinx docs)

• Move into core (keeping as an extension) and default enable
• Do we need tests for controller? (No: already there)
• Documentation (?) - e.g. of basic config options
• Remove lib/stats.py which is still in core
  • dread moved it to extension in ​https://github.com/okfn/ckanext-stats/commit/293b2544737d8ab7610884bd5e999ee37f1ab813 but did not remove from core
• Deprecation notice on ckanext-stats repo and update extension registry

Est: 0.5d.

Questions:

• Why do this?
  • tiny extension with few dependencies - and really nice to have out of the box
  • trial for doing this on larger scale
• Do we keep as extension (even if in core)?
  • Ans: Yes, keep as extension because:
    • Already set up that way
    • Cleaner
    • Easier to disable / enable
• How do we integrate with main them (e.g. have stats link)
  • Ans: not sure (this is part of more general issue of how we update theme for varying changes elsewhere). Best answer is to have some widgetization in theme.
• Hide ratings section (at least until we reinstate ratings #1598)
  • Ans: no, let's not bother (and having ratings there encourages us to do #1598 and/or find out whether people are interested in ratings)

We should allow full text search within databases for individual databases, although we may want to wait for any pending ports to postgres.

The CKAN Google Analytics extension has been updated to work with the latest version of CKAN, could make for a nice blog post.

Can ping John Glover in January for any details required.

Key link is: ​http://thedatahub.org/analytics/dataset/top though this should probably move to be under stats (e.g. ​http://thedatahub.org/stats/usage)

Tasks:

• On dataset view page, add star rating after each resource view url. Probably similar to current format label after url.
• Add star rating to resource view page, along with a way of displaying the reason for the rating and tips to improve. Should be unobtrusive.
• Fix the table at ​http://thedatahub.org/qa/dataset/broken_resource_links - URLs should be truncated to a fixed not-too-long length and the other fields line up (eg by using a table)~
• Handle 404s by showing that 'we think this resource is 404ing'.
• Handle the absence of QA data on a resource (currently nothing is displayed. Maybe that's fine.
• Do we need to integrate the 'reason for rating' string into the UI?

Next Steps:

• Use db dump of thedatahub.org for final testing.

(details embargoed until 31/1/2012)

Super: #1594

From Richard Cyganiak on the CKAN discuss list:

According to (most of) the definitions of the five-star scheme, the first star already requires an open license, so a dataset shouldn't get any stars at all if it's not under an open license.

Super: #1594

From Richard Cyganiak on the CKAN Discuss list:

Regarding the fifth star (is the dataset linked to others?). This cannot be automatically determined just by looking at the format. It either requires inspection of the actual data, or information about links in the metadata. As you're probably aware, we've established conventions for recording information on data links in CKAN [1], as part of the work of the lodcloud group on the Data Hub. Link information is captured for hundreds of datasets. I would claim that we have the majority of four-star datasets covered there, and hence you can determine if they should get the fifth star by checking for the presence of a links:xxx field.