{23} Trac comments (3729 matches)

Results (2501 - 2600 of 3729)

← 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 →
Ticket Posixtime Author Newvalue
#1129 1305209601000000 rgrp Replying to [comment:2 rgrp]: > It seems like this ticket is getting a bit confused with ticket:1076 (changes re vdm) :-) I of course ;0 meant ticket:1077
#1307 1315247298000000 zephod Replying to [comment:2 zephod]: Oops: cset:cbd6677ec41e
#1737 1340015695000000 icmurray Replying to [comment:22 rgrp]: > But not v1.7.1? (When is v1.8 due?). Not 1.7.1 as it's not a bug fix (https://docs.google.com/document/d/170fxET3kd9dJ4L6VAj3yZugtK0rrVe44J4HuLbTUsEU/) I don't know when 1.8 is due. > > Also for the record a couple of things I found when trying to use this: > > * No support for facet sort order or facet limit afaict ... Thanks, that's good to know. facet.limit should be working [1], so if it's not, then that's a bug. I can check that. for facet.sort, I've added ticket #2543 [1] https://github.com/okfn/ckan/blob/master/ckan/logic/action/get.py#L1022
#1737 1340112732000000 icmurray Replying to [comment:23 icmurray]: > > > > Also for the record a couple of things I found when trying to use this: > > > > * No support for facet sort order or facet limit afaict ... > > Thanks, that's good to know. > > facet.limit should be working [1], so if it's not, then that's a bug. I can check that. facet.limit is working as I'd expect. eg (on master): {{{ import requests import json from pprint import pprint as pp pp(json.loads(requests.get('http://ian-laptop:5000/api/3/action/package_search?q=data&facet.field=tags&facet.limit=1').content)) }}} Returns a result where only the tag with the highest count is returned in the search_facets result dict. One thing I did spot though was that we aren't able to specify per-field parameters. ie whilst `facet.limit` sets the facet limit for ''all'' facet fields, solr allows that to be overridden on a per-field basis, eg `facet.tags.limit`. This isn't something we support at the moment. I've created a ticket for this, #2573 . Let me know if this something that you'd find useful, otherwise I'll leave it on the backlog for a future iteration.
#1214 1310054305000000 aron Replying to [comment:3 dread]: > "Tag returned as a JSON object when updating but as a string when requesting." > I'm not sure what you mean. > > http://test.ckan.net/api/2/rest/package/reference-example > gives tags: {{{"tags": ["country-uk", "example-package"],}}} I'm getting back objects for each tag in the response body from a PUT request. For example "country-uk" would be something like. {{{ { "id" : "600dc72e-6127-4704-b801-bee00474ec0c", "name" : "country-uk", "revision_timestamp" : "2011-07-06T09:09:21.578034", "state" : "active" } }}} Hopefully this gist <https://gist.github.com/97447d0b28bf52f3e06b> will illustrate the issue. > Is it this - returning package names, rather than ids? Here is certainly a bug I'll fix. > http://test.ckan.net/api/2/rest/tag/country-uk That was the fifth point on the list.
#2330 1336387328000000 icmurray Replying to [comment:3 icmurray]: > > or, for cases where a more complex data_dict is required, the data_dict can be parsed as a json-encoded dict in a single url-parameter called ``data_dict``, ie: > > {{{ > curl http://127.0.0.1:5000/api/3/action/package_search?data_dict={'q':'police'} > }}} > Another option is to have the data_dict json-encoded in the GET request's body. This is possible, but 1) Although permissable, it's not, as I understand it, conventional to have a GET request's body form the options of the request. 2) Caching proxies won't inspect the body of the request, only the URL.
#235 1340627624000000 icmurray Replying to [comment:3 icmurray]: > Moved to ckan-future and unassign so that this ticket will be picked up in triage. Sorry, this comment bears no resemblemnce to what I actually did! Assigned to tobes for 1.9.
#275 1280999963000000 pudo Replying to [comment:3 pudo]: > cset:1396 fixes this Where "this" is the field renderer.
#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.
#1214 1310054863000000 aron Replying to [comment:5 dread]: > Deleting an extra using 'null' works for me: Hmm, it works for me too when there are other keys remaining in the "extras" object. However I can't seem to delete the last one. Take the following example. {{{ curl -i -XPUT -d'{"extras": {"Tester": null}}' -H"X-CKAN-Type: application/json" http://test.ckan.net:80/api/2/rest/package/ec9cb930-d15f-441f-a1e1-36f4d5df19bf }}} Gives: {{{ { "author" : "", "author_email" : "", "extras" : [ { "id" : "88cc50ca-9e29-4499-a542-09d364f5f64f", "key" : "Tester", "package_id" : "ec9cb930-d15f-441f-a1e1-36f4d5df19bf", "revision_id" : "e5c3ca9c-1dae-4a86-837f-b8c19ac31964", "revision_timestamp" : "2011-07-07T16:01:05.696025", "state" : "active", "value" : "\"Test Value\"" } ], "groups" : [ ], "id" : "ec9cb930-d15f-441f-a1e1-36f4d5df19bf", "license_id" : "", "maintainer" : "aron", "maintainer_email" : "", "name" : "my-test-package", "notes" : "Heading\r\n===\r\nThis _is_ some text", "relationships_as_object" : [ ], "relationships_as_subject" : [ ], "resources" : [ ], "revision_id" : "688d33fb-5629-4ab3-9f59-a649fc7caa00", "revision_timestamp" : "2011-07-06T10:37:50.182894", "state" : "active", "tags" : [ { "id" : "600dc72e-6127-4704-b801-bee00474ec0c", "name" : "test-tag", "revision_timestamp" : "2011-07-06T09:09:21.578034", "state" : "active" } ], "title" : "My Test Package", "url" : "", "version" : "" } }}}
#274 1287402155000000 pudo Replying to [comment:7 dread]: > I fixed the docs a couple of weeks ago. Need to ensure there is a test though. there is as of cset:c2e66cec3610
#274 1287402800000000 dread Replying to [comment:8 pudo]: > Replying to [comment:7 dread]: > > I fixed the docs a couple of weeks ago. Need to ensure there is a test though. > > there is as of cset:c2e66cec3610 Error: Invalid Changeset Number
#371 1292704716000000 nils.toedtmann Replying to [comment:9 nils.toedtmann]: > There seem to be are at least three monitors already in place: [[BR]] Correction: at least four, we seem to have a Montastic account, too:[[BR]] On 18/12/10 15:03, [email protected] wrote: {{{ Dear okfn, This is a monthly reminder that you have an account on Montastic, the website monitor service. ### ACCOUNT INFORMATION Signup date: 2009-10-06 Email you signup with: [email protected] ### 20 WEBSITES MONITORED [OK] - http://www.ckan.net/ [OK] - http://www.knowledgeforge.net/ [OK] - http://okfn.org/ [not monitored] - http://blog.okfn.org/ [...] ### EMAIL ALERT RECIPIENTS - [email protected] - [email protected] - [email protected] [...] To make changes to your account or contact us, go to www.montastic.com. [...] }}}
#1142 1305881244000000 lucychambers Replying to [ticket:1142 rgrp]: > Previous super ticket (from 3m ago): http://trac.ckan.org/ticket/927 > > * CKAN 1-page overview (for enterprise and for data hackers) > * Administrator's Guide (including install) > * Extensions Guide > * Separate CKAN.net info from Software Documentation (?) > > == Minor Items == > * Include guide on how to configure local filesystem storage, instead of Google storage. (http://lists.okfn.org/pipermail/ckan-discuss/2011-May/001235.html)
#1591 1325866229000000 rgrp Report of time spent / time estimate would be brilliant :-)
#374 1280223744000000 johnbywater Requested by DGU.
#1688 1328289101000000 dread Requested by Philipp Laemmel. Is going into CKAN 1.6 release, planned for 2 weeks time.
#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!
#161 1258573607000000 rgrp Resolved in cset:6d466d8b702a
#1379 1320155927000000 zephod Resolved in cset:af694663f30e Now allowing markdown to do its thing, then fixing remaining links afterwards. More success that way.
#35 1185471537000000 rgrp Resolved in r157.
#36 1185470035000000 rgrp Resolved in r168.
#1521 1327405394000000 zephod Resolved in this merge: https://github.com/okfn/ckan/commit/2337424dd4ebe3b81b6da454f2305031922d3d5c
#2319 1340624083000000 ross Resolved with rework of UI
#1636 1338204258000000 seanh Resolving as won't fix as this doesn't seem important.
#100 1318181227000000 rgrp Resolving as wontfix since not really sure any point to this.
#2255 1334582784000000 ross Review + restrict resource access (when private)
#2364 1335890204000000 ross Review the FRY app and investigate alternative payment gateways.
#1571 1325265148000000 rgrp Rewrote description extending it significantly and linking to etherpad and code.
#1430 1320431138000000 amercader Right, more news on this front. I've tested a patch which uses a hash of the dataset id and site_id to produce a unique id, and then configured the iati solr cores to use index_id as uniqueKey: https://bitbucket.org/okfn/ckan/changeset/855f5a452f60 Unfortunately, that did not solve the issue. Again, updating the same dataset in both apps messes things up. In this case, documents don't get replaced, but duplicated, so the new uniqueKey is working. I am more inclined to think that this is caused by a misconfiguration in the SOLR instance in s046. This is the file where the two cores are configured: {{{ <solr persistent="true" sharedLib="lib"> <cores adminPath="/admin/cores"> <core name="testing.iatiregistry.org" instanceDir="testing.iatiregistry.org"> <property name="dataDir" value="/usr/share/solr/testing.iatiregistry.org/data" /> </core> <core name="iatiregistry.org" instanceDir="iatiregistry.org"> <property name="dataDir" value="/usr/share/solr/iatiregistry.org/data" /> </core> </cores> </solr> }}} Following this paths: /usr/share/solr/iatiregistry.org symlinks to /etc/solr/iatiregistry.org, /etc/solr/iatiregistry.org/data is empty (as well as the testing equivalent). On the other hand, looking at the admin interface and at some errors that I got it seems that the data folder that both cores are using is /var/lib/solr/data/index Maybe that's the problem?
#1812 1335874864000000 johnglover Ross has fixed this via group authentication.
#1553 1340628453000000 aron.carroll Ross, I think you just did :) I'll make sure the new form takes this into account.
#214 1263056226000000 nickstenning Routing now redirects /packages to /package, in addition to /packages/* to /package/*. Introduced in cset:9eda6ff974ae.
#1159 1307615133000000 pudo Rudimentary RDFa has been added with seeAlso to API.
#1208 1310124599000000 thejimmyg Rufus and Friedrich are working on this at the moment so putting into the current sprint. I'm considering this as preliminary investigation to inform the wider project that David Raznick is leading on.
#300 1272384474000000 dread Rufus fixed this in cset:e6e3
#1520 1323280999000000 dread Rufus has persuaded me that this is not important since it is so rare, and focus on #1534 (which was #1514) instead.
#829 1303122056000000 dread Rufus originally specified it. Reassigning to him to decide whether we still want it or not.
#1710 1327580140000000 dread Rufus says that the paster command is enough for now.
#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
#1032 1303117292000000 thejimmyg Rufus, I think this is potentially quite a big change and needs to be done as part of the entity refactor rather than as a quick hack. I'd like David Raznick to work on timeseries this week so I'd like to understand a bit more about this ticket. Could you flesh it out please or let's discuss in the catch up?
#538 1294412635000000 thejimmyg Rufus, is this something you want to take on or shall we close the ticket as wontfix?
#405 1296467471000000 pudo Rufus, you mentioned this could be done very quickly - could you have a look?
#1014 1299245293000000 sebbacon Run out of time for decoupling, but tests and README.txt written (including pointers about how to customise for anyone who needs to decouple in the future)
#770 1294413390000000 thejimmyg Running CLI harvester command without arguments or with --help would return help for the harvester (currently crashes). We can therefore close #772, #773 and #774
#1267 1312894071000000 dread Running tests with WebOb 0.9.7.1, we see the error! Am now trying to fix.
#273 1270717895000000 pudo SOLR Requirements * 4GB Memory * Sun Java * Tomcat * Scala (for Etherpad) * MySQL 5 (for Etherpad) * Cheap bandwidth/low latency to the CKAN servers.
#1737 1329916781000000 dread SOLR syntax is already accepted in: * api/3/search/package * Action API "package_search" Actually api/1/search/package and api/1/search/package accept SOLR syntax too, but they also translate old-CKAN search parameters syntax to SOLR as well. See: http://docs.ckan.org/en/latest/apiv3.html
#1418 1319539691000000 dread Same as #1374
#512 1294917121000000 dread Same as #513
#897 1294914333000000 dread Same as #870
#147 1255515162000000 dread Same as ticket:148
#87 1258470719000000 dread Same as ticket:189
#514 1282757391000000 dread Same as ticket:515
#1034 1320174353000000 dread Same problem as #1321 I believe
#521 1283897124000000 pudo Schema has been adapted to suit IATI
#2331 1338455981000000 kindly Scoring is primary in my opinion. Who cares if you have 1000 results if the top few are yours. If things are hard to find we need to change our relevancy first. So if you have examples of where you think the scoring is wrong then please make a ticket for that. Google, I imagine, just has a cutoff of anything under a certain score not being shown. We could do that as well but it would take some working out what we wanted that score to be. Full "And" queries also limit any accidental discovery, especially of rare terms. If you do not get your search exactly correct then you get nothing, which is bad. Obviously you can still AND things or +things. The correct solution to this is adding a minimum match parameter which is a middle ground. eg you can say that you want to match over half of the terms. "thing1 thing2 thing3 thing3" means you have to match at least 2. There are many options described here. http://wiki.apache.org/solr/DisMaxQParserPlugin. You can change this in an extension if you want it just requries adding an mm field to the before_search in the Ipackage controller. I do not personally think we should change it as default. I am closing it as wont fix as its trivial to change and is a philosophical difference not a technical one.
#1530 1323283240000000 lucychambers Screenshot attached - browser = Chrome
#2351 1340615641000000 icmurray Scripts and docs in https://github.com/okfn/ecportal-server-setup
#1451 1323165781000000 johnglover Scripts and templates updated for CKAN 1.5.1 Waiting for Tom to finish dataset view and resource view updates, then will discuss best place to put the download stats on the page.
#1298 1323710593000000 dread Sean says: This is done on the activity stream branch. Just would like David Raznick to review it.
#1154 1314179290000000 dread Search requests - option one seems like a bad user experience, and option three seems too complicated. I should do option 2, explain it may well be a temporary problem, and let the user press reload, as per any normal web request. A more difficult problem though is what to do about a failed search indexing. Because of the try/except catch we've had until the patch yesterday, we get no exception emails for this, but I'm worried that this has caused packages to not be indexed, and hence are essentially lost in CKAN (unless someone realises there is a problem and does a reindex at some point). BTW I added paster command 'search-index check' for looking at this problem, but I don't think it was ever added to solr. Is it easy to add get_all_entity_ids for the purpose of checking for this problem?
#838 1291736461000000 memespring Search results changes: http://ckan.org/ticket/864
#2470 1338284041000000 johnglover Search results validated against schema. Added a class implementing IPackageController, in after_search results are replaced with package dicts got from package_show. A bit heavy-handed, but works for now. Maybe we should just call package_show in the package_search logic function in core?
#79 1250789298000000 dread Search: geo landsat Gives: 3 tags found: geo (1), geo-somthing (12), landsat (4) 11 packages found: (usual results)
#1452 1321276189000000 dread Seb Bacon: > I agree.  It is quite standard for people to have their browser > language as en-US in many countries. > Yes, geo-location is likely to be better if you want to automate it. > > http://www.maxmind.com/app/geoip_country > > But I wouldn't automatically detect it at all.  Just have a default > language for each site, as you suggest.
#876 1294753889000000 dread Seb and David have completed this I believe. I've merged the changes into core CKAN in cset:68d63fda4814.
#921 1300197629000000 thejimmyg Seb started this, I completed it and the code is now live. Further refactoring will be done first in #1037 and then in #987.
#576 1294753848000000 dread Seb's completed this now I believe. It's merged into head CKAN cset:68d63fda4814.
#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
#736 1304963598000000 amercader See https://bitbucket.org/okfn/ckanext-harvest/changeset/a7b6d8c0dde7 https://bitbucket.org/okfn/ckanext-harvest/changeset/40de12fada74
#1231 1325474447000000 rgrp See #1101 for other duplicate ...
#1386 1323278831000000 rgrp See #1534 for remaining work to ensure that when usernames get changed connection with activity is not lost.
#1611 1325846987000000 ross See #1550
#1677 1326807655000000 amercader See #1678
#2534 1340631124000000 amercader See #2399
#2495 1340624905000000 amercader See #2467
#1345 1338551926000000 nils.toedtmann See #2485 for workarounds containing the leak(s).
#537 1283325156000000 wwaites See #540 for a story about Varnish. Strongly favouring squid at this juncture.
#841 1300364333000000 thejimmyg See #995
#1639 1328213300000000 seanh See activity_stream_event() in ckan/templates/_util.html for the CSS classes used.
#103 1300217647000000 thejimmyg See also #1012 Add package revision history to api
#1012 1300217601000000 thejimmyg See also #103 which says: As a user I want to view a package at a given revision: * When I visit /package/read/xyz?rev=yyy I should be shown package at revision yyy * package history page should provide links to these pages Could you please investigate how doable this would be given the current package read.html page. I expect it could be very easy once the revision API is in place because we could build a c.pkg object from the revision data instead of the model data. Perhaps another case where we could try introducing the dictization?
#2365 1336492342000000 ross See also #1165 and #1096
#922 1310128789000000 thejimmyg See also #358 which I'm closing because it gets merged into this ticket. The reason we were blockd on #358 was to do with issues around authorization.
#711 1288014219000000 johnbywater See also #504.
#868 1292921428000000 sebbacon See also #867 Thanks for the patch.
#1108 1311180204000000 thejimmyg See also comment on #1200 about using the pdeu theme.
#1094 1303129670000000 rgrp See also comments on the mailing list. Item 1 seems fine (what is difference from current extension mechanism?) Item 2: concerns here. What about list views? What about editing 'permissions'? I also think getting rid of System object isn't really a benefit (if anything may be a cost). Item 3: feel this may be better as part of big domain model change (also gives us time to really dig into this -- this is an important requirement/conceptual issue). Item 4: No objections but seems very minor gain for fairly significant migration work.
#941 1301909446000000 thejimmyg See also discussion on #1069 about stub datasets.
#1096 1307444626000000 nils.toedtmann See also http://ckan.okfnpad.org/multisite
#1165 1307444733000000 nils.toedtmann See also http://ckan.okfnpad.org/multisite
#1076 1302515674000000 sebbacon See also http://trac.ckan.org/ticket/948
#995 1311179009000000 thejimmyg See also previous tickets: * #537 Caching and Performance improvement * #543 Investigate partial page caching and edge-side includes
#811 1294415158000000 thejimmyg See also related extras field tickets #811 and #893
#954 1310134531000000 thejimmyg See also this proposal about "inlining" extras fields #972. David Raznick and I have also agreed that for API 3, each call to the logic layer will return an object (basically a dictionary) rather than using Exceptions. This means the return values from the logic layer can exactly mirror the JSON data strucutres returned via the API. The help values can come from the docstrings of the logic layer functions.
#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.
#5 1157371211000000 rgrp See changeset:37 (searching for packages) and changeset:38 (A-Z finding)
#7 1157371311000000 rgrp See changeset:39
#11 1157371568000000 rgrp See changeset:39
← 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 →
Note: See TracReports for help on using and creating reports.