{23} Trac comments (3729 matches)

Results (3401 - 3500 of 3729)

← 25 26 27 28 29 30 31 32 33 34 35 36 37 38 →
Ticket Posixtime Author Newvalue
#196 1265389771000000 dread In cset:7eadcdc94b3a package URI changed to: http://ckan.net/package/32000-naples-florida-businesses-kml This resolves to html or rdf+xml - see ticket:90
#195 1258585500000000 rgrp Easy for groups because simple secondary=m2m table setup in sqlalchemy (done in cset:9e17314583ce). For packages+tags was hard because PackageTag is versioned and therefore only get the package_tags relation to work with in mappers. Tried various methods but gave up (see cset:ea4a790e9db9 for details). My conclusion was that if you want the fields ordered let's just do it by hand with a dedicated attribute or method and added packages_ordered and tags_ordered attributes to Tag and Package respectively (cset:3d3c1025a311).
#194 1260456304000000 dread Judging by the logs, a great number of bots are hitting the star ratings. In cset:8985cd53f8e5 I've added a robots.txt as well as cli functions to reset star ratings.
#192 1261487668000000 dread Similar stuff is being done in ticket:204. Consider transferring this field into default package schema?
#192 1291733895000000 dread The gov form has had this for months.
#191 1305732285000000 dread Will's suggestion is to have "modified_since" param, just as we have for Revision Search. Maybe we don't need a range. 'Order by modification' should be on by default for queries with 'modified_since' param.
#191 1305732414000000 dread Do this after refactor #1129
#191 1305814900000000 dread Maybe allow searching by package creation date too? Suggestion from kindly: when indexing a package, have the search backend also store the metadata_modified value, to make it easy to search on it.
#191 1322762567000000 dread So you can do this sort of search: {{{ curl http://thedatahub.org/api/action/package_search -d '{"q": "groups:lodcloud", "sort": "metadata_modified asc"}' }}} but it doesn't work because solr doesn't store the metadata_modified field yet.
#191 1323171514000000 thejimmyg John will just check that the API version 3 does support modified after the new solr schema handled by Adria is in place.
#191 1323706210000000 johnglover working in current master and 1.5.1
#191 1323708844000000 dread A test for this would be great, and maybe add as an example in the search docs too?
#191 1323970011000000 dread Added a fix for the problems caused by the #1546 fix. SOLR indexing was excepting for new packages (tests such as ckan/tests/functional/api/model/test_package.py:TestPackagesUnversioned.test_entity_update_indexerror failed). The problem was (somehow) related to last_modified function using a new connection causing problems for the modified_metadata in finding the revision & package table entries created during the commit. Changeset: [release-v1.5.1c 2c595ae] and cherry picked to [origin/defect-191-modification-date f98a4b2]
#191 1323973116000000 dread I put the sort syntax example in the apiv3.rst table and moved the full curl example to http://wiki.ckan.org/Searching_CKAN I added tests for metadata_modified and prepared this branch for closure. Changeset: [origin/defect-191-modification-date bebf7a5] John, please review and close/merge if you think it is all ok.
#191 1324030875000000 johnglover Thanks for this David. This one in particular was causing me some grief: https://github.com/okfn/ckan/commit/f98a4b2a5f5013fa4aed475bd8b3237bb7847fcc Good spot. All looks good to me.
#191 1330020677000000 dread Went into CKAN 1.6
#191 1330020983000000 dread Replying to [comment:15 dread]: > Went into CKAN 1.6 Sorry, I meant 1.5.1
#190 1280686074000000 pudo This will be solved using an external plugin and the disqus service. A current test version of the external code is at: http://bitbucket.org/pudo/ckandisqus
#190 1280820852000000 pudo fixed as of cset:1389
#189 1259925111000000 dread All done in 5 days in: cset:5c7f0ebd728c cset:20374a1ee763 cset:02ce73aef595 cset:36eda4112f72 cset:dd285dd1b821 Also made relevant changes in importer, create-search-test-data and data4nr. It wasn't clear that download_url could be made a SA proxy, so instead put download_url proxy in the REST interface to maintain compatibility with existing clients.
#188 1264436473000000 dread Duplicate of ticket:219
#187 1258970509000000 dread Done in cset:af3cbf266750 and e70af291455e. Issues addressed: * tags ARE indexed * if tags are converted into lexemes but we also search on exact match. * name is split on dash when indexed by postgres. * weight name and title higher than other fields. Remaining issues: * natural language search doesn't do partial words, so search for 'gov' doesn't bring up 'government'. * previous search system not yet usable with a config file switch (for if we install on a db aside from postgres)
#187 1258970766000000 dread Cost: 16h
#186 1296341182000000 rgrp Now duplicate: * #877 - File upload in WUI: 2d * #878 - Integrate file upload with workflow around package resources: 3d
#185 1291830039000000 thejimmyg This is probably no longer necessary. I've implemented JavaScript to hide the help text and allow it to be revealed by clicking "More >". This makes the form look simpler without needing to hide actual fields.
#184 1266837414000000 dread This is done in cset:d2026bcf43f5 cset:ac7cf572cbf9 cset:51c6de2dc390 cset:58c660932fcf cset:dd9761591ffb
#183 1290604779000000 dread <[email protected]> You can see the top rated packages in the stats box. Actually not very useful at the moment - not much rating is going on.
#182 1270567116000000 rgrp Done as part of UI overhaul for v0.11 around xmas. Current openness icons seem good enough.
#181 1296339510000000 rgrp Uncertain we want to do this and rather overtaken by other events, see e.g. http://ckan.org/wiki/UIRedesignHome
#180 1263373715000000 rgrp Looked through jquery plugins and best I could find was this one: http://addywaddy.github.com/jquery.tagcloud.js/ (http://plugins.jquery.com/project/jquery_tagcloud)
#180 1264439377000000 dread Duplicate of ticket:223
#179 1257762996000000 dread Changeset was to solve 'deprecated' messages. See line 46 ff. of changeset.
#179 1258392697000000 dread Done in cset:76e6cd49e503
#179 1258392723000000 dread Cost: 1.5 h
#178 1257439349000000 dread First batch of changes for this in cset:b5ef888e44b6. Works in basic way.
#178 1257523544000000 dread Second batch of changes in cset:7d524a92d602. Status: You can import new packages with all package properties using Excel or CSV format. Outstanding: * Validation is displayed poorly. * Overwriting existing packages is warned about, but doesn't work. * Can't add packages to group yet. * Functional tests are only working for the basic case. * Need to centralise package rendering for package controller. Time spent: 13hrs
#178 1257523596000000 dread Expect 1d to finish outstanding features.
#178 1257523668000000 dread Time spent (correction): 20h
#177 1273050236000000 rgrp Not really relevant to this trac (as outside of CKAN scope) and is duplicate of http://knowledgeforge.net/okfn/tasks/ticket/252 (which is now closed as well!).
#176 1257533003000000 rgrp My suggestion here is that this ticket get taken to okfn-discuss/okfn-help. This isn't a trivial issue. Do we go Debian (must exist in debian and to a name) or PyPI (very flexible, to name + version) route?
#176 1266928721000000 dread Covered in ticket:253
#175 1257780907000000 dread Migration requires quoting of table names 'user' and 'group' - need SA migrate v0.5.6.
#175 1257847996000000 dread Done in cset:78f04724b875 Cost: 6.5h
#174 1256650986000000 dread Fixed in cset:d13bfdb99282
#173 1258543707000000 dread Done in cset:05b1a12c5e71 Cost: 8.25h but only basic fields. e.g. extras not covered, license is not pretty.
#172 1256495095000000 rgrp Largely done in cset:f3782c1071cc
#172 1257532331000000 rgrp Done in cset mentioned previously. See: http://knowledgeforge.net/ckan/ckan/doc/
#171 1297210925000000 rgrp A lot of work on config was done in 0.7 and these refactorings and improvements either fix or render this ticket invalid so marking as fixed.
#170 1256572201000000 dread Done in cset:517d25bc56f3
#169 1266928708000000 dread Covered in ticket:253
#168 1257414795000000 dread Duplicate of ticket:145
#167 1256210109000000 dread Done in cset:7d129fc35e5c
#166 1256222093000000 dread Done in cset:bb7566d82b9f. Couldn't get logging going.
#165 1311181391000000 thejimmyg This is more than 6 months old so closing.
#164 1256056395000000 dread Done in cset:ab50a8ee0ba3
#164 1264875709000000 rgrp Reopen as now part of semantic.ckan.net
#164 1271251422000000 rgrp This is done in semantic.ckan.net. Docs at http://wiki.okfn.org/ckan/doc/rdf/
#163 1256140829000000 dread Basic facility to do it with CLI command done in cset:a4217353a7be Still need to make it regular.
#163 1257415333000000 dread Facility to do this, pulling packages out of ckan over REST, is here: ckan/lib/ckan-to-talis.py (cset:752f346b47c2) Currently not implementing a cron job to do this regularly.
#162 1256142462000000 dread Done in cset:429f2c89d4de
#161 1256114485000000 dread Yes, deleted tags are still listed and associated with a package.
#161 1257762932000000 dread Rufus says: Two issues: 1. search -- this has be done in internals ... 2. is: tag.packages attribute -- this is solved by using StatefulList
#161 1258381450000000 dread Cost: 4h with help from rgrp
#161 1258573607000000 rgrp Resolved in cset:6d466d8b702a
#160 1261399380000000 dread Done in 1h in cset:9c3e64104cbf. Not allowing space - non-standard.
#159 1256060264000000 dread Fixed in cset:e7ea5b97365e Note: no spaces allowed between search operator and the word associated with the operator. So with "tags: postcode" it was searching for a blank tag. I've made the change so that would ignore 'tags' in this case, producing reasonable search results for postcodes in all fields. postcodes. Cost: 1.5h
#158 1255949818000000 dread Done in cset:2aaaedff9d60
#157 1256062680000000 dread As far as I can tell this never worked in the past. Added in cset:f4ba0dcfb1a3 Cost: .65h
#156 1256145730000000 dread Done in cset:8a29d5351650
#156 1258981721000000 dread Looks like it was taking out a lot of stuff.
#156 1261399351000000 dread Sorted display of <links> by converting them to markdown format [links] (links) in cset:9c3e64104cbf
#156 1266348238000000 dread Example problem: http://ckan.net/package/patent-nber
#156 1267373651000000 dread Another example: http://www.ckan.net/package/dbtune
#156 1271962871000000 johnbywater Fixed by encoding elements before and decoding elements after passing text through Markdown engine.
#155 1255621836000000 dread Comments from rgrp: Very reasonable - and should not be too hard to do (bit of javascript and support at the backend ...)
#155 1271760041000000 rgrp Duplicate of ticket:295
#154 1255621856000000 dread Comment from rgrp: I don't think we have to prescribe one or the other.
#154 1257535066000000 rgrp Don't think anything obvious to fix at present (and perhaps plan a larger ticket on form customization).
#153 1255621895000000 dread Comment from rgrp: Yes, and want this for tags too -- this involves working out how to order joins in sqlalchemy (shouldn't be too hard).
#153 1258381364000000 dread Cost: 3h with help from rgrp
#153 1258971895000000 dread Duplicate of ticket:195
#152 1256056193000000 dread Done in: cset:f57dbb45418e - main work cset:78930cfd01b7 - not requiring values now.
#151 1257414545000000 dread Duplicate of ticket:175
#150 1256751974000000 dread Done in cset:4dcb28d339a3
#149 1257414916000000 dread Done in cset:4d6bfca98d97
#148 1255515222000000 dread Done in cset:4d6bfca98d97
#147 1255515162000000 dread Same as ticket:148
#146 1281002247000000 pudo After test hasn't reproduced it, let's wait for someone to notice this in production. We can analyze weberror then.
#146 1291829862000000 thejimmyg I've just tested this too and it works for me. Let's close this ticket.
#145 1255434248000000 dread Done in cset:d664c9caeb69.
#144 1257533957000000 rgrp But we don't record views ...
#144 1264439281000000 dread Duplicate of ticket:215
#143 1311181336000000 thejimmyg Baze is looking into this and also into most followed packages.
#142 1256417440000000 rgrp Might be interested here in auto-extracting a nickname from openid (or getting service to give it to us). This question is of relevance on this point: http://stackoverflow.com/questions/572939/extracting-a-username-from-an-openid-identity (though basic answer is "you can't").
#142 1276121257000000 [email protected] See also: http://stackoverflow.com/questions/1355292/friendly-name-from-google-using-openid Looks like Google has made this difficult intentionally.
#142 1289219069000000 pudo Fixed in cset:a3f713368bba pending release of repoze.who.openid==0.5.3
#141 1255007583000000 dread Decision made to put it in a section alongside REST docs at api/index. Search API docs already done in cset:5562b3e53977. Refactored in cset:a096132a6c6b
#140 1257535009000000 rgrp Not sure how useful this is atm
#139 1255188974000000 dread I didn't manage to create duplicate tags - must be the old code. I fixed this particular package in ckan.
#138 1258466054000000 dread Done in cset:bfbd0bb1b91d
← 25 26 27 28 29 30 31 32 33 34 35 36 37 38 →
Note: See TracReports for help on using and creating reports.