{23} Trac comments (3729 matches)

Results (2201 - 2300 of 3729)

← 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 →
Ticket Posixtime Author Newvalue
#1365 1319815052000000 dread Done on defect-1365-search-params for 1.5. No official releases exist with this broken
#1431 1320084104000000 dread Fixed in cset:711a68a12d90 for release 1.5.
#1383 1320141781000000 kindly fixed cset:ecfb0f8b633c
#1408 1320141847000000 kindly fixed cset:51c7d51f3c17
#1387 1320142210000000 rgrp This won't happen in v1.5.
#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
#954 1320142744000000 kindly This is basically the complete now with documentation. The child tickets no longer seem to fit and are not essential for completion.
#891 1320143424000000 johnglover Almost finished (see http://github.com/okfn/ckanext-archiver). Still to address: - check headers to see if hash / cache / max-age / expires indicates that the resource does not need to be downloaded. - add cache url to resource
#1190 1320143592000000 rgrp A very substantial portion of this got done as part of 0.5 including the webstore #1208 and the majority of automated conversion #1398. #1432 is currently deferred so we're going to close this ticket on basis that item (3) is now out of scope.
#1292 1320145677000000 dread Review process of releases and updating strings (pot) and translations (po) files c.f. http://lists.okfn.org/pipermail/ckan-dev/2011-May/000718.html http://wiki.ckan.net/Release_process updated with basic process Get language changing thing to get home page to mostly work - push to key strings translated (or don't advertise the translation?) Welcome message is translated in all languages. Most language have upped their percentage translated significantly and Swedish and Polish added as well. Review long list of strings for improvement Consolidate any? Get rid of i18n for strings in api About 50% of the strings are templates, 30% are in the logic layer and 20% are in the controllers. Removed a handful from ckan/lib/base.py that were only displayed in the api, but the logic layer ones are generally errors that can be displayed in the Web UI as well as the API, so not ideal to remove. Try and remove javascript Tom did this. Add in extensions This could be done. Have raised ticket #1292 for this, next release. #1374 Fix switching to en from other default language Done #1417 Fix browser language detection Done
#1292 1320145732000000 dread These fixes all went into release 1.5.
#891 1320149841000000 johnglover Added cache_url and cache_last_updated to resources after archiving. Not checking for hash value in headers. This process will generally only run when a new resource is added or someone updates a URL, so we don't expect to be regularly downloading the same resource. We will need something along these lines if this is running as a regular cron job, but in that case the logic will be added to the cron job itself (probably a paster command).
#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.
#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.
#1393 1320153590000000 dread Thanks John, reassigning to you for the future.
#1379 1320155927000000 zephod Resolved in cset:af694663f30e Now allowing markdown to do its thing, then fixing remaining links afterwards. More success that way.
#1379 1320161439000000 zephod actually here: https://bitbucket.org/okfn/ckan/changeset/607f3363a8c5
#1437 1320173496000000 dread This can be fixed with one line of code, so I'm doing it for release 1.5.
#1315 1320173768000000 dread Tidied up in cset:39daf1afd64a for release 1.5.
#1437 1320173795000000 dread Fixed in cset:5d0bf20a1746 for 1.5. Broken since 1.4.3.
#1388 1320174229000000 dread Etags fixed in cset:a3c8d4f7cf91 for release 1.5.
#1373 1320174240000000 dread Squid force caching is now turned off on the main page, and etags sorted out in #1388.
#1034 1320174353000000 dread Same problem as #1321 I believe
#1436 1320230896000000 johnglover This also applies to CKAN core
#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.
#1436 1320243278000000 johnglover Fixed in branch feature-1371-task-status-logic-layer, will merge with default after 1.5 release later today.
#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.
#1107 1320321170000000 dread Notes to complete this: * ckan/logic/action/get.py:'def package_autocomplete' exists and is the one that should be used * need to ensure all places in the templates and public/scripts use this action directly, not dataset/autocomplete (or its alias package/autocomplete) * ckan/controllers/package.py:'def autocomplete' should be removed. * ckan/config/routes.py dataset/autocomplete should be removed.
#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?
#1443 1320432511000000 dread Fixed in cset:96b5d9af70a7 for release-v1.5
#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?
#1327 1320662446000000 rgrp Duplicate of #1397
#1217 1320663277000000 dread I haven't seen this for a while - could have been due to database corruption which has been fixed.
#1394 1320663304000000 dread I have half a fix for this at the moment.
#922 1320664187000000 rgrp Duplicate of #1032 (I think)
#958 1320664462000000 rgrp This was done as part of dataset resource editing in #1294 (duplicate)
#1433 1320666509000000 kindly Done but waiting to merge after 1.5 release.
#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.
#1454 1320849527000000 dread Done in cset:138c5daf7765 heading for release 1.5.1.
#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.
#1087 1320866159000000 dread Implemented in cset:0b7e2b0bed44 as status_show logic action, heading for 1.5.1 release. Took 0.5h
#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.
#526 1320930201000000 dread Is this still relevant or can it be closed?
#488 1320930240000000 dread Not a current reqt.
#1435 1320930310000000 dread Interesting. What's the reason to justify the effort?
#1456 1320930770000000 dread I see you've done this in cset:939e0e0809c1. Close now? BTW Take a look at the first suggestion from #1423 too, whilst in the area.
#1453 1320947955000000 icmurray Added the restriction of not allowing the double quote character, '"', as well as commas as this simplifies any use of quoting multiple words to mean a single tag name. For example, this simplifies the use of quotes in identifying tags in internal markdown links: {{{ tag:"multiple word tag name" }}} A possible solution is to allowing escaping, such as: {{{ tag:"something about \"Ian\"" }}} But I think the compromise is a better solution than allowing the escaping as it's simpler, and this may crop up elsewhere.
#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 }}}
#1298 1321199769000000 seanh I've been working on this in this branch: https://github.com/seanh/ckan/commits/feature-1298-activities-table
#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.
#1461 1321359503000000 dread Fixed in cset:6ea5d3c50444 so all functions supply api key.
#1449 1321465348000000 johnglover Basic change done in branch feature-1449-resource-listing. Currently showing: * resource name (clickable) or (none) * resource description * resource format * resource last modified (if exists)
#1470 1321540943000000 dread Adria put in fix cset:ad29e3ea75 but the model change missed a migration script and left some spurious tests broken.
#1470 1321543837000000 dread Tidy up done in cset:c46388b945d581 for 1.5.1 release and merged to master.
#1453 1321548452000000 icmurray The allowable characters in a tagname has changed to "unicode alphanmeric plus simple punctuation". This means: - alphanumeric (inc. foreign characters) - [ .-_] The completed feature is in the [https://github.com/okfn/ckan/tree/feature-1453-flexible-tag-names feature-1453-flexible-tag-names branch]. Awaiting a code review.
#1359 1321563082000000 rgrp Really annoying.
#1453 1321635178000000 dread Code review: * basically - really excellent code and very thorough :-) * links should have %20 rather than spaces (tests/misc/test_format_text.py:61) * also check unicode chars encoding in urls (tests/misc/test_format_text.py:115) * also check searching for the tag with this encoding (ckan/tests/functional/api/model/test_tag.py:35) * we follow the PEP8 coding style which I interpret to mean not having blank lines after a function definition. But whichever, we're not consistent from file to file, but we should be within each file. e.g. ckan/tests/forms/test_package.py:12. * moo package problem - need to ensure test works on its own and when run as part of the suite, so independent of whether moo exists. tests/functional/api/test_action.py: * best to make tag search case insensitive - see ckan/tests/functional/api/model * It's worth keeping the old test in addition to your modified one - because query for just {q:''} will return both packages too. ckan/tests/functional/api/test_package_search.py:203 * Let's add an example of tag search with quotes in /doc/api.rst:337 * Please put imports at the top of the file, unless there's a good reason ckan/tests/functional/api/test_package_search.py:296 * Can you not the old test any more? It seems sufficiently to the test you changed it to, so can we include both? ckan/tests/functional/api/test_package_search.py:295
#1472 1321721874000000 rgrp Done yesterday. See https://github.com/okfn/ckanclient
#1398 1321826380000000 kindly deployed on test.ckan.net docs added cset:47216c49fcec881f4eacc7170cb02d0a443500a2
#1474 1321826753000000 kindly fixed cset:8f3d917e24390f91db577fdbd8b8c6a1d6228505
#1433 1321827123000000 kindly cset: 68c37312ef70349431213465005761edf434d27e
#1467 1321872507000000 dread Leaving this to James to schedule
#1455 1321872633000000 dread John to look at.
#1394 1321872676000000 dread Not moved on during fortnight - keen to close this off.
#1473 1321872717000000 dread Done in cset:7733eb19971ff06e for 1.5.2
#1446 1321872724000000 rgrp Have made significant progress on new recline but not yet operational. See https://github.com/okfn/recline and https://github.com/okfn/recline/issues/6 https://github.com/okfn/recline/issues/12 https://github.com/okfn/recline/issues/8 also https://github.com/okfn/recline/issues/10 and more ...
#1463 1321874259000000 johnglover This works with the new Celery feature that will be in 1.5.1 (which should be released in this sprint). So, will not update this old version of QA for 1.5, people should use the new version (on okfn Github) after 1.5.1 is released.
#1468 1321875777000000 johnglover New ticket, moving over to new sprint
#1450 1321875986000000 johnglover Still working on this, moving to new sprint
#1451 1321876014000000 johnglover Haven't looked at this yet, moving to new sprint
#1479 1321961592000000 dread Fixed in cset:380eab620c7397 for CKAN 1.5.1.
#1453 1321965613000000 icmurray Updated code now in feature-1453-flexible-tag-names branch. (Also, deleted the ian-review branch.)
#1480 1321978546000000 dread Done in /api/util. Added length limits to mungers. Also added markdown test and documentation. Cset:e43009db393cb for 1.5.2
#1484 1322059006000000 dread Fixed and added tests. Improved IntegrityError error messages. Changeset:ddca1a7 for release 1.5.1.
#1486 1322061518000000 seanh Fixed here: https://github.com/seanh/ckan/tree/defect-1486
#1481 1322062707000000 johnglover Fixed in new dataset UX changes (branch feature-1450-dataset-view), still has to be merged with master.
#1401 1322066474000000 dread Patch from Augusto Herrmann for the icon URLs: http://pastebin.com/aRBQmftL
#1486 1322077524000000 seanh I've merged the fix for this into my feature-1298-activities-table branch, will merge it all into master at once: https://github.com/seanh/ckan/commits/feature-1298-activities-table
#1487 1322095808000000 kindly fixed cset:4160859c8c9786588dbf0893981b93d9621019a9
#1489 1322138014000000 dread I updated the theme stuff in a75ca84. I've asked Ian to see if he can replace the form stuff with a new form (v. quick simple!).
#1447 1322220690000000 dread This appears to have happened again today on test.ckan.net and someone has sorted it. The problem is visible on munin as inodes running out. * eu25 seems ready to fall over in about a week: http://munin.okfn.org/okfn.org/eu25.okfn.org-df_inode.html * thedatahub.org on s055 (and other fry instances) seem to have dynamically adjusted inode table size (by the kernel) so is less of a problem
#1488 1322241966000000 dread 'extensions' added. Also mounted RESTful version of status_show at: /api/util/status Done in cset:415d9ae aiming for 1.5.2 release.
#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
#1490 1322489155000000 amercader Fixed in c23821b
#1455 1322491506000000 johnglover Fixed - commit: https://github.com/okfn/ckan/commit/05b675a4314ad269c6e6a095d57e3f2a21e771eb Note: - Includes a small change to Solr schema file. - Search index will need to be rebuilt for changes to take effect
#1468 1322495417000000 johnglover Done - commit: https://github.com/okfn/ckan/commit/7789e85c973c9e085f623486bced6be14f25678f rebuild can now take an optional package name/id (single package to be consistent with other paster commands, not a list of packages)
#1002 1322515684000000 dread I've redone these changes in cset:91258a6296db71d78a on master, aiming for 1.5.2.
#1491 1322563620000000 seanh I've finished some work on this ticket here, ready to be reviewed: https://github.com/seanh/ckan/compare/defect-1491-visible-strings-need-internationalisation
#1451 1322567112000000 johnglover This was taken from the UX pad. I'm looking at it now to make sure that it's working and that we can use it on the new dataset view page. Is it really a good idea to move it to core though? There was no reason given on the pad so I'm not sure why this should be moved to core?
#1451 1322568784000000 dread With the cron job setup, maybe this is best left as an extension. The core CKAN was designed to be mean and lean.
#1497 1322569805000000 dread Got rid of this one that appears on many CLI commands: {{{ /home/dread/gitroot/pyenv-ckan/lib/python2.6/site-packages/pylons/templating.py:610: UserWarning: Unbuilt egg for setuptools [unknown version] (/usr/lib/python2.6/dist-packages) Engine = entry_point.load() }}} cset:e1e2918 Look out for others and reopen when found.
#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! :)
#1453 1322581830000000 dread I believe this is finished now. This was merged into master in cset:c0aaa31c4b7ded54d and headed for release 1.5.2.
#1499 1322591888000000 dread Done in cset:9d97592 on master aimed for release 1.5.2.
#1468 1322591997000000 dread We originally talked about a command-line interface for deleting packages. I've done this here: #1499. Note: you can update the search index from a paster shell, simply by doing this before running your commands that edit packages: {{{ from ckan import plugins plugins.load('synchronous_search') }}}
← 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 →
Note: See TracReports for help on using and creating reports.