{23} Trac comments (3729 matches)

Results (3301 - 3400 of 3729)

Ticket Posixtime Author Newvalue
#320 1279105983000000 dread site_title added in cset:b4c0e0a5630d site_logo is changeable in one place in the template so not essential
#317 1279005278000000 pudo this has been in for a while now but still needs to be extended to include the indexing of entities (ckan.model.search_index)
#356 1278931816000000 rgrp Done in cset:a1af5f8fe59e. Have not done advanced search link normal package search currently provides no info about how to use advanced features.
#274 1278700842000000 dread A significant chunk of the work towards this done in cset:742adebb707c (refactoring search options).
#336 1278700266000000 dread Took 0.75 days.
#336 1278700021000000 dread Done in cset:742adebb707c and cset:1748e6554e77.
#325 1278599979000000 dread Both sending and received tickets closed.
#324 1278599927000000 dread Done in changesets leading up to cset:ca565562129d.
#273 1278578527000000 dread rgrp: We plan to use SOLR. May investigate Xapian. Nothing more to do in this investigation.
#343 1277892699000000 johnbywater Okay, so in version 2, names were still being used in the relationships part of the packages entity. But I don't know why these entities can't be retrieved independently, and references to the entities returned in representations of the entities which reference them.
#343 1277824018000000 johnbywater Regarding the package search, if I do: $ paster db clean && paster db init && paster create-test-data and then: $ paster serve development.ini & and then: $ curl http://127.0.0.1:5000/api/1/search/package?name=warandpeace I get: {"count": 1, "results": ["warandpeace"]} and with: $ curl http://127.0.0.1:5000/api/2/search/package?name=warandpeace I get: {"count": 1, "results": ["c90b6c00-9496-4c8c-b7fa-7bdd3ef65c72"]} Am I missing something?
#349 1277820679000000 anonymous Mostly done, but issue regarding departments still outstanding: can the association between packages, groups, and departments be placed elsewhere?
#323 1277722845000000 dread Done but not pushed yet. Took 3.5 days.
#322 1277722821000000 dread Done but not pushed. Took 3.5 days.
#263 1277717180000000 rgrp I consistently get sent to google login even though I choose openid meaning I am unable to login!
#341 1277483030000000 dread Done in cset:c7a9ba55db0d on metastable and merged to default.
#344 1277477712000000 dread Done in cset:13737a7ba4d9
#357 1277461466000000 johnbywater Fixed in 79c426c0acb6.
#350 1277072822000000 [email protected] Also check out the SEO review done by Charles Coxhead - http://www.quicksitereviews.com/ckan-net/ Pagination – In the tag section of the site particularly I’d suggest replacing the traditional numbered pagination with alphabetical links, ie, display 26 links A-Z and then on each of those pages displaying the relevant tags. The point being that the tag pages represent an opportunity to index pages which intersect with very targeted search demand, so let’s give them all every opportunity to get crawled and indexed. Linking to all 26 alphabetically arranged pages from the main tag page (and maybe even the home page) will bring all the tag pages closer to the home page and give them all some more link popularity. Also suggest something similar to this for the listings in the Packages section, so arrange these on alphabetical pages. Tag page titles – Take a programmatic, but more focussed approach to these. Currently all tag pages have the title “CKAN – Comprehensive Knowledge Archive Network – Tags – [tag]” – I would make this something like “[tag] – Open Data – CKAN” or something like that which puts the emphasis on the tag keyword and adds some meaningful qualifiers to that. Tag page listings – On the tag pages there are related open data sets listed and next to each the associated tags. This leads to masses of tag links on the page and loads of duplicated links. If possible I recommend removing the tags from each data set listing, and instead displaying a cloud of “Related tags” on the right hand side. Group pages – The user curated group pages are possibly even better than the tag pages from a search perspective because they all intersect with very clear search demand, so would also benefit from having improved page titles. I suggest a similar approach to the above where the group name becomes the main keyword with some qualifiers added. It might even be a good idea to let group owners define their own page titles. Data set pages – These also could do with improved page titles, presumably the data set name, eg. “[data-set-name] – CKAN” Heading tags – not a big deal but I’m always in favor of using H tags strictly for headlines (rather than wrapping an H1 around the site logo for example).
#318 1276438907000000 wwaites I've updated ckanrdf to strip out datatypes and use this ll.url on external references so that should be sufficient to hold off talis. Still need to work particularly on validating dates though...
#318 1276438832000000 wwaites Also fyi, getting ll.url is done like so {{ pip install ll-xist }}}
#318 1276438793000000 wwaites Some good news, ll.url seems to take bad urls and make them into good urls. viz: {{{ In [1]: from ll import url In [2]: print url.URL("https://mqi.ic.nhs.uk/IndicatorDataView.aspx?query=NRLS%3&ref=3.02.16") ------> print(url.URL("https://mqi.ic.nhs.uk/IndicatorDataView.aspx?query=NRLS%3&ref=3.02.16")) /Users/ww/Work/OKF/ckanrdf/lib/python2.6/site-packages/ll/url.py:2358: UserWarning: truncated escape at position 4 value = _unescape(namevalue[1].replace("+", " ")) https://mqi.ic.nhs.uk/IndicatorDataView.aspx?query=NRLS%253&ref=3%2E02%2E16 }}}
#342 1276278485000000 dread Done in cset:61f145b7d4a8
#318 1276271343000000 wwaites url validation reputed to be here: http://www.livinglogic.de/Python/url/Howto.html
#335 1276179605000000 dread On discussion with rgrp it's clear that it's also useful to set the redirect url in a config variable - then the client doesn't have to change. This was done in cset:b9fdd208dd45
#336 1276162601000000 dread
#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.
#340 1276010234000000 dread Done in cset:f77639ddcf0d
#335 1275997752000000 dread Done in cset:5c0c0b6e1342
#315 1275846764000000 dread Fixed in cset:61548ced8b7d - Quote marks correctly read in for data4nr data, which makes this problem record ok (which opened in openoffice fine incidentally). Fields in package are now dumped in correct order to make it clearer. Not changed resource serialisation - if you want tidy json, then use the json dump. No real call for half-way house dump.
#128 1275694573000000 Floallgloli Futures Trading Key your Futures education provider Learn how to trade futures with live trading education Futures education and trading free trial live on line room <a href=http://www.futurestradingkey.com><B>Futures</B></a>
#333 1275407987000000 dread Use case 1: decided that when the user is redirected back to the front-end system, the URL contains a parameter with the package just edited. (In addition to the notification message.) Use case 2: decided that if the load on the front-end is not high from 100 non-web requests. Should it become a problem in future, the queue consumer could be adapted to slow down / amalgate multiple requests.
#313 1275404524000000 johnbywater Fixed in changeset 06c949266644.
#318 1275320677000000 dread We can't change any of the metadata without permission from the various departments who supplied it. I think "Don't shoot the messenger" is apt here. Adding this to the form validation isn't going to change any of the existing data. I think this is better off in the data quality scoring.
#328 1275318745000000 dread Done in cset:170cac0b50ac and uploaded to kforge.
#332 1275306933000000 dread Switched from YUI a couple of months ago.
#330 1275303122000000 dread Fixed in cset:2f18d0e661fd on metastable and default branches.
#308 1275302577000000 rgrp Duplicate of ticket:234.
#329 1275079189000000 dread Fixed in cset:d264f9d57477 and cset:07701ef4085e
#301 1274832112000000 tim Duplicate of #190, although that ticket has a different implementation. It prefers comments as blog comments.
#324 1274807970000000 pudo I am currently writing a Solr subclass for the search index (#317) and would propose adding standard methods to the ckan.libn.search.Search class: index_package(), index_tag(), index_group(). Those could then be called by a generic queue consumer, irrespective of the used search back-end. I will prototype such a consumer soon, so we should talk to avoid doing some duplicate work here.
#322 1274807530000000 pudo Replying to [comment:2 pudo]: > This looks very reasonable. Maybe we should have a webhooks client as a simple demo for this? c.f. #327
#326 1274789296000000 dread Done in cset:66c21d78d2f8. Took 20mins.
#322 1274773856000000 pudo This looks very reasonable. Maybe we should have a webhooks client as a simple demo for this?
#318 1274377385000000 wwaites Some more datapoints from Leigh Dodds of Talis: I'm still having no joy with this I'm afraid. I'm test parsing the data locally using the TDB command-line tools, specifically tdbcheck which will parse the data and generate warnings/exceptions. This uses the same parsing code, data and URI validation code as we're using on the Platform. Currently its giving me warnings for invalid lexical values for dates, e.g: Lexical not valid for datatype: "2008"^^http://www.w3.org/2001/XMLSchema#date While these aren't a major issue, looking at some of the data suggests that there are more underlying data problems that need checking and fixing up, e.g: Lexical not valid for datatype: "n/a"^^http://www.w3.org/2001/XMLSchema#date Lexical not valid for datatype: "27/04/2006 13:56"^^http://www.w3.org/2001/XMLSchema#date Lexical not valid for datatype: "Real time calculation"^^http://www.w3.org/2001/XMLSchema#date Lexical not valid for datatype: "varies by country"^^http://www.w3.org/2001/XMLSchema#date And there are still some invalid URIs, e.g: <https://mqi.ic.nhs.uk/IndicatorDataView.aspx?query=NRLS%3&ref=3.02.16> Code: 30/ILLEGAL_PERCENT_ENCODING in QUERY: The host component a percent occurred without two following hexadecimal digits. Can I suggest you try running the converted data through tdbcheck to iron out any problems? Then I can push it into the Platform.
#319 1274366882000000 dread Fixed in cset:a1ef783d27d2 on default and metastable.
#316 1274366801000000 dread This exception occurs for ckan.net with just this one character: http://ckan.net/package/search?q=%C2 (you can wget it) But I can't recreate it on my machine. Maybe it's a version issue. The client that is making all these crazy calls is googlebot.
#311 1274282065000000 rgrp Resolved (sort of) in cset:489007a10bb9. This was a migration issue. Tracked this down to fact that on ckan.net we have: "package_resource_revision_pkey" PRIMARY KEY, btree (id) When it should be: "package_resource_revision_pkey" PRIMARY KEY, btree (id, revision_id) Looking in browser:ckan/migration/versions/012_add_resources.py find: {{{ Column('revision_id', UnicodeText, ForeignKey('revision.id')), #NB revision_id should have been primary_key too (joint with id) }}} How come this was not corrected here or at least noted for upgrade of ckan.net??? I have now fixed this so that others doing migration (at least with v1.0) will end up with correct code. I have also fixed issue on ckan.net by manual sql!
#291 1273254895000000 dread This seems spurious. The options.q is unicode finds foreign characters fine. The hack has since been taken out.
#132 1273254514000000 dread This was fixed before and now works.
#227 1273254223000000 dread The pagination issue was corrected a while ago. The inconsistency of page titles needs looking at still.
#133 1273253977000000 dread WUI and REST interfaces recently updated. You can't read, list or search for packages or groups not-authorised for. The only remaining view of a non-authorised group is that the group is named when viewing a package using all_fields option in REST interface. But no details of other packages in the group are given.
#226 1273247829000000 dread Lots of excellent suggestions here.
#223 1273247748000000 dread Tag cloud is already on the front page. The consolidation of browse and search of tags has already been done.
#263 1273155234000000 rgrp OK, I think we're agreeing to close this now since reasonable and not worth the switch to anything different atm. Still concerned about usability but if necessary we can open a new ticket.
#263 1273136715000000 dread Replying to [comment:4 rgrp]: > I also do not understand how I can login using my own openid e.g. one not provided by any of those providers (at least not directly ...): by default no box is showing and to make one appear I have to click on a specific provider (with unknown results if i then enter something). I found it pretty obvious to login using openid - clicking on the 'openid' box made sense. The input box may serve to confuse the majority who login via Yahoo/Gmail. I don't think it's worth changing AGAIN.
#263 1273135032000000 rgrp Sorry, I meant this plugin: http://jvance.com/pages/JQueryOpenIDPlugin.xhtml I also do not understand how I can login using my own openid e.g. one not provided by any of those providers (at least not directly ...): by default no box is showing and to make one appear I have to click on a specific provider (with unknown results if i then enter something). Basically, I think this plugin is poor because it does not offer me a login box by default (as the other plugin seems to ...). What we really want is a simple login box with autocomplete based on provider like the civirm example!
#263 1273083179000000 johnbywater 1. Have suspended cookie setting (which was remembering the provider). 2. We are already using openid-selector. 3. Fixed type in page ('indentity' => 'identity') 4. Have changed 'sign in or create new account' to 'Login to CKAN using Open ID'
#233 1273080345000000 rgrp Done in cset:75756e565b6a
#59 1273080019000000 johnbywater All points in comment:5 have been implemented.
#233 1273078975000000 rgrp Introduction option 1.
#263 1273072985000000 rgrp Issue where if you click on google or yahoo seems to "remember" login so next time you click on google or yahoo item it takes you to what you clicked on previously (e.g. click on google then go back and click on yahoo and you are taken to google login). Also think this plugin may be nicer: http://code.google.com/p/openid-selector/ Also: * typo in page (indentity) * Not sure "sign in or create new account" is clear without some indication of how openid works e.g. better to say something like: "Login to CKAN using Open ID"
#216 1273050561000000 rgrp Closing. Everything done except for item 4: "autocomplete package names & tags" which I'm not sure needs doing and certainly won't be done any time soon. Have created a new ticket for this: ticket:308
#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!).
#276 1272996237000000 dread Fixed in cset:060e2df72148
#305 1272994804000000 rgrp Closed in cset:8136e7369c0c
#303 1272988619000000 dread Done in cset:dc99df3ab4bd cset:beb72a0aa810 cset:96bab1eb53f5 and vdm cset:bb9f97b1c4b0
#267 1272960518000000 rgrp Fixed in cset:9e2e66cced90/vdm
#303 1272912573000000 dread Package history page now shows revisions for tag, extra and resources. Needs tidying up and adding to REST. Done in cset:dc99df3ab4bd
#59 1272468398000000 rgrp Think we should resolve this by: * Removing guide page. * Putting a link to ckan user guide (http://wiki.okfn.org/ckan/doc/) in RHS sidebox on front page along with other links ... -- can this link url be made a config option in ini (defaulted to that url on load in lib/base.py or wherever it is loaded) * Move current content of guide (one item about bookmarklet) to http://wiki.okfn.org/ckan/doc/faq/
#303 1272454025000000 johnbywater We could also fix up the temporal model.
#302 1272453821000000 johnbywater Fixed in 61c8b3107f0e.
#279 1272451384000000 johnbywater Fixed in 5b6029c72f9a.
#304 1272447296000000 johnbywater Fixed in c4bf92996b8a.
#264 1272390013000000 dread Mainly sorted in ticket:292. Also related changes in cset:ed4c500fcd90
#295 1272384758000000 dread Done in cset:18edc4d95f2f. Took: 3h
#300 1272384474000000 dread Rufus fixed this in cset:e6e3
#240 1272383770000000 johnbywater Fixed in revision 5567025e6d5e.
#292 1272286005000000 dread Achieved in cset:56b02fda195e (rgrp), cset:95498407d15e and cset:f5af59a3365c. Remaining broken test put in ticket:300.
#271 1272280005000000 johnbywater Initial spike solution has been written, covering four user stories: 1. Commit CKAN revisions to changeset system (#296) 2. Update CKAN repository from changeset system (#297) 3. Pull changesets from remote CKAN instance (#298) 4. Merge diverging lines of changesets (#299) Emails to ckan-discuss include: * http://lists.okfn.org/pipermail/ckan-discuss/2010-March/000109.html * http://lists.okfn.org/pipermail/ckan-discuss/2010-March/000154.html
#276 1272276020000000 dread Estimate: 0.5day
#156 1271962871000000 johnbywater Fixed by encoding elements before and decoding elements after passing text through Markdown engine.
#293 1271940083000000 johnbywater With the metastable revision of CKAN, the package resource data structure in ckanclient scripts must have all four keys set in the Resource-Dict. Setting 'hash' in the resource data cures this issues with "metastable". The "bad" code was: resources.append((res['url'], res['format'], res['description'], res['hash'])) KeyError: 'hash' This code was adjusted in revision 40c4fe04038d, to default unspecified resource attributes to the empty string. It was changed further in subsequent revisions, to use parameters of the Package.add_resource method to default unspecified values. However, the API doc doesn't mention the resource hash, although it is required, but I just fixed that in the source (in revision 0f20bfb45d13). http://knowledgeforge.net/ckan/doc/ckan/api.html
#293 1271885457000000 johnbywater Can't reproduce this exception. Have added tests covering adding, removing and updating resources, and it all seems to work.
#272 1271764003000000 dread Package feed done in ticket:255
#155 1271760041000000 rgrp Duplicate of ticket:295
#221 1271756757000000 dread * Ability to add the package to groups on this page. MOVED to ticket:295 * Fields could be grouped. DONE * Inconsistent capitalisation (Url -> URL). DONE * Tag editor YUI script appears to break occasionally. DONE * Perhaps move to two column forms to save vertical space? IGNORE * Notes field to monospace? IGNORE * Extras fields need some jQuery love -- shouldn't have a fixed number available. MOVED into ticket:294 * Typography is a bit of a mess. DONE
#263 1271690219000000 johnbywater All seems to work. Reported Wordpress trouble may result from user having Wordpress account, but no blog (ie they have 'myname' login, but haven't got a 'myname.wordpress.com' blog. Having the blog makes it work (otherwise you get told that you aren't the owner of the identity).
#164 1271251422000000 rgrp This is done in semantic.ckan.net. Docs at http://wiki.okfn.org/ckan/doc/rdf/
#276 1271250866000000 dread I could not recreate this. I think it is only for particular packages?
#207 1271250740000000 dread This was done in forms branch - merge: cset:c22854a52319
#289 1271249368000000 dread Done in cset:bf98b63331cf
#244 1271248968000000 dread This has been fixed by Benoit (backed out changes, waiting for upgrades to babel / genshi)
#247 1271248813000000 dread Done in cset:36c2c01a480c
#288 1271173777000000 dread Fixed in cset:ad64bd0f6073
#280 1271173769000000 dread Fixed on default in cset:ad64bd0f6073
#278 1271173752000000 dread Fixed in cset:ad64bd0f6073 - copes with spaces now.
#287 1270801210000000 dread Done in cset:76560fa09db8 through cset:ea397fc03587
#248 1270745304000000 dread Done in cset:193280d51050. Cost: 0.8 days
#281 1270723675000000 dread Done in cset:5e9f8ce150c2
Note: See TracReports for help on using and creating reports.