<?xml version="1.0"?>
<rss xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0">
  <channel>
    <title>CKAN: Ticket Query</title>
    <link>http://localhost/query?status=!closed&amp;repo=ckan&amp;desc=1&amp;order=owner</link>
    <description>The open source data portal software</description>
    <language>en-US</language>
    <image>
      <title>CKAN</title>
      <url>http://assets.okfn.org/p/ckan/img/ckan_logo_shortname.png</url>
      <link>http://localhost/query?status=!closed&amp;repo=ckan&amp;desc=1&amp;order=owner</link>
    </image>
    <generator>Trac 0.12.3</generator>
    <item>
        <link>http://localhost/ticket/253</link>
        <guid isPermaLink="false">http://localhost/ticket/253</guid>
        <title>#253: Package relationships</title>
        <pubDate>Mon, 22 Feb 2010 16:05:21 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;h1 id="Overview"&gt;Overview&lt;/h1&gt;
&lt;p&gt;
Functionality to formally associate packages. We see a need for specific parent-child, inheriting or dependency relations. Not only should this help navigation between packages in the web interface, but it also provides a mechanism to automatically pull dependencies when downloading a data package, in a similar manner as we see in software package management.
&lt;/p&gt;
&lt;h1 id="Examples"&gt;Examples&lt;/h1&gt;
&lt;ol&gt;&lt;li&gt;There are 27 packages in data.gov.uk to do with the Data4NR's Health Poverty Index. There is currently no common link between these, unless you search for 'HPI' (which also brings up House Price Index), or look under tag 'health' (which also has 600 other results). There should be a link on each HPI package page to navigate to the other 'sibling' HPI packages, and to a 'root' package that has info about the set. This could be partially achieved using the existing tag or group concepts, but a more explicit/official/obvious marking of their relationship could be beneficial.
&lt;/li&gt;&lt;/ol&gt;&lt;ol start="2"&gt;&lt;li&gt;In ckan.net is freedict, a collection of translation dictionaries. You could make each dictionary a child package and use this system. But it would probably be better to make each dictionary a different resource in the same package. (There are other ideas to denote a resource as the data making up a 'portion' of package, or a 'whole' of the package, to help people downloading datasets in the software package style.)
&lt;/li&gt;&lt;/ol&gt;&lt;ol start="3"&gt;&lt;li&gt;OSM has had some Naptan data imported (bus stops), with special permission - i.e. a more liberal license. It would be useful to show this link on both OSM and Naptan packages in CKAN: OSM 'derives from' Naptan with a comment about the license change. I'm not sure this is useful to an automatic download or use of these datasets, but may aid exploration on the CKAN website and understanding the provenance of the bus stop data on it.
&lt;/li&gt;&lt;/ol&gt;&lt;ol start="4"&gt;&lt;li&gt;IPCC collection of data linked / mirrored. Not sure if there are useful relationships here?
&lt;/li&gt;&lt;/ol&gt;&lt;ol start="5"&gt;&lt;li&gt;Dracos gets postbox locations from crowd sourcing and OSM. We could say Dracos 'derives from' OSM.
&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;
See more examples discussed here: &lt;a class="ext-link" href="http://trac.ckan.org/ticket/253"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://trac.ckan.org/ticket/253&lt;/a&gt;
&lt;/p&gt;
&lt;h1 id="Implementation"&gt;Implementation&lt;/h1&gt;
&lt;p&gt;
This is split into four tickets:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Model: &lt;a class="closed ticket" href="http://localhost/ticket/254" title="enhancement: Package relationships - 1. model (closed: fixed)"&gt;ticket:254&lt;/a&gt;
&lt;/li&gt;&lt;li&gt;Read in WUI: &lt;a class="closed ticket" href="http://localhost/ticket/255" title="enhancement: Package relationships - 2. Read in WUI (closed: fixed)"&gt;ticket:255&lt;/a&gt;
&lt;/li&gt;&lt;li&gt;Edit in WUI: &lt;a class="assigned ticket" href="http://localhost/ticket/256" title="requirement: Package relationships - 3. Edit in WUI (assigned)"&gt;ticket:256&lt;/a&gt;
&lt;/li&gt;&lt;li&gt;API: &lt;a class="closed ticket" href="http://localhost/ticket/257" title="enhancement: Package relationships - 4. Read in API (closed: fixed)"&gt;ticket:257&lt;/a&gt;
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
No need for write access to be provided API for the moment.
&lt;/p&gt;
&lt;p&gt;
This ticket also encompasses &lt;a class="closed ticket" href="http://localhost/ticket/169" title="enhancement: Package derivations (closed: duplicate)"&gt;ticket:169&lt;/a&gt; (Package derivations) and &lt;a class="closed ticket" href="http://localhost/ticket/176" title="enhancement: Package dependencies (closed: duplicate)"&gt;ticket:176&lt;/a&gt; (Package dependencies).
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/253#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/256</link>
        <guid isPermaLink="false">http://localhost/ticket/256</guid>
        <title>#256: Package relationships - 3. Edit in WUI</title>
        <pubDate>Tue, 23 Feb 2010 12:36:01 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
WUI:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Editable as part of package or separately? (e.g. like authz)
&lt;/li&gt;&lt;li&gt;Do we normalize to only one type name of the pair?
&lt;/li&gt;&lt;li&gt;Do we allow create of relationship from both ends (e.g. only from dependency to dependent or either way?)
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/256#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/285</link>
        <guid isPermaLink="false">http://localhost/ticket/285</guid>
        <title>#285: Paginate list of packages on tag read page</title>
        <pubDate>Wed, 07 Apr 2010 18:23:26 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Is this worth doing? On hmg.ckan.net start to have a lot of packages with a given tag ...
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/285#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/301</link>
        <guid isPermaLink="false">http://localhost/ticket/301</guid>
        <title>#301: Package discussion pages</title>
        <pubDate>Mon, 26 Apr 2010 16:57:13 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
A package discussion page is like a wikipedia discussion page: an editable free text page for people to have discussion/post comments about a given package.
&lt;/p&gt;
&lt;p&gt;
It provides a way for people to make suggestions about a package without needing access to main package.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/301#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/331</link>
        <guid isPermaLink="false">http://localhost/ticket/331</guid>
        <title>#331: Timezone of CKAN timestamps should be configurable</title>
        <pubDate>Mon, 31 May 2010 10:40:40 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Revisions are timestamped using the server's clock, which may not relate to the expected timezone for the site. e.g. the Norway site has a server on GMT. No timezone info is displayed either.
&lt;/p&gt;
&lt;p&gt;
Would like to set timezone for a CKAN instance to use in rendering revision timestamps. For example, use CET or EST timezone.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/331#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/350</link>
        <guid isPermaLink="false">http://localhost/ticket/350</guid>
        <title>#350: Search engine optimisation</title>
        <pubDate>Tue, 15 Jun 2010 09:35:41 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Need to research what can easily be done to improve CKAN packages in the search rankings.
&lt;/p&gt;
&lt;p&gt;
Comments from Glen Barnes:
&lt;/p&gt;
&lt;p&gt;
We've been pretty successful at SEO without even really trying (see &lt;a class="ext-link" href="http://www.google.co.nz/search?client=safari&amp;amp;rls=en&amp;amp;q=auckland+google+transit+feed&amp;amp;ie=UTF-8&amp;amp;oe=UTF-8&amp;amp;redir_esc=&amp;amp;ei=dsYSTOzJLs2eceuZiI8I"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://www.google.co.nz/search?client=safari&amp;amp;rls=en&amp;amp;q=auckland+google+transit+feed&amp;amp;ie=UTF-8&amp;amp;oe=UTF-8&amp;amp;redir_esc=&amp;amp;ei=dsYSTOzJLs2eceuZiI8I&lt;/a&gt; as an example). This to me is key. If we are to make data available it has to be findable which is the main reason for a catalogue. There are probably things we should be doing on CKAN like using slugged urls (&lt;a class="ext-link" href="http://www.ckan.net/package/ascoe"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://www.ckan.net/package/ascoe&lt;/a&gt; -&amp;gt; &lt;a class="ext-link" href="http://www.ckan.net/package/ascoe/atmospheric-chemistry-studies-in-the-oceanic-environment"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://www.ckan.net/package/ascoe/atmospheric-chemistry-studies-in-the-oceanic-environment&lt;/a&gt;), setting the H1 tag correctly ("Atmospheric Chemistry Studies in the Oceanic Environment"  on the example above). Some basic SEO 101 on page optimisations.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/350#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/351</link>
        <guid isPermaLink="false">http://localhost/ticket/351</guid>
        <title>#351: Homepage: list new, updated and 'hot' packages</title>
        <pubDate>Tue, 15 Jun 2010 09:56:56 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Have a simpler list of exciting data, as opposed to the big revision list.
&lt;/p&gt;
&lt;p&gt;
For example:
&lt;/p&gt;
&lt;pre class="wiki"&gt;Hot data
===========
New packages: package1, package2, package3
Updated resources: package1, package2, package3
Popular packages:
&lt;/pre&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/351#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/369</link>
        <guid isPermaLink="false">http://localhost/ticket/369</guid>
        <title>#369: "Package Listing Key" should appear on Tag results</title>
        <pubDate>Thu, 22 Jul 2010 18:00:34 GMT</pubDate>
        
        <dc:creator>shudson@…</dc:creator>

        <description>&lt;p&gt;
Currently there's a nice legend titled "Package Listing Key" that appears in right side of "Browse Packages" results. The same key should show on other search results like when searching for a tag.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/369#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/370</link>
        <guid isPermaLink="false">http://localhost/ticket/370</guid>
        <title>#370: Use better email encryption for author_email and maintainer_email</title>
        <pubDate>Thu, 22 Jul 2010 18:03:39 GMT</pubDate>
        
        <dc:creator>shudson@…</dc:creator>

        <description>&lt;p&gt;
The &lt;a class="missing wiki"&gt;JavaScript?&lt;/a&gt; email encryption used is not very reassuring. Google's &lt;a class="missing wiki"&gt;MailHide?&lt;/a&gt; is a much better solution that is easily implemented.
&lt;/p&gt;
&lt;p&gt;
&lt;a class="ext-link" href="http://www.google.com/recaptcha/mailhide/"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://www.google.com/recaptcha/mailhide/&lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;
Check on the Mailhide API where there are even some Python libraries already built.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/370#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/653</link>
        <guid isPermaLink="false">http://localhost/ticket/653</guid>
        <title>#653: Trackback links for packages</title>
        <pubDate>Tue, 21 Sep 2010 09:40:25 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
When people link to a package, a track-back link is auto-created. (Similar system as for blogs).
&lt;/p&gt;
&lt;p&gt;
As suggested by Tim Davies:
&lt;/p&gt;
&lt;p&gt;
Allowing some form of ‘track back’ against datasets
When a non-technical user comes to look at a dataset it would be really useful for them to be able to see if anyone has created an interface interpretation of it already.
&lt;/p&gt;
&lt;p&gt;
I found quite a few cases in research of end-users struggling to make sense of a dataset when good interfaces to that data had already been built and blogged about, but without there being any link from the dataset listing to those data uses.
Accepting track backs could also make it easier for technical users to find blog posts / shared code etc. relating to a given dataset.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/653#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/737</link>
        <guid isPermaLink="false">http://localhost/ticket/737</guid>
        <title>#737: Markdown syntax summary page</title>
        <pubDate>Fri, 22 Oct 2010 16:59:09 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
I suggest we produce a quick Markdown cheat-sheet page, showing the key runes: e.g. create a title and quote some text. This page can link to the full Markdown docs for advanced users.
&lt;/p&gt;
&lt;p&gt;
A user going to the Markdown docs that we link will have to read a couple of pages of the raison-d'etre of Markdown before he gets to the syntax. And it's not very easy to read, and being white on black it looks like proper geek stuff.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/737#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/763</link>
        <guid isPermaLink="false">http://localhost/ticket/763</guid>
        <title>#763: Read-only mode - Setup</title>
        <pubDate>Tue, 26 Oct 2010 11:11:46 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Admin configures entering read-only mode in one of two places:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;CKAN config file (e.g. ckan.ini)
&lt;/li&gt;&lt;li&gt;environment variable from Apache config
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
Once enabled, no writes can occur to the database (including user ratings and other usage stats).
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/763#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/765</link>
        <guid isPermaLink="false">http://localhost/ticket/765</guid>
        <title>#765: Read-only mode - API usage</title>
        <pubDate>Tue, 26 Oct 2010 11:18:17 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
All writes to the API are captured and you are returned an error explaining the reason.
&lt;/p&gt;
&lt;p&gt;
Possible errors:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;503 temporary maintenance
&lt;/li&gt;&lt;li&gt;403 forbidden (if server if permanently read-only)
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/765#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/811</link>
        <guid isPermaLink="false">http://localhost/ticket/811</guid>
        <title>#811: Extra field editing form layout breaks when there are long field names</title>
        <pubDate>Wed, 17 Nov 2010 11:53:32 GMT</pubDate>
        
        <dc:creator>cygri</dc:creator>

        <description>&lt;p&gt;
The layout of the editing section for extra fields breaks when a field name is slightly too long. Field names jump over to the right. See &lt;a class="ext-link" href="http://ckan.net/package/edit/dbpedia"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://ckan.net/package/edit/dbpedia&lt;/a&gt; for examples.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/811#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/812</link>
        <guid isPermaLink="false">http://localhost/ticket/812</guid>
        <title>#812: Package edit form only allows three extra fields</title>
        <pubDate>Wed, 17 Nov 2010 11:56:50 GMT</pubDate>
        
        <dc:creator>cygri</dc:creator>

        <description>&lt;h1 id="Rationale"&gt;Rationale&lt;/h1&gt;
&lt;p&gt;
The package edit form is restricted to three extra fields. To enter more than three fields, one has to save the package and hit edit again (or hit preview).
&lt;/p&gt;
&lt;h1 id="Implementation"&gt;Implementation&lt;/h1&gt;
&lt;p&gt;
A mechanism similar to the one for resources (where you can add lines as you go) would solve this. So, have a button that adds more extra field rows via JS. (Extra fields don't need up/down buttons that the Resource table has)
&lt;/p&gt;
&lt;p&gt;
Nice to have: a blank field is added when you tab from the last filled-in field in the table.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/812#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/818</link>
        <guid isPermaLink="false">http://localhost/ticket/818</guid>
        <title>#818: Rethinking the author and maintainer fields</title>
        <pubDate>Wed, 17 Nov 2010 14:18:44 GMT</pubDate>
        
        <dc:creator>cygri</dc:creator>

        <description>&lt;p&gt;
The semantics of the Author and Maintainer fields are really unclear at the moment. This leads to very inconsistent usage. Also, perhaps Name and Email are not the only fields that are needed for a contact.
&lt;/p&gt;
&lt;p&gt;
Here is a table that shows the current usage of these fields in CKAN:
&lt;a class="ext-link" href="http://richard.cyganiak.de/2010/ckan/ckan-ppl.html"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://richard.cyganiak.de/2010/ckan/ckan-ppl.html&lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;
We note several problems:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Author and Maintainer are often the same
&lt;/li&gt;&lt;li&gt;Author and Maintainer are often used interchangeably
&lt;/li&gt;&lt;li&gt;People really want to specify URLs for the contacts and stick them into random places because there is no field for it
&lt;/li&gt;&lt;li&gt;Multiple comma-separated names in a single field
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
I'm not sure what to do about this, but a redesign is necessary in my opinion.
&lt;/p&gt;
&lt;p&gt;
Some ideas:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Remove the maintainer field?
&lt;/li&gt;&lt;li&gt;Make really clear that Author doesn't refer to the metadata on CKAN, but to the original data
&lt;/li&gt;&lt;li&gt;Add an “author URL” field?
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/818#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/837</link>
        <guid isPermaLink="false">http://localhost/ticket/837</guid>
        <title>#837: CKAN integration with freebase gridworks / google refine</title>
        <pubDate>Tue, 30 Nov 2010 18:10:09 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Thread: &lt;a class="ext-link" href="http://lists.okfn.org/pipermail/ckan-discuss/2010-November/000718.html"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://lists.okfn.org/pipermail/ckan-discuss/2010-November/000718.html&lt;/a&gt;
&lt;/p&gt;
&lt;h3 id="Scenario1"&gt;Scenario 1&lt;/h3&gt;
&lt;ol&gt;&lt;li&gt;User installs Refine and CKAN extension for refine
&lt;/li&gt;&lt;li&gt;On booting refine and asked to load data they can choose from any data package on CKAN.net (or any other CKAN instance)
&lt;/li&gt;&lt;li&gt;They edit the dataset on Refine
&lt;/li&gt;&lt;li&gt;On save (or perhaps as a separate option) they are prompted as to whether they wish  to sync the dataset back to CKAN (either as a new package or as a new resource on the existing package)
&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;
NB: for the dataset sync back some form of "CKAN" storage would be
required (we already have storage.ckan.net running but a closer
integration would be required)
&lt;/p&gt;
&lt;h3 id="Scenario2"&gt;Scenario 2&lt;/h3&gt;
&lt;ol&gt;&lt;li&gt;User visits a package on CKAN.net (or another CKAN instance)
&lt;/li&gt;&lt;li&gt;There is a button on the page "View and edit this dataset in Google Refine"
&lt;/li&gt;&lt;li&gt;Click button -- ask them if they have Google refine installed
&lt;ul&gt;&lt;li&gt;Yes: instructions for loading dataset into refine
&lt;/li&gt;&lt;li&gt;No: load dataset in hosted version of google refine (we could run this)
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li&gt;User edits dataset and hits save. As in previous scenario they are prompted to sync the dataset.
&lt;/li&gt;&lt;/ol&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/837#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/895</link>
        <guid isPermaLink="false">http://localhost/ticket/895</guid>
        <title>#895: Add version number (or simular) to css/js includes query string</title>
        <pubDate>Thu, 06 Jan 2011 19:49:42 GMT</pubDate>
        
        <dc:creator>memespring</dc:creator>

        <description>&lt;p&gt;
Updates to css after a new deploy don't come through without a hard refresh. Adding the version number to the include urls will solve this e.g.
&lt;/p&gt;
&lt;p&gt;
mycssfile.css?v=12345678
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/895#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/909</link>
        <guid isPermaLink="false">http://localhost/ticket/909</guid>
        <title>#909: DCat importer for CKAN</title>
        <pubDate>Mon, 17 Jan 2011 12:05:58 GMT</pubDate>
        
        <dc:creator>pudo</dc:creator>

        <description>&lt;p&gt;
Write an importer that supports most well known variants of DCat in importing the data as CKAN packages. In particular, the following sources should be supported:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;CKANrdf generated exports
&lt;/li&gt;&lt;li&gt;opengov.se RDF (not really DCat)
&lt;/li&gt;&lt;li&gt;Sunlight Nationdatacatalog as harvested by dcat-tools.
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/909#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/924</link>
        <guid isPermaLink="false">http://localhost/ticket/924</guid>
        <title>#924: Search box has no search button</title>
        <pubDate>Mon, 24 Jan 2011 11:12:13 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
The search box at the top-right of CKAN's page doesn't have a 'go' button. I feel that a larger percentage of users expect a 'go' or 'search' button on the right-hand side of the box to press to start searching. Techies tend to know the keyboard shortcut of pressing 'carriage-return' but it might be better to follow standard practise on this.
&lt;/p&gt;
&lt;p&gt;
Examples with 'search' button: Internet Explorer, Firefox, Google, Amazon, trac
Examples without: ?
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/924#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/948</link>
        <guid isPermaLink="false">http://localhost/ticket/948</guid>
        <title>#948: Highlight (to a sysadmin) which packages are deleted</title>
        <pubDate>Wed, 02 Feb 2011 11:32:49 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
When a customer logs in as a sysadmin then he/she see all packages, including deleted and pending ones. These are hidden to the average user, but the sysadmin has no idea of this until he clicks on the package and sees at the bottom 'state: deleted'.
&lt;/p&gt;
&lt;p&gt;
It should be more obvious than that on the search view - an icon, message or crossed-out name to packages are deleted.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/948#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1120</link>
        <guid isPermaLink="false">http://localhost/ticket/1120</guid>
        <title>#1120: Atom feeds of each tag</title>
        <pubDate>Mon, 02 May 2011 04:08:05 GMT</pubDate>
        
        <dc:creator>tsm</dc:creator>

        <description>&lt;p&gt;
Tags could/should have an Atom feed. This would mean that every edit to relevant packages could be easily monitored. See &lt;a class="missing changeset" title="No default repository defined"&gt;[1]&lt;/a&gt;.
&lt;/p&gt;
&lt;p&gt;
&lt;a class="missing changeset" title="No default repository defined"&gt;[1]&lt;/a&gt; &lt;a class="ext-link" href="http://lists.okfn.org/pipermail/ckan-discuss/2011-May/001162.html"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://lists.okfn.org/pipermail/ckan-discuss/2011-May/001162.html&lt;/a&gt;
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1120#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1130</link>
        <guid isPermaLink="false">http://localhost/ticket/1130</guid>
        <title>#1130: First time users</title>
        <pubDate>Mon, 09 May 2011 10:59:21 GMT</pubDate>
        
        <dc:creator>lucychambers</dc:creator>

        <description>&lt;p&gt;
Send users to FAQ first time on CKAN
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1130#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1144</link>
        <guid isPermaLink="false">http://localhost/ticket/1144</guid>
        <title>#1144: Support DSPL</title>
        <pubDate>Thu, 19 May 2011 00:06:49 GMT</pubDate>
        
        <dc:creator>timmcnamara</dc:creator>

        <description>&lt;p&gt;
DSPL, the Dataset Publishing Language, is being promoted by Google for its "Google Public Data Explorer" system. It is an XML format with metadata.
&lt;/p&gt;
&lt;p&gt;
The format is described on the &lt;a class="ext-link" href="http://code.google.com/apis/publicdata/docs/developer_guide.html"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;developer docs ofthe Google Code site&lt;/a&gt;.
&lt;/p&gt;
&lt;p&gt;
Google provides a &lt;a class="ext-link" href="http://code.google.com/apis/publicdata/docs/dsplgen.html"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;Python script which reads CSV data and generates DSPL&lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;
Sample from &lt;a class="ext-link" href="http://code.google.com/apis/publicdata/docs/dspl_sample.html"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://code.google.com/apis/publicdata/docs/dspl_sample.html&lt;/a&gt;:
&lt;/p&gt;
&lt;div class="code"&gt;&lt;pre&gt;
&lt;span class="cp"&gt;&amp;lt;?xml version="1.0" encoding="UTF-8"?&amp;gt;&lt;/span&gt;
&lt;span class="nt"&gt;&amp;lt;dspl&lt;/span&gt; &lt;span class="na"&gt;xmlns=&lt;/span&gt;&lt;span class="s"&gt;"http://schemas.google.com/dspl/2010"&lt;/span&gt;
    &lt;span class="na"&gt;xmlns:geo=&lt;/span&gt;&lt;span class="s"&gt;"http://www.google.com/publicdata/dataset/google/geo"&lt;/span&gt;
    &lt;span class="na"&gt;xmlns:geo_usa=&lt;/span&gt;&lt;span class="s"&gt;"http://www.google.com/publicdata/dataset/google/geo/us"&lt;/span&gt;
    &lt;span class="na"&gt;xmlns:time=&lt;/span&gt;&lt;span class="s"&gt;"http://www.google.com/publicdata/dataset/google/time"&lt;/span&gt;
    &lt;span class="na"&gt;xmlns:quantity=&lt;/span&gt;&lt;span class="s"&gt;"http://www.google.com/publicdata/dataset/google/quantity"&lt;/span&gt;
    &lt;span class="na"&gt;xmlns:entity=&lt;/span&gt;&lt;span class="s"&gt;"http://www.google.com/publicdata/dataset/google/entity"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;import&lt;/span&gt; &lt;span class="na"&gt;namespace=&lt;/span&gt;&lt;span class="s"&gt;"http://www.google.com/publicdata/dataset/google/time"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;import&lt;/span&gt; &lt;span class="na"&gt;namespace=&lt;/span&gt;&lt;span class="s"&gt;"http://www.google.com/publicdata/dataset/google/quantity"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;import&lt;/span&gt; &lt;span class="na"&gt;namespace=&lt;/span&gt;&lt;span class="s"&gt;"http://www.google.com/publicdata/dataset/google/entity"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;import&lt;/span&gt; &lt;span class="na"&gt;namespace=&lt;/span&gt;&lt;span class="s"&gt;"http://www.google.com/publicdata/dataset/google/geo"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;info&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;My statistics&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;description&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;Some very interesting statistics about countries&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/description&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;url&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;http://www.stats-bureau.com/mystats/info.html&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/url&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;/info&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;provider&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;Bureau of Statistics&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;url&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;http://www.stats-bureau.com&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/url&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;/provider&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;topics&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;topic&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"geography"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;info&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&amp;lt;value&amp;gt;&lt;/span&gt;Geography&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/info&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/topic&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;topic&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"social_indicators"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;info&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&amp;lt;value&amp;gt;&lt;/span&gt;Social indicators&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/info&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;topic&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"population_indicators"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;info&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&amp;lt;value&amp;gt;&lt;/span&gt;Population indicators&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/info&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/topic&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;topic&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"poverty_and_income"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;info&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&amp;lt;value&amp;gt;&lt;/span&gt;Poverty &lt;span class="err"&gt;&amp;amp;&lt;/span&gt; income&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/info&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/topic&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;topic&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"health"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;info&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&amp;lt;value&amp;gt;&lt;/span&gt;Health&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/info&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/topic&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/topic&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;/topics&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;concepts&amp;gt;&lt;/span&gt;
    &lt;span class="c"&gt;&amp;lt;!-- As noted in the tutorial, this concept should extend quantity:amount.--&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;concept&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"population"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;info&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;Population&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;description&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;Size of the resident population.&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/description&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/info&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;topic&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"population_indicators"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;type&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"integer"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/concept&amp;gt;&lt;/span&gt;
    &lt;span class="c"&gt;&amp;lt;!-- This country concept is defined for educational purposes only. A country
    concept exists in the Google geo dataset. See:
    http://code.google.com/apis/publicdata/docs/canonical/geo.html --&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;concept&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"country"&lt;/span&gt; &lt;span class="na"&gt;extends=&lt;/span&gt;&lt;span class="s"&gt;"geo:location"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;info&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;Country&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;description&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;My list of countries&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/description&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/info&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;type&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;property&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"name"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;info&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&amp;lt;value&lt;/span&gt; &lt;span class="na"&gt;xml:lang=&lt;/span&gt;&lt;span class="s"&gt;"en"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;Country name&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;description&amp;gt;&lt;/span&gt;
            &lt;span class="nt"&gt;&amp;lt;value&lt;/span&gt; &lt;span class="na"&gt;xml:lang=&lt;/span&gt;&lt;span class="s"&gt;"en"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;The official name of the country&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;/description&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/info&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;type&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/property&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;table&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"countries_table"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/concept&amp;gt;&lt;/span&gt;
    &lt;span class="c"&gt;&amp;lt;!-- This US state concept is defined for educational purposes only. A US state
      concept exists in the Google geo US dataset. See:
      http://code.google.com/apis/publicdata/docs/canonical/geo.us.html --&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;concept&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"state"&lt;/span&gt; &lt;span class="na"&gt;extends=&lt;/span&gt;&lt;span class="s"&gt;"geo:location"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;info&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;State&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;description&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;US states&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/description&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/info&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;type&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;property&lt;/span&gt; &lt;span class="na"&gt;concept=&lt;/span&gt;&lt;span class="s"&gt;"country"&lt;/span&gt; &lt;span class="na"&gt;isParent=&lt;/span&gt;&lt;span class="s"&gt;"true"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;table&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"states_table"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/concept&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;concept&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"gender"&lt;/span&gt; &lt;span class="na"&gt;extends=&lt;/span&gt;&lt;span class="s"&gt;"entity:entity"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;info&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;Gender&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;description&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;Gender, Male or Female&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/description&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;pluralName&amp;gt;&amp;lt;value&amp;gt;&lt;/span&gt;Genders&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&amp;lt;/pluralName&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;totalName&amp;gt;&amp;lt;value&amp;gt;&lt;/span&gt;Both genders&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&amp;lt;/totalName&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/info&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;type&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;table&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"genders_table"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/concept&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;concept&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"unemployment_rate"&lt;/span&gt; &lt;span class="na"&gt;extends=&lt;/span&gt;&lt;span class="s"&gt;"quantity:rate"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;info&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;name&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;unemployment rate&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/name&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;description&amp;gt;&lt;/span&gt;
          &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;The percent of the labor force that is unemployed, not seasonally
            adjusted.&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;/description&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;url&amp;gt;&amp;lt;value&amp;gt;&lt;/span&gt;http://www.bls.gov/cps/cps_htgm.htm&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&amp;lt;/url&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/info&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;topic&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"social_indicators"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;type&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"float"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;attribute&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"is_percentage"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;type&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"boolean"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;true&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/attribute&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/concept&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;/concepts&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;slices&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;slice&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"countries_slice"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;dimension&lt;/span&gt; &lt;span class="na"&gt;concept=&lt;/span&gt;&lt;span class="s"&gt;"country"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;dimension&lt;/span&gt; &lt;span class="na"&gt;concept=&lt;/span&gt;&lt;span class="s"&gt;"time:year"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;metric&lt;/span&gt; &lt;span class="na"&gt;concept=&lt;/span&gt;&lt;span class="s"&gt;"population"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;table&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"countries_slice_table"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/slice&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;slice&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"states_slice"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;dimension&lt;/span&gt; &lt;span class="na"&gt;concept=&lt;/span&gt;&lt;span class="s"&gt;"state"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;dimension&lt;/span&gt; &lt;span class="na"&gt;concept=&lt;/span&gt;&lt;span class="s"&gt;"time:year"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;metric&lt;/span&gt; &lt;span class="na"&gt;concept=&lt;/span&gt;&lt;span class="s"&gt;"population"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;metric&lt;/span&gt; &lt;span class="na"&gt;concept=&lt;/span&gt;&lt;span class="s"&gt;"unemployment_rate"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;table&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"states_slice_table"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/slice&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;slice&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"countries_gender_slice"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;dimension&lt;/span&gt; &lt;span class="na"&gt;concept=&lt;/span&gt;&lt;span class="s"&gt;"country"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;dimension&lt;/span&gt; &lt;span class="na"&gt;concept=&lt;/span&gt;&lt;span class="s"&gt;"gender"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;dimension&lt;/span&gt; &lt;span class="na"&gt;concept=&lt;/span&gt;&lt;span class="s"&gt;"time:year"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;metric&lt;/span&gt; &lt;span class="na"&gt;concept=&lt;/span&gt;&lt;span class="s"&gt;"population"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;table&lt;/span&gt; &lt;span class="na"&gt;ref=&lt;/span&gt;&lt;span class="s"&gt;"countries_gender_slice_table"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/slice&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;/slices&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;tables&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;table&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"countries_table"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"country"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"name"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"latitude"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"float"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"longitude"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"float"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;data&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;file&lt;/span&gt; &lt;span class="na"&gt;format=&lt;/span&gt;&lt;span class="s"&gt;"csv"&lt;/span&gt; &lt;span class="na"&gt;encoding=&lt;/span&gt;&lt;span class="s"&gt;"utf-8"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;countries.csv&lt;span class="nt"&gt;&amp;lt;/file&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/data&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/table&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;table&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"countries_slice_table"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"country"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"year"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"date"&lt;/span&gt; &lt;span class="na"&gt;format=&lt;/span&gt;&lt;span class="s"&gt;"yyyy"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"population"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"integer"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;data&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;file&lt;/span&gt; &lt;span class="na"&gt;format=&lt;/span&gt;&lt;span class="s"&gt;"csv"&lt;/span&gt; &lt;span class="na"&gt;encoding=&lt;/span&gt;&lt;span class="s"&gt;"utf-8"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;country_slice.csv&lt;span class="nt"&gt;&amp;lt;/file&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/data&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/table&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;table&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"states_table"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"state"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"name"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"country"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;value&amp;gt;&lt;/span&gt;US&lt;span class="nt"&gt;&amp;lt;/value&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/column&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"latitude"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"float"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"longitude"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"float"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;data&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;file&lt;/span&gt; &lt;span class="na"&gt;format=&lt;/span&gt;&lt;span class="s"&gt;"csv"&lt;/span&gt; &lt;span class="na"&gt;encoding=&lt;/span&gt;&lt;span class="s"&gt;"utf-8"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;states.csv&lt;span class="nt"&gt;&amp;lt;/file&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/data&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/table&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;table&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"states_slice_table"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"state"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"year"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"date"&lt;/span&gt; &lt;span class="na"&gt;format=&lt;/span&gt;&lt;span class="s"&gt;"yyyy"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"population"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"integer"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"unemployment_rate"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"float"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;data&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;file&lt;/span&gt; &lt;span class="na"&gt;format=&lt;/span&gt;&lt;span class="s"&gt;"csv"&lt;/span&gt; &lt;span class="na"&gt;encoding=&lt;/span&gt;&lt;span class="s"&gt;"utf-8"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;state_slice.csv&lt;span class="nt"&gt;&amp;lt;/file&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/data&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/table&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;table&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"genders_table"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"gender"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"name"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;data&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;file&lt;/span&gt; &lt;span class="na"&gt;format=&lt;/span&gt;&lt;span class="s"&gt;"csv"&lt;/span&gt; &lt;span class="na"&gt;encoding=&lt;/span&gt;&lt;span class="s"&gt;"utf-8"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;genders.csv&lt;span class="nt"&gt;&amp;lt;/file&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/data&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/table&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;table&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"countries_gender_slice_table"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"country"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"gender"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"string"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"year"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"date"&lt;/span&gt; &lt;span class="na"&gt;format=&lt;/span&gt;&lt;span class="s"&gt;"yyyy"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;column&lt;/span&gt; &lt;span class="na"&gt;id=&lt;/span&gt;&lt;span class="s"&gt;"population"&lt;/span&gt; &lt;span class="na"&gt;type=&lt;/span&gt;&lt;span class="s"&gt;"integer"&lt;/span&gt;&lt;span class="nt"&gt;/&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;data&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;file&lt;/span&gt; &lt;span class="na"&gt;format=&lt;/span&gt;&lt;span class="s"&gt;"csv"&lt;/span&gt; &lt;span class="na"&gt;encoding=&lt;/span&gt;&lt;span class="s"&gt;"utf-8"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;gender_country_slice.csv&lt;span class="nt"&gt;&amp;lt;/file&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/data&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/table&amp;gt;&lt;/span&gt;
  &lt;span class="nt"&gt;&amp;lt;/tables&amp;gt;&lt;/span&gt;
&lt;span class="nt"&gt;&amp;lt;/dspl&amp;gt;&lt;/span&gt;
&lt;/pre&gt;&lt;/div&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1144#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1145</link>
        <guid isPermaLink="false">http://localhost/ticket/1145</guid>
        <title>#1145: Support the Handle System</title>
        <pubDate>Thu, 19 May 2011 00:26:15 GMT</pubDate>
        
        <dc:creator>timmcnamara</dc:creator>

        <description>&lt;p&gt;
The Handle System is an initiative to provide persistent references for resources. That is, it's basically a proxy system for preventing link rot.
&lt;/p&gt;
&lt;p&gt;
Its documentation is here: &lt;a class="ext-link" href="http://www.handle.net/"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://www.handle.net/&lt;/a&gt;. Servers running CKAN could host a "Local Handle Service", which redirects a hash of a resource to an actual URL.
&lt;/p&gt;
&lt;p&gt;
Some suggested use cases:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Researcher would like to cite where data came from
&lt;/li&gt;&lt;li&gt;Agencies would like to have a way to prevent vendor
lock-in from CKAN if they decide to move to another
platform
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1145#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1165</link>
        <guid isPermaLink="false">http://localhost/ticket/1165</guid>
        <title>#1165: Add multi-site support to ckan</title>
        <pubDate>Thu, 26 May 2011 12:41:07 GMT</pubDate>
        
        <dc:creator>nils.toedtmann</dc:creator>

        <description>&lt;p&gt;
Currently, each ckan site needs its own ckan wsgi process. That eats a lot of resources where many ckan sites are served from one machine (e.g. eu3).
&lt;/p&gt;
&lt;p&gt;
That would dramatically change if a ckan process could behave like multiple ckans (e.g. like Apache's "&amp;lt;&lt;a class="missing wiki"&gt;VirtualHost?&lt;/a&gt;&amp;gt;", or tracd). Depending on the "Host:" header in the HTTP1.1 request, it would choose which local ckan ini file to obey.
&lt;/p&gt;
&lt;p&gt;
I see two ways to constitute the map hostname-to-ini-file map:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;ckan reads a set of ini files, and each ini file declares which servers names it is responsible for
&lt;/li&gt;&lt;li&gt;In a global ini file, there are directives mapping servernames to ini files.
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
In either case there should be a global ckan ini having the default settings for all local ckan sites. Each site ini could be very short then, just having e.g. title, name, database credentials, active plugins etc.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1165#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1179</link>
        <guid isPermaLink="false">http://localhost/ticket/1179</guid>
        <title>#1179: Support tag aliases</title>
        <pubDate>Tue, 07 Jun 2011 06:47:01 GMT</pubDate>
        
        <dc:creator>timmcnamara</dc:creator>

        <description>&lt;p&gt;
A small number of tags are near-duplicates of each other.
&lt;/p&gt;
&lt;p&gt;
Perhaps we could support word stemming from NLTK and/or manual tag aliases:
&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;
statistics
statistik
...
survey
surveying
surveys
&lt;/p&gt;
&lt;/blockquote&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1179#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1182</link>
        <guid isPermaLink="false">http://localhost/ticket/1182</guid>
        <title>#1182: Comments from deleted packages appear in "Recent Comments" feed</title>
        <pubDate>Thu, 09 Jun 2011 22:24:11 GMT</pubDate>
        
        <dc:creator>timmcnamara</dc:creator>

        <description>&lt;p&gt;
When a package has been deleted, say for spam moderation, comments still appear in the recent comments section.
&lt;/p&gt;
&lt;p&gt;
This is a problem because non-admin users will be shown a warning that they're not authorised to view the package if they click on the link.
&lt;/p&gt;
&lt;p&gt;
At CKAN.net currently, this affects the most recent comment.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1182#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1184</link>
        <guid isPermaLink="false">http://localhost/ticket/1184</guid>
        <title>#1184: Support Wuala as CKAN storage option</title>
        <pubDate>Tue, 14 Jun 2011 06:59:11 GMT</pubDate>
        
        <dc:creator>timmcnamara</dc:creator>

        <description>&lt;p&gt;
Most of CKANs storage options are tied to the USA. This brings concerns of data security for some organisations who may wish to adopt the system. &lt;a class="ext-link" href="http://wua.la"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;Wuala&lt;/a&gt; is a distributed file system that stores data in a peer-to-peer manner. The company behind it, &lt;a class="missing wiki"&gt;LaCie?&lt;/a&gt; sells storage for a fee. However, they also enable clients to have 'free' storage space when machines act as a storage node.
&lt;/p&gt;
&lt;p&gt;
In order to be a storage node, a machine needs to be online for more than 14% of the time - roughly 4h per day. Most CKAN servers are likely to have a far greater uptime than this.
&lt;/p&gt;
&lt;p&gt;
Supporting Wuala would go some way to enabling CKAN to be used in a secure manner. That is, CKAN could be promoted for organisational use where there is lots of data to be stored and large geographic distances to be managed. There is a &lt;a class="ext-link" href="http://www.wuala.com/Wuala%20API/Sample%20Clients/Python/wualaAPI/"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;Python client available&lt;/a&gt; and a fairly &lt;a class="ext-link" href="http://www.youtube.com/watch?v=3xKZ4KGkQY8"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;long Google Tech Talk&lt;/a&gt; that overviews the system.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1184#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1185</link>
        <guid isPermaLink="false">http://localhost/ticket/1185</guid>
        <title>#1185: Administrators can't delete packages from web UI</title>
        <pubDate>Wed, 15 Jun 2011 04:23:38 GMT</pubDate>
        
        <dc:creator>timmcnamara</dc:creator>

        <description>&lt;p&gt;
Administrators have "View", "Edit" and "History" tabs. However, I can't see a way to delete a package from the web UI.
&lt;/p&gt;
&lt;p&gt;
Version: CKAN.net as of today
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1185#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1188</link>
        <guid isPermaLink="false">http://localhost/ticket/1188</guid>
        <title>#1188: Allow diffing against initial (blank) package version</title>
        <pubDate>Wed, 15 Jun 2011 15:52:40 GMT</pubDate>
        
        <dc:creator>nickstenning</dc:creator>

        <description>&lt;p&gt;
Currently the history page only allows diffing between different versions of a package, but there doesn't appear to be any easy way to see the changes introduced by the first version of a package.
&lt;/p&gt;
&lt;p&gt;
I'm requesting the ability to diff against a "blank slate" initial state of a project, so I can see the content of the first project commit.
&lt;/p&gt;
&lt;p&gt;
Not sure if this is a vdm feature, so I'm putting this ticket in against ckan.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1188#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1198</link>
        <guid isPermaLink="false">http://localhost/ticket/1198</guid>
        <title>#1198: Publisher hierarchy</title>
        <pubDate>Thu, 23 Jun 2011 09:16:32 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
'Publisher' entities in the model. They are hierarchical.
&lt;/p&gt;
&lt;p&gt;
'User-Publisher' connections with one or more roles (e.g. drafter, moderator).
&lt;/p&gt;
&lt;p&gt;
Authorization settings can control who can set what values in a 'published by' type field.
&lt;/p&gt;
&lt;p&gt;
Publishers and User-Publishers available to read in the API.
&lt;/p&gt;
&lt;p&gt;
Future tickets will provide:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;API to write Publishers and User-Publishers
&lt;/li&gt;&lt;li&gt;UI to edit Publishers and User-Publishers
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
(This feature deprecates authorization groups)
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1198#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1201</link>
        <guid isPermaLink="false">http://localhost/ticket/1201</guid>
        <title>#1201: seperate out logic in atom feeds to logic layer.</title>
        <pubDate>Fri, 24 Jun 2011 15:21:32 GMT</pubDate>
        
        <dc:creator>kindly</dc:creator>

        <description>&lt;p&gt;
Simplify the logic in the atom feed an make all feeds use logic layer to return lists.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1201#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1227</link>
        <guid isPermaLink="false">http://localhost/ticket/1227</guid>
        <title>#1227: Display packages' tags in search results</title>
        <pubDate>Tue, 19 Jul 2011 00:11:02 GMT</pubDate>
        
        <dc:creator>timmcnamara</dc:creator>

        <description>&lt;p&gt;
In when displaying search results, it would be useful to also display the tags of a package. Sometimes it's difficult to infer the scope of what the package does from the title and the first sentence of the description. Tags are quite concise way to display rich information.
&lt;/p&gt;
&lt;p&gt;
ENV=datacatalos.org, with CKAN 1.4.2a
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1227#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1232</link>
        <guid isPermaLink="false">http://localhost/ticket/1232</guid>
        <title>#1232: [super] Interface improvements</title>
        <pubDate>Wed, 20 Jul 2011 16:11:36 GMT</pubDate>
        
        <dc:creator>thejimmyg</dc:creator>

        <description>&lt;p&gt;
Child tickets:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/1194" title="defect: &amp;#34;Welcome back&amp;#34; message for newly registered user (closed: fixed)"&gt;#1194&lt;/a&gt; "Welcome back" message for newly registered user
&lt;/li&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/1202" title="enhancement: Links to datapkg utility don't lead to info about it (closed: invalid)"&gt;#1202&lt;/a&gt; Links to datapkg utility don't lead to info about it
&lt;/li&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/925" title="defect: Change the search box icon to remove the down arrow (closed: fixed)"&gt;#925&lt;/a&gt; Change the search box icon to remove the down arrow
&lt;/li&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/923" title="defect: Search box doesn't work in leaderboard page (closed: worksforme)"&gt;#923&lt;/a&gt; Search box doesn't work in leaderboard page in stats extension
&lt;/li&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/1034" title="defect: Flash message cached (closed: duplicate)"&gt;#1034&lt;/a&gt; Flash message cached
&lt;/li&gt;&lt;li&gt;&lt;a class="new ticket" href="http://localhost/ticket/737" title="enhancement: Markdown syntax summary page (new)"&gt;#737&lt;/a&gt; Markdown syntax summary page
&lt;/li&gt;&lt;li&gt;&lt;a class="new ticket" href="http://localhost/ticket/811" title="defect: Extra field editing form layout breaks when there are long field names (new)"&gt;#811&lt;/a&gt; Extra field editing form layout breaks when there are long field names
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1232#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1233</link>
        <guid isPermaLink="false">http://localhost/ticket/1233</guid>
        <title>#1233: [super] Improve wiki-style functionality for history</title>
        <pubDate>Wed, 20 Jul 2011 16:29:52 GMT</pubDate>
        
        <dc:creator>thejimmyg</dc:creator>

        <description>&lt;p&gt;
At the moment we have a good revisioning system but a poor history interface. We need to improve this in a number of areas:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/191" title="enhancement: Searching by modification date (closed: fixed)"&gt;#191&lt;/a&gt; Searching by modification date
&lt;/li&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/193" title="enhancement: Searching by time-related field (closed: wontfix)"&gt;#193&lt;/a&gt; Searching by time-related field
&lt;/li&gt;&lt;li&gt;&lt;a class="assigned ticket" href="http://localhost/ticket/301" title="enhancement: Package discussion pages (assigned)"&gt;#301&lt;/a&gt; Package discussion pages
&lt;/li&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/1236" title="enhancement: View a package at a given revision (closed: fixed)"&gt;#1236&lt;/a&gt; Package history page should provide links to pages at particular revisions, similar to the wikipedia pages
&lt;/li&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/1236" title="enhancement: View a package at a given revision (closed: fixed)"&gt;#1236&lt;/a&gt; Viewing old revisions or unmoderated changes should have a message at the top of the package page
&lt;/li&gt;&lt;li&gt;Other improvements as per my word doc.
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1233#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1235</link>
        <guid isPermaLink="false">http://localhost/ticket/1235</guid>
        <title>#1235: [super] Search Improvements</title>
        <pubDate>Wed, 20 Jul 2011 17:24:01 GMT</pubDate>
        
        <dc:creator>thejimmyg</dc:creator>

        <description>&lt;p&gt;
Child tickets:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/234" title="enhancement: UI Review - Autocomplete package names &amp;amp; tags in search (closed: wontfix)"&gt;#234&lt;/a&gt; UI Review - Autocomplete package names &amp;amp; tags in search
&lt;/li&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/193" title="enhancement: Searching by time-related field (closed: wontfix)"&gt;#193&lt;/a&gt;        Searching by time-related field
&lt;/li&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/191" title="enhancement: Searching by modification date (closed: fixed)"&gt;#191&lt;/a&gt;        Searching by modification date
&lt;/li&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/905" title="defect: Unable to search with accented characters in package names (closed: worksforme)"&gt;#905&lt;/a&gt; Unable to search with accented characters in package names
&lt;/li&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/906" title="enhancement: Ability to search without accents for accented words (closed: fixed)"&gt;#906&lt;/a&gt; Ability to search without accents for accented words
&lt;/li&gt;&lt;li&gt;&lt;a class="new ticket" href="http://localhost/ticket/924" title="enhancement: Search box has no search button (new)"&gt;#924&lt;/a&gt; Search box has no search button
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
Broadly speaking though we need to choose PostgreSQL, Solr or something else. We don't want to invest our time maintaining two search backends with a limited abstraction layer between the two.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1235#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1244</link>
        <guid isPermaLink="false">http://localhost/ticket/1244</guid>
        <title>#1244: Notes field carriage-returns converted to CRLF</title>
        <pubDate>Tue, 26 Jul 2011 14:10:56 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
When you edit a package in the web form, if the notes field had &lt;tt&gt;\n&lt;/tt&gt; as the End Of Line symbol, it gets lost when you preview or save the package, and the notes field is displayed all on one line.
&lt;/p&gt;
&lt;p&gt;
This can be seen when editing annakarenina (as created by 'paster create-test-data'). The diff shows for example:
&lt;/p&gt;
&lt;pre class="wiki"&gt;- Some test notes
+ Some test notes
?                +
&lt;/pre&gt;&lt;p&gt;
but it would more clearly be shown as:
&lt;/p&gt;
&lt;pre class="wiki"&gt;- Some test notes\n
+ Some test notes
?                ++
&lt;/pre&gt;&lt;p&gt;
This is a significant problem with DGU, since a lot comes in via the API.
&lt;/p&gt;
&lt;p&gt;
It's not clear what we should do about it. We could standardise on \n or \r\n when the form submission comes in. Do different browsers on different platforms do different things with EOLs?
&lt;/p&gt;
&lt;h2 id="Analysis"&gt;Analysis&lt;/h2&gt;
&lt;p&gt;
Displaying the package: the Markdown processor respects both EOLs when displaying the field, putting each line in a &amp;lt;p&amp;gt; tag.
&lt;/p&gt;
&lt;p&gt;
Creating the package edit form: placed into &amp;lt;textfield&amp;gt;.
&lt;/p&gt;
&lt;p&gt;
Browser displaying package edit form: &amp;lt;textfield&amp;gt; displays \n and \r\n as EOL. But \n\n gets compressed to one EOL. But on submission, both are returned as \r\n.
&lt;/p&gt;
&lt;p&gt;
Receiving the edited package: Somewhere along the line the EOL gets converted to \n\n.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1244#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1257</link>
        <guid isPermaLink="false">http://localhost/ticket/1257</guid>
        <title>#1257: Anti-Spam tools</title>
        <pubDate>Tue, 02 Aug 2011 11:12:45 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
We are getting more and more spam on ckan.net and we need to improve our strategy of combating it. It is bad because google ranks who we link to (which we do want for legitimate links), and our front page contains the latest package edits, so spam is immediately very visible.
&lt;/p&gt;
&lt;p&gt;
Spam:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Package creation
&lt;/li&gt;&lt;li&gt;Package edit
&lt;/li&gt;&lt;li&gt;User creation
&lt;/li&gt;&lt;li&gt;Group creation
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
Systems to consider:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Automatic
&lt;ul&gt;&lt;li&gt;captcha
&lt;/li&gt;&lt;li&gt;bayesian scoring
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li&gt;Sysadmin
&lt;ul&gt;&lt;li&gt;a tool to quickly analyse and remove packages, edits and users
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li&gt;Helpful users
&lt;ul&gt;&lt;li&gt;button to click indicating spam, leading to any/all of:
&lt;ul&gt;&lt;li&gt;add TODO item (which emails package admin and sysadmins)
&lt;/li&gt;&lt;li&gt;quarantine the package/user so it doesn't show up on the front page and a warning is shown when you view it
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
General thoughts:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;We should learn from the wikipedia tools, as they are the experts
&lt;/li&gt;&lt;li&gt;This is a serious problem that is only going to get worse and is a threat to the whole site.
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1257#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1260</link>
        <guid isPermaLink="false">http://localhost/ticket/1260</guid>
        <title>#1260: Remove duplicate functions from _util.html</title>
        <pubDate>Wed, 03 Aug 2011 10:17:32 GMT</pubDate>
        
        <dc:creator>pudo</dc:creator>

        <description>&lt;p&gt;
There seems to be both a list view for dictized and non dictized data structures for all entities in _util.html at the moment. Probably in the back of someone's mind already, but cleanup here would be nice.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1260#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1262</link>
        <guid isPermaLink="false">http://localhost/ticket/1262</guid>
        <title>#1262: Enforce "create-user" permission</title>
        <pubDate>Wed, 03 Aug 2011 12:41:36 GMT</pubDate>
        
        <dc:creator>pudo</dc:creator>

        <description>&lt;p&gt;
This does not seem to have any implications at the moment, it should lock down registration and remove all related links.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1262#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1273</link>
        <guid isPermaLink="false">http://localhost/ticket/1273</guid>
        <title>#1273: Create docs for API v3</title>
        <pubDate>Mon, 15 Aug 2011 12:41:23 GMT</pubDate>
        
        <dc:creator>amercader</dc:creator>

        <description></description>
        <category>Results</category>
        <comments>http://localhost/ticket/1273#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1278</link>
        <guid isPermaLink="false">http://localhost/ticket/1278</guid>
        <title>#1278: Refactor authorized_query calls</title>
        <pubDate>Mon, 15 Aug 2011 13:32:57 GMT</pubDate>
        
        <dc:creator>amercader</dc:creator>

        <description>&lt;p&gt;
There are some functions that still use the Auhtorizer().authorized_query method:
&lt;/p&gt;
&lt;pre class="wiki"&gt;./ckan/controllers/authorization_group.py:24:        query = ckan.authz.Authorizer().authorized_query(c.user, model.AuthorizationGroup)
./ckan/lib/base.py:237:        groups = ckan.authz.Authorizer.authorized_query(c.user, model.Group,
./ckan/lib/search/sql.py:55:        q = authz.Authorizer().authorized_query(username, model.Group)
./ckan/lib/search/sql.py:118:        q = authz.Authorizer().authorized_query(self.options.get('username'), model.Package)
./ckan/logic/action/get.py:154:    query = Authorizer().authorized_query(user, model.Group, model.Action.EDIT)
./ckan/tests/test_authz.py:158:        q = self.authorizer.authorized_query(self.notadmin.name, model.Package)
./ckan/tests/test_authz.py:353:        q = self.authorizer.authorized_query(self.notmember.name, model.Package)
./ckan/tests/test_authz.py:357:        q = self.authorizer.authorized_query(self.member.name, model.Package)
./ckan/tests/functional/test_authorization_group.py:44:        group_count = Authorizer.authorized_query(u'russianfan', model.AuthorizationGroup).count()
&lt;/pre&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1278#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1285</link>
        <guid isPermaLink="false">http://localhost/ticket/1285</guid>
        <title>#1285: Errors cause emails</title>
        <pubDate>Tue, 23 Aug 2011 16:29:04 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Currently a sysadmin gets an email when an exception is not caught. But there are occasions when we DO want to catch an exception so we can fail nicely for the user, but the sysadmin STILL gets an email to know to fix something.
e.g. if there is an exception when search indexes a package. You want to catch the exception and still run any other notify calls.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1285#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1286</link>
        <guid isPermaLink="false">http://localhost/ticket/1286</guid>
        <title>#1286: Remove remaining formalchemy stuff</title>
        <pubDate>Tue, 23 Aug 2011 16:29:56 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Stuff I've spotted:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;forms/*
&lt;/li&gt;&lt;li&gt;template/group/edit_form.html
&lt;/li&gt;&lt;li&gt;template/package/edit_form.html
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
This can go once new DGU form is in.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1286#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1288</link>
        <guid isPermaLink="false">http://localhost/ticket/1288</guid>
        <title>#1288: Package edit/creation can't include 'relationships' field</title>
        <pubDate>Wed, 24 Aug 2011 16:34:55 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
When you create or edit a package (via the API), you aren't able to specify the relationships it has. (If you do you get 409 &lt;tt&gt; {"__junk": ["The input field __junk was not expected."]} &lt;/tt&gt;)
&lt;/p&gt;
&lt;p&gt;
The normal way to create relationships is via /api/rest/relationships/ and this works. But when you GET a package, the dictionary lists all relationship details. So this bug creates a problem for editing a package that has relationships - you want to GET it, make any edits and then PUT it back. The work-around is to delete the 'relationships' key from the dict before you PUT it back.
&lt;/p&gt;
&lt;h2 id="Options"&gt;Options&lt;/h2&gt;
&lt;p&gt;
Ideally, CKAN would read the 'relationships' key and make the necessary changes. This is a chunk of work.
&lt;/p&gt;
&lt;p&gt;
Another good option is to allow an unchanged 'relationships' value, but barf it is edited. This is also a chunk of work.
&lt;/p&gt;
&lt;p&gt;
A bad option would be to just ignore the 'relationships' value, since users will get frustrated changing this value and wonder why it never saves, not understanding it is different to all the rest, without error message.
&lt;/p&gt;
&lt;p&gt;
A final option is to get rid of relationships altogether.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1288#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1317</link>
        <guid isPermaLink="false">http://localhost/ticket/1317</guid>
        <title>#1317: password reset - improve user search</title>
        <pubDate>Wed, 07 Sep 2011 17:12:19 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
In password reset, it gets confused if you have two similar users. This is because with the string the user provides, it searches several fields, not just name but also fullname and email address, allowing you to search for these. But only name is unique.
&lt;/p&gt;
&lt;p&gt;
Specific problem:
Ira searches for "Irina" then it finds both:
&lt;tt&gt;&amp;lt;User name=irina fullname=Irina email=irina.bolychevsky@okfn.org ]&lt;/tt&gt;
and
&lt;tt&gt;&amp;lt;User name=shevski fullname=Ira email=&amp;gt;&lt;/tt&gt;
(I think)
&lt;/p&gt;
&lt;p&gt;
Maybe need to choose which field it searches?
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1317#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1322</link>
        <guid isPermaLink="false">http://localhost/ticket/1322</guid>
        <title>#1322: Action API improvements</title>
        <pubDate>Thu, 08 Sep 2011 09:39:09 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Focusing on improving Action API as the v3 API:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;have an optional parameter of the data_dict called "options".  Options would contain items that would get passed into the context. e.g. &lt;tt&gt;{"options" : {"ref_package_by": "id"}}. &lt;/tt&gt;
&lt;/li&gt;&lt;li&gt;instead of using API version to change the way packages are referenced, use the ref_package_by.
&lt;/li&gt;&lt;li&gt;All package_show, group_show etc. to accept an object 'name' as an alternative to object 'id'.
&lt;/li&gt;&lt;li&gt;Action API is v3 of api, replacement for v1 &amp;amp; v2. Default for most urls is still v1, but if url is /api/action then default to v3.
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
Next steps:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Add search API (package, resource,
&lt;/li&gt;&lt;li&gt;Add Util API
&lt;/li&gt;&lt;li&gt;Clarify JSONP still applies
&lt;/li&gt;&lt;li&gt;Add doc strings, clarifying parameters
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1322#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1326</link>
        <guid isPermaLink="false">http://localhost/ticket/1326</guid>
        <title>#1326: Write a set of auth plugin functions to integrate with Druapl</title>
        <pubDate>Mon, 12 Sep 2011 09:51:24 GMT</pubDate>
        
        <dc:creator>thejimmyg</dc:creator>

        <description>&lt;p&gt;
Ticket &lt;a class="closed ticket" href="http://localhost/ticket/787" title="task: Auth API (closed: fixed)"&gt;#787&lt;/a&gt; described join auth between CKAN and Drupal. The authentication part is live and implemented. This ticket is a placeholder for work that will be needed in the new auth system to link authorization functions to Drupal. It is dependent on the groups refactor.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1326#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1328</link>
        <guid isPermaLink="false">http://localhost/ticket/1328</guid>
        <title>#1328: Unicode &amp; paster commands</title>
        <pubDate>Mon, 12 Sep 2011 10:25:10 GMT</pubDate>
        
        <dc:creator>minspamboks@…</dc:creator>

        <description>&lt;p&gt;
A possible bug in CKAN when I tried deleting users using "paster --plugin=ckan user delete" command.
&lt;/p&gt;
&lt;p&gt;
To reproduce the bug do the following:
&lt;/p&gt;
&lt;ol&gt;&lt;li&gt;Create a user with an ID (which in my case was a user's full name)
&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;
that contains non-unicode caracters like Norwegian "æ", "ø", or "å".
&lt;/p&gt;
&lt;ol start="2"&gt;&lt;li&gt;Make sure that you can see something like the example below:
&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;
(pyenv) rm@mycomputer:$ paster --plugin=ckan user
Users:
name=Rustæm
&lt;/p&gt;
&lt;ol start="3"&gt;&lt;li&gt;Then try deleting the user with following command:
&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;
(pyenv) rm@mycomputer:$ paster --plugin=ckan user delete "Rustæm"
&lt;/p&gt;
&lt;p&gt;
You should now get a python encoding error. I know that this is quite
rare case, but in our case it caused some trouble. Could you guys have
a look at this bug?
&lt;/p&gt;
&lt;p&gt;
CKAN ver. 1.3.3.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1328#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1352</link>
        <guid isPermaLink="false">http://localhost/ticket/1352</guid>
        <title>#1352: Use logic functions instead of as_dict when indexing entities</title>
        <pubDate>Wed, 21 Sep 2011 14:29:57 GMT</pubDate>
        
        <dc:creator>amercader</dc:creator>

        <description>&lt;p&gt;
The current search implementation uses the output of the the as_dict method of the domain Package object to update the index
&lt;/p&gt;
&lt;p&gt;
&lt;a class="ext-link" href="https://bitbucket.org/okfn/ckan/src/56c79e3fc44c/ckan/lib/search/index.py#cl-48"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;https://bitbucket.org/okfn/ckan/src/56c79e3fc44c/ckan/lib/search/index.py#cl-48&lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;
It also uses package_to_api1 in the &lt;a class="missing wiki"&gt;SynchronousSearch?&lt;/a&gt; plugin:
&lt;/p&gt;
&lt;p&gt;
&lt;a class="ext-link" href="https://bitbucket.org/okfn/ckan/src/f9dfb0506594/ckan/lib/search/__init__.py#cl-93"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;https://bitbucket.org/okfn/ckan/src/f9dfb0506594/ckan/lib/search/__init__.py#cl-93&lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;
This prevents extensions from being able to index custom properties (e.g. faceting by custom extras not included in the model).
&lt;/p&gt;
&lt;p&gt;
The search should use the logic function to get the package properties:
&lt;/p&gt;
&lt;pre class="wiki"&gt;get_action('package_show')(context,data_dict)
&lt;/pre&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1352#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1355</link>
        <guid isPermaLink="false">http://localhost/ticket/1355</guid>
        <title>#1355: Package extras property does not include the newly created ones</title>
        <pubDate>Mon, 26 Sep 2011 10:48:46 GMT</pubDate>
        
        <dc:creator>amercader</dc:creator>

        <description>&lt;p&gt;
The extras in the package object sent to the extensions after editing (&lt;a class="ext-link" href="https://bitbucket.org/okfn/ckan/src/01efd5649c10/ckan/logic/action/update.py#cl-226"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;https://bitbucket.org/okfn/ckan/src/01efd5649c10/ckan/logic/action/update.py#cl-226&lt;/a&gt;) do not include the newly added.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1355#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1366</link>
        <guid isPermaLink="false">http://localhost/ticket/1366</guid>
        <title>#1366: Search inside extra fields</title>
        <pubDate>Thu, 29 Sep 2011 10:09:52 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
SOLR search doesn't support searching for part of an extra field, but it does for other fields.
&lt;/p&gt;
&lt;p&gt;
i.e. title="One Two Three" matches q=one AND q=title:one
and geographic_coverage="England Scotland" matches q=England BUT NOT q=geographic_coverage:England
&lt;/p&gt;
&lt;p&gt;
This problem emerged when we went to SOLR in &lt;a class="closed ticket" href="http://localhost/ticket/1275" title="enhancement: Move solr search extension to ckan core (closed: fixed)"&gt;#1275&lt;/a&gt; (CKAN 1.5a). Tests were skipped.
&lt;/p&gt;
&lt;p&gt;
This is could be a problem for DGU and maybe elsewhere.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1366#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1406</link>
        <guid isPermaLink="false">http://localhost/ticket/1406</guid>
        <title>#1406: Re-enable RSS subscriptions</title>
        <pubDate>Mon, 17 Oct 2011 14:22:07 GMT</pubDate>
        
        <dc:creator>zephod</dc:creator>

        <description>&lt;p&gt;
RSS 'subscribe' buttons appeared in many places on the site but were not very helpful. They took (confused) users pointed to the raw feed code, and Google Reader could not understand the feed. Safari, however, could interpret it correctly.
&lt;/p&gt;
&lt;p&gt;
Their presentation needs to be clear and consistent; the RSS feed really needs testing in a variety of readers; and we need to decide exactly which items should get a feed. (Package updates? Groups?)
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1406#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1414</link>
        <guid isPermaLink="false">http://localhost/ticket/1414</guid>
        <title>#1414: track user log-ins on thedatahub.org</title>
        <pubDate>Mon, 24 Oct 2011 11:13:02 GMT</pubDate>
        
        <dc:creator>shevski</dc:creator>

        <description>&lt;p&gt;
Set up tracking for user logins so that we have stats about how many active users of thedatahub exist
want to be able to see who logged in the the last x months
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1414#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1423</link>
        <guid isPermaLink="false">http://localhost/ticket/1423</guid>
        <title>#1423: Edit resources suggestions</title>
        <pubDate>Wed, 26 Oct 2011 15:11:46 GMT</pubDate>
        
        <dc:creator>markbrough</dc:creator>

        <description>&lt;ul&gt;&lt;li&gt;Description vs Name - Edit Resources view is showing the name of the package rather than the description, and a lot (all?) of the packages before the upgrade don't have names, so might be good to swap this round again, e.g.: &lt;a class="ext-link" href="http://thedatahub.org/dataset/edit/iati-registry"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://thedatahub.org/dataset/edit/iati-registry&lt;/a&gt;
&lt;/li&gt;&lt;li&gt;Moving resources - Moving them up or down the list used to be quite useful if you had a lot of resources that you might want to leave on the resources page, but only one or two that were actually current and that you wanted to draw attention to. This doesn't exist any more on CKAN but I think it would be good to add it back in.
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1423#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1424</link>
        <guid isPermaLink="false">http://localhost/ticket/1424</guid>
        <title>#1424: Openness notice should be clearer</title>
        <pubDate>Wed, 26 Oct 2011 16:54:49 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
ckan-discuss discussion suggests changes to the 'openness' indicator
( &lt;a class="ext-link" href="http://lists.okfn.org/pipermail/ckan-discuss/2011-October/001786.html"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://lists.okfn.org/pipermail/ckan-discuss/2011-October/001786.html&lt;/a&gt; )
&lt;/p&gt;
&lt;p&gt;
Dataset view page:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;If there is an explicit but non-OKD compliant license, such as CC-BY-NC, then this should be stated explicitly, perhaps: “This dataset is Not Open. License: Creative Commons Attribution Noncommerical. This is not an open license as it does not meet the Open Knowledge Definition.”
&lt;/li&gt;&lt;li&gt;If the license is marked as “Other::License Not Specified”, then this should be stated explicitly, perhaps:
“This dataset is Not Open. It is published without an explicit license, the publisher reserves all rights to the dataset.”
&lt;/li&gt;&lt;li&gt;3. If the license field was left empty by the contributor of the Data Hub record, then again this should be stated explicitly, perhaps: “This dataset is Not Open. The license of this dataset is unknown or unspecified. Start an enquiry on &lt;a class="missing wiki"&gt;IsItOpenData?&lt;/a&gt; »
&lt;/li&gt;&lt;li&gt;There is a bug so that non-open licenses doesn't have an openness notice.
&lt;/li&gt;&lt;li&gt;If downloadable resources are not available, this should not affect 'openness' - check this has been removed.
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1424#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1432</link>
        <guid isPermaLink="false">http://localhost/ticket/1432</guid>
        <title>#1432: [super] Data processing system for CKAN and Webstore</title>
        <pubDate>Tue, 01 Nov 2011 10:19:07 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Super ticket: &lt;a class="closed ticket" href="http://localhost/ticket/1190" title="enhancement: [super] CREP 0004 Data API and Data Processing System (closed: fixed)"&gt;#1190&lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;
A data processing system which utilizes the  Webstore. One could
get a long way with simple javascript running in the browser for development with this javascript then run offline using something like nodejs. Alternatively one could allow one to specify a url to e.g. a python file which would then be run in a sandbox (with access to some specified set of python modules)
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1432#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1438</link>
        <guid isPermaLink="false">http://localhost/ticket/1438</guid>
        <title>#1438: Action API - parameter discovery/checking</title>
        <pubDate>Tue, 01 Nov 2011 15:38:10 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
Currently they are listed in the docs, extracted from the code manually.
&lt;/p&gt;
&lt;p&gt;
So you could GET /action/api/package_list to receive not only the help text, but a list of arguments.
&lt;/p&gt;
&lt;p&gt;
And if you send an extra or missing argument then an intelligent error message can be returned.
&lt;/p&gt;
&lt;h1 id="implementation"&gt;implementation&lt;/h1&gt;
&lt;p&gt;
How about some sort of decorator on the action function:
&lt;/p&gt;
&lt;pre class="wiki"&gt;@logic_params(id, offset, limit)
def get_package_list(context, data_dict):
    ...
&lt;/pre&gt;&lt;p&gt;
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?
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
Another good thing would be to pass in the params named as themselves, rather than having them contained in the data_dict.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1438#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1439</link>
        <guid isPermaLink="false">http://localhost/ticket/1439</guid>
        <title>#1439: Action API discoverablility</title>
        <pubDate>Tue, 01 Nov 2011 15:39:30 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
A good service API needs to be discoverable, so you are not always having to refer to the documentation html.
&lt;/p&gt;
&lt;p&gt;
Maybe /api/action should return a list of actions available? (Currently this returns a 404.)
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;It would be nice to sort these into get/create/update/delete.
&lt;/li&gt;&lt;li&gt;&lt;a class="new ticket" href="http://localhost/ticket/1438" title="enhancement: Action API - parameter discovery/checking (new)"&gt;#1438&lt;/a&gt; Parameters for each of the actions must be discoverable too
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
/api/action/{action_name} should also return the help text / parameters allowable. (Currently this returns 400 error)
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1439#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1457</link>
        <guid isPermaLink="false">http://localhost/ticket/1457</guid>
        <title>#1457: Bug with DataNL instance</title>
        <pubDate>Thu, 10 Nov 2011 11:37:21 GMT</pubDate>
        
        <dc:creator>jilly.mathews</dc:creator>

        <description>&lt;blockquote&gt;
&lt;p&gt;
"when logging into &lt;a class="ext-link" href="http://register.data.overheid.nl/"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://register.data.overheid.nl/&lt;/a&gt; with OpenID, the /user/me page gives a 404. CKAN version 1.3.4."
&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;
n the manual it says an API key kan be created via &lt;a class="ext-link" href="http://test.ckan.net/user/me"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://test.ckan.net/user/me&lt;/a&gt; /. However, when I try the corresponding  &lt;a class="ext-link" href="http://register.data.overheid.nl/user/me"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://register.data.overheid.nl/user/me&lt;/a&gt;, I get a 404 error (not found).
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1457#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1460</link>
        <guid isPermaLink="false">http://localhost/ticket/1460</guid>
        <title>#1460: Improve extensions documentation</title>
        <pubDate>Sat, 12 Nov 2011 16:15:23 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Current extensions documentation needs some work: &lt;a class="ext-link" href="http://docs.ckan.org/en/latest/plugins.html"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://docs.ckan.org/en/latest/plugins.html&lt;/a&gt;
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Queue extension section may now be out of date (?)
&lt;/li&gt;&lt;li&gt;Think about how it integrates with &lt;a class="ext-link" href="https://github.com/okfn/ckanext-example"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;https://github.com/okfn/ckanext-example&lt;/a&gt; (especially tutorial and example extension)
&lt;/li&gt;&lt;li&gt;Document all plugin points (auto-extract from CKAN source??)
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1460#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1466</link>
        <guid isPermaLink="false">http://localhost/ticket/1466</guid>
        <title>#1466: Need to support https login for multiple instances as part of the CKAN package install</title>
        <pubDate>Tue, 15 Nov 2011 16:52:58 GMT</pubDate>
        
        <dc:creator>thejimmyg</dc:creator>

        <description></description>
        <category>Results</category>
        <comments>http://localhost/ticket/1466#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1509</link>
        <guid isPermaLink="false">http://localhost/ticket/1509</guid>
        <title>#1509: Mis-dated old revisions of datasets</title>
        <pubDate>Mon, 05 Dec 2011 13:06:38 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
e.g. &lt;a class="ext-link" href="http://thedatahub.org/dataset/osm%402011-07-12T12%3A16%3A47.590358"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://thedatahub.org/dataset/osm%402011-07-12T12%3A16%3A47.590358&lt;/a&gt; gives:
&lt;/p&gt;
&lt;pre class="wiki"&gt;This is the current revision of this dataset, as edited at 2011-07-12 12:16.
&lt;/pre&gt;&lt;p&gt;
but it should say the date 2011-07-12 (which is the data being displayed).
&lt;/p&gt;
&lt;p&gt;
The problem is looking at &lt;a class="missing wiki"&gt;PackageRevision?&lt;/a&gt;, when it might be a tag or extra.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1509#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1534</link>
        <guid isPermaLink="false">http://localhost/ticket/1534</guid>
        <title>#1534: Change revisions to record userid rather than username</title>
        <pubDate>Wed, 07 Dec 2011 17:26:30 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
The use of username is problematic because username's can change.
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Change all revision creation code to use user id (simplest is to change c.author field in lib/base.py (?))
&lt;ul&gt;&lt;li&gt;(?) 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)
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li&gt;Change user view page to look up against user id rather than name
&lt;/li&gt;&lt;li&gt;Perform migration on existing Revision objects
&lt;ul&gt;&lt;li&gt;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)
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1534#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1535</link>
        <guid isPermaLink="false">http://localhost/ticket/1535</guid>
        <title>#1535: Plump for auth header of: X-CKAN-API-KEY</title>
        <pubDate>Wed, 07 Dec 2011 17:31:22 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
When using the API, the apikey needs to be supplied in a header called 'Authorization'. Because some proxys / deployments use this header for other things, a configurable header was provided as an alternative, with default "X-CKAN-API-KEY".
&lt;/p&gt;
&lt;p&gt;
Rufus suggests having *one* way for this.
a) making this not configurable any more
b) making X-CKAN-API-KEY the default
&lt;/p&gt;
&lt;p&gt;
(keep Authorization allowed, but not documented, for backwards compatibility)
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1535#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1542</link>
        <guid isPermaLink="false">http://localhost/ticket/1542</guid>
        <title>#1542: Buttons to purge spam datasets and groups</title>
        <pubDate>Thu, 08 Dec 2011 17:22:10 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
A sysadmin should be able to easily examine a suspect group or package, determine if it was created by a spammer (as opposed to being a legitimate object that has been graffitied by a spammer) and purge it.
&lt;/p&gt;
&lt;p&gt;
The existing two-stage revision delete is currently unreliable and perhaps too laborious.
&lt;/p&gt;
&lt;p&gt;
Olav and Richard have needs along this line.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1542#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1544</link>
        <guid isPermaLink="false">http://localhost/ticket/1544</guid>
        <title>#1544: delete old git branches</title>
        <pubDate>Mon, 12 Dec 2011 15:10:10 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
We have 150 odd branches (&lt;tt&gt;git branch -a&lt;/tt&gt;) - most of them old - we should prune them. At very least, branches that have been merged in should be deleted. Look at old branches that haven't been merged in and wonder why.
&lt;/p&gt;
&lt;p&gt;
May be of some use:
&lt;/p&gt;
&lt;pre class="wiki"&gt;git branch --merged
git branch --no-merged
&lt;/pre&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1544#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1550</link>
        <guid isPermaLink="false">http://localhost/ticket/1550</guid>
        <title>#1550: Allow simple auth via the API</title>
        <pubDate>Fri, 16 Dec 2011 15:29:29 GMT</pubDate>
        
        <dc:creator>ross</dc:creator>

        <description>&lt;p&gt;
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.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1550#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1578</link>
        <guid isPermaLink="false">http://localhost/ticket/1578</guid>
        <title>#1578: [super] Re-enable and refactor ratings</title>
        <pubDate>Mon, 19 Dec 2011 19:20:43 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description></description>
        <category>Results</category>
        <comments>http://localhost/ticket/1578#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1596</link>
        <guid isPermaLink="false">http://localhost/ticket/1596</guid>
        <title>#1596: Refactor authz roles</title>
        <pubDate>Thu, 22 Dec 2011 10:31:28 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Suggestions from rgrp:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Get rid of Roles, and replace them with direct assignment of actions, even though there are many actions, and extensions can add arbitrary ones.
&lt;/li&gt;&lt;li&gt;Debatable whether we should cut the number of actions to correspond to the three roles defined by the base system.
&lt;/li&gt;&lt;li&gt;Have a method of finding roles (or, in future, actions) relevant to a given protection object (e.g. FILE-UPLOAD(ER) not relevant to Packages)
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
(This ticket is split off from &lt;a class="closed ticket" href="http://localhost/ticket/1065" title="enhancement: [super] Change Authorization System (closed: fixed)"&gt;#1065&lt;/a&gt;)
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1596#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1598</link>
        <guid isPermaLink="false">http://localhost/ticket/1598</guid>
        <title>#1598: Reinstate Ratings</title>
        <pubDate>Thu, 29 Dec 2011 16:52:04 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Ratings were disabled approximately a year ago because:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Unclear purpose and UX. What did ratings tell you? How useful were they?
&lt;/li&gt;&lt;li&gt;Spamming (esp by bots: you could submit an anonymous rating via a GET request which caused problems)
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
Both problems are solvable and it would be nice to have this feature reinstated.
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Purpose: can make this more purposable by limiting to logged in users (or at least distinguishing logged in from non-logged in users)
&lt;ul&gt;&lt;li&gt;Even better we could allow ratings to be made public (I'm interested in what someone else I respect finds important)
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li&gt;Spamming: limit to logged in users and / or use AJAX over an API to submit ...
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1598#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1604</link>
        <guid isPermaLink="false">http://localhost/ticket/1604</guid>
        <title>#1604: Get ckanext-moderatededits working with CKAN 1.5+ templates</title>
        <pubDate>Sat, 31 Dec 2011 17:27:09 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
ckanext-moderatededits requires an old and possibly development version of CKAN. It would be good to update it for later CKAN versions.
&lt;/p&gt;
&lt;p&gt;
According to the README, you need CKAN from branch feature-1141-moderated-edits-ajax but the changelog suggests this branch went into version 1.4.2. So it possibly works with 1.4.2 and 1.4.3(.1). But CKAN 1.5 has revamped templates, so the genshi stream filters definitely don't work.
&lt;/p&gt;
&lt;p&gt;
BTW history_ajax/read_ajax calls have been deprecated in CKAN since 1.5.2a and will need fixing up to use the Action API too as part of this.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1604#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1606</link>
        <guid isPermaLink="false">http://localhost/ticket/1606</guid>
        <title>#1606: metadata license config option</title>
        <pubDate>Mon, 02 Jan 2012 10:45:30 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Add a config option to choose the metadata licence. Set default to Open Database License.
&lt;/p&gt;
&lt;p&gt;
Currently the dataset edit form says "Important: By submitting content, you agree to release your contributions under the Open Database License." This is hard-coded, but not suitable for when DGU uses the CKAN form - they use the OGL.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1606#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1642</link>
        <guid isPermaLink="false">http://localhost/ticket/1642</guid>
        <title>#1642: Extra link generators generate garbled HTML</title>
        <pubDate>Thu, 12 Jan 2012 15:29:31 GMT</pubDate>
        
        <dc:creator>pudo</dc:creator>

        <description>&lt;p&gt;
I had a package descriptions with URLs that contain "group:foo". This produces garbled output as the system tries to generate two sets of links: the outer link and an inner link.
&lt;/p&gt;
&lt;p&gt;
Need to fix the parser.
&lt;/p&gt;
&lt;p&gt;
Text:
&lt;/p&gt;
&lt;p&gt;
Webdienst basierende Bereitstellung von Geobasisdaten der Freien und Hansestadt Hamburg. Folgende Geobasisdaten werden als &lt;a class="missing wiki"&gt;WebMapTileService?&lt;/a&gt; (WMT-S) für die Dauer des Wettbewerbs netzbasiert unter der Creative Commons Lizenz zur Verfügung gestellt: Digitale Orthophotos 40 cm Auflösung (Layer: apps4d_DOP40), Digitale Stadtkarte (Layer: apps4d_DISK), Digitale Regionalkarte (Layer: apps4d_DIRK), Digitale Karte 1:5000 (Layer: apps4d_DK5).
&lt;/p&gt;
&lt;p&gt;
Metadateneinträge zu den Daten im PortalU:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;[apps4d_DOP40](&lt;a class="ext-link" href="http://www.portalu.de/trefferanzeige?docuuid=D6082285-6CAC-49C5-B7ED-B5A72BC17DEC&amp;amp;plugid=/kug-group:kug-iplug-udk-db_hh"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://www.portalu.de/trefferanzeige?docuuid=D6082285-6CAC-49C5-B7ED-B5A72BC17DEC&amp;amp;plugid=/kug-group:kug-iplug-udk-db_hh&lt;/a&gt;)
&lt;/li&gt;&lt;li&gt;[apps4d_DISK](&lt;a class="ext-link" href="http://www.portalu.de/trefferanzeige?docuuid=D2DA3359-3DC9-4CA4-AE9B-7C63D53B220F&amp;amp;plugid=/kug-group:kug-iplug-udk-db_hh"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://www.portalu.de/trefferanzeige?docuuid=D2DA3359-3DC9-4CA4-AE9B-7C63D53B220F&amp;amp;plugid=/kug-group:kug-iplug-udk-db_hh&lt;/a&gt;)
&lt;/li&gt;&lt;li&gt;[apps4d_DIRK](&lt;a class="ext-link" href="http://www.portalu.de/trefferanzeige?docuuid=B7DDD599-F677-4C80-BED5-F11D82D5D1DD&amp;amp;plugid=/kug-group:kug-iplug-udk-db_hh"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://www.portalu.de/trefferanzeige?docuuid=B7DDD599-F677-4C80-BED5-F11D82D5D1DD&amp;amp;plugid=/kug-group:kug-iplug-udk-db_hh&lt;/a&gt;)
&lt;/li&gt;&lt;li&gt;[apps4d_DK5](&lt;a class="ext-link" href="http://www.portalu.de/trefferanzeige?docuuid=2AE6D23E-48A5-4D85-BC0A-160737E0C8D2&amp;amp;plugid=/kug-group:kug-iplug-udk-db_hh"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://www.portalu.de/trefferanzeige?docuuid=2AE6D23E-48A5-4D85-BC0A-160737E0C8D2&amp;amp;plugid=/kug-group:kug-iplug-udk-db_hh&lt;/a&gt;)
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
One fix is quoting the URLs
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1642#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1643</link>
        <guid isPermaLink="false">http://localhost/ticket/1643</guid>
        <title>#1643: Add fixed tags to thedatahub for better browsing</title>
        <pubDate>Thu, 12 Jan 2012 18:34:53 GMT</pubDate>
        
        <dc:creator>shevski</dc:creator>

        <description>&lt;p&gt;
Similar to publicdata.eu, want to have themed areas such as finance, environment, census, etc and country tags
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1643#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1644</link>
        <guid isPermaLink="false">http://localhost/ticket/1644</guid>
        <title>#1644: Order default dataset page by most downloaded resources on thedatahub</title>
        <pubDate>Thu, 12 Jan 2012 18:39:02 GMT</pubDate>
        
        <dc:creator>shevski</dc:creator>

        <description>&lt;p&gt;
Instead of alphabetically as we do currently, alternatively by most viewed datasets
&lt;/p&gt;
&lt;p&gt;
for &lt;a class="ext-link" href="http://thedatahub.org/dataset"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://thedatahub.org/dataset&lt;/a&gt;
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1644#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1647</link>
        <guid isPermaLink="false">http://localhost/ticket/1647</guid>
        <title>#1647: add links to ckan discuss &amp; dev to thedatahub</title>
        <pubDate>Mon, 16 Jan 2012 00:30:52 GMT</pubDate>
        
        <dc:creator>shevski</dc:creator>

        <description>&lt;p&gt;
In the footer as well as more clearly &amp;amp; directly on the About page
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1647#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1661</link>
        <guid isPermaLink="false">http://localhost/ticket/1661</guid>
        <title>#1661: Wrong Routes version installed by CKAN package</title>
        <pubDate>Mon, 16 Jan 2012 12:47:41 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Jaakko Louhio reported that the wrong Routes version got installed during CKAN's package install.
&lt;/p&gt;
&lt;p&gt;
He is using Ubuntu 10.04 and he believes it install Routes 1.12.3 instead of what we use which is 1.11.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1661#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1668</link>
        <guid isPermaLink="false">http://localhost/ticket/1668</guid>
        <title>#1668: repoze version discrepency</title>
        <pubDate>Tue, 17 Jan 2012 12:02:26 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
There's a discrepency in repoze.who versions between the source and package installs:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;repoze.who - package 1.0.18 vs source 1.0.19
&lt;/li&gt;&lt;li&gt;repoze.who-friendlyform - package 1.0b3 vs source 1.0.8
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
We get a test failure &lt;a class="missing changeset" title="No default repository defined"&gt;[1]&lt;/a&gt; with the 1.0b3 version (from the ubuntu 10.04 python-repoze.who-plugins package). But we've not noticed any problems on s057 instances (br, no, ie etc) which have the package versions of repoze.who.
&lt;/p&gt;
&lt;p&gt;
The reason the package install uses the earlier packaged versions rather than the ones we'd like is that repoze uses all sorts of horrendous import hacks, making it too difficult to put into our 'ckan-conflict' source package.
&lt;/p&gt;
&lt;p&gt;
James suggests we 'do something horrible like dynamically patch repoze on CKAN import'.
&lt;/p&gt;
&lt;p&gt;
&lt;a class="missing changeset" title="No default repository defined"&gt;[1]&lt;/a&gt; &lt;a class="ext-link" href="http://buildbot.okfn.org/builders/builder-ckan/builds/1371/steps/shell/logs/stdio"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://buildbot.okfn.org/builders/builder-ckan/builds/1371/steps/shell/logs/stdio&lt;/a&gt;
ERROR: ckan.tests.functional.test_user.&lt;a class="missing wiki"&gt;TestUserController?&lt;/a&gt;.test_user_create_unicode
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1668#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1679</link>
        <guid isPermaLink="false">http://localhost/ticket/1679</guid>
        <title>#1679: Default roles problem</title>
        <pubDate>Tue, 17 Jan 2012 17:57:22 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
The 'editor', 'anon_editor' and 'reader' roles are intended to have immutable actions. This was designed to prevent their names being subverted - e.g. an editor should always be able to edit! It also meant that when we add Actions (e.g. DELETE-PACKAGE) then it can be added sensibly to these roles in an upgrade just by changing the defaults table (ckan/model/authz.py).
&lt;/p&gt;
&lt;p&gt;
The problem is that this immutability is only enforced on 'db upgrade'. So you can happily change the editor role using the paster command and it works, right up until you do an upgrade and realise permissions are different.
&lt;/p&gt;
&lt;p&gt;
We should stop the paster commands being able to edit these roles. Or get rid of the immutability completely. Views?
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1679#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1684</link>
        <guid isPermaLink="false">http://localhost/ticket/1684</guid>
        <title>#1684: Remove all config from ckanext-archiver</title>
        <pubDate>Thu, 19 Jan 2012 14:37:01 GMT</pubDate>
        
        <dc:creator>ross</dc:creator>

        <description>&lt;p&gt;
ckanext-archiver currently has a settings file (and a default) and it should be passed in all relevant information from the context.
&lt;/p&gt;
&lt;p&gt;
Remove all settings (ARCHIVE_DIR and MAX_CONTENT_LENGTH and others) and pass them in from CKAN.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1684#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1697</link>
        <guid isPermaLink="false">http://localhost/ticket/1697</guid>
        <title>#1697: A Configurable list of states for a Dataset</title>
        <pubDate>Tue, 24 Jan 2012 10:23:50 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Currently have 'active' and 'deleted' suggest also:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;'draft'
&lt;/li&gt;&lt;li&gt;'hidden'
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
(Do we need both). Also write out workflows related to these.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1697#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1717</link>
        <guid isPermaLink="false">http://localhost/ticket/1717</guid>
        <title>#1717: [super] Search UX improvements</title>
        <pubDate>Thu, 26 Jan 2012 18:53:01 GMT</pubDate>
        
        <dc:creator>shevski</dc:creator>

        <description>&lt;ol&gt;&lt;li&gt;Make it possible to search by tag (e.g. by typing tag:csv into the search bar and clicking enter, it should add the 'csv' tag facet to the search)
&lt;/li&gt;&lt;/ol&gt;&lt;ol start="2"&gt;&lt;li&gt;Rename and standardise the list of format tags, on search page this should also be called 'Format' instead of 'res_format' (in the right hand side bar on search page).
&lt;/li&gt;&lt;/ol&gt;&lt;ol start="3"&gt;&lt;li&gt;Make it possible to view full list of tags, formats and groups by clicking on the name. From here you should be table to click on a classification and go back to a search page faceted by that classification. E.g. from search page, click on 'tags', on tag page click on 'london' or whatever, and be navigated back to search page with search within 'london' tag only.  Or y'know, a better way of doing it.
&lt;/li&gt;&lt;/ol&gt;&lt;ol start="4"&gt;&lt;li&gt;More standard classifications, such as 'Location' and 'Theme' - like on publicdata.eu
&lt;/li&gt;&lt;/ol&gt;&lt;ol start="5"&gt;&lt;li&gt;Blue search button should be displayed in line with the search bar, not underneath
&lt;/li&gt;&lt;/ol&gt;&lt;ol start="6"&gt;&lt;li&gt;Datasets should be displayed in order of most viewed or downloaded instead of alphabetically. For alphabetic search we could consider adding a way to facet by first letter of dataset name
&lt;/li&gt;&lt;/ol&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1717#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1740</link>
        <guid isPermaLink="false">http://localhost/ticket/1740</guid>
        <title>#1740: Get rid of `from module import ...`</title>
        <pubDate>Wed, 01 Feb 2012 11:06:09 GMT</pubDate>
        
        <dc:creator>seanh</dc:creator>

        <description>&lt;p&gt;
It's really bad to do &lt;tt&gt;from module import *&lt;/tt&gt; and CKAN has a lot of them. I suggest a three-pronged approach:
&lt;/p&gt;
&lt;ol&gt;&lt;li&gt;Don't add any more of them.
&lt;/li&gt;&lt;/ol&gt;&lt;ol start="2"&gt;&lt;li&gt;When you're programming if you see an easy opportunity to remove one then do so.
&lt;/li&gt;&lt;/ol&gt;&lt;ol start="3"&gt;&lt;li&gt;At some point we should task someone to go through the code and remove them all (which is what this ticket is for), but this will be a big job and may break things.
&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;
We should also get rid of most or all of the &lt;tt&gt;from module import foo&lt;/tt&gt; and &lt;tt&gt;from module import foo, bar&lt;/tt&gt; statements.
&lt;/p&gt;
&lt;p&gt;
I think the right thing to do is just &lt;tt&gt;import module&lt;/tt&gt; and then use &lt;tt&gt;module.foo&lt;/tt&gt; in your code. But if you find yourself doing &lt;tt&gt;module.foo.bar&lt;/tt&gt; then you may have a code smell.
&lt;/p&gt;
&lt;p&gt;
See: &lt;a class="ext-link" href="http://docs.python.org/dev/howto/doanddont.html"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://docs.python.org/dev/howto/doanddont.html&lt;/a&gt;
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1740#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1745</link>
        <guid isPermaLink="false">http://localhost/ticket/1745</guid>
        <title>#1745: Dataset search UX improvements as of Jan 2012</title>
        <pubDate>Thu, 02 Feb 2012 23:22:21 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Changes to make search both more exploratory and more satisfying to use
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Search query build - &lt;a class="closed ticket" href="http://localhost/ticket/1603" title="enhancement: Search query builder (closed: duplicate)"&gt;#1603&lt;/a&gt;
&lt;ul&gt;&lt;li&gt;Ability to add new facet fields "live"
&lt;/li&gt;&lt;li&gt;That is add fields which then contain faceted options (a bit like data.hri.fi)
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li&gt;(??) Autocomplete  / drop down on search (i.e. search while you type)
&lt;ul&gt;&lt;li&gt;Dubious about value / cost ratio here
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
Probably would involve to pure JS and HTML implementation.
&lt;/p&gt;
&lt;h2 id="Implementation"&gt;Implementation&lt;/h2&gt;
&lt;p&gt;
Probably require
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt; API changes to expose solr style API directly &lt;a class="closed ticket" href="http://localhost/ticket/1737" title="enhancement: Expose solr-based search API (closed: fixed)"&gt;#1737&lt;/a&gt;
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1745#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1747</link>
        <guid isPermaLink="false">http://localhost/ticket/1747</guid>
        <title>#1747: Expire old activities</title>
        <pubDate>Sun, 05 Feb 2012 12:56:29 GMT</pubDate>
        
        <dc:creator>seanh</dc:creator>

        <description>&lt;p&gt;
Currently the activity streams database tables just get longer and longer over time. Do we want to eventually delete the oldest activities, to keep the length of the table within limits?
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1747#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1749</link>
        <guid isPermaLink="false">http://localhost/ticket/1749</guid>
        <title>#1749: Allow creating activity details through API</title>
        <pubDate>Sun, 05 Feb 2012 18:10:06 GMT</pubDate>
        
        <dc:creator>seanh</dc:creator>

        <description>&lt;p&gt;
Currently the activity_create() logic action function only lets you create top-level activity stream items, and not their related activity details. It should handle activity details via nested dicts.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1749#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1750</link>
        <guid isPermaLink="false">http://localhost/ticket/1750</guid>
        <title>#1750: Move ckan/lib/activity.py into the model</title>
        <pubDate>Sun, 05 Feb 2012 18:18:08 GMT</pubDate>
        
        <dc:creator>seanh</dc:creator>

        <description>&lt;p&gt;
Move ckan/lib/activity.py moved to into the model - say ckan/model/activity_extension.py, because it's so tightly knit with the model code, whereas most of the lib code is used in the controllers.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1750#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1787</link>
        <guid isPermaLink="false">http://localhost/ticket/1787</guid>
        <title>#1787: [super] Improve RESTful API</title>
        <pubDate>Wed, 08 Feb 2012 11:54:42 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;ul&gt;&lt;li&gt;Lists of entities should be full URLs, rather than just the names
&lt;/li&gt;&lt;li&gt;Discoverability - /api/v3/rest should list the entity types that can be listed
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
This could be v3 of the RESTful interface.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1787#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1789</link>
        <guid isPermaLink="false">http://localhost/ticket/1789</guid>
        <title>#1789: Implement a tag_update() logic action function</title>
        <pubDate>Thu, 09 Feb 2012 16:36:53 GMT</pubDate>
        
        <dc:creator>seanh</dc:creator>

        <description>&lt;p&gt;
So users can rename a tag and/or move it between vocabularies using the API.
&lt;/p&gt;
&lt;p&gt;
Currently we have create_tag() and delete_tag(), but if you were to 'update' a tag by deleting it and then recreating it all the datasets that had that tag will have lost it and you'll have to re-add it to them all.
&lt;/p&gt;
&lt;p&gt;
What should happen to datasets that have the tag, if the tag gets moved between vocabularies? All the datasets just keep the tag with the new vocabulary? This will become a problem if/when we support 'radio button'-style vocabularies (where each dataset can only have one tag from the vocabulary).
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1789#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1790</link>
        <guid isPermaLink="false">http://localhost/ticket/1790</guid>
        <title>#1790: Click to delete tags, rather than have all existing tags in the tag text box</title>
        <pubDate>Fri, 10 Feb 2012 15:44:34 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
From Pablo:
&lt;/p&gt;
&lt;p&gt;
Editing the tags field is clumsy when there are too many tags. Could
show existing effectively as tags (like delicious), then allow clicks
to delete. New tags added via text box.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1790#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1800</link>
        <guid isPermaLink="false">http://localhost/ticket/1800</guid>
        <title>#1800: Tidy up *_list() and *_search() functions in ckan/logic/action/get.py</title>
        <pubDate>Thu, 16 Feb 2012 15:12:09 GMT</pubDate>
        
        <dc:creator>seanh</dc:creator>

        <description>&lt;p&gt;
For consistency all the *_list() functions should list objects only and not accept an optional search query. There should be *_search() functions whenever search is needed.
&lt;/p&gt;
&lt;p&gt;
Currently it is inconsistent, e.g. package_list() and resource_list() do not accept a search query option and there are package_search() and resource_search(), but user_list() does accept a query and there is no user_search(). tag_list() also accepts a query, and there is also a tag_search() that apparently duplicates the search functionality.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1800#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1823</link>
        <guid isPermaLink="false">http://localhost/ticket/1823</guid>
        <title>#1823: Spring clean bin directory</title>
        <pubDate>Mon, 20 Feb 2012 21:28:51 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Huge number of accumulated (and likely unnecessary) scripts in /bin directory.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1823#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1824</link>
        <guid isPermaLink="false">http://localhost/ticket/1824</guid>
        <title>#1824: Add vocabulary pages</title>
        <pubDate>Tue, 21 Feb 2012 17:24:49 GMT</pubDate>
        
        <dc:creator>seanh</dc:creator>

        <description>&lt;p&gt;
For a free tag foo you can visit the page at /tag/foo and see a list of all the datasets that have the tag foo, and when the tag appears on dataset view pages etc. it's linked to this tag page.
&lt;/p&gt;
&lt;p&gt;
We should do the same thing for vocabulary tags. A tag bar in vocabulary baz should be hyperlinked to a page /tag/baz/bar, or perhaps /vocab/baz/bar.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1824#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1827</link>
        <guid isPermaLink="false">http://localhost/ticket/1827</guid>
        <title>#1827: 'Register' link should be hidden if you not allowed to register</title>
        <pubDate>Wed, 22 Feb 2012 15:35:39 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;pre class="wiki"&gt;I have just deny visitors the create-user permission:
sudo -u ckanstd paster --plugin=ckan roles deny reader create-user -c /etc/ckan/std/std.ini
sudo -u ckanstd paster --plugin=ckan roles deny anon_editor create-user -c /etc/ckan/std/std.ini
and after restarting, the register link is *not* hidden, but now when you access the register page, it shows you this message "Unauthorized to create a user" (when not logged in). But anyway that is an improvement.
&lt;/pre&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1827#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1831</link>
        <guid isPermaLink="false">http://localhost/ticket/1831</guid>
        <title>#1831: Login with email address</title>
        <pubDate>Fri, 24 Feb 2012 08:58:26 GMT</pubDate>
        
        <dc:creator>ross</dc:creator>

        <description>&lt;p&gt;
Users should be able to log in using either their username, or their email address, both of which are unique.
&lt;/p&gt;
&lt;p&gt;
Will require a change to &lt;a class="missing wiki"&gt;UsernamePasswordAuthenticator?&lt;/a&gt; in ckan.lib.authenticator.py and possible a useful User.by_email in the user model if it doesn't already exist.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1831#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1832</link>
        <guid isPermaLink="false">http://localhost/ticket/1832</guid>
        <title>#1832: dataset purge API</title>
        <pubDate>Fri, 24 Feb 2012 10:02:25 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Purging datasets (deleting them fully, not just changing the state to 'deleted') is important for users testing dataset creation over the API on a test CKAN instance.
&lt;/p&gt;
&lt;p&gt;
Without this, they need to resort to more difficult methods such as:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;cleaning and reloading the database
&lt;/li&gt;&lt;li&gt;setting the test datasets to state 'deleted' and also appending a suffix '_00' and incrementing the number until there is no clash of names.
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
Requested for NHSIC.
&lt;/p&gt;
&lt;h2 id="Implementation"&gt;Implementation&lt;/h2&gt;
&lt;ul&gt;&lt;li&gt;This could slot into the Action API.
&lt;/li&gt;&lt;li&gt;Of course we would need to ensure the user's had been given the specific right to purge.
&lt;/li&gt;&lt;li&gt;I suggest we log the full details of the dataset being purged.
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1832#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/2197</link>
        <guid isPermaLink="false">http://localhost/ticket/2197</guid>
        <title>#2197: Storage Metadata API: add/update not working with local file storage (Pairtree)</title>
        <pubDate>Tue, 28 Feb 2012 09:29:37 GMT</pubDate>
        
        <dc:creator>zydio</dc:creator>

        <description>&lt;p&gt;
If OFS is configured with Pairtree to use a local file storage, all POST requests to add/update metadata ( /api/storage/metadata/{label} ) will fail.
&lt;/p&gt;
&lt;p&gt;
This is due to the use of &lt;a class="ext-link" href="https://github.com/okfn/ofs/blob/master/ofs/remote/botostore.py"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;BotoOFS&lt;/a&gt; specific &lt;em&gt;private&lt;/em&gt; methods in &lt;a class="ext-link" href="https://github.com/okfn/ckan/blob/master/ckan/controllers/storage.py"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;StorageAPIController.set_metadata()&lt;/a&gt;, eg: self.ofs.&lt;strong&gt;_require_bucket&lt;/strong&gt;(bucket), self.ofs.&lt;strong&gt;_get_key&lt;/strong&gt;(b, label), self.ofs.&lt;strong&gt;_update_key_metadata&lt;/strong&gt;(k, metadata) ... those methods can't be found in &lt;a class="ext-link" href="https://github.com/okfn/ofs/blob/master/ofs/local/pairtreestore.py"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;POTFS&lt;/a&gt; and this causes errors.
The API should use only &lt;a class="ext-link" href="https://github.com/okfn/ofs/blob/master/ofs/base.py"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;OFSInterface&lt;/a&gt; methods, or should conditionally make calls based off the actual type of &lt;em&gt;self.ofs&lt;/em&gt;.
&lt;/p&gt;
&lt;p&gt;
&lt;em&gt;PS: I did set "ckan" as "Component" in the ticket because storage has been integrated back into the core in CKAN 1.6&lt;/em&gt;
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/2197#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/2202</link>
        <guid isPermaLink="false">http://localhost/ticket/2202</guid>
        <title>#2202: Display page view count on dataset and resource pages</title>
        <pubDate>Sat, 03 Mar 2012 09:04:15 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Just like we display download counts we should display view counts.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/2202#changelog</comments>
    </item>
 </channel>
</rss>