{23} Trac comments (3729 matches)

Results (1101 - 1200 of 3729)

← 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 →
Ticket Posixtime Author Newvalue
#2305 1335879165000000 seanh Setting the priority to major as I think it's worth getting this done since the follow support (which is almost finished) is a bit pointless without this.
#2345 1335878420000000 seanh Setting priority high as we want this done by Friday for the 1.7 release.
#2304 1335885463000000 seanh Setting minor again after cleaning tickets out of this sprint
#2305 1335885478000000 seanh Setting minor again after cleaning tickets out of this sprint
#2434 1350296272000000 amercader Seems to be working again, closing.
#1646 1327407044000000 dread Seems ok now. Chrome auto updates - maybe it had a bug before.
#2605 1340874110000000 ross Seeing *very* strange behaviour here with the tests working fine when run individually, but when run as part of the entire suite it is returning an old group (called david) that is NOT in the database (set breakpoint, queried db, not there). Hoping Mr Raznicks sqlalchemy skills will be able to see what is going on with this.
#885 1293314219000000 wwaites See: https://bitbucket.org/ww/ckanext-ows impossible as of yet to test against live server from the OS
#2477 1343124123000000 seanh See thread on ckan-dev for list of officially supported non-core extensions: http://lists.okfn.org/pipermail/ckan-dev/2012-June/002439.html
#1298 1323106307000000 seanh See the new super ticket and its branch: #1515
#1760 1328709521000000 ross See src/ckanext-dgu/ckanext/dgu/bin/import_publishers.py which will pull publishers from the provided CSV file and build the hierarchy in the database. This file describes how to obtain the publisher list (with hierarchy detail).
#1032 1303118226000000 thejimmyg See related ticket #922
#5 1185473622000000 rgrp See r64 ff.
#58 1239974365000000 rgrp See r442 and r437.
#53 1239133021000000 rgrp See r435. This just provides basic list of revisions affecting this. Next step would be to show diffs but that is another ticket.
#56 1239018857000000 rgrp See r398 + r412. Could do a bit more here to have nicer icons and a big sign on the package indicating whether open or not).
#39 1223908298000000 rgrp See r363 r364 and r366.
#54 1230211256000000 rgrp See r362, r365, r370 + more.
#55 1223909475000000 rgrp See r356 and r362 and r365.
#55 1223909891000000 rgrp See r356 and r362 and r365.
#42 1204133257000000 rgrp See r234 and previous. Pagination now implemented for packages and tags (but not for revisions yet).
#1345 1343215489000000 amercader See https://github.com/okfn/ckan/pull/73
#1737 1334591246000000 icmurray See http://ckan.okfnpad.org/feature-1737-expose-solr-based-search-api = Immediate actions * analysis of whether the current action/get.py:package_search() function exposes all we currently need for the use cases described above. * how to return that data (expand the current format?) * analysis of whether the current (action) API v.3 can use query parameters rather than as well as POSTed data. (controlles/api.py:action() ) uses "self._get_request_data()" which in-turn pulls out data from POST body. = Tasks Extend the existing package_search action. * pass the facet fields into the logic layer from the request parameters. - /api/3/action/package_search * facet information not being returned via package_search action (is empty). - curl -X POST -d '{"q": "{!lucene q.op=AND df=text}tags:health +community -profile"}' 'http://thedatahub.org/api/3/action/package_search' - figure out why it's not working, and what the facet information should look like * whitelist any GETable api actions, and optionally construct the query from url params rather than body
#517 1283897199000000 pudo See forms/iati, fixtures.py, fixtures.json as of ckanextiati: a02467cb67ba
#2756 1343231863000000 seanh See commits: f5043a2, 2280428, a8eedda (the ticket number wasn't in the commit messages, sorry)
#29 1157371518000000 rgrp See changeset:40.
#7 1157371311000000 rgrp See changeset:39
#11 1157371568000000 rgrp See changeset:39
#12 1157371398000000 rgrp See changeset:39
#13 1157373546000000 rgrp See changeset:39
#14 1157371389000000 rgrp See changeset:39
#5 1157371211000000 rgrp See changeset:37 (searching for packages) and changeset:38 (A-Z finding)
#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.
#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.
#811 1294415158000000 thejimmyg See also related extras field tickets #811 and #893
#995 1311179009000000 thejimmyg See also previous tickets: * #537 Caching and Performance improvement * #543 Investigate partial page caching and edge-side includes
#1076 1302515674000000 sebbacon See also http://trac.ckan.org/ticket/948
#1096 1307444626000000 nils.toedtmann See also http://ckan.okfnpad.org/multisite
#1165 1307444733000000 nils.toedtmann See also http://ckan.okfnpad.org/multisite
#941 1301909446000000 thejimmyg See also discussion on #1069 about stub datasets.
#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.
#1108 1311180204000000 thejimmyg See also comment on #1200 about using the pdeu theme.
#868 1292921428000000 sebbacon See also #867 Thanks for the patch.
#711 1288014219000000 johnbywater See also #504.
#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.
#2365 1336492342000000 ross See also #1165 and #1096
#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?
#103 1300217647000000 thejimmyg See also #1012 Add package revision history to api
#1639 1328213300000000 seanh See activity_stream_event() in ckan/templates/_util.html for the CSS classes used.
#841 1300364333000000 thejimmyg See #995
#537 1283325156000000 wwaites See #540 for a story about Varnish. Strongly favouring squid at this juncture.
#1345 1338551926000000 nils.toedtmann See #2485 for workarounds containing the leak(s).
#2495 1340624905000000 amercader See #2467
#2534 1340631124000000 amercader See #2399
#1677 1326807655000000 amercader See #1678
#1611 1325846987000000 ross See #1550
#1386 1323278831000000 rgrp See #1534 for remaining work to ensure that when usernames get changed connection with activity is not lost.
#1231 1325474447000000 rgrp See #1101 for other duplicate ...
#736 1304963598000000 amercader See https://bitbucket.org/okfn/ckanext-harvest/changeset/a7b6d8c0dde7 https://bitbucket.org/okfn/ckanext-harvest/changeset/40de12fada74
#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
#576 1294753848000000 dread Seb's completed this now I believe. It's merged into head CKAN 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.
#876 1294753889000000 dread Seb and David have completed this I believe. I've merged the changes into core CKAN in cset:68d63fda4814.
#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.
#79 1250789298000000 dread Search: geo landsat Gives: 3 tags found: geo (1), geo-somthing (12), landsat (4) 11 packages found: (usual results)
#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?
#838 1291736461000000 memespring Search results changes: http://ckan.org/ticket/864
#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?
#1298 1323710593000000 dread Sean says: This is done on the activity stream branch. Just would like David Raznick to review it.
#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.
#2351 1340615641000000 icmurray Scripts and docs in https://github.com/okfn/ecportal-server-setup
#1530 1323283240000000 lucychambers Screenshot attached - browser = Chrome
#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.
#521 1283897124000000 pudo Schema has been adapted to suit IATI
#1034 1320174353000000 dread Same problem as #1321 I believe
#514 1282757391000000 dread Same as ticket:515
#87 1258470719000000 dread Same as ticket:189
#147 1255515162000000 dread Same as ticket:148
#897 1294914333000000 dread Same as #870
#512 1294917121000000 dread Same as #513
#1418 1319539691000000 dread Same as #1374
#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
#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.
#1267 1312894071000000 dread Running tests with WebOb 0.9.7.1, we see the error! Am now trying to fix.
#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
#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)
#405 1296467471000000 pudo Rufus, you mentioned this could be done very quickly - could you have a look?
#538 1294412635000000 thejimmyg Rufus, is this something you want to take on or shall we close the ticket as wontfix?
#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?
#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
#1710 1327580140000000 dread Rufus says that the paster command is enough for now.
#829 1303122056000000 dread Rufus originally specified it. Reassigning to him to decide whether we still want it or not.
#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.
#300 1272384474000000 dread Rufus fixed this in cset:e6e3
#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.
#1159 1307615133000000 pudo Rudimentary RDFa has been added with seeAlso to API.
#214 1263056226000000 nickstenning Routing now redirects /packages to /package, in addition to /packages/* to /package/*. Introduced in cset:9eda6ff974ae.
#1553 1340628453000000 aron.carroll Ross, I think you just did :) I'll make sure the new form takes this into account.
#1812 1335874864000000 johnglover Ross has fixed this via group authentication.
#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?
← 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 →
Note: See TracReports for help on using and creating reports.