{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.