{23} Trac comments (3729 matches)

Results (1501 - 1600 of 3729)

← 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 →
Ticket Posixtime Author Newvalue
#878 1315820838000000 rgrp This is now done in feature-1294-ux-improvements-dataset. see e.g. cset:c6f7f5018b4f
#879 1294604066000000 wwaites first cut: https://bitbucket.org/ww/ckanext-storage/src
#880 1292945137000000 dread Fixed in ckanclient cset:e7c0af586367 and ckanext cset:82d974ab6860 with test in dgu cset:c0b2c5fd95ea
#881 1294410574000000 thejimmyg Hello fccoelho, Could you please post the output you get from running pip? Thanks, James
#881 1296335072000000 rgrp Closing due to lack of clarification.
#883 1300196622000000 thejimmyg Now complete.
#884 1293319984000000 wwaites Implemented in feature-884-rmsource branch at https://bitbucket.org/ww/ckan/changeset/50cbfc5a6bee
#884 1294247654000000 thejimmyg Related to ticket #665, reopening so that I can close it once I've got it working with Drupal too.
#884 1294253563000000 wwaites see feature-884-rmsource in the main ckan repo deleting my own repo
#884 1296592140000000 thejimmyg OK, I've implemented an API call for this too now and all is merged into default.
#885 1293278564000000 wwaites Friedrich had some mixed experiences with owslib and some German CSW endpoints: http://pudo.okfnpad.org/geodaten
#885 1293314219000000 wwaites See: https://bitbucket.org/ww/ckanext-ows impossible as of yet to test against live server from the OS
#885 1294253497000000 wwaites done with feature-885-owslib
#886 1294916538000000 dread Being done as part of DGU ticket: https://trac.dataco.coi.gov.uk/projects/datagov/ticket/757
#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.
#888 1294830297000000 Stiivi Chages to Data Proxy: * tests added with configurable list of known URLs * use brewery for transformations (included reference to brewery framework in a new vendor directory) * side effect: code to make google find external packages in vendor directory (from now on, all external packages should go there and be referenced from .hgsub if they are mercurial repositories) * changed response contents: moved from 'headers' to root, renamed 'response' to 'data', added field list as 'fields' * changed way of registering transformers (now class object is used instead of name) * added 'encoding' and 'dialect' parameters for CSV * added optional data audit (parameter 'audit') Changes: https://bitbucket.org/Stiivi/dataproxy/changeset/fccbdd275be5 Data information: http://databrewery.org/doc/data_quality.html#brewery.dq.FieldStatistics
#888 1307352537000000 thejimmyg I don't think any progress has been made on this for a bit so I'm assigning it to me.
#888 1311773103000000 johnglover Dataproxy / Dataapi now deprecated in favour of the combination of new QA archive / process commands and the webstore. Changes in relation to Dataproxy / Dataapi: * Currently only supports CSV files, but plans to add support for excel and google docs spreadsheets soon. * Uses David Raznick's CSV parser instead of Brewery for parsing, handles messy CSV data better. Changes in relation to old QA functionality: * decoupled archiving (downloading) and QA process * added a new 'process' command which parses downloaded files and adds them to a local webstore Closing for now, any improvements/feature requests should be in tickets relating to either the QA functionality or the webstore.
#889 1293715109000000 rgrp Done in cset:cdbb2e6128b3 (had added item to template earlier pulling from 'g' object but had not tied that up to config as yet). Also added test and also '''removed existing google analytics code''' -- so need to explicitly set this in config from now on.
#890 1318529648000000 rgrp May want to close as invalid as obsoleted by more recent queue work.
#890 1318599247000000 kindly Invalid due to #1397, We will be using celery instead.
#891 1318602128000000 rgrp May only do link-checker and not do full storage in this sprint.
#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
#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).
#892 1324314636000000 rgrp Moved to v1.6.
#892 1324402480000000 johnglover https://github.com/okfn/ckan/compare/bff538b%5E...d700680 Merged with master and deployed on test.ckan.org
#893 1298293527000000 thejimmyg We don't understand the use case for this requirement. Closing for now until a use case can be demonstrated.
#894 1300196388000000 thejimmyg All test CSWs have been successfully harvested from. CSW harvesting is disabled on that source so we can't harvest from it. I don't think we need a ticket for this now do we?
#896 1300217375000000 thejimmyg Actually, I think this should be implemented instead by considering a different CKAN instance as a potential harvest source and then harvesting from it. By thinking of it this way in the first instance, we effectively get a read-only copy of other data in CKAN but one which will be kept up to date. Marking as duplicate. Discussion can now carry on via #987 Common harvesting framework.
#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.
#902 1296638257000000 rgrp Also confirmed in FF. David (R) and I have both had a go and fixing this and it seems to be a bit tricky (very odd css behaviour!). Rather than directly fix this I'm thinking of doing a bit of rework of that set of menu tabs as they could be much nicer anyway and hence re-titling of this ticket.
#902 1297078885000000 rgrp Fixed in cset:42102bf7f922 and cset:42102bf7f922 by switching to a new 'tabs' look that has none of these issues. (See branch feature-902-submenu).
#903 1295265645000000 pudo This is now partially solved by filtering for deleted packages. As two further measures, we should also add a package deletion method to the Solr backend and skip deleted packages when indexing.
#903 1296588070000000 pudo fixed in https://bitbucket.org/okfn/ckanext-solr/changeset/be4cffa9b987
#904 1299840539000000 rgrp We're already now into improving the docs and ticket:927 is now reasonably detailed.
#905 1328638536000000 dread This works with the current SOLR search. e.g. http://thedatahub.org/dataset?q=gr%C3%B6%C3%9Ften
#906 1324299793000000 rgrp Do we need to change in core code or just configure solr?
#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?
#906 1328782087000000 amercader Yes, I don't think there will be any problem, and we won't need to create a new version of the schema as the change is backwards compatible.
#907 1296335337000000 rgrp Basic implementation done and deployed. However plenty to improve, e.g. * Support more formats (use external systems for preview?) * json (!) * html (trivial!) * sparql * ... * Do not display preview if no preview
#907 1297072303000000 rgrp Closing this now and improvements can go in a new ticket.
#908 1296403695000000 wwaites see also from http://knowledgeforge.net/okfn/tasks/ticket/485 {{{ (pyenv)okfn@eu7:~/var/srvc/ckan.net$ sudo uwsgi -C -iH /home/okfn/var/srvc/ckan.net/pyenv --paste config:ckan.net.ini --uid www-data -s 10.48.162.201:9001 *** Starting uWSGI 0.9.6.6 (32bit) on [Sun Jan 30 16:00:13 2011] *** compiled with version: 4.4.3 Python version: 2.6.5 (r265:79063, Apr 16 2010, 13:28:26) [GCC 4.4.3] uWSGI running as root, you can use --uid/--gid/--chroot options setuid() to 33 *** WARNING: you are running uWSGI without its master process manager *** your memory page size is 4096 bytes allocated 412 bytes (0 KB) for 1 request's buffer. Setting PythonHome to /home/okfn/var/srvc/ckan.net/pyenv... binding on TCP port: 9001 your server socket listen backlog is limited to 64 connections initializing hooks...done. Loading paste environment: config:ckan.net.ini Traceback (most recent call last): File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/paste/deploy/__init__.py", line 3, in <module> from loadwsgi import * File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/paste/deploy/loadwsgi.py", line 8, in <module> import pkg_resources File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/pkg_resources.py", line 2691, in <module> add_activation_listener(lambda dist: dist.activate()) File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/pkg_resources.py", line 668, in subscribe callback(dist) File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/pkg_resources.py", line 2691, in <lambda> add_activation_listener(lambda dist: dist.activate()) File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/pkg_resources.py", line 2195, in activate map(declare_namespace, self._get_metadata('namespace_packages.txt')) File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/pkg_resources.py", line 1790, in declare_namespace _handle_ns(packageName, path_item) File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/pkg_resources.py", line 1761, in _handle_ns loader.load_module(packageName); module.__path__ = path File "/usr/lib/python2.6/pkgutil.py", line 238, in load_module mod = imp.load_module(fullname, self.file, self.filename, self.etc) File "/home/okfn/var/srvc/ckan.net/pyenv/src/ckanext-dataapi/ckanext/dataapi/__init__.py", line 36, in <module> from pylons import config File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/pylons/__init__.py", line 4, in <module> from pylons.config import config File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/pylons/config.py", line 2, in <module> from pylons.configuration import * File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/pylons/configuration.py", line 25, in <module> import pylons.legacy File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/pylons/legacy.py", line 11, in <module> from pylons.util import deprecated, func_move File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/pylons/util.py", line 18, in <module> from paste.script.appinstall import Installer File "/home/okfn/var/srvc/ckan.net/pyenv/lib/python2.6/site-packages/paste/script/appinstall.py", line 23, in <module> from paste.deploy import appconfig ImportError: cannot import name appconfig }}}
#908 1296659056000000 pudo fixed in https://bitbucket.org/okfn/ckan/changeset/08c0e1a819e4 and https://bitbucket.org/okfn/ckanext-stats/changeset/6e86c071db99
#908 1296660052000000 wwaites Not fixed. Try running with: {{{ uwsgi -C -iH /path/to/your/pyenv --paste config:ckan.net.ini -s 127.0.0.1:9000 }}} Still get giant traceback relating to a circular import centered on an arbitrary plugin
#908 1296730578000000 pudo I've moved the uswgi/nginx part to #952, closing this issue since the problem it describes has been fixed.
#909 1346669602000000 ross Backlog until funded.
#910 1310128544000000 thejimmyg Not enough information and over 6 months old so closing.
#911 1296467375000000 pudo Done.
#912 1306774876000000 pudo moving to ckan
#913 1299841413000000 rgrp If at all possible this should uris from the OKF licenses registry at http://licenses.opendefinition.org/
#913 1306774962000000 pudo moving to CKAN, still need a resolver
#915 1296467518000000 pudo Live and running :-)
#916 1297066902000000 rgrp Moved to https://bitbucket.org/okfn/vdm/issue/4/port-new-vdm-to-mongodb
#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.
#920 1295355318000000 [email protected] my first email address was wrong...
#920 1300217199000000 thejimmyg @David Should we implement this as a change to the way tags work or via a tidy up cron job?
#920 1300319140000000 kindly The only issue here is that we are listing tags that relate to 'inactive' packages. We are already not listing tags that relate to NO packages. I have fixed this. cset:cd0347eed69f The tag in the example is related to a deleted package so should not be deleted. With this patch it no longer gets displayed.
#921 1300197629000000 thejimmyg Seb started this, I completed it and the code is now live. Further refactoring will be done first in #1037 and then in #987.
#922 1310128789000000 thejimmyg See also #358 which I'm closing because it gets merged into this ticket. The reason we were blockd on #358 was to do with issues around authorization.
#922 1320664187000000 rgrp Duplicate of #1032 (I think)
#925 1323168588000000 thejimmyg This is fixed in CKAN 1.5
#926 1296637927000000 rgrp Comments from RP - http://lists.okfn.org/pipermail/ckan-dev/2011-January/000181.html Libraries I have used: FormEncode, FormAlchemy (what we are currently using, before that formencode). Neither seemed perfect but I think the form issue is a 'hard' problem (perhaps with no perfect answer) [1]. FormAlchemy, in retrospect, was probably a mistake as it merges too much model/validation/form generation into one thing. At least 3 functions involved: 1. Generating (or just filling) a form template with 'form data' (and errors) 2. Converting model data to form data (also happens for APIs in fact) -- let's call this 'dict-ization' 3. Converting form data to model data (and validating) (inverse of previous step) I think one can and should separate 1 from 2+3 (and one of problems with formalchemy is it doesn't -- the attraction being you don't repeat yourself as forms get generated from model but I think this is actually a false economy in medium-term). I'm not specifically recommending the following as I haven't used them but I've looked through docs, they are active and reasonably mature: 1. Flatland: http://discorporate.us/projects/flatland/docs/tip/ * Only does 2+3 which is a good thing IMO 2. WTForms: http://wtforms.simplecodes.com/ * Used in standard flask docs: <http://flask.pocoo.org/docs/patterns/wtforms/>
#926 1298489517000000 rgrp @Seb: I believe this is now decided following discussion last week. Please could you detail results and close :)
#926 1298541597000000 anonymous Goals: We want the interface for updating an object to be loosely coupled to the method for updating it. We might update a Package from: - HTML forms - a REST API (using JSON) - a CLI (potentially using command line arguments, YaML, XML or ini files) Right now, data is validated using a form framework, even if we're not using forms. Data is written to the object as part of the forms framework (using the "sync()" method), making the process hard to customise and hard to discover. Instead, there should be a standard chain for: - deserialising untyped data (such as that received from an HTTP POST or parsed from a YaML file) into valid data - returning structured errors suitable for displaying to the user - saving the validated, deserialised data Ideally, it would look something like: schema = MySchemaDefinition() raw_data = open("raw.csv", "r").read() structured_data = to_python(raw_data, schema) try: validated = validate(python_data) myobject.update_from_dict(validated) return "Updated OK" except ValidationError, e: return "Error: %s" % e.to_dict() The inverse would be something like: structured_data = myobject.render_to_dict() raw_data.write(to_csv(structured_data, schema) print "Wrote CSV %s" % to_logformat(serialized_data, schema) The question of how to generate and display forms should be completely decoupled from this. It should be easy to write forms by hand, which means it should be simple to flatten the serialized data to key, value pairs, and match up any validation errors to each key. Optionally, a form widget generation framework is a nice-to-have, but not essential, as it is expected that, given enough time, the majority of forms will require manual coding to accomodate edge conditions. A form widget generation framework should be reasonably complete if it's worth trying at all, which means it should support things like: - nested fields (at least repeating, multi-value fieldsets) - widgets for dates and file uploads - internationalisation ...but note I'd settle for *no* widget generation Components of a serialisation / validation framework: - a simple, obvious way to define a schema - a lightweight validation implementation - simple interface for validators - easy to match validation errors to data structure items Overall, I'd like to see: - loose coupling, no framework dependencies - maximal test coverage - extensive documentation with readily available examples ## Findings I looked at flatland, formencode, FormAlchemy, formish, WTForms, Django, web2py, deform/colander, formconvert and web.py - **web2py** just helps build HTML from python, so isn't what I'm after at all - **web.py** has rudimentary validation which is only aimed at HTML forms and is hence tightly coupled with them. - **Django**'s forms are again tightly coupled to HTML forms (and their generation) - **FormAlchemy** similarly couples validation to forms, and is focussed on inferring a schema from a data model SQLAlchemy. - **WTForms** again focuses on Form generation and don't make itx easy to deserialise arbitrary data This leaves us with Flatland, Formencode, Formish, Colander/Peppercorn/Deform, and FormConvert. Having reviewed all of these, I rejected Formencode on the basis of its patchy documentation and relatively low unit test coverage. I also found it mixed concerns a bit much for my taste. Formish felt similarly sparsely documented. Of the remainder, I'd be happy using any of them, but opted for Colander in the end as it has the most exhaustive documentation and unit tests and has been used in production for a long time. FormConvert has a nice design but is a bit of a moving target at the moment -- worth revisiting in the future.
#927 1299841206000000 rgrp Major update including notes of what has been done (where not a separate ticket) and addition of a few items.
#927 1300105638000000 rgrp Closing this ticket as #841 is minor. More work on docs can go in new tickets.
#928 1297115097000000 rgrp Fixed in cset::540e8e548d84
#928 1297115136000000 rgrp Forgot to say moved contributors material to http://ckan.org/wiki/Contributors for the time being.
#929 1297686088000000 thejimmyg The licenses service was down, it is back up now. We should be able to cope with this situation better though. Renaming the ticket.
#929 1299840884000000 rgrp I'm closing this ticket as a) most systems should install the licenses package (and hence have the licenses locally) and b) licenses service has now moved to s3 so should be very robust (see ticket:973 and http://knowledgeforge.net/okfn/tasks/ticket/605)
#930 1296062391000000 wwaites This is for HMG to prove to them that requests are being serviced in a timely manner * move this functionality to a plugin * make it use rrdtool instead of lots of itty bitty files
#930 1296070197000000 wwaites actually, this is a configuration variable ckan.enable_call_timing cleaned up the code a bit, make sure this variable unset or set to false or no and there should be no millions of files as it is unclear if this is actually used or necessary, not doing the rrdtool part just yet. if there is call for it, make a new ticket for this.
#930 1297066292000000 rgrp Just want to agree with wwaites assessment here. dubious this code is currently useful as a) not used b) (more importantly) probably better ways to achieve this functionality.
#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.
#934 1323171047000000 thejimmyg We have other ways of solving this problem now rather than a key value store for plugins. Marking as invalid.
#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
#936 1303117147000000 thejimmyg How is this coming on John?
#936 1303838713000000 rgrp Completed it seems :-) see https://bitbucket.org/okfn/ckanext-follower
#937 1296385042000000 sebbacon Could consider using third-party analytics tracking here, which will also give referrer etc data for free? Would probably be bes provided in the form of optional piwik or google analytics integration. Being able to say in the UI how many downloads there have been would need piwik.
#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
#937 1297689859000000 sebbacon (and it would also need some proper caching as the GA API is very slow)
#937 1298892547000000 sebbacon The current implementation I referenced above will be a good starting point. Work that remains: * Add download click tracking to individual download links (currently we just record page views for packages, not downloads) * Somehow cache the download stats against each package (the Google API is very slow); package reddis or sqlite or similar as a local storage for the extension * Expose download information in the relevant places in the UI (all users? package owners? where?) This is about 2 days' work. Unlikely to get it done in this sprint.
#937 1302513831000000 sebbacon Completed; software at https://bitbucket.org/okfn/ckanext-googleanalytics/src
#938 1296753055000000 pudo fixed in https://bitbucket.org/okfn/ckan/changeset/064d74a1ead8
#939 1323171158000000 thejimmyg This is now implemented, the notification links to the about page. We might want to update that page with better information, but that would be a different ticket.
#940 1296656433000000 pudo It seems like even with openid.realm set we could only create two "zones": *.ckan.net and ckan.net. We do not want *.ckan.net because it interferes with ccCKANs. My vote for the moment would be to 303 www.ckan.net to ckan.net.
#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] }}}
#940 1297071748000000 rgrp Listing as wontfix now since: 1. Have workaround 2. Better for most sites to converge on a single domain anyway (for SEO etc) -- via std redirect approach or otherwise 3. Seems problematic to fix this via openid realm
#941 1297246005000000 thejimmyg This will be implemented in http://bitbucket.org/okfn/ckanext-community by Wayne.
#941 1297689750000000 thejimmyg The system will need some way of plugging in the model. See ticket #989 for progress on this. Other ideas: * The apps will need an image upload * We might like a voting system for apps and ideas, potentially that could be re-used later. Let's discuss the above ideas after the basic functionality is in place.
← 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 →
Note: See TracReports for help on using and creating reports.