{23} Trac comments (3729 matches)

Results (1701 - 1800 of 3729)

← 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 →
Ticket Posixtime Author Newvalue
#1001 1300367555000000 thejimmyg Yes, I think the two should be consolidated, but as was noted elsewhere (I think) we don't want the API to ever be authenticated via a cookie, otherwise we open ourselves to CSRF attacks. Instead we could support the API key as a query parameter as an alternative to via the HTTP header if it is hard to set an HTTP header in JS libraries?
#1001 1300625888000000 pudo My vote on this would be to enable "httpbasic" auth via repoze.who and to add an API key challenger to ckan/lib/authenticator.py that accepts API keys, from within repoze.who. This way we won't have to work around the framework at all and can retain compatibility to the existing mechanisms.
#1001 1300703779000000 rgrp First work in cset:6b8cbe465b61
#1001 1300704249000000 pudo Wrote a WDMMG version of this yesterday: https://bitbucket.org/okfn/wdmmg/changeset/398ce0eb3901#chg-wdmmg/lib/authenticator.py
#1001 1301229082000000 rgrp Completed and merged into default in cset:cb200f339dbb. At the moment have done the very simple option but pudo's approach seems better and we could refactor towards that going forward.
#1001 1301307814000000 dread You mentioned writing tests? Also the CSRF question from James hasn't been addressed.
#1001 1301310351000000 rgrp This ticket did not include CSRF matters - please raise in a separate ticket if you wish. I looked in some detail at the testing options and nothing seemed simple to do that didn't duplicate code we already have (since no way to access the base controller halfway through a request). This can be tested as necessary as part of the development of the new js work.
#1002 1311173185000000 thejimmyg I've done this in my branch and it will get merged in.
#1002 1311675754000000 dread Can you also delete the "paster changes" in ckan/lib/cli with this removal?
#1002 1311676199000000 dread Reopening this, since it has not been pushed or merged in afaict.
#1002 1322515684000000 dread I've redone these changes in cset:91258a6296db71d78a on master, aiming for 1.5.2.
#1003 1298490126000000 rgrp Work so far in http://bitbucket.org/rgrp/ckanjs
#1003 1298889293000000 rgrp Have now started refactor to use backbone and have basic inline editing working and started on Add dataset view.
#1003 1300100411000000 rgrp Converted completely to backbone and now have fully-operational add dataset functionality. I'm closing this ticket now - further improvements can be in there own tickets.
#1004 1311173560000000 thejimmyg At the moment it says "Create a new group" and clicking it takes you to the login page. We want it to do the same thing but if you aren't logged in the label should say "Log in to create a group".
#1004 1323171375000000 thejimmyg The yellow box on the right is now back and you don't get taken to the login page. We'll write more detailed instructions once the group refactor is done.
#1004 1323172489000000 dread There is a description of groups, but that is not the subject of this ticket. In fact if you're not logged in you do get taken to the login page (which is quite correct). I agree with your earlier comment that the text of the link needs changing. Sorry to be reopening this, but I think the previous comment misses the point. Doing this ticket would be a valuable quick fix. Putting on backlog.
#1004 1323174597000000 thejimmyg I don't understand. We just had a team meeting about this, all discussed it and agreed to close it. Yes, you get taken to the login page, but that is the correct behaviour. The problem in the past was that the link was in the yellow box and there was no explanation as to why you had to login. This time you click from the header bar and there is a clear message saying "Unauthorized to create a group" - exactly as a user would expect. Even if the exact text of the ticket description isn't fully implemented in the current release, the UX isn't broken anymore. Yes, it might be even nicer to have a message warning them in advanced but these improvements will be taken forward in the UX work - maybe there is an even better solution than a message? Since you are unhappy about closing it I'm marking it as "Duplicate" of #1521. As agreed earlier with the entire team, we'll take this forward as part of the groups refactor. See #1521 for more information.
#1004 1323177994000000 dread My suggested fix: {{{ diff --git a/ckan/templates/group/index.html b/ckan/templates/group/index.html index 8502df9..064e066 100644 --- a/ckan/templates/group/index.html +++ b/ckan/templates/group/index.html @@ -9,7 +9,15 @@ <py:match path="primarysidebar"> <li class="widget-container boxed widget_text"> <h3>What Are Groups?</h3> - <span i18n:msg="">Whilst tags are great at collecting datasets together, + <p><span i18n:msg="">Whilst tags are great at collecting datasets togethe + <p> + <span i18n:msg="" class="ckan-logged-in" style="display: none;"> + <a href="${h.url_for(controller='group',action='new', id=None)}">Creat + </span> + <span i18n:msg="" class="ckan-logged-out"> + To create a new group, please first <a href="${h.url_for(controller='u + </span> + </p> </li> </py:match> diff --git a/ckan/templates/group/layout.html b/ckan/templates/group/layout.html index 64153aa..a3f732b 100644 --- a/ckan/templates/group/layout.html +++ b/ckan/templates/group/layout.html @@ -25,9 +25,12 @@ <li py:attrs="{'class':'current-tab'} if c.action=='index' else {}"> ${h.subnav_link(c, h.icon('group') + _('List Groups'), controller='grou </li> - <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}"> + <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}" class=" ${h.subnav_link(c, h.icon('group_add') + _('Add a Group'), controller=' </li> + <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}" class=" + ${h.subnav_link(c, h.icon('group_add') + _('Log-in to add a Group'), co + </li> </ul> </py:match> }}} BUT this fix doesn't completely work. When you log-in and create a group, at this point the nav bar changes from the (correct) "Add a group" to (incorrect) "Log-in to add a group".
#1004 1323187352000000 dread Here is the unclipped version: {{{ <p> <span i18n:msg="" class="ckan-logged-in" style="display: none;"> <a href="${h.url_for(controller='group',action='new', id=None)}">Create a new group</a> </span> <span i18n:msg="" class="ckan-logged-out"> To create a new group, please first <a href="${h.url_for(controller='user',action='login', id=None)}">log-in</a>. </span> </p> }}} {{{ <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}" class="ckan-logged-in" style="display: none;"> ${h.subnav_link(c, h.icon('group_add') + _('Add a Group'), controller='group', action='new')} </li> <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}" class="ckan-logged-out"> ${h.subnav_link(c, h.icon('group_add') + _('Log-in to add a Group'), controller='group', action='new')} </li> }}}
#1004 1323194016000000 zephod Dread, that fix wouldn't work because the class attribute was being defined in Genshi and again in HTML, with slighly undefined behaviour (in this case Genshi overwrites HTML). I have performed a very very simple fix which modifies the navbar text when you're not logged in. https://github.com/okfn/ckan/commit/a89a48731ba548170045a60ac2930e0019c299c7 I don't think the link should be restored in the sidebar, it was explicitly removed as part of a site-wide sweep to make the sidebar a passive, helpful element rather than an active element with action links. Site looks great to me, I'm closing this ticket.
#1004 1323195485000000 dread Great stuff zeph! Diff looks really good and cheers for the explanation. On master, cset:a89a48731ba548170045a60ac2930e0019c299c7 and I've cherry picked this for release 1.5.1. too.
#1005 1300100085000000 dread Moved to dgu trac ticket 869
#1006 1298631145000000 dread This command is slightly different to your branch policy as of two weeks ago: {{{ stable: stable code metastable: (will soon be deprecated) for code preparing to be stable default: development HEAD }}} which I prefer. My ideal would be to get rid of the confusing name 'metastable' and unneeded 'stable' and start a new branch called 'released', which will act the same as 'master' in this diagram but with a more intuitive name: http://nvie.com/posts/a-successful-git-branching-model Then for each ckan instance we can either use the most recent release (from 'released') or choose a specific one (e.g. 'ckan-1.3' or even 'default' or 'enh-865' for getting latest features). This gives a good degree of flexibility, is more understandable to newbies and probably a more widely understood branching model.
#1006 1300098217000000 dread Reassigning to rgrp for response
#1006 1300105927000000 rgrp Not sure when i described that other process but I'm definitely of the opinion that we should: * Deprecate and remove stable branch * Deprecate and remove metastable branch (going forward we can use release branches for what we did with metastable in the past) May want to update BranchingPolicy to reflect this (also should probably have some statement about closing release branches and tagging) Reassigning to David Raznick as he is our release guru now.
#1006 1300372286000000 thejimmyg I'm updating the branching policy now. David has closed stable and closed metastable. Marking as fixed.
#1008 1298821826000000 rgrp I've removed the eval in cset:1b8fedeb7ab0 - the more general question about caching should go in a separate ticket.
#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
#1010 1298733856000000 rgrp Complete see branch feature-1010-list-users and closing changeset cset:feature-1010-list-users.
#1010 1298740889000000 rgrp Meant this cset:d2651db566ef
#1011 1298820235000000 sebbacon On reflection, may as well make a Plugin interface called IAuthorizer, which allows customisation of get_authorization_groups, get_roles, and is_authorized....
#1011 1298821699000000 rgrp I agree that IAuthorizer is useful but not sure how it addresses the requirement of the ticket. AuthorizationGroups are already editable via the web interface at /authorizationgroup
#1011 1298824649000000 sebbacon The "external source" is an Oauth service. We need to lookup user groups from that service.
#1011 1298825600000000 sebbacon Proposed implementation at https://bitbucket.org/okfn/ckan/changeset/187e65afb35f
#1011 1299245206000000 sebbacon Merged to default https://bitbucket.org/okfn/ckan/changeset/e8217c317a8e
#1012 1300217601000000 thejimmyg See also #103 which says: As a user I want to view a package at a given revision: * When I visit /package/read/xyz?rev=yyy I should be shown package at revision yyy * package history page should provide links to these pages Could you please investigate how doable this would be given the current package read.html page. I expect it could be very easy once the revision API is in place because we could build a c.pkg object from the revision data instead of the model data. Perhaps another case where we could try introducing the dictization?
#1012 1300352334000000 kindly This is entirely not trivial at the moment. Hopefully after the dictization it will become more so. Simply putting in the package revision object in place of the package does not work. It will obviously work for changes to the package object itself. However, there are no mappers on that object for getting out the related package_tags, resources and extras at that revision. You will have to construct a fake pkg object with some messy and painful queries using dates.
#1012 1300362584000000 kindly cset:5649d6e761fc The basic revision history is merged. I will keep this ticket open if it is not sufficient. All it does is give a list with the most recent first of revision_ids, authors and timestamps. i.e {{{ [{"timestamp": "2011-03-16T15:55:19.941961", "author": "southampton-ac-uk", "revision": "202e9eb8-afaa-4bc9-b8a1-a317561547ea"}, {"timestamp": "2011-03-15T17:59:16.430804", "author": "southampton-ac-uk", "revision": "8235bd0a-d39a-49e0-887a-b0f231be8a92"}] }}}
#1012 1300364620000000 thejimmyg The API part is now done. Bumping the view history part to 1.5
#1012 1300368449000000 dread As I understand it, the whole point to vdm is to make it easy to get old versions of not only the package, but its related objects (like tags, extras). David take a look at this function: Package.get_as_of(revision)
#1012 1301909937000000 thejimmyg No-one really seems to have requested this part.
#1012 1301943096000000 dread Changing this to 'Fixed' and #103 to 'Wont fix' to ensure this feature is noted.
#1013 1299245157000000 sebbacon This is now resolved, but depends on core CKAN behaviour (specifically pluggable middleware and unicode-aware error pages) to function: https://bitbucket.org/okfn/ckan/changeset/c846794c1799
#1014 1299245293000000 sebbacon Run out of time for decoupling, but tests and README.txt written (including pointers about how to customise for anyone who needs to decouple in the future)
#1015 1298902753000000 kindly The migration fixes should sort this out, but I will keep the ticket open to check.
#1015 1299788821000000 rgrp Today kindly applied the sql fixes and I can confirm this is now fixed. Well done kindly for all the great work here.
#1017 1299668555000000 pudo fixed in cset:86d49a775fd3
#1018 1299073340000000 dread Done in cset:e4167f8b3f80 on default
#1019 1299166930000000 pudo fixed in https://bitbucket.org/okfn/ckanext-webhooks/changeset/034647931921
#1020 1300196215000000 thejimmyg This is now on DGU live.
#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)
#1025 1299598708000000 dread Done in enh-1025-config-default-authz and goes into release 1.3.2.
#1025 1299750097000000 rgrp (Link to changeset). Could you briefly clarify why this was needed in config -- we already have a process for putting things into a more restricted mode (see ticket:833) and have been working on creating a WUI to be able to do this automatically (see that ticket).
#1025 1299751045000000 dread Thanks for pointing this out. Although changing the definition of 'editor' to not allow edit (as you admit) is a bit hacky, and I think prone to confusion. James and I weren't aware there was a precedent for doing it this way, but if we had, we may well have followed it. I mentioned the branch for this cset, in preference to the csets.
#1026 1299605128000000 dread Done in cset:2dde3bd563fd for branch 1.3.2
#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
#1028 1299760360000000 dread Fixed in cset 4d860a53fbad on 1.3.2 and merged to default.
#1029 1301311643000000 thejimmyg This was fixed by kindly as part of the 1.3.2 release.
#1030 1300103984000000 amercader This includes: * Take out all references to harvestsource, harvestingjob and harvesteddocument in the rest API * Move the harvesting bits of ckan/lib/cli.py into ckanext-harvest. * Move ckan/controller/harvesting.py and cknan/model/harvesting.py to ckanext-harvest as well * Update ckanext-csw to be able to find the code it needs in the new place.
#1030 1300209975000000 thejimmyg Also: * Delete harvest sources * Implement a Genshi template filter so that if there is an INSPIRE package_extra set to True, you can link to the XML and HTML generation API calls in ckanext-csw * Write tests in ckanext-dgu for all the API calls that Drupal is making
#1030 1303117978000000 amercader All the points described in this ticket have been completed. Harvesting work is being done mainly under #1037
#1031 1299863222000000 rgrp Done, see cset:78d96b520679
#1032 1300380606000000 rgrp This is urgent for me as without upload does not really function.
#1032 1303117292000000 thejimmyg Rufus, I think this is potentially quite a big change and needs to be done as part of the entity refactor rather than as a quick hack. I'd like David Raznick to work on timeseries this week so I'd like to understand a bit more about this ticket. Could you flesh it out please or let's discuss in the catch up?
#1032 1303118226000000 thejimmyg See related ticket #922
#1032 1304094162000000 rgrp Agreed to defer this. Resource editing, to the extent it happens can be kept very simple and part of package editing.
#1032 1330348463000000 zephod Streamlining supertickets. #1506 is the new parent of #978; all tasks remaining in this ticket are complete.
#1033 1308310446000000 dread Fixed in 5c7caca30737 for v1.4.1
#1034 1320174353000000 dread Same problem as #1321 I believe
#1035 1323172908000000 thejimmyg Re-assigning to me temporarily to investigate now that Seb has left. It may be that this should be deleted given that it is over 6 month's old.
#1035 1338206251000000 ross Removing until we can come up with a case for implementing
#1037 1303117000000000 thejimmyg We spent last week integrating the new harvesting architecture and testing the code but there are still some areas that need looking at * The source type and label should be part of the plugin, not named in DGU. * Need warnings if a document changes but its date doesn't -> do we have these? * I noticed there are some tests in DGU, should these perhaps be in ckanext-harvest? * If active is False, the job should not be put on the queue * Log if the wrong type of URL is entered as an error the user can see * Deny if the source is already registered * Overwrite all extras, not just merge new ones. * During the import stage use iswms.py to add an extra during import if it is a WMS so that we can add a link to the WMS later https://gist.github.com/900878 * Can errors/warnings be logged in the import stage? Do all fetched documents get passed to import in one go?
#1037 1304937601000000 thejimmyg Closing this now, any outstanding small issues will be logged in new tickets.
#1038 1300212841000000 dread Done in cset:0373737f0866 for release 1.3.2
#1039 1300212856000000 dread Done in cset:97d563bbf01d for release 1.3.2
#1040 1300213922000000 dread Fixed by James in 904f1f36a672 for 1.3.2
#1040 1328805778000000 dread The problem arises when you do two things together: 1. Have code like this in a CKAN extension's plugin.py: {{{ config['extra_public_paths'] = ','.join([our_public_dir, config.get('extra_public_paths', '')]) }}} which will have a trailing blank value (unless you set extra_public_paths in the config file) {{{ extra_public_paths=['/some/path/', ''] }}} 2. Run CKAN with this code: {{{ extra_public_paths = config.get('extra_public_paths') if extra_public_paths: static_parsers = [StaticURLParser(public_path) \ for public_path in \ extra_public_paths.split(',')] + static_parsers }}} Introduced in #340 https://github.com/okfn/ckan/commit/0593c3e5050882a9dbf54fb6c263f4a2f1de2097#ckan/config/middleware.py in CKAN 1.0.2 This was made safer in https://github.com/okfn/ckan/commit/e0d5f02168116a18a7aeb7b058e4160bbd402a02#ckan/config/middleware.py for CKAN 1.3.2 (it ignores blank paths)
#1040 1328806824000000 dread Here are all the CKAN instances potentially involved in this issue: == ckan.net / DGU == These suffered this problem briefly and were fixed 15/3/11 == opengov_es http://opengov.es/ 1.2 == This does not have a theme extension. Is not serving files from root. == nosdonnees_fr http://www.nosdonnees.fr/ 1.3.1a == This does have a theme extension but does not seem to have a trailing blank public path since it is not serving files from root.
#1041 1300284809000000 thejimmyg Also, this means moving documentation out of the current CKAN dev wiki at trac.ckan.org and into the community wiki. Core developer docs should remain in the Sphinx-based .rst format in CKAN. Much-needed new tutorials go on the community wiki.
#1041 1310135309000000 thejimmyg Child ticket of #1142
#1041 1312372367000000 rgrp James says this is not priority and he does not plan to do docs for debs until he has got that system functioning.
#1042 1300969265000000 dread Done in ckanext cset:7610512277bd and ckanext-importlib cset:7737716e0d7b.
#1042 1300969865000000 dread Remaining parts of ckanext are: * blackbox (rgrp, pudo, dread) * hammer (ww) * link_checker (ww) * solr configuration (pudo) & indexer (pudo) * amqp listener command (ww) * geo form field (rgrp) * GData Loaders: * aidprojdata (johnbywater) * norwaygovdata (johnbywater) * ordsurv (johnbywater) * Gemini2 (iso19139) (johnbywater, ww)
#1043 1300321033000000 kindly cset:c894f92c5b9a Sesion.remove() needed to be run before configure as we want the original session made not to be used over the newly configured ones.
#1044 1300359562000000 rgrp Think this would be resolved by refactoring implied in ticket:1001 (specifically checks for api key and remote user should lead to availability of same set of identification information).
#1044 1300382367000000 dread I agree with leaving #1001 solving this issue. Centralising this is good. This ticket can instead focus on: * returning the correct 403 error (rather than the 302 currently) * creating some tests * documenting * consider renaming the SITE_READ variable and rethinking purpose
#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.
#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.
#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.
#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.
#1044 1302096155000000 dread I've added in the docs for this in cset:013da53052d1 ready for release 1.3.3.
#1045 1300457708000000 dread Fixed in cset:98eb8b8d063e on default, scheduled for CKAN version 1.4.
#1045 1300787161000000 dread Want to identify groups by ID also in the Web interface.
#1045 1300793261000000 dread Fixed in cset:71621df50983 on default ready for ckan 1.4
#1046 1302777668000000 kindly cset:35ba6ad033ae
← 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 →
Note: See TracReports for help on using and creating reports.