{23} Trac comments (3729 matches)

Results (1901 - 2000 of 3729)

← 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 →
Ticket Posixtime Author Newvalue
#274 1279890237000000 pudo This is included in the Solr indexing engine and will become available as Solr is adopted.
#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
#275 1280999840000000 pudo cset:1396 fixes this
#275 1280999963000000 pudo Replying to [comment:3 pudo]: > cset:1396 fixes this Where "this" is the field renderer.
#275 1281001911000000 pudo Replying to [comment:2 rgrp]: > Also, now if you visit ckan.net/admin/Package get 500 error and following in logs: > > [Mon Aug 02 08:17:35 2010] [error] [client 86.26.8.30] Error - <type 'exceptions.UnicodeEncodeError'>: 'ascii' codec can't encode character u'\\xf4' in position 988: ordinal not in range(128) Cannot reproduce this at the moment. Will wait for it to occur again and then create another ticket.
#309 1280743432000000 pudo fixed in cset:1382
#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)
#317 1279286041000000 pudo should be done after refactoring the search functions.
#318 1296467308000000 pudo This will be implicit in #852, thus not building something specific for it now.
#322 1274773856000000 pudo This looks very reasonable. Maybe we should have a webhooks client as a simple demo for this?
#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
#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.
#327 1296467361000000 pudo Nerdy solution that doesn't really seem to catch on, does nothing that cannot be done through queue workers.
#332 1280743320000000 pudo was fixed in cset:1381
#334 1280743667000000 pudo fixed in cset:1380
#353 1280262363000000 pudo cset:1366:e719f449bc74 fixes this
#353 1280737966000000 pudo Add a supervisord example config
#353 1280756379000000 pudo This is done as of cset:8 (of ckanext!)
#366 1299845781000000 pudo You're right, that's done!
#401 1281373828000000 pudo Coming along nicely: * http://bitbucket.org/pudo/ckanextworker
#402 1281373707000000 pudo This is beginning to go somewhere: * http://bitbucket.org/pudo/ckanextarchive
#402 1296467635000000 pudo De-dup: #891
#403 1287392451000000 pudo Available at http://bitbucket.org/pudo/repod
#405 1296467471000000 pudo Rufus, you mentioned this could be done very quickly - could you have a look?
#406 1296467427000000 pudo Has existed for a while, not implementing any more except for what is in #852.
#408 1281609572000000 pudo * Plugin for this is located at: http://bitbucket.org/pudo/ckanextdeliverance * Usage is documented in HOWTO.txt (http://bitbucket.org/pudo/ckanextdeliverance/src/tip/HOWTO.txt) * Changes to CKAN were in: cset: 1422
#410 1281619720000000 pudo Done in http://bitbucket.org/pudo/ckandisqus/changeset/be90fd4d386c
#411 1287393033000000 pudo Now using squid in production on eu6; will only need one cache at a time.
#501 1282563166000000 pudo * Apache version is documented here: http://knowledgeforge.net/okfn/tasks/ticket/466
#517 1283897199000000 pudo See forms/iati, fixtures.py, fixtures.json as of ckanextiati: a02467cb67ba
#518 1282893844000000 pudo * Priority: 5 * Web user interface for publishing entities
#518 1283536932000000 pudo * Still needs "archive file" and "donors country" fields, PE questions to be answered.
#518 1283896718000000 pudo functional as of cset:ae4d4263b0c0 in ckanextiati
#519 1283536828000000 pudo * Mostly implemented, still have to consider further cleanup.
#520 1283538080000000 pudo * http://bitbucket.org/okfn/iati/changeset/378431974c76 solr facets
#521 1282893545000000 pudo Ability to search over the IATI metadata stored about the IATI records that have been registered. * Priority: 5 (may merge into 1 to some extent)
#521 1283538342000000 pudo * still needs to have schema adapted a bit * work so far is at eu4:~/var/solr/iati/conf/schema.xml
#521 1283897124000000 pudo Schema has been adapted to suit IATI
#522 1285595317000000 pudo Still missing some internal authorization work but on the UI side, things are mostly functional. cf. http://bitbucket.org/okfn/ckanextiati/changeset/b2588091fa56 ff
#522 1287392999000000 pudo Has been fixed for quite some time.
#523 1283897688000000 pudo * Auth will be finished in #524. * PE write access etc. via standard API, compare ckanextiati:a02467cb67ba
#524 1285594971000000 pudo fixed as of cset:470d1e1c4460
#525 1285595080000000 pudo As of now, PE creation can only be done by sysadmins. When opened to normal users, they will not be able to set the group type and thus moderation will be required of sysadmins.
#528 1283536475000000 pudo Done at http://iati.ckan.net
#529 1283536554000000 pudo at https://spreadsheets5.google.com/ccc?key=tuOtQjD0Psoqr1pWTS8EXZQ&hl=en#gid=0
#530 1282899463000000 pudo The core of the COI/data.gov.uk standard seems to look like: Identifier Title Abstract Department Contact Contact e-mail Licence Resource format Resource URL Resource ID Publisher And the IATI-specific ones we'd want are: Publishing Entity: Publishing Entity Type: (Donor, Recipient, Community Data..) Donor Country Activity period: Verification status: enumeration of statuses (checked, not checked etc) Resource links: to the actual IATI record Number of activities: ... Date record updated: Date data updated: License: Need this field even if it may be a standard license So naively mashing these together, we get something like: Identifier Title Abstract Donor Country Publisher Publisher Type Verification Status Department Contact Contact e-mail Licence Resource format Resource URL Resource ID Activity period Number of activities Date record updated Date data updated
#531 1283536676000000 pudo done: http://bitbucket.org/okfn/ckanextiati/src/tip/ckanext/iati/fixtures.py
#558 1283781883000000 pudo fixed in cset:2c4c43302f21
#559 1288085627000000 pudo Still missing: the possibility to remove an added entry before committing the form (i.e. you look up a package and then decide not to include it after all).
#562 1284063574000000 pudo fixed by ww by upgrading python-openid
#648 1284889656000000 pudo introduced in ckan-authz2 cset:934b30ec84fd
#649 1284889939000000 pudo developed in cset:e65d7342ffe4
#650 1287391932000000 pudo included since cset:781ef73e61cc
#652 1284998201000000 pudo Fixed in cset: 688cbd25b3f0 (ckan-authz2)
#669 1291715237000000 pudo Important sub-task: check in schema.xml from eu4 somewhere.
#672 1291715338000000 pudo This is fixed for Solr now, plus a decision not to support postgres facets has been made.
#695 1287391751000000 pudo This is triggered by an issue where having local blinker notifications without asynchronous notifications will break indexing. The issues cause is still unknown, but one possible fix is running CKAN with a queue enabled, synchronous indexing on and no queue consumers attached. Not a real solution, but made possible in cset:a065dbc8041c
#699 1296499061000000 pudo fixed in cset:81a0f5538a5b
#703 1289909096000000 pudo fixed in cset:b23377108b6d
#706 1289909028000000 pudo fixed in cset:b23377108b6d
#715 1297796784000000 pudo fixed in cset:69c4210f635a
#718 1288459823000000 pudo fixed http://bitbucket.org/okfn/ckanextiati/changeset/4bf10d3f26e7
#720 1288459344000000 pudo Customer has stated they do not want this in the current iteration.
#721 1288459534000000 pudo Solved using javascript to toggle hide/show preview for each resource: http://bitbucket.org/okfn/ckanextiati/changeset/942cec028cf5
#722 1288459703000000 pudo fixed: http://bitbucket.org/okfn/ckanextiati/changeset/fb166fde9d3e
#723 1288459610000000 pudo Fixed in cset:78b23f3f6aaf
#725 1289295966000000 pudo fixed in cset:ff4264eb609c (http://bitbucket.org/okfn/iati/changeset/ff4264eb609c)
#775 1295260144000000 pudo fixed in cset:98c9997e80e8
#782 1289218497000000 pudo This has existed for quite a while, but misses documentation. Has been documented in cset:db18a16a5b4d
#787 1289295207000000 pudo Alternative: * The Drupal system will expose a resource at data.gov.uk/profile which wil contain the reqesting user's nickname, fullname, email etc. in JSON (or XML) form. * The Drupal system will also run an OAuth server (and provide /request_token, /access_token, /authorize). * CKAN's login form will be rewired to initiate a client OAuth request on the /profile resource. * Recognizing CKAN's callback URL at catalogue.data.gov.uk, Drupal will automatically grant the request if a user is signed in. * Upon return, a user is created, optionally using the OAuth access token as the users API key, thus making it known both to Drupal and CKAN. * The authorizer will be extended to check access to the /profile resource for OAuth accounts (slow but safe). Advantages: * Well-known protocol, does not depend on cookies (which are strange and never behave as defined, or even the same in multiple browsers) * Python code is available: http://oauth.googlecode.com/svn/code/python/oauth/example * Drupal seems to have very complete support: http://drupal.org/node/296205 * Can be fully implemented as a plugin, using an OAuthClientController for callback and adding hooks to the Authorizer (perhaps need to reconfigure who.ini)
#808 1297783658000000 pudo implemented in cset:8200247e74e9
#810 1297679091000000 pudo At the moment, this crashes the groups field for some mysterious reason. Since this is going to be redundant with the new forms and the ticket has a low priority, I'm bumping this back 2 weeks.
#826 1297415095000000 pudo I want to strongly support david in his call for fully flexible extras: one of my use cases for them is to store the various bits of fallout from an archiving process, such as: * last-status * last-crawled * last-etag * last-expires * last-md5 * failure-count * fall-back-url These are things needed to really archive the data well, but they have nothing to do with CKAN core ops. Essentially, the archiver is a seperate concern and it need not appear in the CKAN config.
#835 1291644820000000 pudo done in cset:d41b77099954
#843 1291652696000000 pudo The real name is also requested via AX/SReg extensions in OpenID so for new users who are not using google, this should usually be filled in automatically.
#847 1295259902000000 pudo This is now functional, minus the index testing tool.
#849 1291715179000000 pudo == #846
#853 1294047550000000 pudo Looking at the changeset this cannot be functional yet: where is the implementation of the policy document exchange. It seems to me like this is currently adding the actual credentials to the request (self.ofs.conn.add_aws_auth_header(headers, 'PUT', path)). c.f.: * http://doc.s3.amazonaws.com/proposals/post.html#Form_Fields * http://code.google.com/apis/storage/docs/reference-methods.html#postobject
#865 1295259773000000 pudo This has been fixed on the respective branch and merged into default..
#875 1297085261000000 pudo So far opting for route 1) (not implementing facets), therefore this can be closed!
#903 1295265645000000 pudo This is now partially solved by filtering for deleted packages. As two further measures, we should also add a package deletion method to the Solr backend and skip deleted packages when indexing.
#903 1296588070000000 pudo fixed in https://bitbucket.org/okfn/ckanext-solr/changeset/be4cffa9b987
#908 1296659056000000 pudo fixed in https://bitbucket.org/okfn/ckan/changeset/08c0e1a819e4 and https://bitbucket.org/okfn/ckanext-stats/changeset/6e86c071db99
#908 1296730578000000 pudo I've moved the uswgi/nginx part to #952, closing this issue since the problem it describes has been fixed.
#911 1296467375000000 pudo Done.
#912 1306774876000000 pudo moving to ckan
#913 1306774962000000 pudo moving to CKAN, still need a resolver
#915 1296467518000000 pudo Live and running :-)
#938 1296753055000000 pudo fixed in https://bitbucket.org/okfn/ckan/changeset/064d74a1ead8
#940 1296656433000000 pudo It seems like even with openid.realm set we could only create two "zones": *.ckan.net and ckan.net. We do not want *.ckan.net because it interferes with ccCKANs. My vote for the moment would be to 303 www.ckan.net to ckan.net.
#942 1296499160000000 pudo fixed in cset:81a0f5538a5b
#944 1298571917000000 pudo Won't work on this for now - IATI is now running against plain CKAN but this is not deployed. We will continue work on this once IATI requests more functionality and shelf it for now.
#944 1306774766000000 pudo done at iati.ckan.net
#949 1296730355000000 pudo Fixed in: * https://bitbucket.org/okfn/ckan/changeset/8017a6686838 * https://bitbucket.org/okfn/ckan/changeset/5e6634aab275
#960 1297080672000000 pudo Test this with a dedicated test using a unicode user name.
#960 1297169056000000 pudo fixed in cset:8cb94dcdecb2
#980 1297503120000000 pudo Re package editing issue, that was a "double error" fixed by the first two changesets mentioned.
#985 1298571248000000 pudo digitialiser.dk has been assigned to Stefan Marsirske to get him into this Framework, everything else is delayed.
#989 1297700818000000 pudo Kindly, I agree - it would be much preferable to have independent storage for plugins and this would be easy to do if we were using another type of storage already. As it stands, however, our storage mechanism is SQL. I think we should use it for what it is as much as possible and do the weird, vertical stuff (k,v tables, swapping to redis) only if we really need it. For everything else: lets use SQL as it was intended. Examples: * We want to develop an apps catalogue as a CKAN plugin. While we could certainly put this in Redis, there is no reason why we can't have the following table: application (id, name, title, description, author, project_url, site_url, code_url, image). * A watchlist plugin could essentially work on UUIDs alone. What you'd end up with is something like this: watch (id, user, scope_id). Re migrations you're right, but my first intention would be to handle that seperatly for each plugin (i.e. they need to have their own migration repositories that they keep track of, e.g. via an apps_migrate_version table)
#1001 1300625888000000 pudo My vote on this would be to enable "httpbasic" auth via repoze.who and to add an API key challenger to ckan/lib/authenticator.py that accepts API keys, from within repoze.who. This way we won't have to work around the framework at all and can retain compatibility to the existing mechanisms.
← 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 →
Note: See TracReports for help on using and creating reports.