<?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;component=ckan&amp;milestone=ckan-v1.4-sprint-6&amp;group=resolution&amp;order=type</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;component=ckan&amp;milestone=ckan-v1.4-sprint-6&amp;group=resolution&amp;order=type</link>
    </image>
    <generator>Trac 0.12.3</generator>
    <item>
        <link>http://localhost/ticket/515</link>
        <guid isPermaLink="false">http://localhost/ticket/515</guid>
        <title>#515: Inconsistent use of 'location' header in API</title>
        <pubDate>Wed, 25 Aug 2010 17:29:20 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
When you create a package then the 'location' header gets set. This doesn't happen for any other domain objects. I think this should be consistent - either none or all.
&lt;/p&gt;
&lt;p&gt;
I've removed the info about the header in the docs in the meantime.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/515#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/854</link>
        <guid isPermaLink="false">http://localhost/ticket/854</guid>
        <title>#854: Tests for authorization_group</title>
        <pubDate>Tue, 07 Dec 2010 12:10:15 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
The coverage tool (run by buildbot in the ckan build) reports that only 24% of lines of ckan.controllers.authorization_group are run in tests and 38% of ckan.forms.authorization_group. This suggests a need for more tests.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/854#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1056</link>
        <guid isPermaLink="false">http://localhost/ticket/1056</guid>
        <title>#1056: User links for OpenID users are broken</title>
        <pubDate>Fri, 25 Mar 2011 13:37:29 GMT</pubDate>
        
        <dc:creator>pudo</dc:creator>

        <description>&lt;p&gt;
Use case:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Login using OpenID
&lt;/li&gt;&lt;li&gt;Click on 'My account' - results in 404
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
Solutions:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;User user.id instead of their name
&lt;/li&gt;&lt;li&gt;Escape the URL properly.
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1056#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1090</link>
        <guid isPermaLink="false">http://localhost/ticket/1090</guid>
        <title>#1090: Visitor can't create packages on new CKAN install</title>
        <pubDate>Tue, 12 Apr 2011 19:06:59 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Default visitor roles in default config is reader, not anon_editor.
&lt;/p&gt;
&lt;p&gt;
Problem caused by changes in &lt;a class="closed ticket" href="http://localhost/ticket/1066" title="enhancement: Default reader role too permissive (closed: fixed)"&gt;#1066&lt;/a&gt; (released in 1.3.3)
&lt;/p&gt;
&lt;p&gt;
New installs will be affected, although simple to just increase permissions when the installer realises a visitor can't create packages.
&lt;/p&gt;
&lt;p&gt;
The solution to the config getting out of sync with the code like this is to not have the default_roles in the config - refer to the code in the configuration instructions.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1090#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1092</link>
        <guid isPermaLink="false">http://localhost/ticket/1092</guid>
        <title>#1092: refactor logic layer to seperate out api, form logic</title>
        <pubDate>Thu, 14 Apr 2011 10:45:29 GMT</pubDate>
        
        <dc:creator>kindly</dc:creator>

        <description>&lt;p&gt;
The logic layer is a bit too api centric. Make the reusable parts separate in preparation for the wui refactor.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1092#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1093</link>
        <guid isPermaLink="false">http://localhost/ticket/1093</guid>
        <title>#1093: 500 errors on GET to api/rest/licenses</title>
        <pubDate>Fri, 15 Apr 2011 10:11:01 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
CKAN gets its license list from a license service, which can be a local file, but is often the &lt;a class="ext-link" href="http://licenses.opendefinition.org/2.0/ckan_original"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://licenses.opendefinition.org/2.0/ckan_original&lt;/a&gt; server. This server is currently flakey, but I think we only request the list on start up. The problem is we query it much more often than required. It is queried for every request to api/rest/licenses, and we are returning lots of 500 errors when the license server is timing out.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1093#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1100</link>
        <guid isPermaLink="false">http://localhost/ticket/1100</guid>
        <title>#1100: Get buildbot running on ckan branches</title>
        <pubDate>Thu, 21 Apr 2011 11:27:47 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Need some changes to pip-requirements files in release branches.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1100#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1106</link>
        <guid isPermaLink="false">http://localhost/ticket/1106</guid>
        <title>#1106: Bugs related to routes arising from API refactor + removal of default routes</title>
        <pubDate>Mon, 25 Apr 2011 16:02:40 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Various bugs I've been encountering:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Autocomplete of tag names no longer works (no longer works on &lt;a class="ext-link" href="http://ckan.net/"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://ckan.net/&lt;/a&gt;). Appears to be due to no longer have a routes for apiv2 (i'm seeing failing calls to:  &lt;a class="ext-link" href="http://ckan.net/apiv2/package/autocomplete?callback=callback&amp;amp;incomplete=a"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://ckan.net/apiv2/package/autocomplete?callback=callback&amp;amp;incomplete=a&lt;/a&gt;)
&lt;/li&gt;&lt;li&gt;Incorrect url generated for API in page footer (e.g.  &lt;a class="ext-link" href="http://ckan.net/rest/get_api"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://ckan.net/rest/get_api&lt;/a&gt;) due to use of old 'rest' rather than new 'api'
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
Latter issue was masked by existence of 'default' routes:
&lt;/p&gt;
&lt;pre class="wiki"&gt;   map.connect('/{controller}', action='index')
   map.connect('/:controller/{action}')
   map.connect('/{controller}/{action}/{id}')
&lt;/pre&gt;&lt;p&gt;
Having these is, I think, bad practice as it is better to be explicit and we should therefore remove asap.
&lt;/p&gt;
&lt;p&gt;
In addition I think we should be cautious about 'default' routes in core such as:
&lt;/p&gt;
&lt;pre class="wiki"&gt;    map.connect('/api/rest/:register', controller='api', action='list',
        conditions=dict(method=['GET'])
        )
&lt;/pre&gt;&lt;p&gt;
As it makes it harder for extensions to introduce their own APIs (here one could perhaps add something at /api/rest/{my-object} but only by using before_map rather than after_map).
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1106#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/833</link>
        <guid isPermaLink="false">http://localhost/ticket/833</guid>
        <title>#833: [super] Administrative dashboard extension</title>
        <pubDate>Fri, 26 Nov 2010 10:05:21 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Create an admin dashboard as /ckan-admin/ allowing for admin operations and overview.
&lt;/p&gt;
&lt;p&gt;
Possible features:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Purge revisions (or sets of revisions) and purge objects &lt;a class="closed ticket" href="http://localhost/ticket/1076" title="enhancement: Improve revision and package purge system (closed: fixed)"&gt;#1076&lt;/a&gt;
&lt;/li&gt;&lt;li&gt;Set roles for users &lt;a class="closed ticket" href="http://localhost/ticket/1075" title="enhancement: Administrative dashboard - Edit Authorization related to System object (closed: fixed)"&gt;#1075&lt;/a&gt;
&lt;/li&gt;&lt;li&gt;Put system into particular modes e.g. wiki mode (anyone can add, edit packages by default), data portal (only sysadmins or members of a special Editor group can create and edit packages)
&lt;ul&gt;&lt;li&gt;WONTFIX
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li&gt;Overview of activity
&lt;ul&gt;&lt;li&gt;WONTFIX - already have revision log
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
Currently have an admin section using the formalchemy admin controller to provide basic editing of model objects. This can still be used but located at /admin/model/.
&lt;/p&gt;
&lt;p&gt;
&lt;a class="ext-link" href="https://bitbucket.org/okfn/ckanext-admin"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;https://bitbucket.org/okfn/ckanext-admin&lt;/a&gt;
&lt;/p&gt;
&lt;h3 id="Tickets"&gt;Tickets&lt;/h3&gt;
&lt;ul&gt;&lt;li&gt;&lt;a class="closed ticket" href="http://localhost/ticket/1031" title="enhancement: User lookup API (closed: fixed)"&gt;ticket:1031&lt;/a&gt; - user autocomplete api in ckan
&lt;/li&gt;&lt;/ul&gt;&lt;h3 id="Notes"&gt;Notes&lt;/h3&gt;
&lt;p&gt;
Here's putting into restricted mode (plus creating a dedicated authz group so that others can admin sysadmin simply through that group):
&lt;/p&gt;
&lt;pre class="wiki"&gt;# first remove permissions from roles
# this is hacky but have to do it because we hardcode assignment of
# role permissions on package on package create (see model/authz.py)
paster roles deny editor edit
paster roles deny editor create-authorization-group
paster roles deny editor create-group
paster roles deny editor create-package
paster roles deny reader create-package
# make superuser group
# create authz group administrators / Administrators (if not exists)
paster rights make agroup:administrators admin system
&lt;/pre&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/833#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/840</link>
        <guid isPermaLink="false">http://localhost/ticket/840</guid>
        <title>#840: On/off switch for ETags cache</title>
        <pubDate>Thu, 02 Dec 2010 16:52:07 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;ul&gt;&lt;li&gt;Use config variable to switch ETags caching on or off. Consider joining in with 'cache_enabled'.
&lt;/li&gt;&lt;li&gt;Default setting for (all) caching should be off.
&lt;/li&gt;&lt;li&gt;Needs documenting in configuration.rst
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/840#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/919</link>
        <guid isPermaLink="false">http://localhost/ticket/919</guid>
        <title>#919: Package preview contains API &amp; datapkg instructions</title>
        <pubDate>Tue, 18 Jan 2011 10:32:10 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;ol&gt;&lt;li&gt;Edit a package
&lt;/li&gt;&lt;li&gt;Hit 'preview'.
&lt;/li&gt;&lt;/ol&gt;&lt;p&gt;
The preview contains the section "CKAN API / datapkg" which seems irrelevant at this point. Looking at ckan.net previews, the Comments section only appears when you view a package and not when you preview it. This seems more sensible - can this be done for the "CKAN API / datapkg" section too?
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/919#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/936</link>
        <guid isPermaLink="false">http://localhost/ticket/936</guid>
        <title>#936: Follow / watch package extension</title>
        <pubDate>Sat, 29 Jan 2011 22:11:19 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
As a (logged-in) User I want to watch (follow) a package, that is register my interest about a package. (Similar to watch/follow features in github/bitbucket/wikis).
&lt;/p&gt;
&lt;p&gt;
NB: this is as much (if not more) about showing what packages are interesting to people as giving info to 'watchers'.
&lt;/p&gt;
&lt;p&gt;
Need to finalize terminology (github uses watch for repos and follow for users while bitbucket combines both in 'followers'). &lt;strong&gt;Decision: use follow&lt;/strong&gt;
&lt;/p&gt;
&lt;h2 id="Implementation"&gt;Implementation&lt;/h2&gt;
&lt;h3 id="Interface"&gt;Interface&lt;/h3&gt;
&lt;p&gt;
Become a follower:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Follow button on packages (if already watching say 'unfollow')
&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
Package-related changes:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Show number of followers on a package
&lt;/li&gt;&lt;li&gt;List followers of a package at /package/{name}/followers
&lt;ul&gt;&lt;li&gt;On a separate page
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;/ul&gt;&lt;p&gt;
a package
User-related changes:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;List followed packages
&lt;ul&gt;&lt;li&gt;Either on user's page on a separate 'following' page. (NB: called 'following')
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li&gt;Does watching involve notifications (by email)
&lt;ul&gt;&lt;li&gt;Probably not: you can already subscribe to RSS feed after all and email not that necessary (?)
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li&gt;[Future - don't have activity stream yet] Show what packages a user has started/stopped  followed on a user's public activity stream on their user page
&lt;/li&gt;&lt;/ul&gt;&lt;h3 id="Nitty-Gritty"&gt;Nitty-Gritty&lt;/h3&gt;
&lt;ul&gt;&lt;li&gt;Want to do this in ajax-y manner
&lt;/li&gt;&lt;li&gt;API endpoint: /api/2/follower
&lt;/li&gt;&lt;li&gt;Store data in a new follower table
&lt;/li&gt;&lt;/ul&gt;&lt;h4 id="API"&gt;API&lt;/h4&gt;
&lt;p&gt;
/api/2/follower
&lt;/p&gt;
&lt;pre class="wiki"&gt;follow =&amp;gt; PUT / POST
{
   user_id
   object_type
   object_id
}
&lt;/pre&gt;&lt;p&gt;
If this is submitted by a user with user.id != user_id =&amp;gt; error (401)
&lt;/p&gt;
&lt;pre class="wiki"&gt;unfollow =&amp;gt; DELETE
/api/2/follower/package/{id}
=&amp;gt; list of followers
[
    { safe dictized user }
]
&lt;/pre&gt;&lt;p&gt;
NB: depends on access to a 'safe' dictized user object. Dictization is in nearly done, and current example of doing this by hand is in user API autocomplete method.
&lt;/p&gt;
&lt;h4 id="Table"&gt;Table&lt;/h4&gt;
&lt;p&gt;
Called 'follower'
&lt;/p&gt;
&lt;pre class="wiki"&gt;user_id, table, object_id, created
xxx, package, yyy, ...
xxx, user, yyy, ... [future]
&lt;/pre&gt;&lt;p&gt;
&lt;/p&gt;
&lt;h3 id="RandomExtras"&gt;Random Extras&lt;/h3&gt;
&lt;ul&gt;&lt;li&gt;What about following users as well
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/936#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1075</link>
        <guid isPermaLink="false">http://localhost/ticket/1075</guid>
        <title>#1075: Administrative dashboard - Edit Authorization related to System object</title>
        <pubDate>Fri, 08 Apr 2011 16:23:19 GMT</pubDate>
        
        <dc:creator>rgrp</dc:creator>

        <description>&lt;p&gt;
Roles on System object are important because admin role on system equates to being a 'sysadmin' (i.e. able to do anything).
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;Make users sysadmin (either as separate action or as part of editing roles on system object)
&lt;/li&gt;&lt;li&gt;/authz subpage for editing roles on system object
&lt;ul&gt;&lt;li&gt;Add and update user roles
&lt;/li&gt;&lt;li&gt;Add and update authz group roles
&lt;/li&gt;&lt;li&gt;List actions associated to roles at top of page (extra points for checkbox table with editability)
&lt;/li&gt;&lt;/ul&gt;&lt;/li&gt;&lt;li&gt;Document on &lt;a class="ext-link" href="http://wiki.ckan.net/Authorization"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://wiki.ckan.net/Authorization&lt;/a&gt; what roles on System object 'mean' esp sysadmin role on System
&lt;/li&gt;&lt;/ul&gt;&lt;h2 id="RelatedTickets"&gt;Related Tickets&lt;/h2&gt;
&lt;p&gt;
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;super ticket: &lt;a class="closed ticket" href="http://localhost/ticket/833" title="enhancement: [super] Administrative dashboard extension (closed: fixed)"&gt;#833&lt;/a&gt;
&lt;/li&gt;&lt;li&gt;authz lib improvement and authztool refactor &lt;a class="closed ticket" href="http://localhost/ticket/1050" title="enhancement: Authz lib improvement and refactor of ckan/lib/authztool.py (closed: invalid)"&gt;#1050&lt;/a&gt;
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1075#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1089</link>
        <guid isPermaLink="false">http://localhost/ticket/1089</guid>
        <title>#1089: Check for "--ckan" when running nosetests</title>
        <pubDate>Tue, 12 Apr 2011 17:59:49 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
(because if you forget, you get difficult to understand errors, and more than one person has tripped up on this)
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1089#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1097</link>
        <guid isPermaLink="false">http://localhost/ticket/1097</guid>
        <title>#1097: Sidebar hideable</title>
        <pubDate>Wed, 20 Apr 2011 09:56:56 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
The web interface has a sidebar (#primary) which should be hidden in some pages. This is for QA extension and useful for package new and edit pages. Must be compatible with DGU theme.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1097#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1084</link>
        <guid isPermaLink="false">http://localhost/ticket/1084</guid>
        <title>#1084: ckan.net RDF links changed</title>
        <pubDate>Tue, 12 Apr 2011 13:58:37 GMT</pubDate>
        
        <dc:creator>wwaites</dc:creator>

        <description>&lt;p&gt;
need to make some changes for the links to semantic.ckan.net. it should use &lt;a class="ext-link" href="http://semantic.ckan.net/record/"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://semantic.ckan.net/record/&lt;/a&gt;&amp;lt;package_id&amp;gt; now
&lt;/p&gt;
&lt;p&gt;
append .rdf, .ttl, .nt, .dot, .json (even .html for an ugly table)  to taste (or just leave off the suffix and let content negotiation take care of it)
&lt;/p&gt;
&lt;p&gt;
the base url is changed, but it now uses id not name.
&lt;/p&gt;
&lt;p&gt;
see for example:
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;&lt;a class="ext-link" href="http://semantic.ckan.net/record/6058c017-607b-48d9-b3cd-72106ad96e33"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://semantic.ckan.net/record/6058c017-607b-48d9-b3cd-72106ad96e33&lt;/a&gt;
&lt;/li&gt;&lt;li&gt;&lt;a class="ext-link" href="http://semantic.ckan.net/record/6058c017-607b-48d9-b3cd-72106ad96e33.ttl"&gt;&lt;span class="icon"&gt;​&lt;/span&gt;http://semantic.ckan.net/record/6058c017-607b-48d9-b3cd-72106ad96e33.ttl&lt;/a&gt;
&lt;/li&gt;&lt;/ul&gt;</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1084#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/1098</link>
        <guid isPermaLink="false">http://localhost/ticket/1098</guid>
        <title>#1098: --ckan-migration tests not initialised correctly</title>
        <pubDate>Thu, 21 Apr 2011 09:15:36 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Only tests with failing --ckan-migration fail, due to authz not being initialised.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/1098#changelog</comments>
    </item><item>
        <link>http://localhost/ticket/829</link>
        <guid isPermaLink="false">http://localhost/ticket/829</guid>
        <title>#829: Admin CRUD broken</title>
        <pubDate>Thu, 25 Nov 2010 14:24:03 GMT</pubDate>
        
        <dc:creator>dread</dc:creator>

        <description>&lt;p&gt;
Browsing to the admin interface /admin (even logged in as a sysadmin) gives an exception.
&lt;/p&gt;
</description>
        <category>Results</category>
        <comments>http://localhost/ticket/829#changelog</comments>
    </item>
 </channel>
</rss>