{23} Trac comments (3729 matches)
Results (2201 - 2300 of 3729)
| Ticket | Posixtime | Author | Newvalue | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| #1491 | 1322563620000000 | seanh | I've finished some work on this ticket here, ready to be reviewed: https://github.com/seanh/ckan/compare/defect-1491-visible-strings-need-internationalisation | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1440 | 1320235084000000 | dread | I've done this. 'db load' now also does 'db upgrade' and 'search-index rebuild'. If you want to debug the load (or don't need the search index, cos it takes ages to do), then you can just do 'db load-only' which does what 'db load' did before. Changed in cset:9e51df5c496b for 1.5 release. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1002 | 1311173185000000 | thejimmyg | I've done this in my branch and it will get merged in. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2550 | 1341767370000000 | icmurray | I've done some initial work on this. I think the best way is to define extra tables in the datahub extension. (Rather than: using groups; or modifying the user table; or defining extras for users (in core)). Initially, I've created a new domain object, PaidService, which captures the different levels of account a user may have. And then attached users to this through a secondary table. I think the advantages of this approach are: - the PaidService table can contain supplementary info about that account type: eg - amount of storage allowed; or cost to sign up etc... - allows us to use a modular payment system if biz decide that would be favourable. ie - users belong to multiple PaidServices which are independant of one another, rather than a linear hierarcy (eg - "sign up for storage, but not for privacy" vs. "sign up for enterprise level rather than basic level") The thing that's held me up today is being able to run tests: I'm having a sqlalchemy issue with defining extra mappings on the User table; which then gets dropped when initializing the test setup. I've gotten to the bottom of the problem, and will ask kindly's advice. In the meantime, I could do with some user stories please. I think I have a fairly good idea of what's likely to be needed by this ticket; but to what extent should this be exposed to a sysadmin (adding payment schemes; adding users to payment schemes; users seeing which payemtn services they're paying for (public to other users or not?); user's seeing history of payments? sysadmins seeing list of users for each service level?) - should this be: through a dashboard? through paster commands? through the api? all 3? Do we want modular payments or a linear hierarchy of payment schemes? How does is this suppossed to fit in with organizations? Do organizations purchase on behalf of users as well as individuals being able to make purchases? Do we need to be able to deativate a user's paid service if their payment hasn't come through? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1298 | 1321199769000000 | seanh | I've been working on this in this branch: https://github.com/seanh/ckan/commits/feature-1298-activities-table | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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 :-) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1430 | 1320339962000000 | amercader | I've been digging more on this one. To reproduce it, you just have to edit the same dataset in both sites (production and testing). Just after editing the dataset, the search index will get mixed site_ids. I checked the jetty logs (see attached files) and just after editing a dataset there are two POST requests to update the index. The request logs don't show the requests params so it's hard to tell what the second call does (it probably is the commit): https://bitbucket.org/okfn/ckan/src/97e1e90d66d7/ckan/lib/search/index.py#cl-144 In any case, it's clear that the problem may be related with the datasets in the two cores sharing the same id. We are currently using the dataset id as uniqueKey in SOLR, i.e in our schema.xml, we are defining: {{{ <uniqueKey>id</uniqueKey> }}} According to the SOLR docs: "If a document is added that contains the same value for this field as an existing document, the old document will be deleted." http://wiki.apache.org/solr/SchemaXml#The_Unique_Key_Field I would expect the uniqueKey not to be mixed between cores, but it looks like it happens otherwise. Maybe we should generate a solr_id specific to each document for each site, as described here: http://wiki.apache.org/solr/UniqueKey#UUID_techniques (Note that apart from the testing/production site use case, at some point sites involved in harvesting could also end up with datasets with the same id.) Again, I'm not a SOLR expert, so the problem could be a completely different one! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2208 | 1332251880000000 | seanh | I've attached a ckan.pot file. To make it, I edited setup.py in CKAN core like this: https://gist.github.com/2135849 and then ran python setup.py extract_messages. (And I had ckanext-ecportal installed at ~/pyenv/src/ckanext-ecportal.) I guess I may need to run this again when the ckanext-ecportal source is finalised, so leaving this ticket open for now. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2437 | 1338487089000000 | seanh | I've also added the commit message guidelines as they reference a trac plugin I'm going to get installed. I'll leave the rest to you. I remembered that http://wiki.ckan.org/Main_Page has a bunch of pages under Developer Resources that should probably be updated and merged into these coding standards and deleted from the wiki | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1284 | 1315212603000000 | dread | I've added tests for this (to prevent yet another regression!) in cset:1b77ce8ce560. Closing. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1054 | 1300989764000000 | dread | I've added some tests in the branch: defect-1054-resource-order | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2791 | 1343906884000000 | aron.carroll | I've added no-wrap as of 1db2037. Not sure what we should do about short titles/long tag lines though. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1044 | 1302096155000000 | dread | I've added in the docs for this in cset:013da53052d1 ready for release 1.3.3. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1044 | 1300449905000000 | dread | I've added in tests for SITE_READ and corrected the 403 response - see branch bug-1044-site-read. The tests have uncovered some inconsistencies in the use of SITE_READ between reading/editing a package in the Web interface vs the REST API. Friedrich, do you want to take a look at ckan/tests/functional/test_authz.py:TestSiteRead.test_pkggroupadmin_read for details and have a think about how this should best work. How about making SITE_READ more widespread in the WUI, to protect read/editing/searching things, in addition to the READ and EDIT RoleActions. Once that is decided, it should be pretty easy to refer to the tests and document SITE_READ. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1494 | 1326103951000000 | seanh | I've added a controller function for getting a user's activity stream as rendered html to ckan/logic/action/get.py in this commit: https://github.com/okfn/ckan/commit/30264997c7fe34324381123d6741d404baa67c1e I'm proposing to leave it at that for now and not actually hook this controller function up to an API call, as I'm not sure how useful an API call for getting rendered HTML will be (we already have an API call for getting the user's activity stream a JSON). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1214 | 1309982828000000 | dread | I'm working through these on branch defect-1214-api-improvements. "Server returns text/html for errors" - now fixed in cset:0a533a8da3df | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #366 | 1299845116000000 | dread | I'm very pleased that this now works when you try to edit a package that is not allowed. Are there other circumstances we should cover or can we close this? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1006 | 1300372286000000 | thejimmyg | I'm updating the branching policy now. David has closed stable and closed metastable. Marking as fixed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2304 | 1335878372000000 | seanh | I'm setting the priority of this high just because it's a low-hanging fruit for this sprint, as it was almost done last sprint. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2331 | 1343814758000000 | rgrp | I'm re-opening this. This is a reasonably significant UX problem -- not just a philosophical difference. It is just *weird* to get *more* results as I add search terms rather than less. Please can we have this fixed ... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1127 | 1305458020000000 | rgrp | I'm obviously a strong +1 but feel we should stick with the CEP name (we have PEP and DEP and CREP really does sound weird compared to CEP). Also I think we may need to do a bit more to clarify when you just do a good ticket and when one does a CEP (looking at what has occurred already). I think this may be one reason to keep CEPs separate in drafting from trac as will clearly distinguish CEPs from standard tickets. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1284 | 1315214358000000 | rgrp | I'm not sure this is the sort of thing we need tests for (we can have too many tests!). Something worse discussing ... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1583 | 1324484387000000 | rgrp | I'm not sure star rating is the key thing I want to know and I also think it will be visually very confusing (I associate stars with ratings now with some automatic quality assessment + (IMO) 5 star isn't that useful). I'm much more interested in things like: * Is this down (all the time) * Has this been down recently * When was this last modified (not quality per se ...) This is an area where referring back to the original user stories (if any) around QA is really useful. I guess my feeling would be some of this should be about providing e.g. helper methods so that theme designers can incorporate things into their design with some work putting this into default CKAN theme. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #803 | 1289489024000000 | dread | I'm not sure a template is needed for the test script - surely repeated stuff can just be factored out? Creating the model dump file: * 'hg up' to ckan as it was at the last model migration * 'paster db clean', 'paster db init', 'paster create-test-data' * 'pgdump' * 'hg up default' * Check in the dumped file Do we really want a script to mess with our repo like this? Isn't it just safer to do manually with good instructions? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #817 | 1289997628000000 | cygri | I'm not allowed to create attachments for some reason. Here's the screenshot: [[Image(http://richard.cyganiak.de/2010/ckan/ckan-resources-table-proposal.png)]] http://richard.cyganiak.de/2010/ckan/ckan-resources-table-proposal.png | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1044 | 1300712223000000 | dread | I'm happy to leave the inconsistencies in SITE_READ for now, since this will be resolved when authz is centralised between WUI and API in the dictization refactor. I'm also happy to leave both TestSiteRead and TestLockedDownUsage as they complement each other nicely actually. So I think all that remains for this ticket is to add a paragraph to the authz documentation about SITE_READ. Pudo would you mind doing this? It's well worth noting where it applies and where it doesn't. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2774 | 1344008312000000 | aron.carroll | I'm happy to just make ajax requests to public/base/i18n/<locale>.js, however this will use the language set in the <html lang> attribute. So if this file doesn't exist then we'll get a 404 and show the english. If we want something more sophisticated, determine an appropriate fallback etc, then I think the API is the way to go. Or we could get CKAN to determine the appropriate language file and include it in the page source... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #838 | 1295259773000000 | rgrp | I'm going to close this ticket as almost everything done and remaining ticket can be done on its own. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2514 | 1340959630000000 | ross | I'm going to close this as it is not safely in Aron's hands for the new demo theme. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1387 | 1318429228000000 | dread | I'm generally against validation. When doing any bulk import, it either have to ignore validation errors or lose data. If you ignore the errors, you find you can't edit the dataset without correcting the validation error, and you often end up guessing, just to get your other changes in. All in all, I think it is better to nudge users, with javascript pop-ups in the form, or quality scores, rather than hard-and-fast validation. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1412 | 1328226385000000 | rgrp | I'm completely unable to reproduce this issue in either FF (9.0.1) or Chrome 16.0.912.75. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2256 | 1336046098000000 | toby | I'm closing this ticket now ckanext-datahub exists and is live - the other work is included in other tickets | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2559 | 1342084940000000 | toby | I'm closing this now we can open tickets for bugs when we qa the add dataset | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2398 | 1337963342000000 | seanh | I'm closing this because we've got a whole bunch of tickets from the dev meetup about fixing the dependencies and requirements file that should deal with this problem | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2562 | 1352206599000000 | johnmartin | I'm closing this because I can't get context on this. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #957 | 1314218701000000 | rgrp | I'm closing this as wontfix as we now have arbitrary metadata for resources so probably won't need a specific field. That said we probably will want a schema but that is not yet finalized and would be a separate and wider ticket. For current proposal of the attributes generally wanted for resources see http://wiki.ckan.net/Domain_Model/Resource (recently updated). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2580 | 1342092353000000 | toby | I'm closing this as now you need to add at least one resource | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1246 | 1311885360000000 | pudo | I'm afraid to say I don't understand any of this: the faulty display of openness is triggered as removing the brackets turns the isopen() check into a check for the existence of the method. Reverting the changes on the server seems to work without generating exceptions. What exactly is the issue that was supposed to be fixed originally? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1329 | 1317118323000000 | dread | I'll take a look to see if I can do any more and then will close it. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #954 | 1300217106000000 | thejimmyg | I'll look at this for a v3 API with kindly as part of the dictization. It also addresses some potential XSS issues in the API we've discovered. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1400 | 1331544816000000 | johnglover | I'll have a look thanks. I'm +1 on using main docs instead (if we move everything), I was just trying to keep things consistent for now. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #442 | 1294661028000000 | dread | I'll close this now. Only thing to note is the importer code pudo wrote in ckanclient that could usefully be merged with the ckanext importer code. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1123 | 1307374691000000 | dread | I'll change the architecture to "all" as per this article: http://linuxreviews.org/man/deb-control/ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1654 | 1330863104000000 | rgrp | I'd vote -1 on SPARQL endpoint and doing the simple version of #1649 as proposed in my comment http://trac.ckan.org/ticket/1649#comment:2 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2836 | 1344859911000000 | toby | I'd quite like some general css like this <span class="hover-for-help">[thing to hover over] <div class="help-text">Help text</div> </span> This is for the qa extension but seems like a general need .hover-for-help .help-text{ display:none; } .hover-for-help:hover .help-text{ display:block; position:absolute; padding:3px; } | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2256 | 1333620795000000 | toby | I'd like to remove all 'custom' icons and just use bootstrap ones - is this reasonable? they are added in different ways but h.icon() could be easily adapted for this. minimal .sj .css files | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2204 | 1334218735000000 | ross | I'd be happier adding this to another ticket rather than moving the target for this ticket half way through so have created #2284 Should only be a short ticket in the next sprint. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2785 | 1344256089000000 | shevski | I would say leave as phase 4 for now | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2255 | 1332752936000000 | rgrp | I would say Public is default for Organization with Private being an option (or do we make this a config option?). What about ownership by users? > New datasets can be created from the organization form, in which case the organization will be set in the dataset form dropdown (with privacy set to private - see below) Does this mean like the setup on groups on the datahub (i.e. forward to new dataset but with some things hard-coded, organization/group?)? Or does it mean actual new dataset form on organization page. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #826 | 1297415095000000 | pudo | I want to strongly support david in his call for fully flexible extras: one of my use cases for them is to store the various bits of fallout from an archiving process, such as: * last-status * last-crawled * last-etag * last-expires * last-md5 * failure-count * fall-back-url These are things needed to really archive the data well, but they have nothing to do with CKAN core ops. Essentially, the archiver is a seperate concern and it need not appear in the CKAN config. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1489 | 1322138014000000 | dread | I updated the theme stuff in a75ca84. I've asked Ian to see if he can replace the form stuff with a new form (v. quick simple!). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1724 | 1328634433000000 | johnglover | I updated tag_list: https://github.com/okfn/ckan/commit/335535b646adf983d1d19bf19613712099db1f5e | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2751 | 1344240974000000 | aron.carroll | I tried {{{paster trans mangler -c datahub.ini}} I also had to {{{ pip install polib }}} and run {{{ python setup.py egg_inf }}} I find it hard to believe out coverage is that poor, I've just been through a random selection of templates and they all have appropriate calls to {{{_()}} or {{{ {% trans %} }}}. Will look once I get this running. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1172 | 1314118883000000 | dread | I took out "raise" by mistake in ckan/lib/search/worker.py:26 but John has added it in in the corresponding place in ckan/lib/search/__init__.py on branch feature-1275-solr-search anyway. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1400 | 1331543941000000 | johnglover | I thought that we had some sort of consensus that the official docs were aimed more at system admins and people using the CKAN WUI/API, with the wiki aimed more at developers? It would be easy to move of course, but there is no real "developers" section in the official docs that I can see, and it's even called "CKAN's Administration Guide". | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2550 | 1341833460000000 | ross | I think you've nailed the user stories already, but have added them to Description to be explicit. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #794 | 1300877517000000 | thejimmyg | I think we need to look at this again in relation to scotland. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2619 | 1351531137000000 | seanh | I think we need a function that filters out all activities and activity details where the user doesn't have permission to read either the subject or object of the activity or any of its activity details. Each of the *_activity_list() functions can then use it. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2698 | 1343378378000000 | toby | I think this would be really helpful/nice | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2644 | 1344255836000000 | shevski | I think this requires some thought & probably a discussion. For example need to be clear on the purpose of a user dashboard vs say a publisher dashboard. I image a publisher dashboard would have the stats to datasets belonging to that group (e.g. views, downloads, comments, shares, ratings), issues reported (when we get that extension working), call to action to add a new dataset (that adds it to the group). User dashboards I'm less clear about. May be we can talk about this on Tues/Wed? Or skype today | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #277 | 1296340723000000 | rgrp | I think this is useful but there may be complexities giving the non-reloading nature of python apps. Have also converted to an extension | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1373 | 1319542883000000 | dread | I think this is due to the etags cache not taking into account whether you are logged in. So the page is cached by squid (which is why it's not seen anywhere apart from thedatahub.org). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #125 | 1257535181000000 | rgrp | I think this is done :) -- dread do you want to close this with linked cset? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1553 | 1326288657000000 | ross | I think this is caused by the javascript xhr call getting redirected (quietly) to the login page, so the original javascript can't complete as it has a login form rather than the auth form it is looking for. Maybe we should change the JS to realise that it is at the login page and do something different than pretend to still be uploading? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #269 | 1288036269000000 | rgrp | I think this has been long obsoleted by other work (e.g. more recent work on gov form). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1334 | 1319798961000000 | dread | I think this has been a problem since 1.3.3. Fixed in v1.5. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2601 | 1340723256000000 | seanh | I think this happens whenever you try to edit a dataset that has no organization | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2669 | 1343597264000000 | shevski | I think they should be slightly greyed out. More importantly they should be hidden to everyone not a member of ownership group | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1579 | 1338212496000000 | ross | I think the new datastore solves this. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2366 | 1336555441000000 | ross | I think the UI aspects have been removed in 1.7 with hopefully the rest of it going in 1.8 - assuming we have a clean migration script. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1177 | 1307374897000000 | dread | I think rgrp was suggesting you have mistakenly set has_commenting to "True" in app_globals or elsewhere. But either way, this should have no side-effects. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2681 | 1342512160000000 | shevski | I think just a file format, but want other perspectives. What do you think? & David: what do you think? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2785 | 1344243731000000 | shevski | I think it's a nice to have, esp if we give it an intuitive UI Rufus is keen for this also | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2852 | 1345103634000000 | toby | I think it should stay red but you can argue | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1198 | 1308824870000000 | dread | I think it is a good idea to allow both users and publishers to be the object of authorization. The user_object_role table and all logic surrounding it would be simpler. I deliberately didn't suggest any detail on the authz front because I know other related changes are afoot so it would be useful for David Raznick to contribute here. I really like the url ideas - more like github. /<agent> having a list of packages and a search box, plus a link to the latest revisions would be great. /package/<package_name> would usefully redirect to /<agent>/<package_name>. I do think this should be split off into a separate ticket though. What do you think? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #277 | 1296470458000000 | kindly | I think generally this is a bad idea. I think in a few controlled circumstances some configuration is worth changing at runtime, however looking through the development.ini file I do not see hardly anything in there that does not require a restart anyway. It would be good to have some clear examples of things that would be in the extension. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1044 | 1301304871000000 | dread | I think all that remains for this ticket is to add a paragraph to the authz documentation about SITE_READ. Pudo would you mind doing this? It's well worth noting where it applies and where it doesn't. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #560 | 1285430085000000 | [email protected] | I think I'm seeing a variation on this behavior: I'm retrieving the packages in the lodcloud group (http://ckan.net/api/rest/group/lodcloud) and finding bibbase, and then fetching the package details (http://ckan.net/api/rest/package/bibbase) and getting a 403 Access Denied. If access to the package isn't available I would think it wouldn't be listed in the lodcloud group response. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #446 | 1282423615000000 | johnbywater | I think "an admin writes to the CKAN API" is a mishearing. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2265 | 1332865837000000 | dread | I started work on this and need to park it somewhere - here will do for now. I was using the 'MLT Component' http://wiki.apache.org/solr/MoreLikeThis : https://gist.github.com/2217684 But I think it would make more sense to use the 'MLT Handler' http://wiki.apache.org/solr/MoreLikeThisHandler which needs enabling by adding this to the config {{{/usr/share/solr/core1/conf/solrconfig.xml}}}: {{{ <requestHandler name="/mlt" class="solr.MoreLikeThisHandler"> </requestHandler> }}} | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #76 | 1250175782000000 | dread | I spent 30 hours on this task. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1456 | 1320930770000000 | dread | I see you've done this in cset:939e0e0809c1. Close now? BTW Take a look at the first suggestion from #1423 too, whilst in the area. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #698 | 1291742752000000 | Stiivi | I see two possible options: Option A: store only mirrors of source files, have file format based plugins for querying files Option B: store mirrors of source files, have plugin based loading scripts into "common structured format", have single query module. I would go with option B as it is: - easier to implement - file format based transformations are simpler than file format based queries - more transparent data management process - only one simple query module (see attached ckan-srcmirror.png) The Option B will fit better to the broader data architecture context: http://democracyfarm.org/f/ckan/data_arch.png Concerning API I would suggest to try to be compatible with google spreadsheet API: http://code.google.com/apis/spreadsheets/data/3.0/reference.html | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1549 | 1324037471000000 | dread | I see a need for short links to any package or resource, so people can Twitter about them. As far as providing forwarding to a resource URL, even if that changes, then I'm not sure there is a need for it to be short - we could just use a long link with the resource-id. e.g. thedatahub.org/resource/c1e89abb-13cd-4e18-9078-03d15bf6f256/url-forward. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2302 | 1343596669000000 | shevski | I reckon getting this live, esp with a easy to fill styled text header (see Sam's design) and a UI for changing About page text, featured dataset on homepage and welcome text is key | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1192 | 1308337652000000 | dread | I really think forms are a key asset of CKAN, and keeping the docs about customising and integrating them is important - i.e. forms.rst and forms-integration.rst. There are ideas being suggested for replacing bits of front-end, but forms hard to do, and David's new system is a significant offering on top of the CKAN back-end, so it seems crazy to me to abandon it. forms.rst has been updated by David Raznick in the release_v1.4.1 branch. i18n.rst - include here the creation of the pot file, deploying a translation, transifex admin load-testing.rst - I think performance should be mentioned in the glossy guide (some sort of basic metrics of speed profile, to return web pages, run searches and API operations, for 100 or 1000 packages, on a given spec machine) and have it based on a report showing how we measured it. The report would look a bit like this file, and it might do as a stub, but it seems pretty lacking. distributed.rst - agreed, remove. design.rst - agreed, delete. loaders.rst / loader_scripts.rst - yes move to wiki feeds.rst - this should be split into a tutorial for the wiki and the reference page left in sphinx importer.rst - this should be moved to ckanext-importer/doc admin.html - this has already gone in 1.4.1 authorization.rst - This is a bit jumbled. We're talking about changes to the code, so maybe not worth working hard to make this good, so I suggest leaving it, but delete the boring section "Requirements and Use Cases". deb.rst - this is an administrator task, so should stay why move this to the wiki? buildbot.rst - ok to stay here? vm.rst - I assume there's no problem with this | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #191 | 1323973116000000 | dread | I put the sort syntax example in the apiv3.rst table and moved the full curl example to http://wiki.ckan.org/Searching_CKAN I added tests for metadata_modified and prepared this branch for closure. Changeset: [origin/defect-191-modification-date bebf7a5] John, please review and close/merge if you think it is all ok. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1173 | 1307000249000000 | pudo | I propose we do a bit of frameworkiness here: set up a two-part content type registry and refactor the API controller to use it. The idea would be to do the following things: 1. Create a registry mapping format extensions to mime types: RepresentationRegistry.add_format('json', 'application/json') 2. Create a registry of (mime types, entity types) -> converter functions that yield an appropriate representation of the entity. 3. Hook this into the _finish method of the API controller based on Accept: handling 4. Add support for /api/rest/ENTITY/NAME.{format} and /ENTITY/NAME.{format} to routing, use registry from (1) to rewrite accept headers. 5. Register converters in load_environment or via IConfigurable plugins 6. Document What do you think? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1695 | 1327323309000000 | dread | I propose spending 2h on this. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1435 | 1323168783000000 | thejimmyg | I personally can't see the benefit of switching to a generic paid service when we already have a highly customised and working infrastructure based on buildbot and buildkit - we do testing in VMs as well as continuous integration. What is the advantage? Suggest wont fix? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #868 | 1292921456000000 | sebbacon | I mean #876, of course. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1050 | 1300458454000000 | dread | I may misunderstand how you intend to build the WUI Admin interface, but I think most of the stuff in authztool is just marshalling command line parameters anyway. The bits which do anything are factored out. For example, to list rights you just loop over obj_classes to call {{{model.Session.query(obj_class).all()}}} and then display the values: {{{type(subj).__name__, subj.name, role, type(obj).__name__, obj.name}}}. To change a right you simply call {{{model.add_user_to_role(subj, role, obj)}}} or {{{model.add_authorization_group_to_role(subj, role, obj)}}}. But of course if there is useful stuff to factor out then be my guest! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2630 | 1343392411000000 | seanh | I made another ticket (#2771) to encompass this and related work, closing this one as dup | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2749 | 1343232304000000 | toby | I like the block page_title approach but not too fussed as long as this instance is working | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #816 | 1312212782000000 | dread | I like rgrp's idea to change the model. But since it's complicated it would be good to have a UI. e.g. You might make format field simply a drop-down with only some common options: 'CSV, Excel, Zip, Other'. If you go for Other, then a more substantial UI appears, to cover more filetypes, APIs, services and a text box for Other. And if you select 'Zip' then another set of options appears to say what is in the zip. etc.etc. Another approach would be to have a background process downloading the data file and filling this in for you. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2890 | 1346175867000000 | rgrp | I know this is tricky. The issue is that Datastore does not exist *just* to provided data views - it also provides a bunch of other stuff like a Data API and, well, a Datastore. I also think there are different audiences. Data view info is about publishers and (viewing) users, while the Data API is for (non-CKAN) devs and CKAN devs and the Datastore sysadmin section is for deployers. My feeling is therefore keeping things as is but with more stuff in the Data View seciton about it all works: * Data viewer: explanation for publisher, links to next 2 sections * Datastore page (as we have it) * Includes datastorer * Using Data API page (as we have it) So main change is a better data viewer page ... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Note:
See TracReports for help on using and creating reports.
