{23} Trac comments (3729 matches)

Results (1901 - 2000 of 3729)

← 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 →
Ticket Posixtime Author Newvalue
#1064 1323169787000000 thejimmyg Marking as duplicate because #1464 will take it on.
#1063 1301522483000000 rgrp This sounds absolutely sensible and suggest we even have a helper method such as lib.helpers.group_link(group) (as we do for user_link). (@Seb: apologies for misunderstanding your query on the list -- I was talking about the group listing table at /group)
#1063 1302514033000000 sebbacon Fixed in https://bitbucket.org/okfn/ckan/changeset/145eaae3168a
#1062 1311178145000000 thejimmyg Hi John, Can you please check that the new webstore+preview works correctly with this one please? Cheers, James
#1062 1311773731000000 johnglover The file is in Turtle format (serialisation format for RDF, which we currently don't archive and have no preview code for. The new preview code will not even create a preview button for this file type. Moving to the backlog for now, support for RDF and related formats should be added along with support for excel docs and google spreadsheets.
#1061 1301397271000000 dread Fixed in cset:fc3bc103db8c ready for release 1.3.3
#1061 1301922325000000 dread Actually there was a link at the bottom of the package edit form that my grep didn't pick up: h.url_for(str('/license')). So it is not orphaned at all.
#1061 1301922350000000 dread Backed out original change fc3bc103db8c here: 7ae9aff8bc68
#1060 1301312487000000 dread Fixed in ckan-importlib cset:bc52bba86d71 and ckan cset:2751f76fb17a in time for ckan 1.4
#1059 1301312516000000 dread Fixed in ckanext-importlib cset:f6d19129ac43.
#1058 1301303221000000 dread Fixed in cset:8e1817ab8d1c on default, ready for 1.4 release.
#1057 1329150236000000 toby fixed in commit 3d7cbf0
#1056 1302626373000000 dread Fixed in cset:a025b5b3293c on default.
#1056 1302882616000000 dread This was broken in cset:b681bbedfa62a68b71260ef48a0da6063109734 which was released in 1.3.2
#1055 1300987241000000 dread This amounted to 14 tests. Fixed in cset:5bbd0005c57e ready for ckan release 1.4.
#1054 1300989764000000 dread I've added some tests in the branch: defect-1054-resource-order
#1054 1300992195000000 dread I've put in a potential fix for this into the branch - do take a look and see what you think.
#1054 1301002995000000 kindly Looks great. Had a look and changed a minor thing because I was not confident with the handling of the null values. I made a fake resource and did an asdict on that to make the identity. Part of my patch I reverted as I mucked up my version of the vdm, so it was not needed.
#1054 1301305615000000 dread This branch is now merged.
#1053 1310125444000000 thejimmyg This is now fixed as part of the API refactor and revisioning updates David Raznick has done.
#1053 1310126546000000 dread Looks to me like DELETE always changed the state to Deleted, so an invalid ticket. We can deal with purging in another ticket if needed.
#1052 1300895410000000 dread Fixed in branch feature-DGU#889-authorization-in-lockdown and merged to default at cset:e6643cf1324c. Only remaining issue is listing in Web interface of package relationships, which shows links to packages even to ones you can't read.
#1051 1301305079000000 sebbacon This has been completed in https://bitbucket.org/okfn/ckan/changeset/64a949990e0b
#1050 1300452200000000 johnlawrenceaspden there's already a file ckan/tests/test_authz.py, which looks like the appropriate place for new tests.
#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!
#1050 1303118188000000 thejimmyg This should also feed into #1075 which will be being worked on this week.
#1050 1315394117000000 dread There's been no objections to my comment 6 months ago saying this is invalid, so marking it invalid. Feel free to reopen if there is indeed a case here.
#1049 1323169424000000 thejimmyg This is over 6 months old. In accordance with wiki policy, closing.
#1048 1300702752000000 dread Done in changeset 9d7bfa124757 on default and expect it to go into 1.4 release.
#1046 1302777668000000 kindly cset:35ba6ad033ae
#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
#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.
#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.
#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)
#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.
#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.
#1039 1300212856000000 dread Done in cset:97d563bbf01d for release 1.3.2
#1038 1300212841000000 dread Done in cset:0373737f0866 for release 1.3.2
#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.
#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
#1034 1320174353000000 dread Same problem as #1321 I believe
#1033 1308310446000000 dread Fixed in 5c7caca30737 for v1.4.1
#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.
#1031 1299863222000000 rgrp Done, see cset:78d96b520679
#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
#1029 1301311643000000 thejimmyg This was fixed by kindly as part of the 1.3.2 release.
#1028 1299760360000000 dread Fixed in cset 4d860a53fbad on 1.3.2 and merged to default.
#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
#1026 1299605128000000 dread Done in cset:2dde3bd563fd for branch 1.3.2
#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.
#1024 1299668648000000 pudo re-created this (#1027)
#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.
#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.
#1021 1299518828000000 pudo fixed in cset:9f1b38add19f
#1020 1300196215000000 thejimmyg This is now on DGU live.
#1019 1299166930000000 pudo fixed in https://bitbucket.org/okfn/ckanext-webhooks/changeset/034647931921
#1018 1299073340000000 dread Done in cset:e4167f8b3f80 on default
#1017 1299668555000000 pudo fixed in cset:86d49a775fd3
#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.
#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)
#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
#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.
#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
#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
← 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 →
Note: See TracReports for help on using and creating reports.