{23} Trac comments (3729 matches)
Results (1301 - 1400 of 3729)
| Ticket | Posixtime | Author | Newvalue | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| #364 | 1291637291000000 | rgrp | Have now switched to solr search (and maybe working in postgres by now). Note correct link is http://ckan.net/package?q=statistics | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1761 | 1328703769000000 | ross | Have overridden the history function in the DGU package_gov3.py controller to make sure the viewer is in at least one group. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2513 | 1340187230000000 | ross | Have pushed back to 1.9 but if may be the the converter service will replace it in the meantime. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #833 | 1295263447000000 | rgrp | Have repo https://bitbucket.org/okfn/ckanext-admin | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #447 | 1294410738000000 | memespring | Have you got a link or screengrab? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1451 | 1321876014000000 | johnglover | Haven't looked at this yet, moving to new sprint | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #463 | 1294916148000000 | dread | Haven't seen this for ages. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #435 | 1298284084000000 | thejimmyg | Haven't seen this myself and it is 6 months old now. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #864 | 1291741028000000 | memespring | Havent implemented all text changes because worried about impact on other themes. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1737 | 1336328947000000 | rgrp | Having now thought about this I'm re-opening this ticket for the following reasons: * No real documentation (other than that in this ticket yet available) * It would also be nice to know how this maps to SOLR API (can i use all of the facet options solr provides or not ...?) * And I would again emphasize my preference for having *direct* access to something that looks *exactly* like SOLR API as I can then use client and docs from SOLR to work with it. * No clear resolution of separation between Action and REST API (and search API). Really seems to me there should be convergence between latter 2 (as suggested in the ticket) -- this would also resolve the problem that having GET /api/dataset return all datasets is *not* a great idea * The Action API requires a POST request. Since the primary purpose of the search API would be usage from JS it would be nice if GET and JSONP were supported. (Though given our CORS support we could argue this was optional). Not saying *all* of this needs fixing but some clear approach here would be useful | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #972 | 1310134129000000 | thejimmyg | Having thought about this more David Raznick and I have decided to stick with separate extras for the timebeing. Mainly because of internationalisation issues. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2445 | 1338472966000000 | ross | He didn't say but I assumed yes given current impl uses dodgy JS->API. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #881 | 1294410574000000 | thejimmyg | Hello fccoelho, Could you please post the output you get from running pip? Thanks, James | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1040 | 1328806824000000 | dread | Here are all the CKAN instances potentially involved in this issue: == ckan.net / DGU == These suffered this problem briefly and were fixed 15/3/11 == opengov_es http://opengov.es/ 1.2 == This does not have a theme extension. Is not serving files from root. == nosdonnees_fr http://www.nosdonnees.fr/ 1.3.1a == This does have a theme extension but does not seem to have a trailing blank public path since it is not serving files from root. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #698 | 1292596589000000 | Stiivi | Here is the fork for (json) data proxy: https://bitbucket.org/Stiivi/dataproxy I've refactored it and moved transformations into separate modules. For each resource type there should be a module in transform/<type>_transform.py Each module should implement ``transform(flow, url, query)`` and should return a dictionary as a result. Existing modules: * transform/csv_transform - CSV files * transform/xls_transform - Excel XLS files if there is no resource_type module, HTTP 200 Error Resource type not supported is returned. You can override URL file extension or specify type if extension is missing through type= URL option. For example if you have any URL that contains CSV data however the url is just foo.com/data then you can pass: url=http://foo.com/data&type=csv Note: Source refactored/updated in example/dataproxy, being tested by running locally localhost:8000. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1004 | 1323187352000000 | dread | Here is the unclipped version: {{{ <p> <span i18n:msg="" class="ckan-logged-in" style="display: none;"> <a href="${h.url_for(controller='group',action='new', id=None)}">Create a new group</a> </span> <span i18n:msg="" class="ckan-logged-out"> To create a new group, please first <a href="${h.url_for(controller='user',action='login', id=None)}">log-in</a>. </span> </p> }}} {{{ <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}" class="ckan-logged-in" style="display: none;"> ${h.subnav_link(c, h.icon('group_add') + _('Add a Group'), controller='group', action='new')} </li> <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}" class="ckan-logged-out"> ${h.subnav_link(c, h.icon('group_add') + _('Log-in to add a Group'), controller='group', action='new')} </li> }}} | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #318 | 1349778662000000 | dread | Here's a real example - one of many from MOD {{{http://www.dasa.mod.uk/applications/newWeb/www/index.php?page=48&thiscontent=180&date=2011-05-26&pubType=1&PublishTime=09:30:00&from=home&tabOption=1}}} Browsers accept colons and slashes happily, which is the main usage of our links. The URL looks better with the colons and slashes, rather than the encoded version. The average departmental user doesn't understand that the reason to encode them is for some academic RFC and RDF which is not "liberal in what it accepts". Since the RDF tool has a satisfactory way to encode links, this problem is essentially solved. Therefore I'm changing ckanext-archiver to accept these unencoded links, I'm afraid. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1683 | 1326976925000000 | dread | Here's someone else with the exact sorting problem: http://lucene.472066.n3.nabble.com/last-item-in-results-page-is-always-the-same-td2513423.html | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2722 | 1343060105000000 | shevski | Hey, I only mentioned bug 2 here because I'm pretty certain this already exists as a separate ticket. Have definitely reported it before, but i think someone else created the ticket - so just wanted to remind that this hasn't been fixed either yet. What's the best way to do this in future? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1175 | 1314030683000000 | dread | Hi Flavio, is this still a concern? I'd like to close this ticket unless you can provide details of the error from your logs or exception email. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1183 | 1311181719000000 | thejimmyg | Hi John, Can you have a look at this one too please? Cheers, James | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1062 | 1311178145000000 | thejimmyg | Hi John, Can you please check that the new webstore+preview works correctly with this one please? Cheers, James | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1150 | 1311178163000000 | thejimmyg | Hi John, Can you please check that the new webstore+preview works correctly with this one too please? Cheers, James | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #447 | 1294410666000000 | thejimmyg | Hi Richard, could you take a look at this please? It is probably invalid now, in which case feel free to close it. Many thanks, James | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1197 | 1340018903000000 | seanh | Hi Toby, yes I think I agree with you, it reminds me of when I install new Android apps on my phone, some of them start off by bothering me with some sort of guided tour or long instructional text, I hate this and always skip through without reading it, expecting to be able to figure out the interface for myself. The one thing that something like this could be useful is, rather than showing someone how to use the site, showing them what the site is capable of so they can assess whether it meets their needs/is something they're interested in. However, we already have a good guided tour of this type on ckan.org/features, those pages are really pretty good. Close this as wontfix? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #936 | 1298283172000000 | thejimmyg | Hi Wayne, I'm assigning this to you but it isn't a priority yet. We'll put it in a sprint when it is time to do it. Cheers, James | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2454 | 1339493727000000 | aron.carroll | Hmm, I totally agree with you on the missing username front but it would be nice at least to provide the errors in the same way we do the other forms. Currently it just displays a flash message which is unexpected. I'd suggest we add a generic "failed to login, invalid fields" in the error_summary block. Then more specific "this field is required" when a required field is left empty. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2668 | 1343130433000000 | ross | Hmmm. dread, are you merging these into master yourself? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #949 | 1297074827000000 | rgrp | Hocus pocus so set owner after being fixed! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #214 | 1263057591000000 | nickstenning | Hover names haven't been addressed yet. Otherwise mostly done. Closing. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #799 | 1294232675000000 | thejimmyg | How can we tell a WAF document has changed, we simply need to re-harvest it to see surely? Moving the issue to ticket #728 to be dealt with together. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #936 | 1303117147000000 | thejimmyg | How is this coming on John? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #750 | 1294408970000000 | thejimmyg | How would this be done? Is it part of the CSW spec? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1737 | 1337942345000000 | rgrp | I *strongly* disagree re access to solr API -- i don't really care if it is direct but I want something that looks like it at least for core query parameters and facets ... Is there some major issue around security etc (e.g. limiting to only public datasets or similar?) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2445 | 1338542340000000 | ross | I *think* this is done in feature-2445-add-related-new although I may have missed something, if you could take a look and let me know if it is what you wanted. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2361 | 1337016768000000 | amercader | I actually spent some more time of this because I upgraded PDEU to CKAN 1.7, which was needed to fix the search index and a good testing for the release as well. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #679 | 1294166120000000 | dread | I added some extra bits in cset:1ca7ba29d409. Resource formats disagree between DGU and the FAQ - have sided with DGU for now as it's simpler. I think this ticket is complete now. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1477 | 1324549459000000 | dread | I added the sub-tickets since this tickets already covers them really. They may provide useful details in the course of doing all this. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1011 | 1298821699000000 | rgrp | I agree that IAuthorizer is useful but not sure how it addresses the requirement of the ticket. AuthorizationGroups are already editable via the web interface at /authorizationgroup | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1104 | 1303920492000000 | dread | I agree this should be fixed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #662 | 1286991079000000 | dread | I agree we should not have the 'read-only' things like Ratings in the default returned Package Entity. What do you think of having a parameter to be able to get these if you want them though? Do you mean you *can* re-post the *entity* post response? Not sure what you mean by "An issue for CKAN too."? In addition to this ticket, what do you think about changing the behaviour of the Package Entity PUT/POST, so that you replace the entire Package, not just the fields you specify? So you don't keep left-over values, just because you didn't specify them as null? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #876 | 1293218714000000 | anonymous | I agree with all your points about testing apart form using sqlite, especially splitting out the functional tests and continuous integration. > Longer term I agree that it would be better to run local tests against postgres too, but that will I think involve refactoring many of the tests. Well there are two options 1. refactor the tests 2. refactor the code to use sqlite and postress It is a value judgment as to which is more complicated. I personally think 2 is more complicated but may be wrong on that. The real danger with 2 is that you are needlessly adding complication to production code, with 1 you are only changing the tests. Upgrading to sqlalchemy 0.5+ should happen first regardless. You will need upto date documentation. There is another option too. Put the postgres data directory on tempfs/ramfs and turn off durability [http://www.postgresql.org/docs/9.0/static/non-durability.html here]. We would need a way to db init before the tests where run (or) at boot). This may be the best of both worlds. Anyway Happy xmas!! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1740 | 1328094884000000 | dread | I agree with getting rid of {{{from module import *}}} and the approach suggested. However, I really disagree with getting rid of {{{from x import y}}}. In particular we have a strong convention of using this for ckan.model. It is a valuable abbreviation as it is used so much in the logic layer and tests. If someone should accidentally reassign the value of model to something else then I believe it is simple to see what has gone wrong. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1044 | 1300382367000000 | dread | I agree with leaving #1001 solving this issue. Centralising this is good. This ticket can instead focus on: * returning the correct 403 error (rather than the 302 currently) * creating some tests * documenting * consider renaming the SITE_READ variable and rethinking purpose | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #940 | 1296807699000000 | rgrp | I agree with pudo (though it would not be the end of the world if these were treated as the same realm!). I've now created a permanent redirect for www.ckan.net to ckan.net. {{{ RewriteEngine on RewriteCond %{HTTP_HOST} ^www\.ckan\.net$ [NC] RewriteRule ^(.*)$ http://ckan.net$1 [R=301,L] }}} | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1709 | 1327620218000000 | rgrp | I also note there is an error with how importing was working (re top level imports in lib/search.py) that meant simple_search was broken. I've fixed this locally and raised with Ross (whose commit triggered the problem) ... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2454 | 1338994536000000 | toby | I am against providing much more that you did something bad things like invalid username leak info - people should not know if usernames exist. Maybe I'm a bit mean about this. I'd be happier to add some javascript check on the form post that checks for no password etc - maybe that's not so practical | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2440 | 1339581622000000 | toby | I am changing this to assigned not accepted as this makes trac easier to use | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1109 | 1305124697000000 | kindly | I am happy this is fixed in cset:445fc04333dd. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #998 | 1298371191000000 | anonymous | I am happy to get rid of paster db create altogether as a compromise? Or add a depreciation warning to it? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1137 | 1305217449000000 | kindly | I am not sure this needs to be done. I think we should keep the continuity object always in the table, even if it is deleted. The querying should be done through the logic layer so the deleted state should not be an issue. The clients should be entirely state aware. The only thing that needs to be done is to remove all statefullness of relations. These are the only things that are complicated. This would make vdm just a simple copy on write mechanism, with the client controlling the state. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1240 | 1314180488000000 | dread | I basically agree, but just thought I'd add a couple of comments into the mix. > GET at root returns whole package set (a *bad* idea) Sure it has a cost, but I don't see what the problem with this is if the list is cached. Forcing developers to paging through the list of packages is putting unnecessary obligations. I'd say that the top two RESTful operations are listing objects and getting a particular one, and you'd be taking away one of those. > Unify on /api/v{version num}/... structure Where is it not currently unified? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1214 | 1310062621000000 | dread | I believe "A PUT request without a body throws a 500 Internal Sever Error" was fixed yesterday in the code. (Not deployed to test.ckan.net yet though) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1467 | 1326119954000000 | dread | I believe that the "publisher issue" that James alludes to is that the dump doesn't contain the 'parent publisher' field that is generated in the DGU system on the Drupal side. This information will be stored following the Groups Refactor #1477 and should be added to the dump at this point. Excluding Datasets that are state=deleted is a good idea. I've split that off into #1623 The other issues mentioned are simply data quality - the same whether viewing the dump or elsewhere. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #460 | 1285443859000000 | [email protected] | I believe the initial report is incorrect. It states that the status was changed from "active" to "deleted". I believe that it was actually changed from "active" to "None". This might indicate a bug in the code: The value of the status field is lost. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1452 | 1340190587000000 | ross | I believe this has been addressed by Toby. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1453 | 1322581830000000 | dread | I believe this is finished now. This was merged into master in cset:c0aaa31c4b7ded54d and headed for release 1.5.2. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2671 | 1345209579000000 | toby | I believe this is fixed in master/2375 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1258 | 1319812452000000 | dread | I believe this was broken with the introduction of moderated edits in CKAN 1.4.3 and this fix went into 1.5. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1360 | 1317315031000000 | dread | I believe zephod has removed these from the UI already. I removed them from the search code, tests, docs and provided suitable guidance in cset:5b20ae1673ea which is headed for CKAN 1.5. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2691 | 1342542047000000 | shevski | I can replicate the 404 error. Follow steps below 1. Click on add a new dataset 2. Name it and put an incorrect character in tag field "e.g. " :" 3. Click on 'Next: Add Data' 4. Error message shows, wipe tag field (i.e. delete " : " until field is blank 5. Click in 'Next: Add Data" again | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #700 | 1288562082000000 | rgrp | I can verify that groups are getting lost on package preview on ckan.net (steps: 1. click edit, 2. preview 3. look at edit form and group has disappeared). Given this is a bug on a production service it is urgent this gets fixed. @pudo: please can you confirm your expected fix date on this? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2471 | 1352206679000000 | johnmartin | I can't context on this. Closing. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1701 | 1330084925000000 | dread | I can't find these changesets - am not sure which release this is in. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2446 | 1352206530000000 | johnmartin | I can't get access to said project. Can someone please give me access so I can triage this? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2451 | 1352206567000000 | johnmartin | I can't get access to said project. Can someone please give me access so I can triage this? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2457 | 1352206516000000 | johnmartin | I can't get access to said project. Can someone please give me access so I can triage this? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2641 | 1352206794000000 | johnmartin | I can't get access to the project... can someone link me? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1238 | 1311583876000000 | kindly | I cannot reproduce this, to me it looks like it does get the correct revision. If you for example look at the package a millisecond before i.e http://ckan.net/package/osm%402010-11-30%2000%3A21%3A49.627829 the tags are no longer there that were added in that revision. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2855 | 1345104178000000 | shevski | I cleared my cache and it's working now | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #263 | 1277717180000000 | rgrp | I consistently get sent to google login even though I choose openid meaning I am unable to login! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #276 | 1271250866000000 | dread | I could not recreate this. I think it is only for particular packages? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1285 | 1323173125000000 | thejimmyg | I could write some middleware to handle this. Can we come up with a list of exceptions not to catch or should I create a base exception called "NoEmailReportTriggeredException()" which exceptions for this purpose have to be derived from or which code has to raise? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1532 | 1323956004000000 | dread | I couldn't see a way to communicate the situation "OpenID authenticated, but doesn't match any CKAN user" from the repoze middleware to CKAN. So in [release-v1.5.1c 9e86c8b] I have provided extra instructions in the OpenID log-in screen, and in the log-in error message suggest what could have gone wrong. This issue appeared in 1.5.1b and fixed in 1.5.1c in time for the 1.5.1 release. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #937 | 1297689781000000 | sebbacon | I did a very quick hacky thing at the end of last week on top of the "insert google analytics code" extension we discussed, to work out "most popular packages" based off data harvested from the Google Analytics API. Needs making generic, tests etc but could be a starting point: https://bitbucket.org/sebbacon/ckanext-googleanalytics/src | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #536 | 1286376029000000 | dread | I did this a few weeks ago. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2734 | 1343061994000000 | shevski | I did this with a dataset I just created, 5 mins before creating this ticket Tried it again with a new datasrt, happened again. It's when you're editing a resource | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #139 | 1255188974000000 | dread | I didn't manage to create duplicate tags - must be the old code. I fixed this particular package in ckan. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #989 | 1297706620000000 | kindly | I do not think we need to 'extend the model' if you intend to make the migrations separate. If the schema is decoupled, then there are no problems. So each plugin can have its own model and use sqlalchemy independently i.e have their own metadata, classes and mappers. They do not have to even use sqlalchemy. What I mean is that there is no need to do anything apart from. * Agree on a naming convention of the plugin tables (including their own migrate table each) * Agree to the rule that no plugin can add a column to an existing table. * Agree that no table can have a (database level) foreign key constraint between the core tables and itself in either direction. They *can* have implied sqlalchemy level joins. * Maybe have a hook that on db upgrade all plugins are upgraded. Each plugin will have to redefine the tables, classes and mappers they need to join onto the core tables themselves. reusing/extending the core model will not be worth the trouble. This seems to cover your use cases and this way everything is nicely decoupled. Best of all there is very little work to do... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1784 | 1328615106000000 | dread | I don't agree. I think we have a good compromise at the moment, where you have readable URLs, and people can change names if they want to. Names are changed only occasionally. The CKAN site adjusts all its links automatically of course. External blog posts may have incoming links, and these would break, but it's not difficult to search for a dataset. If we're really worried about this then we should provide a 'permalink' somewhere on the Package / Group / Resource page. In the meantime, I suggest changing the Activity Stream links to be with names. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #770 | 1296593925000000 | thejimmyg | I don't care about this. It is too trivial. If I get around to fixing it they great but I don't need it logged as a ticket. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #368 | 1291831811000000 | thejimmyg | I don't have enough information to debug this problem. I'm assuming that since this has been a while that the problem is solved? If not please re-open the ticket and add your contact details. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #972 | 1300219509000000 | thejimmyg | I don't really agree with this. In fact I'd rather move further away from auto-magic key value pairs stored in JsonTypes. Can we discuss on Skype please? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #801 | 1296593735000000 | thejimmyg | I don't see why we'd really need to do this. Under the current system a job would be created just before the harvesting would be run so the creation date of the job is (give or take a few seconds) the date of the harvesting. If we moved to a queue system this would be done better anyway. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #888 | 1307352537000000 | thejimmyg | I don't think any progress has been made on this for a bit so I'm assigning it to me. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1343 | 1316078440000000 | dread | I don't think email confirmation is necessary - see discussion at #1319 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #982 | 1297525477000000 | rgrp | I don't think i understand why this has been closed (and it would surely be wontfix rather than invalid ...). Let me explain in more detail: we would move to having one and only one pip-requirements.txt in the repo at any given revision and it would simply have the correct info for whatever branch/revision it was on. At the moment we are having extra pip-requirements-....txt for labelling branch pip-requirements when we could just the branching facility of mercurial. You'd do {{{ wget http://bitbucket.org/okfn/ckan/src/metastable/pip-requirements.txt }}} rather than {{{ wget http://bitbucket.org/okfn/ckan/src/default/pip-requirements-metastable.txt }}} | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2678 | 1342461370000000 | aron.carroll | I don't think there's actually any logic in CKAN to let you delete a related item at the moment. So assigning to Toby to take a look. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1122 | 1306662099000000 | pudo | I don't think there's really a nice way to do this with the current solr indexing library, but I've commented out the list handling code which should really make handling this cleaner. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1085 | 1302621951000000 | rgrp | I don't think this is very useful output :) Most of this is test/demo/rdf and therefore not relevant. Also have you checked your ckan.site_url in your development.ini -- which configures where what is used as based for all external urls in the templates? IMO there is nothing to fix here. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #559 | 1310126313000000 | shevski | I don't understand this one. It is older than 6 months so marking invalid. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #611 | 1294408239000000 | thejimmyg | I don't understand this task, but suspect it can be treated as a duplicate of #569. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #446 | 1294414077000000 | thejimmyg | I don't understand this ticket. Since no-one has contributed to this ticket in 5 months I'm closing it. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1004 | 1323174597000000 | thejimmyg | I don't understand. We just had a team meeting about this, all discussed it and agreed to close it. Yes, you get taken to the login page, but that is the correct behaviour. The problem in the past was that the link was in the yellow box and there was no explanation as to why you had to login. This time you click from the header bar and there is a clear message saying "Unauthorized to create a group" - exactly as a user would expect. Even if the exact text of the ticket description isn't fully implemented in the current release, the UX isn't broken anymore. Yes, it might be even nicer to have a message warning them in advanced but these improvements will be taken forward in the UX work - maybe there is an even better solution than a message? Since you are unhappy about closing it I'm marking it as "Duplicate" of #1521. As agreed earlier with the entire team, we'll take this forward as part of the groups refactor. See #1521 for more information. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #274 | 1287398398000000 | dread | I fixed the docs a couple of weeks ago. Need to ensure there is a test though. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Note:
See TracReports for help on using and creating reports.
