{23} Trac comments (3729 matches)

Results (801 - 900 of 3729)

← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 →
Ticket Posixtime Author Newvalue
#1633 1326736502000000 seanh This is finished, see the activity streams branch: https://github.com/okfn/ckan/tree/feature-1515-activity-streams but I think that before closing this ticket a little more thought needs to go into what the activity streams and the dataset page should look like, where on the page they should go, what else should go on the page, etc. Also maybe add a simple test that the activity stream is being rendered into the page.
#1496 1326736298000000 seanh This is finished, but I think that before closing this ticket a little more thought needs to go into what the activity streams and the user page should look like, where on the page they should go, what else should go on the page, etc. Also maybe add a simple test that the activity stream is being rendered into the page.
#1729 1328537269000000 johnglover This is essentially a duplicate of #1720. We do not really need helper functions for this (as it's trivial to get the default schema and add 1 extra key), but I have added a converter for tag string (with vocab) to tag and vice versa.
#1012 1300352334000000 kindly This is entirely not trivial at the moment. Hopefully after the dictization it will become more so. Simply putting in the package revision object in place of the package does not work. It will obviously work for changes to the package object itself. However, there are no mappers on that object for getting out the related package_tags, resources and extras at that revision. You will have to construct a fake pkg object with some messy and painful queries using dates.
#109 1291829457000000 thejimmyg This is effectively implemented by the util API; http://knowledgeforge.net/ckan/hg/file/tip/doc/api/version2.rst John has a separate proposal to move the util API into the REST API but that is a different discussion. Here's how you can now search on tags: /api/2/util/tag/autocomplete?incomplete=ru
#695 1287677169000000 ollyc This is down to blinker not persisting the signal objects. Although the docs claim: "Every call to signal('name') returns the same signal object, allowing unconnected parts of code (different modules, plugins, anything) to all use the same signal without requiring any code sharing or special imports" This isn't true unless you maintain a reference to the signal object. To demonstrate this: {{{ >>> import gc >>> from blinker import signal >>> signal_id = id(signal('Package')) >>> gc.collect() 0 >>> id(signal('Package')) == signal_id False }}} The synchronous notifications code connects to signals without storing the signal objects, which are subsequently garbage collected and hence never fire. The async notifications stores references to all signals as a class attribute, so this problem is not seen when async notifications are enabled.
#887 1300196600000000 thejimmyg This is done. See https://bitbucket.org/okfn/ckanext-harvest At the moment we are not adding migrations to remove the harvesting tables. We are designing a harvesting refactor and will write migrations once the refactor is complete so that instances that use harvesting get upgraded, and those that don't get their harvesting tables removed. Also, see this #1030 for the moving harvesting out of the REST API.
#1477 1328016209000000 kindly This is done pending new superticket publihser_profile. (#1669)
#1252 1317315135000000 dread This is done now?
#806 1290071159000000 dread This is done now I think? Please list changesets, time taken vs estimate and close ticket.
#427 1299164063000000 thejimmyg This is done in the latest release to test.
#164 1271251422000000 rgrp This is done in semantic.ckan.net. Docs at http://wiki.okfn.org/ckan/doc/rdf/
#184 1266837414000000 dread This is done in cset:d2026bcf43f5 cset:ac7cf572cbf9 cset:51c6de2dc390 cset:58c660932fcf cset:dd9761591ffb
#353 1280756379000000 pudo This is done as of cset:8 (of ckanext!)
#1563 1324314806000000 rgrp This is done and invalid to add this again.
#43 1214244140000000 rgrp This is currently low priority and should only happen after move to vdm 0.2 (sqlalchemy etc).
#1112 1304358643000000 dread This is complete in the branch feature-1112-allow-search-all for release 1.3.5
#1116 1304358664000000 dread This is complete in branch defect-1116-boolean-search-options for release-1.3.5
#480 1300281551000000 thejimmyg This is complete (albeit with a different architecture).
#2863 1345122876000000 ross This is changeable in config. The default permissions are specified in there I believe.
#402 1281373707000000 pudo This is beginning to go somewhere: * http://bitbucket.org/pudo/ckanextarchive
#1447 1340726283000000 nils.toedtmann This is becoming painful for the sysadmins. Please fix.
#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.
#1735 1328531105000000 zephod This is an edge case, and there's no simple fix -- you can't detect *why* the tags box has lost focus -- so I think let's not waste time inventing something complicated.
#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.
#2331 1337782689000000 kindly This is a wontfix. I think terms should be ored by default. All modern search engines work like this. If there is an issue due to relevancy (i.e if you type mulitple words and your result not coming near the top) then we should use this examples so we can tweak the results.
#829 1303838115000000 rgrp This is a wontfix for the present.
#1091 1303746408000000 rgrp This is a well known issue (see some discussoin in #142). There is nothing directly we can do about it (this is what google gives us) but we could make usernames editable (this has been discussed but not ticketed I believe). Given our general "downer" on openids I'm not sure this is a big priority.
#256 1290463475000000 dread This is a test
#486 1291639321000000 rgrp This is a requirement ticket which we no longer support and a duplicate #847.
#2873 1345136489000000 toby This is a problem with the summary data not the resource qa score it is almost certainly due to stale data. keeping here till resolved
#2780 1345023811000000 toby This is a new feature moving to phase 4
#2411 1338210872000000 toby This is a long term goal
#1219 1310471415000000 dread This is a known issue and of low importance.
#781 1294415081000000 thejimmyg This is a duplicate of #812 so closing.
#795 1296593361000000 thejimmyg This is a duplicate of #794 because if we needed to do this it would be because we need to support harvest sources registered on behalf of publishers by agents,
#766 1296593519000000 thejimmyg This is a duplicate of #767
#563 1296592472000000 thejimmyg This is a duplicate of #496
#815 1294410951000000 thejimmyg This is a duplicate of #234. Please have a look at existing tickets or re-open closed ones rather than adding new ones so that we can keep the old discussions. I've added your point to #234. Thanks!
#1200 1311180218000000 thejimmyg This is a duplicate of #1108. Let's have the discussion there please.
#345 1291831615000000 thejimmyg This is a bit out of date. We have moved to a system of "stable" and "default" branches with feature branches for features, bugs and tickets. We already have default and stable tested by buildbot.
#646 1294413500000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#744 1294412813000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#745 1294412820000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#746 1294412827000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#747 1294412834000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#564 1294412714000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#743 1294412807000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#1030 1300103984000000 amercader This includes: * Take out all references to harvestsource, harvestingjob and harvesteddocument in the rest API * Move the harvesting bits of ckan/lib/cli.py into ckanext-harvest. * Move ckan/controller/harvesting.py and cknan/model/harvesting.py to ckanext-harvest as well * Update ckanext-csw to be able to find the code it needs in the new place.
#2383 1337872916000000 icmurray This helper function won't parse UTC offset if passed a UTC offset as "+01:00"; but incorrectly parses the UTC offset "+0100" as 100 microseconds. Resolution: - I've decided to keep the behaviour of not parsing UTC offsets because we currently don't store timezone information in the database; and I think that either dropping the tzinfo, or adjusting for it would appear to be "magic behaviour" from the user's perspective. Also, as this is a helper function, I think it makes sense to keep the behaviour as is, even if it's slightly non-standard. This fix [1] maintains all the old non-ISO behaviour: - not allowing UTC offset to be specified. - arbitrary delimiters between date and time values. - microsecond precision. But won't parse "+0100" as microsecond precision. I tried using a couple of python modules for parsing date strings; but none maintained the same behaviour. [1] https://github.com/okfn/ckan/commit/d6c9e48f8df5e926abd3fb1a1607f4f5a30075b4
#321 1291831399000000 anonymous This has now been superseded with this proposal: #787
#987 1311177705000000 thejimmyg This has largely been implemented now for publicdata.eu. There is a CREP #1134 outstanding to take the harvesting to the next level so marking this one as duplicate for now.
#1380 1324048324000000 dread This has gone into v1.5.1.
#1453 1329395697000000 dread This has gone into release 1.6.
#1608 1330036982000000 dread This has gone into CKAN 1.6
#782 1289218497000000 pudo This has existed for quite a while, but misses documentation. Has been documented in cset:db18a16a5b4d
#1533 1338202636000000 ross This has been superceded by #2234
#651 1311169144000000 thejimmyg This has been open for more than 6 months so closing it. It may even have been fixed in John's auth refactor.
#232 1297246297000000 thejimmyg This has been here for over a year and is not a technical ticket. Suggest we close it?
#681 1288036387000000 rgrp This has been fixed.
#1207 1311325343000000 dread This has been fixed.
#2631 1352205778000000 johnmartin This has been fixed with the LOD2 work on activity streams.
#865 1295259773000000 pudo This has been fixed on the respective branch and merged into default..
#1804 1330347185000000 toby This has been fixed in master for a while and was only a 1.6 issue
#244 1271248968000000 dread This has been fixed by Benoit (backed out changes, waiting for upgrades to babel / genshi)
#820 1311325226000000 dread This has been fixed
#123 1254321447000000 dread This has been done, starting with cset:7d8bada15d88.
#1218 1310385419000000 dread This has been done in cset:bd0f83a2e287 for release 1.4.2. Deployed to ckan.net.
#108 1252318938000000 dread This has been done in changeset:ec90f59040e0.
#681 1290507180000000 dread <[email protected]> This has been deployed now.
#1051 1301305079000000 sebbacon This has been completed in https://bitbucket.org/okfn/ckan/changeset/64a949990e0b
#836 1302882808000000 dread This has been a (minor) issue since release v1.3
#1256 1312409296000000 kindly This has also caused problems in authorization for deleted packages.
#2620 1342074737000000 toby This got fixed at some point
#1521 1327080136000000 zephod This function can be deprecated, as groups will use Solr searching to list their packages. https://github.com/okfn/ckan/blob/master/ckan/logic/action/get.py#L398
#1597 1324550545000000 dread This feature is requested by Colin Calnan
#1236 1323090508000000 dread This feature is now released, but there is a remaining bug which I've put in this ticket: #1509
#316 1274366801000000 dread This exception occurs for ckan.net with just this one character: http://ckan.net/package/search?q=%C2 (you can wget it) But I can't recreate it on my machine. Maybe it's a version issue. The client that is making all these crazy calls is googlebot.
#1267 1312890962000000 dread This error has been occurring on at.ckan.net which has webob 0.9.7.1-1
#1175 1325355170000000 dread This error (which will be in the apache or ckan log) must be unrelated. Stats extension runs fine elsewhere.
#690 1288013610000000 johnbywater This concern was resolved in favour of a converged set of attributes (#711).
#1006 1298631145000000 dread This command is slightly different to your branch policy as of two weeks ago: {{{ stable: stable code metastable: (will soon be deprecated) for code preparing to be stable default: development HEAD }}} which I prefer. My ideal would be to get rid of the confusing name 'metastable' and unneeded 'stable' and start a new branch called 'released', which will act the same as 'master' in this diagram but with a more intuitive name: http://nvie.com/posts/a-successful-git-branching-model Then for each ckan instance we can either use the most recent release (from 'released') or choose a specific one (e.g. 'ckan-1.3' or even 'default' or 'enh-865' for getting latest features). This gives a good degree of flexibility, is more understandable to newbies and probably a more widely understood branching model.
#2579 1340899337000000 toby This can move to 1.9 as will need agreement to be merged
#1286 1342436420000000 dread This can happen now, if it hasn't already.
#1437 1320173496000000 dread This can be fixed with one line of code, so I'm doing it for release 1.5.
#1054 1301305615000000 dread This branch is now merged.
#1345 1337961353000000 nils.toedtmann This becomes an actual problem on the CKAN farm s057, see http://trac.okfn.org/ticket/1245
#2428 1341234933000000 seanh This awaiting merge, pull request: https://github.com/okfn/ckan/pull/46
#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
#1226 1314029434000000 dread This appears to have gone away. No sign of it for two weeks on any OKF sites.
#1214 1314029628000000 dread This appears to have been fixed by version 1.4.3.
#817 1297073724000000 thejimmyg This appears to be fixed now.
#1331 1325355631000000 dread This appears to be fixed in 1.5, 1.5.1 and 1.5.2a.
#2292 1335021860000000 rgrp This annoyed me so much I just fixed it: https://github.com/okfn/ckan/commit/5eca7d5e37c0ef392b768b8b3768b2c3f93448b5 Issue was that our auto-completion depended on structure of the HTML which changes with bootstrapification. BTW: have deployed this via copy and paste on datahub so i can use it. Will want to revert this when you do a deploy. @Ross: I note that the same bug probably affects organization auto-complete.
#1055 1300987241000000 dread This amounted to 14 tests. Fixed in cset:5bbd0005c57e ready for ckan release 1.4.
#2968 1350297070000000 seanh This also applies to other pages such as /member_new and /member_delete
#1436 1320230896000000 johnglover This also applies to CKAN core
#1197 1340019675000000 toby Thinking horrible thoughts, there was a rumour of a ckan tour, for something like that this would be useful. Not sure where that plan is at? if there is a ticket for it maybe link to this one and close?
#59 1272468398000000 rgrp Think we should resolve this by: * Removing guide page. * Putting a link to ckan user guide (http://wiki.okfn.org/ckan/doc/) in RHS sidebox on front page along with other links ... -- can this link url be made a config option in ini (defaulted to that url on load in lib/base.py or wherever it is loaded) * Move current content of guide (one item about bookmarklet) to http://wiki.okfn.org/ckan/doc/faq/
#1044 1300359562000000 rgrp Think this would be resolved by refactoring implied in ticket:1001 (specifically checks for api key and remote user should lead to availability of same set of identification information).
← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 →
Note: See TracReports for help on using and creating reports.