{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
#2202 1338204801000000 toby re-reading this it's slightly different re-opening
#2201 1330765400000000 rgrp Duplicate of #1171.
#2198 1339771453000000 kindly Already in the docs.
#1831 1330956631000000 ross Already have a branch for this.
#1831 1331549284000000 ross Email is not currently 'unique' in the user model. Find out if this is intentional or not.
#1831 1331655458000000 ross Decided to delay this until later but code is in feature-1831-login-by-email
#1830 1330089912000000 dread Now if you set openid_enabled to false, you are not given the option in user settings to associate your account with openid. Cset: [master b295bde] I looked at removing the openid middleware, but we use it for logging out users, whether they logged in or not - it looks like friendly form plugin is not as good as the openid one in this respect! We could hack the logout function into the friendly form to sort this out, but not sure the effort is worth it at the moment.
#1829 1330001828000000 dread This was due to https://github.com/okfn/ckan/commit/f07bfdb9#diff-1 - string "Language has been set to: English" shouldn't have been translated. I've put in a patch to make the code intentions clearer and added a test: [release-v1.6 07d3a02]. This only affected the 1.6 beta, and is fixed for the release.
#1828 1330525412000000 rgrp Fixed in https://github.com/okfn/ckan/commit/e6da48d9337575a83bc6a30896e68d1081b43847
#1819 1332163324000000 kindly Currently using package_show_rest. Should be moved to just use package_show but that is another ticket.
#1816 1330863079000000 rgrp As per detailed comments in http://wiki.ckan.org/Proposals#Apps_in_CKAN I think Apps is a confusing name. What we are talking about here is the "Related Stuff" item mentioned in that ticket. Rather than update ckanext-apps I suggest we do a rewrite. I've created a detailed super ticket at #2204 and assigned to you Adria for review and thoughts. (While I understand #2204 may involve more work which we maybe cannot do before relaunch I'd still recommend starting on that rather than spending time upgrading this extension -- if we have to disable it for relaunch I don't think that is a big deal ...)
#1816 1331302835000000 amercader +1 to a new, more flexible extension. But in the meantime I've just spent a couple of hours making it work with latest CKAN, which was easier than expected, so we can deploy it with the new version of PDEU.
#1812 1335874864000000 johnglover Ross has fixed this via group authentication.
#1811 1329918517000000 johnglover Deferred for now, moving to backlog
#1811 1335874765000000 johnglover Not using eurovoc tags.
#1810 1329918479000000 johnglover Deferred for now, moving to backlog.
#1810 1335874745000000 johnglover Not using eurovoc tags.
#1809 1330528828000000 johnglover Caught exceptions in QA instead, error message stored as openness_score_reason
#1807 1330809641000000 seanh Implemented the recently-changed-datasets activity stream on branch feature-1807-recently-changed-datasets in CKAN and merged it into master (but the default templates don't make use of it). Added the recently-changed-datasets activity stream to the front page template on branch master in ckanext-ecportal.
#1806 1330942356000000 toby version one completed
#1806 1331295310000000 toby closing as initial work has been done if we need to amend then create a new ticket
#1805 1329760795000000 toby this is fixed in branch feature-1653-i18n_url_rewriting
#1804 1329491156000000 toby This should be fixed in branch feature-1653-i18n_url_rewriting as we use different logic. However it may affect other return_to calls used elsewhere like adding a new package.
#1804 1330000705000000 dread I'll fix this on release-v1.6 and then reassign to Toby to fix on feature-1653-i18n_url_rewriting too if the same issue crops up there.
#1804 1330037202000000 dread Fixed this on release-v1.6 in cset 557e72330db7. Spent 0.5h. Reassigning for Toby to look at branch feature-1653-i18n_url_rewriting
#1804 1330347185000000 toby This has been fixed in master for a while and was only a 1.6 issue
#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.
#1802 1329490081000000 dread I've achieved CKAN running with paster and without SOLR (using simple_search). Running locally on an old XP machine, performance seems fine - no noticeable issues. I installed most things into a pyenv using pip. pyutilib, psycopg2 and lxml were slightly problematic, but I have workarounds. I had problems pip and svn and the Cygwin window, so reverted to DOS prompt. I still had the Cygwin tools installed though, so next step is to try it without these at all - they are a big overhead.
#1802 1329734716000000 dread Spent so far 1.75d
#1802 1329830097000000 dread * Refined install without using Cygwin - this seems a little easier. * Added example Apache & modwsgi deployment. * Documented extensively at: http://wiki.ckan.org/CKAN_install_on_Windows * Have not tried SOLR on Windows - I'm not convinced this is high priority, and normal install should be fine as it is so separate from CKAN. Spent another 0.5d. Total spent 2.25d
#1801 1343144718000000 amercader Closing as both old and new theme now show password reset links
#1799 1330000389000000 dread Fixed in [master ea2d824] for both logging in and registering whilst logged in. Cherry picked to release-v1.6
#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.
#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
#1796 1339586499000000 ross LXML removed, update requirements on the extensions
#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
#1791 1329138315000000 dread Fixed in [release-v1.6 beaeaed]
#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 :-)
#1786 1328640597000000 dread Fixed [master fe6829e]. Aimed for release CKAN 1.6.
#1785 1340724312000000 seanh No point in doing this for 1.8 because the new theme is coming along anyway, moving into 1.9
#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.
#1783 1328612744000000 dread Fixed in [master 8f059ed] aimed for release 1.6.
#1781 1329393814000000 kindly complete at 669a8e9f7a768b147b1668940842b72b2a302088
#1779 1329393759000000 kindly complete at 669a8e9f7a768b147b1668940842b72b2a302088
#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.
#1769 1329737597000000 icmurray Duplicate of #1762
#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.
#1765 1328805833000000 seanh Done on branch feature-1698-tag-taxonomies
#1764 1335878051000000 seanh Closing because I'm not sure what the reason for doing this would be.
#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.
#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).
#1755 1328630657000000 ross Implemented in v1.0-dev of ckanext-dgu and feature-1645-apply-simple-theme of ckanext-dgutheme
#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.
#1746 1355141062000000 seanh Closing this as won't fix, we decided to do http://trac.ckan.org/ticket/3018 instead
#1744 1330349472000000 zephod Massive refactor of parent ticket mean this is all done and can be closed off. See #1506 for remaining UX work.
#1743 1328527086000000 rgrp Marking as wontfix - as per discussion here: http://lists.okfn.org/pipermail/ckan-dev/2012-February/001652.html
#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
#1741 1328526473000000 rgrp 2.5d, 1d remaining.
#1741 1329750838000000 kindly done cset:7825caed3361e88a245b5dd2f946da8bedb160e0
#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.
#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
#1738 1328494709000000 kindly cset: 117dce4d64de731e7b0a3c55175a1d093f2bf540
#1738 1330086105000000 dread Cset is actually dd2c0c677117f06a52aa22b3b2717bb605263570 and went into CKAN 1.6
#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.
#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.
#1734 1332167315000000 amercader All sub tickets have been implemented, so closing it now.
#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.
#1730 1328537387000000 johnglover The function for this is the converter function for tags with vocabs. Will integrate with the JQuery chosen plugin.
#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.
#1725 1328204489000000 dread Fixed in 6fecbd9fb08f5a22e9dd2dd2745c287a38f44a30 on master. Added test for the tag_string_validator too. Aimed for 1.6 release. Took 1h
#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
#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.
#1722 1328805890000000 seanh Done on branch feature-1698-tag-taxonomies
← 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.