{23} Trac comments (3729 matches)

Results (2001 - 2100 of 3729)

← 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 →
Ticket Posixtime Author Newvalue
#1001 1300704249000000 pudo Wrote a WDMMG version of this yesterday: https://bitbucket.org/okfn/wdmmg/changeset/398ce0eb3901#chg-wdmmg/lib/authenticator.py
#1009 1298638447000000 pudo Some more ideas: * /user should list users, sorted by number of packages contributed/editied * /user/{name}/packages shows a list of packages to which users have contributed
#1017 1299668555000000 pudo fixed in cset:86d49a775fd3
#1019 1299166930000000 pudo fixed in https://bitbucket.org/okfn/ckanext-webhooks/changeset/034647931921
#1021 1299518828000000 pudo fixed in cset:9f1b38add19f
#1022 1299512991000000 pudo We're now using fileConfig to configure the logger API from the worker config file and this enables us to use SMTPHandler to send out error messages on queue processing failures. Marking as fixed.
#1023 1299514847000000 pudo Tried implementing this with AMQPs msg.requeue() and channel.basic_recover() but RabbitMQ yield a NOT_IMPLEMENTED error. Bit clueless on how to proceed.
#1024 1299668648000000 pudo re-created this (#1027)
#1027 1299666326000000 pudo 1. home controller -> __before__ (check "site-read" on model.System) 2. user -> each individually (repoze-who pseudo action must not be blocked) * user-read (index/read/update pages for users) * user-create (register) 3. revision -> __before__ (check "site-read" on model.System) 4. tag -> site-read (__before__) functional/test_authz.py * denies site-read ... * checks for visitor / logged in user .. * checks you can still visit login
#1027 1299682082000000 pudo fixed in cset:532c3ad2743b
#1044 1300627007000000 pudo David, thanks for writing those tests - perhaps we should combine them with the ones below ("TestLockedDownUsage") which attempt to basically do the same. As for the inconsistency introduced by the global check in the REST API you're right: Of course it is strange that WUI access checks are more granular than the API checks. The alternative is that we either move authz checks into all relevant REST places (a major refactoring I would be suspicious of) or that we introduce duplicate checks on the WUI actions (I actually have performance concerns about that, authz is incredibly slow - and it introduces another level of special authz that I think we really should not have). Given the choice I'd opt for the REST refactor - there is no good reason to make SITE_READ a duplicate check where authz already applies. On the other hand, this is a function we really don't want to enable or even have and that was only added to satisfy some very specific user demands. Given that these are fulfilled, I'm actually OK keeping the inconsistency for now - nobody will see it in normal operations and in a locked-down environment, users will need to have API keys anyway. Regarding the naming, I'm pretty opionion-less: SITE_READ was proposed by rgrp and I think its pretty fitting, while OTHER_READ would just confuse me. PUBLIC_READ might work, though.
#1122 1306662099000000 pudo I don't think there's really a nice way to do this with the current solr indexing library, but I've commented out the list handling code which should really make handling this cleaner.
#1155 1306773174000000 pudo Now implemented based on CSV export available on the catalogue page: * http://data.london.gov.uk/catalogue
#1156 1306855111000000 pudo Both are now implemented but may need further work to adhere to developing conventions wrt to location etc.
#1159 1307615133000000 pudo Rudimentary RDFa has been added with seeAlso to API.
#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?
#1173 1307615271000000 pudo Now available in ckanext-rdf and linked to from WUI.
#1174 1307615200000000 pudo wontfix as thejimmyg wants to turn REST API into RPC API and this doesn't fit in. Not an excellent plan in my idea but this is to be discussed elsewhere.
#1198 1308821489000000 pudo This ticket is essential I think. I would propose we should be a bit more radical here, though: * Introduce an "Agent" SQLAlchemy object and derive both publishers and users via single table inheritance. * Make agent the central object of authorization, e.g. by introducing c.agencies including the user account, visitor, logged_in, etc. * Abolish AuthorizationGroups in favor of publishers. Yes, they are different but the use case for what AuthzGroups do and Publishers don't is just nerdery. * Restructure URLs to be /<agent>/<package_name> rather than /package/<package_name> and have /<agent> be a useful list of managed resources rather than a revision list (users current home page). * Make Agents a primary facet for all kinds of navigation. Of course this would be done incrementally but I think we should agree on some such scheme as a marching direction.
#1199 1308922389000000 pudo merged to default with password reset forms
#1208 1312191646000000 pudo This should be closed: * https://github.com/okfn/webstore - See README for details * Python client lib: https://github.com/okfn/webstore-client * http://webstore.thedatahub.org/ - Demo install * http://wiki.ckan.net/Webstore - Overview
#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?
#1249 1311959356000000 pudo fixed in cset:0398243111d4
#1250 1312370201000000 pudo The issue is caused after search returns from solr and tries to get objects from the database. These are by default ordered by name and we need to restore the original order after fetching them from the database. Fixed in module.
#1430 1320444567000000 pudo You probably know this by know but the solrconfig.xml for both points to /var/lib/solr/data (line 71).
#4 1220900713000000 rgrp Dependent on upgrade to vdm v0.2 (sqlalchemy). Once that is done should be fairly simple (can port query stuff from microfacts?).
#4 1223908381000000 rgrp r368. Search by package title and name implemented. Other options will become separate tickets.
#5 1157371211000000 rgrp See changeset:37 (searching for packages) and changeset:38 (A-Z finding)
#5 1185473622000000 rgrp See r64 ff.
#7 1157371311000000 rgrp See changeset:39
#7 1204136209000000 rgrp No longer have concept of releases in CKAN domain model (if we did with vdm could now implement simply as a package at a particular point in time).
#8 1204135181000000 rgrp Probably part of ticket:43 (generic attributes) now so downgrading priority (also release no longer exists as a part of CKAN domain model).
#8 1250619147000000 rgrp Not part of domain model conception for a long time so closing. If we need something like this can open a new ticket.
#11 1157371568000000 rgrp See changeset:39
#12 1157371398000000 rgrp See changeset:39
#12 1204135071000000 rgrp No longer have concept of releases in CKAN domain model (if we did with vdm could now implement simply as a package at a particular point in time).
#13 1157373546000000 rgrp See changeset:39
#13 1218545330000000 rgrp No longer have concept of releases in CKAN domain model. See ticket:12.
#14 1157371389000000 rgrp See changeset:39
#14 1204136163000000 rgrp No longer have concept of releases in CKAN domain model (if we did with vdm could now implement simply as a package at a particular point in time).
#15 1204135174000000 rgrp Probably part of ticket:43 (generic attributes) now so downgrading priority (also release no longer exists as a part of CKAN domain model).
#15 1250619139000000 rgrp Not part of domain model conception for a long time so closing. If we need something like this can open a new ticket.
#16 1204135164000000 rgrp Probably part of ticket:43 (generic attributes) now so downgrading priority (also release no longer exists as a part of CKAN domain model).
#16 1250619162000000 rgrp Not part of domain model conception for a long time so closing. If we need something like this can open a new ticket.
#17 1204135155000000 rgrp Probably part of ticket:43 (generic attributes) now so downgrading priority (also release no longer exists as a part of CKAN domain model).
#17 1250619180000000 rgrp Not part of domain model conception for a long time so closing. If we need something like this can open a new ticket.
#18 1199787607000000 rgrp At present we do not have a person domain object on the system as we use openid for authentication and only use username for logging etc. May change this at some point in future but at that point can reopen.
#19 1199787631000000 rgrp At present we do not have a person domain object on the system as we use openid for authentication and only use username for logging etc. May change this at some point in future but at that point can reopen.
#20 1185473187000000 rgrp One can do this from python via the model API. Resolved with use of vdm back in r121.
#22 1199787243000000 rgrp At present we do not have a person domain object on the system as we use openid for authentication and only use username for logging etc. May change this at some point in future but at that point can reopen.
#23 1199786799000000 rgrp Now using openid for signon so this issue is not relevant.
#24 1246441366000000 rgrp Associated to ticket:60 (front page usability improvements) Fixed in r272:e6de501c384e.
#25 1199821005000000 rgrp Amended ticket substantially. Previous title was "A registered person creates their own tags for a package" but this was no longer relevant since anyone may add and amend tags (see ticket:30).
#25 1204131522000000 rgrp Fixed in revisions leading up to r239 and r241. Currently just have autocomplete and no 'suggested tags' as this requires pre-computation and caching of results which needs to be thought about further.
#27 1199788321000000 rgrp In many ways everything that is needed is already in place in that the package update and create controller just require raw posts to do their work. However should implement some kind of authentication/authorization to prevent automated spamming. This would also require some way of distinguishing posts from our own WUI and those coming from outside (at present no checking is performed and the 'post' to these controllers is freely allowed by anyone out there!
#27 1202400048000000 rgrp Methods potentially in need of access control at present (on controllers/package.py) * update (_update) * create Frankly, for time being we can probably leave these unsecured but with monitoring. Should they be abused we can add access control fairly easily. So decision: no work on access control/auth for time being here. Focus instead should be on: * documentation of post parameters (rgrp) * returning restful status values (201 Created, 204 Updated, etc) * returning machine readable output from read and list (json)
#27 1207683863000000 rgrp The remaining issue is authentication. Initially was hopeful that we could use openid (perhaps with oauth) but this does not seem possible (despite much talk of openid and oauth being complementary) ... Thus we shall adopt this old-fashioned approach. * A user who wishes to use the web api must obtain a web api key. They do this by: * Going to ckan.net and signing in using their open id. * Visit /account/apikey/: this should generate them a unique uuid key (or show their existing key if they already have one). This key should then be stored in the db along with their openid. * Once a user has an api key they must include in the request when making changes. This may necessitate an update to the restful api to start having a more generic message format (this also makes it more extensible for the future): * auth: auth key * data: data body (what we currently send)
#27 1215543933000000 rgrp Massive ticket now thoroughly addressed (early start in r242 and ff. then later in r275, r276 etc). Also now have start of demo ckan REST client at browser:ckanclient
#28 1200902911000000 rgrp Mark as wontfix as not sure what benefit this provides given the the sql dump of data already provided in relation to ticket:38. If necessary it can be reopened in the future.
#29 1157371518000000 rgrp See changeset:40.
#30 1185472559000000 rgrp This ticket is partially resolved and partially irrelevant: * Since move to 'ckan2' in Jan 07 (r54 onwards) have had tag support. * Since move to versioned system (r121 and ff.) have allowed tags to be added and amended by anyone.
#31 1177006817000000 rgrp Milestone milestone20 deleted
#31 1185472236000000 rgrp Can get this functionality via Notes section of package. Might want to reopen in future if specifically need something 'comment-like' rather than 'text-wiki-like' but for time being what we have is fine.
#32 1185472746000000 rgrp Added Tag support in r82 to r87 (back in February).
#33 1185472909000000 rgrp Basic listing support for tags in r82 to r87. However search (and paging of tag lists) not yet provided.
#33 1199788094000000 rgrp Added search support in r190. No paging of tag lists but this is now part of new ticket:42.
#35 1185471537000000 rgrp Resolved in r157.
#36 1185470035000000 rgrp Resolved in r168.
#37 1199786536000000 rgrp Fixed in r193 with improvements in r201 and crucial bugfix in r203.
#38 1199787336000000 rgrp Partially addressed by r194 and making available of db dump on production machine.
#38 1200903004000000 rgrp Closing for time being as sql dump seems sufficient. If JSON is to be provided (per package and with Atom feed of changes) this should be made into a separate ticket.
#39 1200761681000000 rgrp Using current vdm system this will be very slow so reassign to v0.6 (when we should have updated to new and better vdm setup).
#39 1214244190000000 rgrp Deferring as transition to new vdm has not yet happened will do as part of 0.7. Also fairly low priority ...
#39 1220900869000000 rgrp Dependent on ticket:51 (upgrade to vdm v0.2).
#39 1223908298000000 rgrp See r363 r364 and r366.
#40 1200993319000000 rgrp Fixed in r211.
#41 1199787967000000 rgrp r198 upgraded trunk to use 0.9.6 and these changes were deployed on production as of 2008-01-06 (PM).
#42 1204133257000000 rgrp See r234 and previous. Pagination now implemented for packages and tags (but not for revisions yet).
#43 1214244140000000 rgrp This is currently low priority and should only happen after move to vdm 0.2 (sqlalchemy etc).
#43 1241779943000000 rgrp Started work on this using "extra" table. See r426.
#43 1246441195000000 rgrp Making this versioned/revisioned turns out to be slightly more complex than anticipated (need a stateful associated list). So defer to 0.95
#43 1249410762000000 rgrp Done in model in changeset:7f9b19d4d54a: "Implement a fully *versioned* PackageExtra domain object in the model and attach to the Package object via a simple dict-like attribute named 'extras'.". However still need to integrate into WUI which can only happen after conversion to formalchemy (ticket:76) is complete.
#43 1253709802000000 rgrp Split out wui work in two new tickets ticket:124 (show) and ticket:125 (edit) and therefore marking this as done.
#44 1215543484000000 rgrp Minor importance and at this point we will defer into v0.7.
#44 1223390660000000 rgrp Done in r339.
#45 1204133342000000 rgrp Fixed in r221 by JB.
#46 1218545499000000 rgrp Fixed in r303.
#47 1201600216000000 rgrp Good suggestion (this has been on my mind for a while). This should be pretty cheap to do, see instructions at: http://wiki.pylonshq.com/display/authkitcookbook/OpenID+Passurl We probably just want to create a normal genshi template and then have a function that renders which can then be set in the config file.
#47 1215543616000000 rgrp Fixed in r303.
#48 1296663361000000 rgrp Done in cset:2a056fce7798.
#49 1214244368000000 rgrp Has become less of a problem since big efforts a few months ago so this can be downgraded for time being.
#49 1257244973000000 rgrp Not a problem at the moment.
#50 1239018913000000 rgrp Have done a bit of digging but noot currently a priority given direction datapkg is going.
#50 1267648356000000 rgrp Do not see there is much more to do here.
#51 1223908230000000 rgrp Done. See r344 to r354.
#52 1223908425000000 rgrp Turned out this was already implemented -- see r366.
#53 1239133021000000 rgrp See r435. This just provides basic list of revisions affecting this. Next step would be to show diffs but that is another ticket.
#54 1223909366000000 rgrp ckan v0.6 (dump only) done in r355 and r358.
#54 1230211256000000 rgrp See r362, r365, r370 + more.
#55 1223909475000000 rgrp See r356 and r362 and r365.
← 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 →
Note: See TracReports for help on using and creating reports.