{23} Trac comments (3729 matches)

Results (2101 - 2200 of 3729)

← 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 →
Ticket Posixtime Author Newvalue
#954 1303118513000000 thejimmyg David Raznick has implemented JSON errors for the v1 and v2 API, we'll look at this over the next few weeks.
#954 1310134531000000 thejimmyg See also this proposal about "inlining" extras fields #972. David Raznick and I have also agreed that for API 3, each call to the logic layer will return an object (basically a dictionary) rather than using Exceptions. This means the return values from the logic layer can exactly mirror the JSON data strucutres returned via the API. The help values can come from the docstrings of the logic layer functions.
#954 1315948855000000 rgrp @kindly: can you update here. My impression is that lots was done but the current ticket description bears little relation to what was done. Suggest we move current content to a new ticket and update this with a short description of what *was* done and then close -- does this sound sensible?
#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.
#953 1296809834000000 rgrp Done in cset:3275d2fc9e43
#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
#950 1296732042000000 dread Done in: * ckan cset:e68d0704e57b * ckanext cset:0d7d223e4302 * dgu cset:c633d2608c29 Importer controller now in new repo ckanext-importer (mothballed)
#950 1297076647000000 rgrp Reopen to set an owenr.
#949 1296730355000000 pudo Fixed in: * https://bitbucket.org/okfn/ckan/changeset/8017a6686838 * https://bitbucket.org/okfn/ckan/changeset/5e6634aab275
#949 1297074827000000 rgrp Hocus pocus so set owner after being fixed!
#948 1300271009000000 sebbacon I would propose a "trash can" model: a "deleted items" area where only deleted items can be viewed / searched. Deleted items should not appear anywhere else, but we could include a "also search deleted items" option in the search for admins. (In which case, deleted items should have a "div class='deleted'" or similar so they can be highlighted with CSS).
#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 1300385979000000 sebbacon Emptying the trashcan (which would amount to purging deleted objects) would probably be a function of the administrative dashboard #833
#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.
#948 1323172859000000 thejimmyg Re-assigning to me temporarily to investigate now that Seb has left.
#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.
#946 1296833368000000 dread Fixed in cset:a30c31b9009d
#945 1301909147000000 dread Moving super ticket to 1.4 milestone
#945 1325259350000000 rgrp Closing as all subcomponents now done. (parts of this duplicate the other super ticket #1032). Also move to ckan-v1.6 as that is when last parts were done.
#944 1298571917000000 pudo Won't work on this for now - IATI is now running against plain CKAN but this is not deployed. We will continue work on this once IATI requests more functionality and shelf it for now.
#944 1306774766000000 pudo done at iati.ckan.net
#943 1297076498000000 rgrp Done see http://wiki.ckan.net/
#942 1296499160000000 pudo fixed in cset:81a0f5538a5b
#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.
#941 1298886391000000 wwitzel3 Continued work on the community plugin. I am still learning the layout of templates and how they work within ckan and getting figuring out Genshi templates so this is where most of the delay has been. I've been able to determine a pretty good plugin layout for extensions that create models. I am currently focusing on getting the rest of the UI in place and trying to determine the best way to get colander to do the desired validation beyond ensuring the form has all the elements. After todays work, I will push what I've done and I would like to walk through the design with someone at some point.
#941 1300295545000000 wwitzel3 https://bitbucket.org/okfn/ckanext-community/changeset/c26cc663fa00 I need to update the README to explain how to enable Edit and Delete now that I've integrated it with authorization in CKAN.
#941 1301909446000000 thejimmyg See also discussion on #1069 about stub datasets.
#941 1310134339000000 thejimmyg This is now implemented by pudo in publicdata.eu. For the portal case, apps and ideas will come from Drupal so we no longer need this 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
#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.
#938 1296753055000000 pudo fixed in https://bitbucket.org/okfn/ckan/changeset/064d74a1ead8
#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
#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
#934 1323171047000000 thejimmyg We have other ways of solving this problem now rather than a key value store for plugins. Marking as invalid.
#933 1297348975000000 dread Done on enh_933_get_rid_self_in_cls_meth and merged into default cset:5750c77e580d ready for ckan 1.4.
#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
#931 1298379187000000 dread This was completed in ckanclient in cset:1bfefd7596d3
#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.
#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)
#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.
#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.
#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.
#925 1323168588000000 thejimmyg This is fixed in CKAN 1.5
#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)
#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.
#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.
#919 1303202627000000 dread Simple to fix this in the process of fixing #108. Fix went in cset:304d30d85816 for release 1.3.4.
#918 1315911507000000 dread Preview feature is now deprecated
#917 1295280232000000 dread Fixed in cset:f2865f43d8ee
#916 1297066902000000 rgrp Moved to https://bitbucket.org/okfn/vdm/issue/4/port-new-vdm-to-mongodb
#915 1296467518000000 pudo Live and running :-)
#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
#912 1306774876000000 pudo moving to ckan
#911 1296467375000000 pudo Done.
#910 1310128544000000 thejimmyg Not enough information and over 6 months old so closing.
#909 1346669602000000 ross Backlog until funded.
#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.
#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.
#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.
#905 1328638536000000 dread This works with the current SOLR search. e.g. http://thedatahub.org/dataset?q=gr%C3%B6%C3%9Ften
#904 1299840539000000 rgrp We're already now into improving the docs and ticket:927 is now reasonably detailed.
#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
#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).
#901 1294662466000000 dread Merged in cset:b8a649f51cab from Seb's changes.
#900 1294662424000000 dread Merged in cset:89bf917f9b46
#899 1294662417000000 dread Merged in cset:89bf917f9b46
#898 1294659537000000 dread From David Raznick
#898 1294662408000000 dread Merged in cset:89bf917f9b46
#897 1294914333000000 dread Same as #870
← 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 →
Note: See TracReports for help on using and creating reports.