{23} Trac comments (3729 matches)

Results (2901 - 3000 of 3729)

← 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 →
Ticket Posixtime Author Newvalue
#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.
#681 1287160548000000 dread Looks like integration with drupal is the problem here. I'm writing tests.
#681 1288036983000000 dread The code is fixed, but not yet deployed, which requires time.
#682 1297358266000000 dread Various improvements to ckanclient to enable this: cset:1bfefd7596d3 and cset:47fd07087547 and installed on buildbot now.
#683 1287142289000000 dread Done apart from ultrastable - not in use at moment.
#684 1286388346000000 dread Referencing ticket #683 has changed sprint.
#685 1286388345000000 dread Referencing ticket #683 has changed sprint.
#686 1286388346000000 dread Referencing ticket #683 has changed sprint.
#686 1287997047000000 dread Don't need this yet.
#695 1287677481000000 dread Superb finding Friedrich! Any chance of a quick fix for metastable then?
#695 1287677524000000 dread Sorry, I meant Olly!
#695 1287766973000000 dread These changesets do the trick. I've: * merged Ollie's changes into default and metastable branches. * updated ckan.net to latest metastable and reindexed it. * ckan.net now searches on latest packages, including sanskrit example. * test-hmg.ckan.net also updated to latest metastable for testing with UAT. * ckanhmg is to be updated next week and DGU ticket remains for this.
#700 1289823108000000 dread This is still holding back releases. @pudo please can you look at it this
#714 1291733788000000 dread This was implemented with DGU ticket 614
#732 1288021197000000 dread Couldn't reproduce
#734 1292587603000000 dread Found problems and ticketed: #872 #873
#735 1292957248000000 dread I have been through looking for package names with a trailing underscore checking if they should indeed be separate package from those without. #872 and #873 cover creation of the duplicates in the first place.
#737 1319730303000000 dread Something like this one on github: {{{ # This is an <h1> tag ## This is an <h2> tag ###### This is an <h6> tag Text styles *This text will be italic* _This will also be italic_ **This text will be bold** __This will also be bold__ *You **can** combine them* Lists Unordered * Item 1 * Item 2 * Item 2a * Item 2b Ordered 1. Item 1 2. Item 2 3. Item 3 * Item 3a * Item 3b Miscellaneous Images ![GitHub Logo](/images/logo.png) Format: ![Alt Text](url) Links http://github.com - automatic! [GitHub](http://github.com) Blockquotes As Kanye West said: > We're living the future so > the present is our past. }}}
#763 1288606918000000 dread Referencing ticket #441 has changed sprint.
#765 1288606918000000 dread Referencing ticket #441 has changed sprint.
#777 1292586843000000 dread James did this a while ago.
#798 1294916973000000 dread This was done a while ago.
#803 1289489024000000 dread I'm not sure a template is needed for the test script - surely repeated stuff can just be factored out? Creating the model dump file: * 'hg up' to ckan as it was at the last model migration * 'paster db clean', 'paster db init', 'paster create-test-data' * 'pgdump' * 'hg up default' * Check in the dumped file Do we really want a script to mess with our repo like this? Isn't it just safer to do manually with good instructions?
#803 1314031451000000 dread We now use nose to test migrations instead.
#805 1298379084000000 dread Migration tests added to buildbot using kindly's new nose option #965. Also removed legacy system of migration testing in: ckan/migration/tests and updated docs. cset:643673c7db3e
#806 1290071159000000 dread This is done now I think? Please list changesets, time taken vs estimate and close ticket.
#806 1291134978000000 dread This is not a duplicate of #827
#806 1294916284000000 dread This looks finished
#806 1324034356000000 dread This was introduced in CKAN 1.3
#812 1294658293000000 dread Just added stuff from duplicate #781
#816 1312212782000000 dread I like rgrp's idea to change the model. But since it's complicated it would be good to have a UI. e.g. You might make format field simply a drop-down with only some common options: 'CSV, Excel, Zip, Other'. If you go for Other, then a more substantial UI appears, to cover more filetypes, APIs, services and a text box for Other. And if you select 'Zip' then another set of options appears to say what is in the zip. etc.etc. Another approach would be to have a background process downloading the data file and filling this in for you.
#816 1319804698000000 dread John did this in cset:1697dfa2552c for release 1.5
#816 1319812324000000 dread And branch feature-816-format-autocomplete
#818 1305559442000000 dread 1.4 complete
#820 1311325226000000 dread This has been fixed
#821 1298486642000000 dread Investigating several of these packages, it works for me (and David Raznick). For example ni_013_migrants_english_language_skills_and_knowledge, one resource is seen created in the diffs, is displayed in CKAN, in the API and in the dumps. Yet looking at the dump from 17/11/10 when this ticket was created, the resource didn't have a URI, which by the current model is a requirement, so it suggests the data was fine underneath, but it had problems displaying this field, and is now fixed.
#822 1290506354000000 dread Fixed in cset:045cab10aa1d Thanks for the patch!
#825 1290624449000000 dread Added plenty of info in cset:627249a1c102
#826 1297414412000000 dread It's great that the extras are added in-line with other Resource properties (as opposed to package extras which are a dict not off 'package' but off 'package.extras'). However, the resource extra field keys are defined in config option "ckan.extra_resource_fields". This config option should be removed - extras need to be entirely flexible for our purposes. (In the next ticket we should make it possible to add/remove both keys and values from the Web UI or API.) It would also be good to tidy things in this direction: http://wiki.okfn.org/Coding_Standards I've merged from default to the branch enhancment_826_resource_extra_fields ready for you.
#826 1297421022000000 dread Ah - I understand. I'd like it if you could make all the extra fields work as attributes and be searchable - is that possible?
#826 1297429910000000 dread Merged into default in cset:613d7bd5fc96. Future tickets in this area include: * #978 Full edit in Web UI * #979 Edit Resource extras in the API
#826 1306766057000000 dread This went into ckan release 1.3.2.
#829 1290697386000000 dread Some work towards this in cset:066b1b553595. No exceptions and test skip in place. Looks like formalchemy changed its interface.
#829 1303122056000000 dread Rufus originally specified it. Reassigning to him to decide whether we still want it or not.
#836 1302882808000000 dread This has been a (minor) issue since release v1.3
#840 1291325251000000 dread dread: ] That's the proxy_cache decorator which sets a Beaker expiry time only. ] Whether that is on or off, you still end up run the ] "etag_cache(cache_key)" command in the package controller won't you? ] And won't that will either insert the Etags header or abort 304 for a ] repeat? I must admit I've not tried it, asking purely with the code in ] front of me and welcome you pointing out where I've gone wrong. ww: Right. So those etag calls predate the cache decorators and should probably be either moved up into the decorator (e.g. use @ckan_cache instead of @proxy_cache) or wrapped in a check for the config parameter. (And @ckan_cache could be changed to use pylons' etag_cache function rather than just setting the header...)
#840 1302694123000000 dread Basic on/off switch added, tested & documented in cset:0da189c9630e on default.
#843 1319710380000000 dread * "we should show the openid as well to distinguish between users with the same name." - when "Full name" is not distinguishable, maybe best to display the unique 'name' field as a hover-over. * "on account creation, the user should be redirected to their personal details page to encourage them to fill in a human readable name." - yes you always got take to the personal details page. We should use a flash message at this point if they have not filled in the "Full name" field to suggest they click edit and do this. * "List is to long" - this has been addressed - see http://thedatahub.org/user
#843 1319721601000000 dread Ok I misunderstood this ticket. This is referring to adding a user in e.g. http://thedatahub.org/group/authz/energy-data This UI seems to be updated. You start typing the name, full name or open id of the person and it has a dropdown that autocompletes. This seems to be sufficient for Will's points 1 and 3. Would be still good to have a flash message on account creation to encourage people to add personal their Full name. This is similar to #1413 so I'll close this ticket and add it there.
#845 1291723492000000 dread This was completed on the feature-845-required-fields branch and merged into default in cset:3b5635ffaa7d
#858 1291734297000000 dread On branch feature-858-diff removed ckan.lib.diff as it was not being used. Merged into default in cset:f9ba1ae63ddd
#867 1291916278000000 dread Done in ckanclient cset:d40fb101aba9
#867 1292410515000000 dread Also ckan cset:c5b018bfe9bb
#868 1294753596000000 dread I've merged in David Raznick's patches: * no_autoflush_deletes.diff cset:2b9591172182 * postgres_speed.diff cset:fa1b7e3a4e0f * vdm_purge_no_autoflush.diff vdm cset 8accdd0b9b7f I've also merged in Seb's fork: cset:68d63fda4814 which closes this ticket, achieving test speeds of under 3 minutes!
#872 1292957110000000 dread Done in ckanext cset:8a7e931ef37c
#873 1292939274000000 dread Fixed in dgu cset:8bfb867e247a and ckanext cset:fabd31544a73
#876 1294753889000000 dread Seb and David have completed this I believe. I've merged the changes into core CKAN in cset:68d63fda4814.
#880 1292945137000000 dread Fixed in ckanclient cset:e7c0af586367 and ckanext cset:82d974ab6860 with test in dgu cset:c0b2c5fd95ea
#886 1294916538000000 dread Being done as part of DGU ticket: https://trac.dataco.coi.gov.uk/projects/datagov/ticket/757
#897 1294914333000000 dread Same as #870
#898 1294659537000000 dread From David Raznick
#898 1294662408000000 dread Merged in cset:89bf917f9b46
#899 1294662417000000 dread Merged in cset:89bf917f9b46
#900 1294662424000000 dread Merged in cset:89bf917f9b46
#901 1294662466000000 dread Merged in cset:b8a649f51cab from Seb's changes.
#905 1328638536000000 dread This works with the current SOLR search. e.g. http://thedatahub.org/dataset?q=gr%C3%B6%C3%9Ften
#906 1328639465000000 dread This was done in #1701 but only in a custom SOLR schema in the ecportal extension: https://github.com/okfn/ckanext-ecportal/commit/6682926d8895f146cdf1e52ab4fbead9b065af77 Can the ASCIIFoldingFilterFactory be added to core CKAN's SOLR schema for all CKAN users to benefit from?
#917 1295280232000000 dread Fixed in cset:f2865f43d8ee
#918 1315911507000000 dread Preview feature is now deprecated
#919 1303202627000000 dread Simple to fix this in the process of fixing #108. Fix went in cset:304d30d85816 for release 1.3.4.
#931 1298379187000000 dread This was completed in ckanclient in cset:1bfefd7596d3
#932 1296159225000000 dread Initial work done on branch: enh_932_sql_migrate_upgrade Not working yet - hopefully kindly will be able to help tomorrow.
#932 1296496416000000 dread Completed on branch and merged into default in cset:25c94cdbd283
#933 1297348975000000 dread Done on enh_933_get_rid_self_in_cls_meth and merged into default cset:5750c77e580d ready for ckan 1.4.
#945 1301909147000000 dread Moving super ticket to 1.4 milestone
#946 1296833368000000 dread Fixed in cset:a30c31b9009d
#947 1314031310000000 dread This was done in #1025 through configuration. Happily you can setup config in an extension, so covers this ticket's aims too.
#948 1300271100000000 dread This sounds like a good solution to me. This should include not just packages, but groups and all other stateful objects.
#948 1300271268000000 dread There's also the API to consider. One edge case to consider too - currently we don't allow reuse of the name of a deleted package, which is confusing. The deleted package should be moved aside (renamed), unless the deleted package is entirely the same as the new or renamed package.
#948 1300728602000000 dread We have a use case now for DGU where if a user requests a deleted package, he is 302 redirected to another package (specified in the deleted package's extras). This is for the API, but could also be done in the Web UI if deleted packages are hidden away in a trashcan. But this suggests we need a trashcan in the API too. i.e we should keep the data model really synchronised between the Web UI and API, (even if they are becoming divorced from the ORM Model - or maybe we should have a trashcan in the ORM model too?) Ideas: * GET api/rest/package - lists active packages * GET api/rest/package/traffic_data - active package * GET api/rest/trash/package - lists deleted packages * GET api/rest/trash/traffic_data_old - deleted package
#948 1314112642000000 dread Note: Packages will now be excluded from the search view (see #1283). Also there is now no redirect requirement from DGU any more.
#950 1296732042000000 dread Done in: * ckan cset:e68d0704e57b * ckanext cset:0d7d223e4302 * dgu cset:c633d2608c29 Importer controller now in new repo ckanext-importer (mothballed)
#951 1314031006000000 dread Specific problem explained by having two users with the same name - one was authorized and one wasn't. See: http://lists.okfn.org/pipermail/ckan-dev/2011-April/000550.html
#955 1296833234000000 dread Fixed in cset:9a45a07ad95e
#955 1297342534000000 dread Fixed on cset:b65b9830571c and merged into default in time for 1.3 release.
#958 1297430414000000 dread Sorry I didn't see this and created #78. Closing this one as #978 is fuller.
#958 1297430602000000 dread Apologies, #978 is subtly different - reopening.
#961 1297073658000000 dread So you also need: 4. Converting form data to dict 5. Converting dict to model i.e. the dict is not the same as the serialized form data or model data.
#974 1297342599000000 dread Fixed in cset:9dc20731d0fd and cset:5149f503e741 for 1.3 release.
#976 1297346954000000 dread Done in cset:1566d08d529f for release 1.3
#977 1297420742000000 dread Fixed in cset:8809fbefaf8c for 1.3 and merged to default.
#979 1315221162000000 dread Changed the title back - it was accurate. The comment was because with formalchemy, WUI and API ran off the same 'form' code. This functionality may already be there with the new stuff, but certainly needs tests.
#982 1298482394000000 dread Need to do this for older branches which isn't subject to #963.
#982 1298887980000000 dread Buildbot scripts now fixed.
#983 1297773407000000 dread Error was tracked down to cset:214a8f9fc1c2 (26-9-2010): upgrade_db called validate_authorization_setup() which calls setup_default_user_roles(System()) Fixed in cset:9f51a1c8ac83 for 1.3 branch and merged to default.
#991 1298037717000000 dread Fixed in cset:56cccbbb9d1a in time for ckan 1.3 release. This did not affect previous releases.
#993 1298373114000000 dread Fixed on 1.3 cset:7708c8b521ed and merged to default. Deployed to ckan.net.
#998 1298369862000000 dread 'paster db create' (or init) should do exactly what we ask. Surely we should simply tell people to use 'paster db upgrade' instead?
#998 1298372171000000 dread Yes I agree - either of those sounds good. I think I've always used 'db init' in preference anyway.
#1001 1301307814000000 dread You mentioned writing tests? Also the CSRF question from James hasn't been addressed.
← 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 →
Note: See TracReports for help on using and creating reports.