{23} Trac comments (3729 matches)

Results (1301 - 1400 of 3729)

← 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 →
Ticket Posixtime Author Newvalue
#1444 1340190852000000 ross 7 months, no activity, dead bug.
#1443 1320432511000000 dread Fixed in cset:96b5d9af70a7 for release-v1.5
#1442 1320275623000000 dread Fixed in cset:819a74bd1c03 for release 1.5. Note release 1.5 doesn't have #1381 feature, so you're not supposed to create with groups anyway, but this will be useful if people try it.
#1441 1320235062000000 dread Fixed in cset:35542f1c60a2 for release 1.5.
#1440 1320235084000000 dread I've done this. 'db load' now also does 'db upgrade' and 'search-index rebuild'. If you want to debug the load (or don't need the search index, cos it takes ages to do), then you can just do 'db load-only' which does what 'db load' did before. Changed in cset:9e51df5c496b for 1.5 release.
#1439 1325474974000000 rgrp Moving out of v1.6 (has not super ticket atm and seems of low relative importance -- nice to have but not essential).
#1437 1320173496000000 dread This can be fixed with one line of code, so I'm doing it for release 1.5.
#1437 1320173795000000 dread Fixed in cset:5d0bf20a1746 for 1.5. Broken since 1.4.3.
#1436 1320230896000000 johnglover This also applies to CKAN core
#1436 1320243278000000 johnglover Fixed in branch feature-1371-task-status-logic-layer, will merge with default after 1.5 release later today.
#1435 1320930310000000 dread Interesting. What's the reason to justify the effort?
#1435 1323168783000000 thejimmyg I personally can't see the benefit of switching to a generic paid service when we already have a highly customised and working infrastructure based on buildbot and buildkit - we do testing in VMs as well as continuous integration. What is the advantage? Suggest wont fix?
#1435 1323283538000000 dread From IRC today: {{{ <rgrp> dread: btw have a big suggstion -- switch to continuous.io for our buildbot stuff ... <rgrp> openspending have done this and it's a nice setup ... <dread> rgrp: interesting - what's better? <dread> i assume it just starts a script and reports the result? <rgrp> that's right though also has integration with some bakcens (but we probably don't need that) <rgrp> the point is we don't need to boot machines, install and configure buildbot etc (though we may now have automated that ...) <dread> ah, i see, it's in the cloud <dread> did all that months ago, and don't need to setup the machine any more. <dread> if we do it again though, I'm all for it }}}
#1434 1338203960000000 seanh At least for the core extensions, any i18n-able strings should be getting pulled into the ckan.pot file by default.
#1434 1341236921000000 seanh Done for the core extensions, pull request: https://github.com/okfn/ckan/pull/47 Perhaps strings from the non-core but officially supported extensions should be added to, but we haven't decided which extensions those are yet, so add another ticket to do that later: http://trac.ckan.org/ticket/2625
#1433 1320666509000000 kindly Done but waiting to merge after 1.5 release.
#1433 1321827123000000 kindly cset: 68c37312ef70349431213465005761edf434d27e
#1433 1324472583000000 dread Has gone into CKAN 1.5.1 release.
#1432 1324290164000000 ross PhantomJS ( http://www.phantomjs.org/ ) looks like the perfect way to run a JS scraper offline but still within the context of a browser. Would need to consider how the script would be executed over multi-page datasets, but I'm fairly sure it would be possible to come up with a workable solution.
#1431 1320084104000000 dread Fixed in cset:711a68a12d90 for release 1.5.
#1430 1320339962000000 amercader I've been digging more on this one. To reproduce it, you just have to edit the same dataset in both sites (production and testing). Just after editing the dataset, the search index will get mixed site_ids. I checked the jetty logs (see attached files) and just after editing a dataset there are two POST requests to update the index. The request logs don't show the requests params so it's hard to tell what the second call does (it probably is the commit): https://bitbucket.org/okfn/ckan/src/97e1e90d66d7/ckan/lib/search/index.py#cl-144 In any case, it's clear that the problem may be related with the datasets in the two cores sharing the same id. We are currently using the dataset id as uniqueKey in SOLR, i.e in our schema.xml, we are defining: {{{ <uniqueKey>id</uniqueKey> }}} According to the SOLR docs: "If a document is added that contains the same value for this field as an existing document, the old document will be deleted." http://wiki.apache.org/solr/SchemaXml#The_Unique_Key_Field I would expect the uniqueKey not to be mixed between cores, but it looks like it happens otherwise. Maybe we should generate a solr_id specific to each document for each site, as described here: http://wiki.apache.org/solr/UniqueKey#UUID_techniques (Note that apart from the testing/production site use case, at some point sites involved in harvesting could also end up with datasets with the same id.) Again, I'm not a SOLR expert, so the problem could be a completely different one!
#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?
#1430 1320444567000000 pudo You probably know this by know but the solrconfig.xml for both points to /var/lib/solr/data (line 71).
#1430 1320660144000000 amercader No, I didn't know it. Is this supposed to be the correct setting or should each core have its own data dir?
#1430 1320667523000000 rgrp @pudo: brilliant spot. How did that misconfig end up there? Anyway, commenting out and rebooting means we do now have separate cores seems to fix it.
#1430 1320670062000000 amercader As rgrp mentioned, we commented out the <dataDir> directive in the solrconfig.xml files and rebooted. That made the cores use the data dir they were supposed to (the one in solr.xml) and from the tests I made looks like it finally fixed the issue.
#1430 1324033923000000 dread Fixed in CKAN 1.5.1. Affects all previous CKANs that use SOLR in these circumstances.
#1428 1319804773000000 dread Fixed in a3b0080467d4 for release 1.5
#1427 1319709925000000 dread Done in cset:ec9a9efc2d40 for release 1.5
#1426 1319709236000000 dread Reading http://www.checkupdown.com/status/E409.html I've changed my mind - 409 is ok for an application level validation error.
#1425 1319735012000000 dread Cheers for taking this on Tom
#1425 1326821722000000 dread There is a package_delete logic function to achieve this (and indeed group_delete too). One of the reasons we haven't advertised it with a button is that anyone with 'edit' privileges can go round deleting packages. It's one thing spotting graffiti, but when you delete packages, it takes a lot of effort to spot nefarious deletions. I think should either restrict deleting to sysadmins or have a separate authz-action DELETE-PACKAGE that is not given to the average logged-in user. I believe Wikipedia does something similar - the average Joe can edit, but can't delete pages.
#1425 1327605718000000 zephod Refactored it to be (a) easy to find, and (b) a two-stage process which has a little more gravity. Like Bitbucket and GitHub. https://github.com/okfn/ckan/commit/f3a4c3de70da08d396da4e65a5d286b253be0e0b
#1425 1330085282000000 dread Went into CKAN 1.6
#1422 1319645722000000 dread Done in cset:54fc460602d2 on default for 1.5.1 release.
#1421 1319639311000000 dread Fixed in cset:109db2176fac for 1.5 release.
#1419 1319548778000000 rgrp I've successfully logged into thedatahub using my openid. Issues may arise especially with google openid due to changes in site (from ckan.net to thedatahub.org). See: http://lists.okfn.org/pipermail/ckan-dev/2011-October/001384.html
#1419 1319795920000000 dread This seems to work better today...! myopenid works for me fine with my existing account and by reregistering. My google id works only if I reregister, and I think that is because I hadn't registered before. Closing.
#1418 1319539691000000 dread Same as #1374
#1417 1319651617000000 dread Fixed in branch defect-1418-i18n for release 1.5.
#1416 1319794595000000 rgrp In normal user submission this would result in errors reported and no 500. Happy to have this switch to 400 if you think this is a good idea.
#1416 1320153507000000 dread This seems to have been fixed in #1229. Added a test for this cset:5d6a3e50fe8f on default to demonstrate it displays a validation error, as rgrp suggests. Note, this ticket is about spammers missing some of the form fields, rather than any normal user usage, where the browser sends all the fields whether you fill them or not.
#1415 1319457583000000 nils.toedtmann Arww ... sorry i only now rediscovered James' mail "CKAN Packaging" from Sept 29th where he announced the availability of the repository http://apt.okfn.org/ckan-1.4.3.1 . This package release already addresses many of the above points. I will test those packages and refine my comments then. Sorry for the noise.
#1415 1323167941000000 thejimmyg This is all complete now. We aren't yet allowing multiple options, but we do support proper version numbers and the domain name. Other features will be implemented as different scripts for the timebeing eg ckan-setup-solr.
#1413 1322479113000000 seanh I've made a first attempt at this here: https://github.com/seanh/ckan/compare/feature-1413-ask-users-to-add-email-address I used flash_notice() to ask the user to add an email whenever they visit their account page, if they don't have one already. This means they'll see the notice when they login, because after login they are redirected to their account page. Issues: Is it okay to approximate 'once they log in' as 'whenever they visit their account page' like this? Do I need to do something to support i18n for the string I added? I looked at users of flash_*() elsewhere and they seemed to be hardcoding the strings in English.
#1413 1322481235000000 dread approximate 'once they log in' as 'whenever they visit their account page' I had imagined that this would be done in the user.py:logged_in method, but doing it in your way sounds like an even better plan. Another thought is: a lot of people might just use the cookie and v. rarely logout/in. Perhaps it could be done when they come back to the site at intervals (e.g. daily)? i18n Yes your strings should be internationalised because they are user visible. You're right that these other strings should be internationalised. I've created a separate ticket for this: #1491
#1413 1322575534000000 seanh Another thought is: a lot of people might just use the cookie and v. rarely logout/in. Perhaps it could be done when they come back to the site at intervals (e.g. daily)? As discussed on IRC I've moved the notice from the user account page to the front page, in the hopes that people will see it often enough even if they are always logged in via a cookie. As discussed on IRC, we could make the notice appear on every page but no more than once per day, but that would be more complicated to implement and more likely to break. Yes your strings should be internationalised because they are user visible. Done. You're right that these other strings should be internationalised. I've created a separate ticket for this: #1491 Also done! :)
#1413 1322595160000000 seanh Added a 'please enter your full name' flash notice as well (the two are combined into one if they have neither full name nor email), added unit tests, fixed some issues. Still need to adjust the strings and change the full name notice so that it applies to people with gmail IDs only. https://github.com/seanh/ckan/compare/feature-1413-ask-users-to-add-email-address
#1413 1323088091000000 seanh Adjusted the 'please add your email' string and changed the 'please add your full name' notice to be used only for Google OpenID users. Finished? https://github.com/seanh/ckan/commits/feature-1413-ask-users-to-add-email-address
#1413 1323269472000000 dread Code reviewed - looks really good. Do merge in to master if it is not already. A couple of tips: * we all use 'model.User' instead of 'model.user.User' but it's not important for tests... * probably better to use CreateTestData.create_user() to create user objects in the future, avoiding faffing around with creating revisions etc. that are also nastier to debug when they go wrong.
#1413 1330020486000000 dread Went into CKAN 1.6
#1412 1328226385000000 rgrp I'm completely unable to reproduce this issue in either FF (9.0.1) or Chrome 16.0.912.75.
#1410 1319213205000000 zephod Oops: #1409 double posted.
#1409 1319306802000000 rgrp What do we do for people without email addresses (no gravatar or a standard anonymous one?)
#1409 1319567582000000 zephod https://bitbucket.org/okfn/ckan/changeset/c8c62bc8766d
#1409 1324047722000000 dread In 1.5.1 release.
#1408 1319794384000000 rgrp Suggest that going forward we always boot a site user with the same id as site id (which we may want to leave ckan.site_id blank and force user to choose this going forward?) and give it a password. May need migration or instructions in UPGRADE.txt for existing users.
#1408 1320141847000000 kindly fixed cset:51c7d51f3c17
#1407 1323764239000000 rgrp Fixed in https://github.com/okfn/ckanext-stats/commit/a95bbf7ffc0a36a747467f568a011b6865b64478.
#1406 1320930088000000 dread Note, the Atom feeds are still working, with the links still advertised with <link>s home and package pages, but the visual element was removed.
#1405 1320152291000000 dread Fixed in cset:e68926926bee for release 1.5. David looked for duplicates on thedatahub.org and found one - http://thedatahub.org/group/lodcloud with http://thedatahub.org/dataset/didactalia. I fixed that by opening the dataset, editing, saving.
#1404 1328609360000000 rgrp Quite a bit of this is now duplicated in other tickets e.g. #1506. Decide what isn't and it's priority (do not have to implement).
#1401 1320142359000000 rgrp Hi, this is very useful to hear. Can you point out links or even better submit a patch / pull request: http://wiki.ckan.org/Submitting_a_code_patch
#1401 1321037805000000 dread Another problem is 401 redirect when your not authorized to do something, like creating a group. The redirect URL is set in the who.ini: {{{ login_form_url= /user/login }}}
#1401 1322066474000000 dread Patch from Augusto Herrmann for the icon URLs: http://pastebin.com/aRBQmftL
#1401 1326460993000000 dread When javascript calls other scripts, it misses the mount-point prefix. e.g. application.js has hard-coded URL /api/2/util/is_slug_valid The URL prefix is stored in request.environ['SCRIPT_NAME'] so perhaps this value should be put in the HTML somewhere for the javascript to get at?
#1401 1326747111000000 dread Links have been fixed on branch defect-1401-mount-non-root. (Instead of using c.site_url the links now just detect the mount url like the rest of the links.) Now it needs the js and css to be fixed too. Reassigning to Tom for this. Brazilians currently waiting for this to be fixed.
#1401 1327089904000000 rgrp Fixed. See https://github.com/okfn/ckan/commit/7088b1fcae685e56a280ec7b396b0f9803a477d9 @dread: not at all clear why we had to change from g.site_url to h.url_for (idea was people could set site_url if the site was not at root ...)
#1401 1327665399000000 dread Basic check of the home page shows the CSS has not been fixed: {{{ GET http://127.0.1.1/img/find.png 404 (Not Found) GET http://127.0.1.1/img/share.png 404 (Not Found) GET http://127.0.1.1/img/collaborate.png 404 (Not Found) }}}
#1401 1328001014000000 rgrp Thanks for that dread. Have now fixed these issues as well: https://github.com/okfn/ckan/commit/abb99cae9972d45f4b3acfbf8ea711da398d8a4a Re-closing.
#1400 1328529013000000 rgrp John: can you comment on status here. Have you already got docs for this?
#1400 1328612209000000 johnglover I haven't written any docs for this. I'm also not sure what the status is, Ross was doing some work on it recently so he is probably the man to ask.
#1400 1329729653000000 rgrp @johnglover: I don't think Ross has done much here and he's obviously occupied with DGU at ;-) As you worked on this earlier would be able to look at this and a) check what docs there are b) add to them as necessary :-)
#1400 1329746131000000 johnglover Will document and update wiki this sprint then ping Mark about a blog post.
#1400 1330524586000000 johnglover Async task docs are at: http://wiki.ckan.org/Writing_asynchronous_tasks Archiver readme at: http://github.com/okfn/ckanext-archiver Emailing Mark RE blog post.
#1400 1331481461000000 rgrp Great to see this is done. I do have one question: why did we put this on the wiki rather than in the proper CKAN docs? In general, I think it would be better to use the wiki less and our proper docs more ...
#1400 1331543941000000 johnglover I thought that we had some sort of consensus that the official docs were aimed more at system admins and people using the CKAN WUI/API, with the wiki aimed more at developers? It would be easy to move of course, but there is no real "developers" section in the official docs that I can see, and it's even called "CKAN's Administration Guide".
#1400 1331544485000000 rgrp Hmmm. Emerging consensus from discussions in last few months is that wiki is fairly confusing and we should move core, solid docs (from whichever area) to the main docs. Furthermore, key dev info like how to setup and do extensions *is* already in the main docs (see http://docs.ckan.org/en/latest/writing-extensions.html) and has been for 6m+. I've created #2226 for more work on docs and you may wish to comment there.
#1400 1331544816000000 johnglover I'll have a look thanks. I'm +1 on using main docs instead (if we move everything), I was just trying to keep things consistent for now.
#1398 1321826380000000 kindly deployed on test.ckan.net docs added cset:47216c49fcec881f4eacc7170cb02d0a443500a2
#1396 1323255616000000 markbrough +1 on listing owned datasets and seeing all historical activity for a user (especially for logged in user :-) )
#1396 1328179618000000 rgrp add note about needing to add datasets attribute to user dict in logic layer
#1396 1328225696000000 rgrp Fixed. https://github.com/okfn/ckan/commit/a22624ffa9b8cac28b78d5ef5f93d5b682558b14 Need to check performance and css possibly as loading lots of datasets could be slow via administrator could be slow.
#1396 1330086237000000 dread Went into CKAN 1.6
#1395 1318520543000000 seanh The exact command that introduced the too-new webob into my virtualenv was: {{{ pip install --ignore-installed -r pyenv/src/ckan/requires/lucid_missing.txt -r pyenv/src/ckan/requires/lucid_conflict.txt }}}
#1395 1318525201000000 dread This problem is mentioned here: http://docs.ckan.org/en/latest/test.html but you're right, it really should be solved in the install instructions.
#1395 1320857823000000 dread I added this to the instructions a few days ago to fix this issue for the 1.5 release: {{{ pip install webob==1.0.8 }}} Cheers Sean.
#1394 1320663304000000 dread I have half a fix for this at the moment.
#1394 1321872676000000 dread Not moved on during fortnight - keen to close this off.
#1394 1323166530000000 dread Not moved yet, but want to finish it...
#1394 1324292900000000 dread Defo for this sprint.
#1394 1325604784000000 dread Done my best here: [release-v1.5.1c c51db1a] Changed "incomplete" to "invalid" but numbering is done in Javascript, so will leave it. I added a test for the main part of the validation (error_dict), but the API doesn't expose the error_summary which the javascript seems to get hold of somehow, so wasn't able to test for that.
#1393 1318505854000000 dread I changed this: {{{ diff -r 47657581fc30 ckan/tests/__init__.py --- a/ckan/tests/__init__.py Wed Oct 12 17:58:19 2011 +0100 +++ b/ckan/tests/__init__.py Thu Oct 13 12:29:54 2011 +0100 @@ -373,7 +373,7 @@ plugins.load('synchronous_search') def is_search_supported(): - supported_db = "sqlite" not in config.get('sqlalchemy.url') + supported_db = True return supported_db def is_regex_supported(): }}} But there seems to be a problem finding the package when trying to index it: {{{ ====================================================================== ERROR: test suite for <class 'ckan.tests.functional.test_search.TestSearch'> ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/nose/suite.py", line 208, in run self.setUp() File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/nose/suite.py", line 291, in setUp self.setupContext(ancestor) File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/nose/suite.py", line 314, in setupContext try_run(context, names) File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/nose/util.py", line 478, in try_run return func() File "/home/dread/hgroot/ckan/ckan/tests/functional/test_search.py", line 21, in setup_class CreateTestData.create_search_test_data() File "/home/dread/hgroot/ckan/ckan/lib/create_test_data.py", line 66, in create_search_test_data cls.create_arbitrary(search_items) File "/home/dread/hgroot/ckan/ckan/lib/create_test_data.py", line 197, in create_arbitrary model.repo.commit_and_remove() File "/home/dread/hgroot/pyenv-ckan/src/vdm/vdm/sqlalchemy/tools.py", line 110, in commit_and_remove self.commit() File "/home/dread/hgroot/pyenv-ckan/src/vdm/vdm/sqlalchemy/tools.py", line 100, in commit self.session.commit() File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/sqlalchemy/orm/scoping.py", line 139, in do return getattr(self.registry(), name)(*args, **kwargs) File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 614, in commit self.transaction.commit() File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 385, in commit self._prepare_impl() File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 361, in _prepare_impl ext.before_commit(self.session) File "/home/dread/hgroot/ckan/ckan/model/extension.py", line 103, in before_commit methodcaller('before_commit', session) File "/home/dread/hgroot/ckan/ckan/model/extension.py", line 38, in notify_observers func(observer) File "/home/dread/hgroot/ckan/ckan/model/modification.py", line 45, in before_commit self.notify(obj, DomainObjectOperation.new) File "/home/dread/hgroot/ckan/ckan/model/modification.py", line 70, in notify observer.notify(entity, operation) File "/home/dread/hgroot/ckan/ckan/lib/search/__init__.py", line 93, in notify package_to_api1(entity, {'model': model}), File "/home/dread/hgroot/ckan/ckan/lib/dictization/model_dictize.py", line 231, in package_to_api1 dictized = package_dictize(pkg, context) File "/home/dread/hgroot/ckan/ckan/lib/dictization/model_dictize.py", line 118, in package_dictize raise NotFound NotFound ---------------------------------------------------------------------- Ran 1 test in 2.734s FAILED (errors=1) }}} Any ideas John?
#1393 1318508765000000 johnglover Yes, there are a few of these problems with SQLite which is why the tests are being skipped currently. I'm not exactly sure of the reason, it seems that it sometimes drops tables from memory, but we haven't found a solution. Myself and David Raznick were going to spend some time looking at it but haven't had a chance yet.
#1393 1320153590000000 dread Thanks John, reassigning to you for the future.
#1392 1319625243000000 johnglover Now on s054.okserver.org
#1388 1320174229000000 dread Etags fixed in cset:a3c8d4f7cf91 for release 1.5.
#1387 1318429228000000 dread I'm generally against validation. When doing any bulk import, it either have to ignore validation errors or lose data. If you ignore the errors, you find you can't edit the dataset without correcting the validation error, and you often end up guessing, just to get your other changes in. All in all, I think it is better to nudge users, with javascript pop-ups in the form, or quality scores, rather than hard-and-fast validation.
#1387 1320142210000000 rgrp This won't happen in v1.5.
#1386 1318527591000000 rgrp Fixed in https://bitbucket.org/okfn/ckan/changeset/130cad62163c
← 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 →
Note: See TracReports for help on using and creating reports.