{23} Trac comments (3729 matches)

Results (2101 - 2200 of 3729)

← 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 →
Ticket Posixtime Author Newvalue
#1221 1310556607000000 dread Other edge cases and error conditions do not work properly either. Fixed in cset:4737c86d1d81 for release 1.4.2.
#1222 1310556618000000 dread Fixed in cset:4737c86d1d81 for release 1.4.2.
#1223 1310573893000000 dread pudo did this in cset:1ab655b7b76a and cset:7a9c6b1060cf ready for release 1.4.2.
#1225 1310642407000000 dread Done in ckanext repo cset:70fb690a0769
#1226 1314029434000000 dread This appears to have gone away. No sign of it for two weeks on any OKF sites.
#1228 1311086612000000 dread Done in cset:88e47b68e42d for 1.4.3
#1229 1312191530000000 amercader Done, except for Revision related stuff, which probably overlaps with work being done by David Raznick.
#1229 1319639472000000 dread I found another direct use of the d.b. in the home controller.
#1229 1319645778000000 dread Replace code in home in cset:f19f9c5bec94 on default for release 1.5.1.
#1230 1311154142000000 kindly The standard way to add tables in a plugin has converged upon putting the tables in the iconfigurable plugin. This runs at the correct point for when the application runs normally. For testing however there are issues due to the tables potentially being dropped, especially for the sqlite case. The fix is to make sure the iconfigurables are run at the start of each set of tests, hence adding it to the ckan_nose_plugin. This is not pretty, but good enough. cset:8531b9fc1ee2
#1231 1315948921000000 rgrp @kindly: Does this fit in with current plans? If not suggest we close as invalid/wontfix or put into the backlog (though given lack of content not sure that is very useful ...)
#1231 1325474087000000 rgrp Closing as wontfix (or duplicate). We now have stats in footer as of #1576. googleanalytics (e.g. http://thedatahub.org/analytics/dataset/top) would be nice to have but should be part of stats
#1231 1325474447000000 rgrp See #1101 for other duplicate ...
#1232 1315948536000000 rgrp Removing from ckan-v1.5 as do not think any of this is top priority (correct me if I'm wrong!)
#1233 1315948668000000 rgrp Removing from v1.5 as not a priority atm.
#1234 1311183328000000 dread Fixed in cset:1ed3fde56a61 for 1.4.3.
#1236 1311351476000000 dread Working on it on branch enh-1236-view-package-revision
#1236 1311699843000000 dread This is merged to default (for rel 1.2.5) but isn't brilliant yet because of bug #1238.
#1236 1311759816000000 dread The bug is in fact in the way I work out what revision I'm displaying - it just looks at the PackageRevision.
#1236 1323090508000000 dread This feature is now released, but there is a remaining bug which I've put in this ticket: #1509
#1236 1330019788000000 dread Went into CKAN 1.4.3
#1238 1311583876000000 kindly I cannot reproduce this, to me it looks like it does get the correct revision. If you for example look at the package a millisecond before i.e http://ckan.net/package/osm%402010-11-30%2000%3A21%3A49.627829 the tags are no longer there that were added in that revision.
#1238 1311759784000000 dread Apologies, I have a problem instead with the way I identify the revision in #1236.
#1239 1311442163000000 rgrp Fixed in cset:adf254b7c507 (see https://bitbucket.org/okfn/ckan/changeset/adf254b7c507)
#1239 1312453156000000 dread Fixed in 1.4.2 release. Broken in UI in 1.4.1 and API in 1.4 & 1.4.1.
#1240 1314180488000000 dread I basically agree, but just thought I'd add a couple of comments into the mix. > GET at root returns whole package set (a *bad* idea) Sure it has a cost, but I don't see what the problem with this is if the list is cached. Forcing developers to paging through the list of packages is putting unnecessary obligations. I'd say that the top two RESTful operations are listing objects and getting a particular one, and you'd be taking away one of those. > Unify on /api/v{version num}/... structure Where is it not currently unified?
#1240 1316022145000000 rgrp add autocomplete
#1240 1324319119000000 rgrp assigning to kindly for review
#1240 1324320107000000 dread Although I'm generally in favour of Action API over RESTful, Action API does need some sorting out wrt listing methods, advertising what params are allowed and checking those that are passed. Using the Action API is so hard without reading the code! The RESTful API is handy when you want to do something quickly in a browser. I'd not want to lose these two, for example: * to look at a package /api/rest/dataset/xyz * API version etc. at /api/util/status (coming with ckan 1.5.2) It's also really handy in demos and to send as links to people on the list.
#1240 1325473312000000 rgrp IMO this is non-urgent and can move out of v1.6 as we have enough more important stuff to do.
#1242 1323173292000000 thejimmyg This text is no longer present on the login page.
#1243 1328000405000000 rgrp invalid as things have changed and this has been fixed or obsoleted.
#1244 1323089995000000 dread No progress yet
#1245 1311864530000000 annapowellsmith Would be nice to list some extensions somewhere on this site (features page perhaps). Along the lines of: http://docs.ckan.org/extensions.html#finding-extensions It wasn't until I wrote this list that I realised just how many extensions there were, and what it said about the CKAN community that there were so many... So I think it would be a good sales point.
#1245 1317422640000000 rgrp Closing as now mostly done and not really a ticket item.
#1246 1311863583000000 dread We have an unresolved issue with the display of the 'open data' icon that showed up when we upgraded ckan.net to the latest beta last week, but I didn't realise the search page http://ckan.net/package was showing all packages as open (the revision page and package pages seem fine). Last week when I upgraded from 1.4.1 to 1.4.2beta, there was an exception thrown when loading the home page. The exception was in doing the isopen call. It was solved by making some code changes directly on the ckan.net server to make it an attribute query instead of function call. It was strange because this behaviour didn't occur on my machine and all the tests passed. Here are the manual patches on ckan.net (the application.js change is unrelated, by someone else): {{{ diff -r adf254b7c507 ckan/public/scripts/application.js --- a/ckan/public/scripts/application.js Sat Jul 23 18:16:15 2011 +0100 +++ b/ckan/public/scripts/application.js Thu Jul 28 14:10:23 2011 +0000 @@ -2,6 +2,7 @@ $(document).ready(function () { CKAN.Utils.setupUserAutocomplete($('input.autocomplete-user')); CKAN.Utils.setupAuthzGroupAutocomplete($('input.autocomplete-authzgroup')); + // $('.resource-url').parent( }); }(jQuery)); diff -r adf254b7c507 ckan/templates/_util.html --- a/ckan/templates/_util.html Sat Jul 23 18:16:15 2011 +0100 +++ b/ckan/templates/_util.html Thu Jul 28 14:10:23 2011 +0000 @@ -43,7 +43,7 @@ standard package listing --> <ul py:def="package_list(packages)" class="packages"> <li py:for="package in packages" - class="${'fullyopen' if (package.isopen() and package.resources) else None}"> + class="${'fullyopen' if (package.isopen and package.resources) else None}"> <div class="header"> <span class="title"> ${h.link_to(package.title or package.name, h.url_for(controller='package', action='read', id=package.name))} @@ -60,7 +60,7 @@ </ul> </py:if> <ul class="openness"> - <py:if test="package.isopen()"> + <py:if test="package.isopen"> <li> <a href="http://opendefinition.org/okd/" title="This package satisfies the Open Definition."> <img src="http://assets.okfn.org/images/ok_buttons/od_80x15_blue.png" alt="[Open Data]" /> @@ -72,7 +72,7 @@ </a> </li> </py:if> - <py:if test="not package.isopen()"> + <py:if test="not package.isopen"> <li> <span class="closed"> ${h.icon('lock')} Not Openly Licensed diff -r adf254b7c507 ckan/templates/home/index.html --- a/ckan/templates/home/index.html Sat Jul 23 18:16:15 2011 +0100 +++ b/ckan/templates/home/index.html Thu Jul 28 14:10:23 2011 +0000 @@ -64,6 +64,7 @@ </py:if> <h4>Recently changed packages</h4> + <!-- ${c.latest_packages} --> ${package_list_from_dict(c.latest_packages)} <p><a href="${h.url_for(controller='revision', action='index', diff -r adf254b7c507 ckan/templates/layout_base.html --- a/ckan/templates/layout_base.html Sat Jul 23 18:16:15 2011 +0100 +++ b/ckan/templates/layout_base.html Thu Jul 28 14:10:23 2011 +0000 @@ -101,6 +101,7 @@ am_authorized_package_create = h.am_authorized(c, actions.PACKAGE_CREATE) ?> <li py:if="am_authorized_package_create">${h.nav_link(c, _('Add a package'), controller='package', action='new', id=None)}</li> + <li><a href="/storage/upload">Upload Data</a></li> <li>${h.nav_link(c, _('Tags'), controller='tag', action='index', id=None)}</li> <li>${h.nav_link(c, _('Groups'), controller='group', action='index', id=None, highlight_actions = 'new index')}</li> <li>${h.nav_link(c, _('About'), controller='home', action='about', id=None)}</li> diff -r adf254b7c507 ckan/templates/package/read.html --- a/ckan/templates/package/read.html Sat Jul 23 18:16:15 2011 +0100 +++ b/ckan/templates/package/read.html Thu Jul 28 14:10:23 2011 +0000 @@ -56,7 +56,7 @@ </py:if> <li class="widget-container widget_text"> - <py:if test="c.pkg.isopen() and c.pkg.resources"> + <py:if test="c.pkg.isopen and c.pkg.resources"> <h3> This Package is Open </h3> @@ -80,7 +80,7 @@ </p> </py:if> - <py:if test="not(c.pkg.isopen() and c.pkg.resources)"> + <py:if test="not(c.pkg.isopen and c.pkg.resources)"> <h3 i18n:msg="">This package is Not Open</h3> <p>Either because it is not openly licensed or is missing }}}
#1246 1311885360000000 pudo I'm afraid to say I don't understand any of this: the faulty display of openness is triggered as removing the brackets turns the isopen() check into a check for the existence of the method. Reverting the changes on the server seems to work without generating exceptions. What exactly is the issue that was supposed to be fixed originally?
#1247 1311955176000000 rgrp Done. See http://ckan.readthedocs.org/ and http://docs.ckan.org/ will propagate soon.
#1248 1319797763000000 dread Fixed in cset:188d27a56c89c35f97f3a79fdd0a6460223f86cf on branch release-v1.4.3. This was only seen in CKAN 1.4.3beta.
#1249 1311959356000000 pudo fixed in cset:0398243111d4
#1250 1312370201000000 pudo The issue is caused after search returns from solr and tries to get objects from the database. These are by default ordered by name and we need to restore the original order after fetching them from the database. Fixed in module.
#1251 1314406332000000 rgrp Really non-urgent and can be done once #1252 is done (which is dependent on v1.5)
#1251 1317315159000000 dread rgrp did this last weekend.
#1252 1314406271000000 rgrp Move to v1.5 since this will coincide with release.
#1252 1316876747000000 rgrp Announced. thedatahub.org now running for 2+ months. Today did wiki.ckan.net redirect and hope to do thedatahub.org redirect.
#1252 1317315135000000 dread This is done now?
#1252 1318160334000000 rgrp This was done ~2 weeks ago.
#1256 1312409296000000 kindly This has also caused problems in authorization for deleted packages.
#1256 1312813529000000 kindly fixed cset:357cf9377b25
#1256 1319812556000000 dread It sounds like this became an issue with CKAN 1.4.3 and the fix goes into CKAN 1.5.
#1258 1312813614000000 kindly cset:e22d4e385fc8
#1258 1319812452000000 dread I believe this was broken with the introduction of moderated edits in CKAN 1.4.3 and this fix went into 1.5.
#1262 1314029150000000 dread Pudo - I'm not sure what's meant here. Are you talking about moderation for new users? Or some other sort of enforcement? Is it spam you want to target? The links you're concerned about - are they the spam ones in the User's 'about' field? If so, I think we *should* allow users to have links, although continue with applying them with 'nofollow' and attack spammers back in a concerted strategy across all editable fields - see ticket #1257.
#1263 1314029279000000 dread This was fixed in cset:8d293393a9f2 for release 1.4.3.
#1264 1314406294000000 rgrp Nothing urgent about this so moving to backlog.
#1264 1318244619000000 zephod Created #1377 to handle bugs revealed while doing this work.
#1264 1318245716000000 zephod Complete; cset:b216952644aa
#1265 1312566052000000 dread Fixed in cset:a1b8dd169f4e on 1.4.3 release and merged to default.
#1266 1312797477000000 dread Fixed in 987dc4fe078e on 1.4.3 branch and default.
#1267 1312889130000000 dread John thinks it is a problem with WebOb 1.0.6
#1267 1312890962000000 dread This error has been occurring on at.ckan.net which has webob 0.9.7.1-1
#1267 1312894071000000 dread Running tests with WebOb 0.9.7.1, we see the error! Am now trying to fix.
#1267 1312897724000000 dread Fixed in cset:db5bf5b45b4f for ckan 1.4.3. Later versions of webob add the charset header for unicode errors (webob/exc.py:generate_response): {{{ extra_kw = {} if isinstance(body, unicode): extra_kw.update(charset='utf-8') resp = Response(body, status=self.status, headerlist=headerlist, content_type=content_type, **extra_kw ) }}} This was fixed in webob cset:25fc14d49623 which went into WebOb 1.0. This problem affects versions from CKAN 1.4.2 back to 1.3.1. We had been avoiding this in CKAN previously by only doing abort() with a plain string.
#1268 1317212499000000 kindly fixed cset:eebbe6071741
#1270 1312912188000000 dread Fixed in cset:ca5295c9c8cf and released as ckanclient version 0.9
#1271 1313753663000000 rgrp Closed in cset:749cb3a087e3
#1272 1313745867000000 rgrp Assume these are the 3 spatial fields listed on http://wiki.ckan.net/Geospatial_Capabilities. I'm a big +1 here. Starting point would be a bit more documentation on that wiki page. Questions: * Is this work going in ckanext-spatial? * What is being proposed here, I assume, is to automatically index those fields in our geospatial search. * Should we develop a simple display widget using google maps or similar (this is orthogonal to the WMS preview i think) which *just* uses the core fields. This is probably a separate ticket and possibly separate from ckanext-spatial extension.
#1275 1314110016000000 johnglover Completed in branch feature-1275-solr-search. Up to date with current default but not yet merged into default. John
#1275 1319812967000000 dread Going into release 1.5.
#1276 1314886010000000 johnglover Added to branch feature-1275-solr-search Don't seem to be able to apply weighting to fields at index time using solrpy (see open issue: http://code.google.com/p/solrpy/issues/detail?id=6). So, switched to using the newer Solr edismax query parser and have applied weights to fields at search time. Current weights are as follows: name: 4 title: 4 group: 2 tag: 2 text (everything else): 1
#1276 1315948394000000 rgrp Closing since done (though not yet in main!)
#1277 1314868204000000 johnglover Done in branch feature-1275-solr-search for all package searches (which use Solr). Resource and Tag searches still use the old ckan query parser.
#1277 1315297186000000 rgrp This just requires merging into main but has been deferred as once solr branch is merged solr is *required* to run CKAN at all (we are thinking of having basic support for sqlite/dbs out of the box ...)
#1277 1315948417000000 rgrp Closing since done (though still need to merge into default)
#1279 1314303732000000 rgrp Wow, that's a pretty big omission. authz groups are important and are used. I think we should discuss this in next planning meeting.
#1279 1314304326000000 rgrp In addition it appears that authz group was left out of the form refactoring so new and edit page use old formalchemy stuff. Should fix this.
#1279 1338212028000000 ross Duplicate of #2366
#1280 1328786670000000 dread David tells me that this was fixed in CKAN when we moved to SQLAlchemy 0.7 #1433 which went into CKAN 1.5.1.
#1281 1314021919000000 dread Done by pudo in cset:eaf342823caf on default branch, so headed for release 1.4.4. "Work around the fact that locale changes do not affect the running request and therefore led to an incorrect flashing message. Now manually changing language."
#1282 1314404540000000 rgrp Done in cset:4b6838a820bb. Have not done either of the optional items. JS testing for what we have is relatively hard and of dubious value. Re CDN stuff requires work and of doubtful of immediate value since can just configure cache or main site to serve static stuff directly. (Likely more value from compressing js and css ...).
#1283 1326720891000000 dread Since we switched completely to SOLR, this has been true. SOLR doesn't index deleted packages so you can't search them, but they can be read/edited by admins.
#1283 1330083933000000 dread This went into CKAN 1.6
#1284 1315212258000000 dread Fixed by rgrp in cset:1952445d2802 on release-v1.4.3 and default. Comment: do not create revision for changes to users as they are not revisioned. * This had already been removed in cset:8d6fde0e2196 (then in user controller) but Adria seems to have reinstated this when refactoring things into the logic layer. This 'bug' explains the huge number of empty revisions we have been seeing on ckan.net.
#1284 1315212603000000 dread I've added tests for this (to prevent yet another regression!) in cset:1b77ce8ce560. Closing.
#1284 1315214358000000 rgrp I'm not sure this is the sort of thing we need tests for (we can have too many tests!). Something worse discussing ...
#1284 1315215626000000 dread Really? How many times do you want to fix this bug again? For the sake of three lines of test...
#1285 1314269414000000 dread Another instance is when the database tables are not created and you want to both display a sensible error and have an email alert. #1290
#1285 1323173125000000 thejimmyg I could write some middleware to handle this. Can we come up with a list of exceptions not to catch or should I create a base exception called "NoEmailReportTriggeredException()" which exceptions for this purpose have to be derived from or which code has to raise?
#1285 1323178678000000 dread Isn't the point is we don't to raise an exception at all - we want to call a method to send the email and then return from the controller a normal html page. Don't we just need a method to get the error email address from the config and send an email.
#1286 1342436420000000 dread This can happen now, if it hasn't already.
#1289 1317315211000000 dread Discussions have not resolved this either way. Decided to leave it like it is for now.
#1290 1314270894000000 dread Improved on option 2. For requests to Home controller, the first thing it does is check the user. I catch SQL errors that are to do with missing tables and that now produces a template-less error saying the site is off-line and then mentions database initialisation. Done in cset:484e50c4f989 on default for ckan 1.4.4.
#1291 1315948475000000 rgrp @kindly: is this not done? (I know there is more work to be done here but though table creation was done ...). If not need to move to next milestone so we can close this one.
#1292 1315999202000000 dread <rgrp> i'm def +1 for removing API stuff entirely from i18n for the present
#1292 1320145677000000 dread Review process of releases and updating strings (pot) and translations (po) files c.f. http://lists.okfn.org/pipermail/ckan-dev/2011-May/000718.html http://wiki.ckan.net/Release_process updated with basic process Get language changing thing to get home page to mostly work - push to key strings translated (or don't advertise the translation?) Welcome message is translated in all languages. Most language have upped their percentage translated significantly and Swedish and Polish added as well. Review long list of strings for improvement Consolidate any? Get rid of i18n for strings in api About 50% of the strings are templates, 30% are in the logic layer and 20% are in the controllers. Removed a handful from ckan/lib/base.py that were only displayed in the api, but the logic layer ones are generally errors that can be displayed in the Web UI as well as the API, so not ideal to remove. Try and remove javascript Tom did this. Add in extensions This could be done. Have raised ticket #1292 for this, next release. #1374 Fix switching to en from other default language Done #1417 Fix browser language detection Done
#1292 1320145732000000 dread These fixes all went into release 1.5.
#1293 1314701675000000 johnglover == Changes == * All templates * Routing: /package/ -> /dataset/ (including API) * Tests: h.url_for(controller='dataset') rather than package ... * One test to check redirect works? * Docs == Leave == * Stay with Package in code e.g. stay with 'PackageController' * also leave stuff like pkg = .... (gradual migration) * Leave extensions == Notes == * Package -> Dataset * Data Package -> Dataset * respect capitalization
#1293 1314905799000000 johnglover Branch: feature-1293-rename-package-to-dataset Routing and test editing should be finished (all tests passings). Have not added test for redirect yet.
#1293 1315214527000000 rgrp Reassign for completion (templates and docs) as john is away.
#1293 1315246628000000 zephod cset:https://bitbucket.org/okfn/ckan/changeset/4a98589af6c1 Fixed
← 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 →
Note: See TracReports for help on using and creating reports.