{23} Trac comments (3729 matches)

Results (2801 - 2900 of 3729)

← 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 →
Ticket Posixtime Author Newvalue
#1703 1329918613000000 johnglover Some metadata model info clarified at meeting today, will update ckanext-ecportal accordingly.
#1703 1330956340000000 johnglover Nearly done, need to write converter to rename tags to keywords, waiting for Toby's API work to be finished.
#1703 1331142926000000 johnglover Marking this stage as complete. Keywords can be added/updated via WUI and API, but are still labelled 'tags' when called via package_show API call, but this will be addressed in a separate ticket.
#1704 1327425354000000 johnglover Importer made and added to ckanext-ecportal/scripts. Still has to be run on the test server with Eurostat JSON datasets.
#1705 1327945105000000 seanh Done in branch feature-1698-tag-taxonomies
#1705 1328094584000000 seanh Reopening because I still need to trace all the places in the model (tag.py, package.py, etc.) where there are methods that depend on tag names being unique, and then in the controllers and logic functions as well, and add new tests for the updated methods.
#1707 1328024253000000 johnglover Tom fixed this as part of #1583
#1708 1327493457000000 dread I've got a fix for this and am just looking to see where this problem started now.
#1708 1327494415000000 dread The problem has traced back to this commit by Ian: https://github.com/okfn/ckan/commit/51136465fb1bb94ea70df32be00eaef6ae43792b ckan/config/routing.py {{{ -from ckan.plugins import PluginImplementations, IRoutes 10 +from ckan.controllers.package import set_fallback_controller as set_fallback_package_controller,\ 11 + add_package_controller,\ 12 + set_default_as_fallback_controller_if_required as set_default_as_fallback_package_controller_if_required 13 +from ckan.plugins import PluginImplementations, IRoutes, IPluggablePackageController }}} By importing the package controller at this earlier point, it sets the ckan_url quasi-global variable before the config file has been loaded. {{{ /home/dread/gitroot/ckan/ckan/config/middleware.py(18)<module>() -> from ckan.config.environment import load_environment /home/dread/gitroot/ckan/ckan/config/environment.py(20)<module>() -> from ckan.config.routing import make_map /home/dread/gitroot/ckan/ckan/config/routing.py(10)<module>() -> from ckan.controllers.package import set_fallback_controller as set_fallback_package_controller,\ /home/dread/gitroot/ckan/ckan/controllers/package.py(20)<module>() -> from ckan.lib.search import SearchIndexError, SearchError /home/dread/gitroot/ckan/ckan/lib/search/__init__.py(9)<module>() -> from common import (SearchIndexError, SearchError, SearchQueryError, > /home/dread/gitroot/ckan/ckan/lib/search/common.py(11)<module>() -> solr_url = config.get('solr_url', DEFAULT_SOLR_URL) }}} In retrospect we should have not initialised the variables from the config during import.
#1708 1327505889000000 dread Fix on its way. This problem also stopped simple_search and affected reading the beaker settings. Patch will make SOLR settings initialised consciously in config/environment.ini, rather than at search import time. I've also moved the search import time to be later.
#1708 1327580995000000 dread Fixed in [master 0d3543c]
#1709 1327620136000000 rgrp I have already fixed the issue with counts (in a branch to be merged) :-) Also this is opened in an already ended sprint :-) IMO we don't bother testing simple_search since intended to be hacky and unsupported. Worth documenting the option but highlighting non-supported nature.
#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) ...
#1709 1327659562000000 dread I have checked in a similar fix and with a simple test.
#1709 1327659722000000 dread Note: imports issue was previously dealt with in #1708 and was originally caused by Ian's commit - Ross just merged it in to master.
#1710 1327580140000000 dread Rufus says that the paster command is enough for now.
#1710 1327583922000000 dread Code done in [master 804b549] headed for release Example usage (on the appropriate server): {{{ paster db user-dump-csv /tmp/users.csv }}}
#1712 1328526163000000 icmurray Update 6/2/2012 : Awaiting the publisher hierarchy in order to populate the "browse by publisher" section.
#1715 1328494878000000 kindly Mostly there, need to added types and stopfiles. Need to add actual multilingual fields. Decided to translated title as well for relevance.
#1716 1327601196000000 zephod Easily done. https://github.com/okfn/ckan/commit/2bd50d92f48ca67edb69e51a7bcfc5009d77a785
#1717 1330088539000000 zephod 1. Already exists; "tags:csv" rather than "tag:csv" 2. Format is user selected; we just show the most popular choices. Perhaps an effort should be made to force people to homogenize their format choices (my work with automatic icons will do this to an extent). Also, res_format doesn't appear on thedatahub.org, but for some reason it does on test... 3. There are thousands. We just show the most popular/relevant tags for your search. This could break out into another ticket though - eg. autocompleting tag input on the page? 4. Can't remember what this is... 5. I did this a while ago and popular opinion was that it should change back. This gives us room for expanded options like on thedatahub's live search page right now, and matches the layout of the Groups view page. 6. They should maybe be ordered by relevance, which includes popularity in some metric? This should be broken into a seperate ticket if you want it to go ahead and given to a Solr expert.
#1718 1328093772000000 rgrp WEll known issue. Just needs an upgrade in jquery to 1.7.
#1718 1340632748000000 icmurray Re-assigned to aron for triage.
#1718 1340703280000000 aron.carroll This was fixed at some point.
#1719 1328519411000000 rgrp Fixed in https://github.com/okfn/ckan/commit/90c76b0b006cf505698834e833b548634cf10d17 (see log message for details of error and the fix).
#1719 1328532877000000 dread I've updated test.ckan.org with this fix and am afraid there are still broken images on http://test.ckan.net/revision
#1719 1328541630000000 dread My bad - the server wasn't updated correctly.
#1720 1328528809000000 johnglover Moving over to current sprint. Basic converters added, still have to write tests.
#1721 1329133348000000 johnglover Done: https://github.com/okfn/ckan/commit/bf3c85fbf9c72c0e8ac27d2079c20e07b6c7c668
#1722 1328805890000000 seanh Done on branch feature-1698-tag-taxonomies
#1723 1328533040000000 seanh We're not going to update the existing tag and package classes (as long as they don't break), going to add our own functional tests in a new file instead.
#1724 1328634433000000 johnglover I updated tag_list: https://github.com/okfn/ckan/commit/335535b646adf983d1d19bf19613712099db1f5e
#1724 1329302302000000 seanh I've updated tag_search() and tag_autocomplete() and added tests for them. So this ticket is finished now on branch feature-1698-tag-taxonomies
#1725 1328204489000000 dread Fixed in 6fecbd9fb08f5a22e9dd2dd2745c287a38f44a30 on master. Added test for the tag_string_validator too. Aimed for 1.6 release. Took 1h
#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.
#1730 1328537387000000 johnglover The function for this is the converter function for tags with vocabs. Will integrate with the JQuery chosen plugin.
#1731 1330942924000000 amercader The underlying auth layer is done, still there isn't UI integration (list of publishers in index page, publisher field in form...). Needs to be moved to the next sprint.
#1734 1332167315000000 amercader All sub tickets have been implemented, so closing it now.
#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.
#1737 1329916781000000 dread SOLR syntax is already accepted in: * api/3/search/package * Action API "package_search" Actually api/1/search/package and api/1/search/package accept SOLR syntax too, but they also translate old-CKAN search parameters syntax to SOLR as well. See: http://docs.ckan.org/en/latest/apiv3.html
#1737 1330908235000000 rgrp Did not get to this sprint as focused on #1797.
#1737 1334591246000000 icmurray See http://ckan.okfnpad.org/feature-1737-expose-solr-based-search-api = Immediate actions * analysis of whether the current action/get.py:package_search() function exposes all we currently need for the use cases described above. * how to return that data (expand the current format?) * analysis of whether the current (action) API v.3 can use query parameters rather than as well as POSTed data. (controlles/api.py:action() ) uses "self._get_request_data()" which in-turn pulls out data from POST body. = Tasks Extend the existing package_search action. * pass the facet fields into the logic layer from the request parameters. - /api/3/action/package_search * facet information not being returned via package_search action (is empty). - curl -X POST -d '{"q": "{!lucene q.op=AND df=text}tags:health +community -profile"}' 'http://thedatahub.org/api/3/action/package_search' - figure out why it's not working, and what the facet information should look like * whitelist any GETable api actions, and optionally construct the query from url params rather than body
#1737 1335460683000000 icmurray Facet results **are** already available through the package_search action api. The facet fields need to be specified in the query, otherwise no faceting will be done (ie - the default facets specified in the .ini file are not used). This leaves "whitelist any GETable api actions, and optionally construct the query from url params rather than body" todo, which I've pulled out into another ticket, as it wasn't originally in this ticket. (#2330)
#1737 1335460997000000 icmurray ... just to add to the above: {{{ >>> pprint(json.loads(requests.post('http://127.0.0.1:8088/api/3/action/package_search', json.dumps({'facet.field': ["tags", "groups"]})).content)) <snip> u'search_facets': {u'groups': {u'items': [{u'count': 1, u'display_name': u"Roger's books", u'name': u'roger'}, {u'count': 2, u'display_name': u"Dave's books", u'name': u'david'}], u'title': u'groups'}, u'tags': {u'items': [{u'count': 1, u'display_name': u'tolstoy', u'name': u'tolstoy'}, {u'count': 2, u'display_name': u'russian', u'name': u'russian'}, {u'count': 2, u'display_name': u'Flexible \u30a1', u'name': u'Flexible \u30a1'}], u'title': u'tags'}}}, u'success': True} }}}
#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
#1737 1337594352000000 icmurray - package_search action is now documented, with reference to the solr search parameters available. http://docs.ckan.org/en/latest/apiv3.html (auto-docs not working on rtd at the moment). - actions defined in get.py are now GETable. http://docs.ckan.org/en/latest/apiv3.html#get-able-actions - we won't be providing direct access to solr api, as we think the cost outweighs the benefit.
#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?)
#1737 1337943671000000 icmurray For completeness, package_search docs can be viewed at https://github.com/okfn/ckan/blob/master/ckan/logic/action/get.py#L983 @rgrp: are you happy with this ticket now, does it expose all you need? If so, I'll close it...
#1737 1338719220000000 rgrp Let's close. What would be nice though is ETA on the GET support getting deployed on the DataHub -- just tried using it today and realized it didn't work :-)
#1737 1340011001000000 icmurray The GET-able actions ( #2330 ) are in master, and will make it into 1.8
#1737 1340011203000000 rgrp But not v1.7.1? (When is v1.8 due?). Also for the record a couple of things I found when trying to use this: * No support for facet sort order or facet limit afaict ...
#1737 1340015695000000 icmurray Replying to [comment:22 rgrp]: > But not v1.7.1? (When is v1.8 due?). Not 1.7.1 as it's not a bug fix (https://docs.google.com/document/d/170fxET3kd9dJ4L6VAj3yZugtK0rrVe44J4HuLbTUsEU/) I don't know when 1.8 is due. > > Also for the record a couple of things I found when trying to use this: > > * No support for facet sort order or facet limit afaict ... Thanks, that's good to know. facet.limit should be working [1], so if it's not, then that's a bug. I can check that. for facet.sort, I've added ticket #2543 [1] https://github.com/okfn/ckan/blob/master/ckan/logic/action/get.py#L1022
#1737 1340112732000000 icmurray Replying to [comment:23 icmurray]: > > > > Also for the record a couple of things I found when trying to use this: > > > > * No support for facet sort order or facet limit afaict ... > > Thanks, that's good to know. > > facet.limit should be working [1], so if it's not, then that's a bug. I can check that. facet.limit is working as I'd expect. eg (on master): {{{ import requests import json from pprint import pprint as pp pp(json.loads(requests.get('http://ian-laptop:5000/api/3/action/package_search?q=data&facet.field=tags&facet.limit=1').content)) }}} Returns a result where only the tag with the highest count is returned in the search_facets result dict. One thing I did spot though was that we aren't able to specify per-field parameters. ie whilst `facet.limit` sets the facet limit for ''all'' facet fields, solr allows that to be overridden on a per-field basis, eg `facet.tags.limit`. This isn't something we support at the moment. I've created a ticket for this, #2573 . Let me know if this something that you'd find useful, otherwise I'll leave it on the backlog for a future iteration.
#1738 1328494709000000 kindly cset: 117dce4d64de731e7b0a3c55175a1d093f2bf540
#1738 1330086105000000 dread Cset is actually dd2c0c677117f06a52aa22b3b2717bb605263570 and went into CKAN 1.6
#1739 1328176197000000 rgrp Sorry if we did. I (and Tom) do run tests ;-) However, occasionally I'm unsure whether I've caused a problem when there are existing failures.
#1739 1328495651000000 kindly fixed cset:117dce4d64de731e7b0a3c55175a1d093f2bf540
#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.
#1741 1328526473000000 rgrp 2.5d, 1d remaining.
#1741 1329750838000000 kindly done cset:7825caed3361e88a245b5dd2f946da8bedb160e0
#1742 1328116635000000 ross Potentially valid diff, needs test + patch when I have time. --- a/ckan/controllers/api.py +++ b/ckan/controllers/api.py @@ -592,6 +592,8 @@ class ApiController(BaseController): def is_slug_valid(self): slug = request.params.get('slug') or '' slugtype = request.params.get('type') or '' + if slug in ['new', 'edit', 'search']: + return self._finish_ok( dict(valid=False) ) if slugtype==u'package': response_data = dict(valid=not bool(package_exists(slug))) return self._finish_ok(response_data)
#1742 1328117135000000 dread Probably better in the ckan/logic/validators.py: name_validator
#1743 1328527086000000 rgrp Marking as wontfix - as per discussion here: http://lists.okfn.org/pipermail/ckan-dev/2012-February/001652.html
#1744 1330349472000000 zephod Massive refactor of parent ticket mean this is all done and can be closed off. See #1506 for remaining UX work.
#1746 1355141062000000 seanh Closing this as won't fix, we decided to do http://trac.ckan.org/ticket/3018 instead
#1753 1330908337000000 rgrp As of today kindly has this working in https://github.com/okfn/ckanext-webstorer/tree/webstorer-for-datastore and deployed on the DataHub. Need to merge into master and to possible rename of extension, update docs and we are done.
#1755 1328630657000000 ross Implemented in v1.0-dev of ckanext-dgu and feature-1645-apply-simple-theme of ckanext-dgutheme
#1760 1328709521000000 ross See src/ckanext-dgu/ckanext/dgu/bin/import_publishers.py which will pull publishers from the provided CSV file and build the hierarchy in the database. This file describes how to obtain the publisher list (with hierarchy detail).
#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.
#1764 1335878051000000 seanh Closing because I'm not sure what the reason for doing this would be.
#1765 1328805833000000 seanh Done on branch feature-1698-tag-taxonomies
#1767 1328806740000000 seanh The API tests are done, in https://github.com/okfn/ckan/compare/master...feature-1698-tag-taxonomies#diff-24 on branch feature-1698-tag-taxonomies. The WUI tests still need to be done.
#1769 1329737597000000 icmurray Duplicate of #1762
#1776 1328805695000000 seanh Implemented create_tag() and delete_tag() logic action functions. If you specify a vocabulary_id in the params you can use these to add tags to vocabs, one at a time. There are not yet functions for adding or removing multiple tags in a single API call.
#1779 1329393759000000 kindly complete at 669a8e9f7a768b147b1668940842b72b2a302088
#1781 1329393814000000 kindly complete at 669a8e9f7a768b147b1668940842b72b2a302088
#1783 1328612744000000 dread Fixed in [master 8f059ed] aimed for release 1.6.
#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.
#1785 1340724312000000 seanh No point in doing this for 1.8 because the new theme is coming along anyway, moving into 1.9
#1786 1328640597000000 dread Fixed [master fe6829e]. Aimed for release CKAN 1.6.
#1788 1330111162000000 rgrp Believe most of these are resolved by https://github.com/okfn/ckan/commit/27f4fc776b9199621d259749cf20787328df101f @zephod: could you check again and see if anything remains?
#1788 1330623913000000 zydio Replying to [comment:1 rgrp]: > Believe most of these are resolved by https://github.com/okfn/ckan/commit/27f4fc776b9199621d259749cf20787328df101f > > @zephod: could you check again and see if anything remains? I noticed that Thedatahub with latest code is still messed up..I was working with absolute paths in my environment without the h.url_for_static() to include the html5shiv.js script so I missed a problem, which can be fixed with my new [pull request #4](https://github.com/okfn/ckan/pull/4). I'm aware of only one problem left: when you hit the "Upload a File" button inside the Dataset Edit/Resources tab nothing happens in IE < 9. This is related to those IE versions not being able to dynamically insert HTML 5 tags, which breaks some jquery-tmpl (actually JQuery) operation (if you debug the code everything works in jquery-tmpl until one of the latest operation involving JQuery returns null instead of the expected object). I was able to fix the issue in my environment by adding the following conditional comment: {{{ </script> <!--[if lt IE 9]> <script type="text/javascript" src="/scripts/jquery.html5.preie9fix.js"> </script> <![endif]--> }}} where the jquery.html5.preie9fix.js is simply the [gist](https://gist.github.com/887560) published by Akkuma in a [jquery-tmpl issue (#36)](https://github.com/jquery/jquery-tmpl/issues/36#issuecomment-918495). This script patches JQuery on the fly on IE < 9 to rework in memory html 5 blocks handled by JQuery, so that it doesn't break. And this fixes the "Upload a File" button on IE. I didn't commit/pull this specific fix for the following reasons: * the script embeds innerShiv, which is a previous incarnation of html5shiv (now included in CKAN). It doesn't sound fine to include 2 pieces of code with similar effect, but I couldn't reproduce the fix with html5shiv! * in my environment I have included this fix sitewide even if I didn't spot other problematic features..I don't know if it would be better to include it only on the dataset edit page in the official CKAN code. Summary: I leave to you guys the choice on how to deal with this problem.
#1788 1330624155000000 zydio Erh...sorry for some formatting errors in my comment. I used markdown formatting for links, and used the #NUMBER format to cite issues, which obviously is interpreted by Trac as references to his own issues...my bad.
#1788 1330644056000000 rgrp Re the Upload file button not sure what's best. We do have plans to replace jquery-tmpl with mustache in the near future (but not clear exactly *how* near). We'll think about this and get back to you. Thanks for the detailed debug report.
#1788 1333133365000000 zephod I've been performing a full sweep of the site to rebuild the markup & stylesheets using Bootstrap, and in doing so have managed to close off this ticket. Bootstrap allows us to delegate lots of clever functionality and layouts to Twitter's tried-and-tested code, making it easier to be compatible with IE7. It has brought up plenty of issues: Lots of Javascript was broken; plenty of pages generate broken doctypes causing the browser to go into quirks mode (which in turn causes the page to explode all over the screen); most dynamic content would fail to generate properly in one way or another.... (see the #1788 branch for a log of issues encountered). I've been refactoring our JS and have managed to strip ckanjs, too, because the only significant element we'd used was the File Upload view (which also now works in IE7). test.ckan.net has been redeployed on master; I'm browsing the site in IE7 and everything is looking great :-)
#1791 1329138315000000 dread Fixed in [release-v1.6 beaeaed]
#1792 1329483249000000 toby package create update use correct schema in get_action
#1792 1332755148000000 toby closing as done all that I was asked to do as part of this ticket
#1792 1332872069000000 dread What is the changeset for this? There is evidence of a branch "enhancement-1792-api-logic" but perhaps this name got fast-forwarded out through a bad merge? Is this merged into 1.6.1 release?
#1792 1332928847000000 toby This is in the 1.6.1 as far as I'm aware. The branch was deleted after the merge into master
#1792 1333037710000000 dread I have tracked down the changesets to: * branched off master at dff9f7a8 * merged master in for the last time (and became the 'new master'?) at 1a9227d9ff73c
#1796 1339586499000000 ross LXML removed, update requirements on the extensions
#1797 1330550304000000 rgrp New API endpoint, Authorization and documentation done and merged to master. Time so far. 1.5d. https://github.com/okfn/ckan/commit/a054071e2e29e70e7cfa69df8c117ad5d5871a24
#1797 1330863639000000 rgrp Data Viewer support for new DataStore in https://github.com/okfn/ckan/commit/9ab8b0283bb086eb4cd663ff73c27066bdd3c79a
#1797 1331412469000000 rgrp All done!! Help for data api done in https://github.com/okfn/ckan/commit/1d8e464f8542d4c33286bb93f4de50060665799f Checkbox for datastore enabled in https://github.com/okfn/ckan/commit/3f1320cd92ae0e775fde1b5eada156260c55e0a6
#1797 1331412644000000 rgrp Merge fix https://github.com/okfn/ckan/commit/476a5bd32a3fac5d2dd85614f5d86c79f4ff6547
#1798 1329395560000000 dread Was fixed by Ian in https://github.com/okfn/ckan/commit/5a9054459e3833443bed3e118bbbb6c442e55b0b on branch feature-1453-flexible-tag-names. This has gone into CKAN 1.6.
#1799 1330000389000000 dread Fixed in [master ea2d824] for both logging in and registering whilst logged in. Cherry picked to release-v1.6
#1801 1343144718000000 amercader Closing as both old and new theme now show password reset links
#1802 1329409718000000 dread Current progress - I have got most of the dependencies installed - many by pip, but some I had to revert to Windows msi installers. Pad with details here: http://ckan.okfnpad.org/windows. So far done: 1 day.
← 19 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.