{23} Trac comments (3729 matches)

Results (1801 - 1900 of 3729)

← 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 →
Ticket Posixtime Author Newvalue
#1123 1307795508000000 rgrp You can't get small amazon instances as 64 bit and many people's own machines are 32 bit. How costly is packaging no-arch exactly (it must be more than a simple 'switch' in the build if you are saying this is costly :-) )
#1123 1311863798000000 nils.toedtmann Looks like the packages on apt.okfn.org are now architecture "all" - great. To avoid future confusion, i change this ticket's solution to "fixed".
#1122 1304368075000000 dread @pudo I notice you tackling solr indexing of lists/tuples in ckanext-solr cset:ecc2d69df991 so have updated to use this on ckan.net and reindexed, but #1122 still seems an issue - any chance you can take a look?
#1122 1305718009000000 dread This user is now storing his list as a string so is happy. But I'll leave this ticket open, for pudo to decide whether there is an issue with SOLR indexing tuples/lists, as per the previous comment.
#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.
#1122 1306747706000000 dread Changing this to "won't fix" just to be clear
#1121 1307358426000000 dread We don't need to support JSON extras at the moment.
#1119 1304104689000000 rgrp * Merged ckanext-upload into ckanext-storage * Got existing API systemin in ckanext-storage fully working (e.g. api section was broken -- maybe due to changed boto ...) * API now supports GET requests and JSONP where appropriate * Added auth form to API (could be useful for ajax form stuff going forward) * Improved UI of upload including having ckan based file links (using redirects) * Set uploaded-by field on uploaded files * Checked on AWS And GS Also did: * Improved ofs in various ways including change to standard metadata handling and improved testing (see e.g. https://bitbucket.org/okfn/ofs/changeset/36fac29b7775) * Tracked down [https://github.com/okfn/boto/commit/0d9635c8a9785c9b20b44ee93a0679c002961592 bug with boto and metadata updating on GS] and provided patch.
#1118 1311174062000000 thejimmyg We haven't ever come across this. Perhaps if you could provide an example we can re-open it. Cheers, James
#1117 1304277240000000 nils.toedtmann Oh, it *does* depend against python-pastescript. Ignore. For some reason it was not (completely/correctly) installed with ckanext-datanl on us4, but is a different issue then. Might be due to missing locale "en_GB.utf8" and dpkg-configrue failing.
#1116 1304358664000000 dread This is complete in branch defect-1116-boolean-search-options for release-1.3.5
#1115 1324054704000000 dread Authorization groups deprecated with the Group refactor #1477
#1114 1304085484000000 dread Done in cset:d7bd4b0f89de on default.
#1113 1304024611000000 kindly cset: 52a3fb230074
#1112 1304358643000000 dread This is complete in the branch feature-1112-allow-search-all for release 1.3.5
#1111 1304935139000000 lucychambers CKAN FAQ now complete (Sections 1,2,5,6 - needs uploading onto site): http://ckan.okfnpad.org/FAQ At CKAN Community Meetup it was decided that Sections 3 and 4 would form a separate contributor's manual.
#1109 1303862352000000 kindly It is fixed now in 1.3.4.1.
#1109 1303916487000000 dread Close ticket?
#1109 1304698621000000 dread Did we decide that this facility for storing non-strings via the API is a new feature, rather than a bug?
#1109 1305123852000000 dread What's the status?
#1109 1305124697000000 kindly I am happy this is fixed in cset:445fc04333dd.
#1108 1310128678000000 thejimmyg Now that we are using ckan.net as thedatahub.org we should go full steam ahead and create a brand new UI to reflect thedatahub.org's new role. See http://ckan.org/2011/07/08/ckan-vision-update/
#1108 1311180204000000 thejimmyg See also comment on #1200 about using the pdeu theme.
#1108 1314878772000000 zephod First, here is a repo with the new DataHub theme: https://bitbucket.org/okfn/ckanext-datahub-theme We plan to integrate this into ckan-core, thereby replacing the current theme.
#1108 1315140879000000 rgrp Completed in https://bitbucket.org/okfn/ckan/changeset/9be1ae232ec3 cset:9be1ae232ec3
#1107 1310134646000000 thejimmyg Child ticket of #954
#1107 1320321170000000 dread Notes to complete this: * ckan/logic/action/get.py:'def package_autocomplete' exists and is the one that should be used * need to ensure all places in the templates and public/scripts use this action directly, not dataset/autocomplete (or its alias package/autocomplete) * ckan/controllers/package.py:'def autocomplete' should be removed. * ckan/config/routes.py dataset/autocomplete should be removed.
#1107 1340632612000000 icmurray autocomplete action has been deprecated in favour of /api/2/util/dataset/autocomplete : https://github.com/okfn/ckan/blob/master/ckan/controllers/package.py#L655
#1106 1303834069000000 rgrp fixed in branch:defect-1106-bugs-with-routing.
#1104 1303744486000000 rgrp You haven't done paster search-index rebuild I think. If you haven't the search index will not have been built (Create Test Data code creates data without indexing it). This could be considered a bug of Create Test Data but I'm not sure -- if you think so re-open this ticket and change description.
#1104 1303920492000000 dread I agree this should be fixed.
#1104 1303920791000000 dread Fixed on default cset:52a3fb230074 - create-test-data now indexes the package it creates.
#1103 1303744575000000 rgrp (Same ticket created 3 times by accident I think -- see #1104).
#1102 1303744552000000 rgrp (Same ticket created 3 times by accident I think -- see #1104).
#1101 1330082908000000 dread Stats already in site nav - adjusting title to just mention google analytics.
#1100 1303406103000000 dread Done in release_1.3.4 cset:580e2b11b4ef and release 1.3.3 cset:cac55b8a0bd9
#1099 1324057106000000 dread Authorization groups deprecated with the Group refactor #1477
#1098 1303387896000000 dread Fixed in b2b37e39de4d in release-1.3.4. Was only broken on this branch a few days before.
#1098 1303406017000000 dread Also found problem with some tests using delete_all. Fixed in cset:f9764dd43a0a release_1.3.4.
#1097 1303293476000000 dread Done in cset:5dec7eb609ab on branch release-v1.3.4.
#1096 1307444626000000 nils.toedtmann See also http://ckan.okfnpad.org/multisite
#1096 1310125173000000 thejimmyg Renaming to CKAN Hosted because whether we introduce a site domain object for subdomain tenants or not is an implementation detail. As far as progress on CKAN hosted goes, we now have: * A build tool to package ckanext-dgu, ckanext-std etc into .deb files * The ability to apt-get install CKAN * A script that can set up multiple non-conflicting CKAN instances on the same machine What we need next is the ability to generate a ckanext-xxx repository for each new instance we want to host. At that point most of the underlying techniques for hosting multiple CKAN instances concurrently will be in place. Once we have that working and know what clients want, we can look at going further and speccing up a multisite solution off a single DB, rather than the multi-instance solution proposed here.
#1096 1311182262000000 thejimmyg Milestone ckan-v-future deleted
#1094 1303129670000000 rgrp See also comments on the mailing list. Item 1 seems fine (what is difference from current extension mechanism?) Item 2: concerns here. What about list views? What about editing 'permissions'? I also think getting rid of System object isn't really a benefit (if anything may be a cost). Item 3: feel this may be better as part of big domain model change (also gives us time to really dig into this -- this is an important requirement/conceptual issue). Item 4: No objections but seems very minor gain for fairly significant migration work.
#1094 1304354036000000 johnlawrenceaspden UserGroup/PackageGroup might also be confusing. A PackageGroup is *just* a group of packages. A UserGroup is both a group of users, and a thing affecting authorizations. Perhaps PackageGroup and UserAuthorizationGroup? Or PackageGroup and AuthorizedUserGroup? I was quite confused by all this at first. I think I understand how the whole thing works pretty well now, and I still can't think of good names for the two concepts, although I can already feel the normal English meanings of the words changing to what I now know they are for. We should be a little wary of this. Things that are even slightly difficult to understand end up being understood by very few people. Would any of us be prepared to sit an exam on exactly how UNIX file permissions work, even though we all use them?
#1094 1311173649000000 thejimmyg Merging with #1065 and closing.
#1093 1302865470000000 dread Fixed by this API call use the existing license cache. Done in cset:a95888ea39be on release-v1.3.4
#1092 1305570822000000 kindly completed cset: ca1ac4112ea2
#1091 1303746408000000 rgrp This is a well known issue (see some discussoin in #142). There is nothing directly we can do about it (this is what google gives us) but we could make usernames editable (this has been discussed but not ticketed I believe). Given our general "downer" on openids I'm not sure this is a big priority.
#1091 1323102767000000 rgrp wontfix plus we now requires usernames see #1386
#1090 1302635699000000 dread Fixed in cset:e0af88edf0f0 on default.
#1089 1302631733000000 dread Done in cset:6d41ecc431e3 on default.
#1088 1302630624000000 wwaites you use the negotiate function in autoneg.py with a cfg dictionary like this, {{{ cfg = { "mime_types": [ ("application/xhtml+xml", ["html"]), ("text/html", ["html"], ("application/rdf+xml", ["rdf", "owl"]), ("application/turtle", ["ttl"]), ("text/plain", ["nt"]), ("text/x-graphviz", ["dot"]), ] for content_type, exts in negotiate(cfg, accept_header): if "html" in exts: render page normally else: redirect to semantic.ckan.net } }}}
#1088 1303035487000000 wwaites fixed in 5c091fc08474 (bug-1088-autoneg-is-wonky) tip
#1087 1310134714000000 thejimmyg Child ticket of #954
#1087 1320866159000000 dread Implemented in cset:0b7e2b0bed44 as status_show logic action, heading for 1.5.1 release. Took 0.5h
#1086 1303381200000000 johnlawrenceaspden There is no (obvious) way to delete an authzgroup.
#1086 1323346552000000 dread Authorization groups are deprecated with the incoming Groups Refactor #1477
#1085 1302621951000000 rgrp I don't think this is very useful output :) Most of this is test/demo/rdf and therefore not relevant. Also have you checked your ckan.site_url in your development.ini -- which configures where what is used as based for all external urls in the templates? IMO there is nothing to fix here.
#1085 1302624602000000 dread As discussed on IRC, the default ckan.site_url should be blank, rather than ckan.net.
#1085 1302625314000000 dread Fixed in cset:01b3de5d4e31 on default.
#1084 1303894555000000 dread ww you did this didn't you? Perhaps you could update us with the branch/changeset it was in and close this ticket please.
#1083 1304975681000000 johnlawrenceaspden Current behaviour: from the web interface, russianfan can be added as an admin on warandpeace twice. and you can then delete the two roles separately. desired behaviour is that you can only add him once. from the command line, you can only add him once, but if he's in there twice, you can't remove him because the command line bombs desired behaviour is that he can be removed from the shell, you can add him twice but can't remove him if he's been added twice. if you try, it bombs. The desired behaviour in all cases is that adding and removing are effective and idempotent in all three cases.
#1083 1305051061000000 johnlawrenceaspden It appears to be possible to get into a state where you can't add or remove roles from the command line. Investigating.
#1083 1305058621000000 johnlawrenceaspden Fixed the problem where you can't delete a role if it's been added twice, but had to leave the add function as it was since putting a commit in it breaks many tests. It appears that the WUI doesn't call these functions anyway. Left that as it is since we're planning to replace it. The cli rights command doesn't appear to add the roles that it says it adds. Possibly because it's not doing the required commit? Reported this as a different bug.
#1082 1315317825000000 dread The flash message 'Language set to: English' was always in the previous language, not the new one. Pudo fixed this in cset:eaf342823caf and I have transplanted this into release-1.4.3. I've also added/corrected translations for all languages for 'Language set to: English' so that it makes sense! "Set language back to English causes server error:" I can't reproduce this. The exception looks like a problem with the forwarding, which improvements were made in #1126.
#1082 1315917217000000 dread Language switch problem has been around since it was introduced in the 1.3.1 release.
#1081 1303332388000000 johnlawrenceaspden Actually it seems to be worse than that. If I add a user to an authz group then I get added too, and then there's no way to remove me.
#1081 1303489474000000 johnlawrenceaspden Fixed as part of feature-854-tests-for-authz-groups branch. Original behaviour was that creating/modifying user is explicitly added to the users in the authz group.
#1079 1302777496000000 kindly Complete see cset:35ba6ad033ae
#1078 1305828965000000 kindly complete: cset:843b78bae016
#1077 1319797284000000 dread I guess this is not a priority now.
#1076 1302515674000000 sebbacon See also http://trac.ckan.org/ticket/948
#1076 1302731255000000 rgrp All main work done as of cset:556efcb91f19 in branch feature-1076-improve-purge-system (+ associated work in ckanext-admin trash bin management). All that remains is to add some tests.
#1076 1303236302000000 rgrp Test of trash functionality in ckanext-admin in https://bitbucket.org/okfn/ckanext-admin/changeset/e86c102a3c60 so now closing (could do with some functional tests in the main interface but can leave for later -- were none before so situation no worse ;0 ).
#1075 1303227982000000 johnlawrenceaspden closing ticket see http://wiki.ckan.net/Authorization and https://bitbucket.org/okfn/ckanext-admin
#1074 1314278296000000 rgrp johnlawrenceaspden did quite a bit on this in feature-1074-refactor-authz-wui branch (including implementing for package and group). However, did not implement for authzgroup and also repeated code a lot. Reassigning to me for completion.
#1074 1314283492000000 rgrp Also work on branch feature-1074-authz-wui (that is primary one in fact)
#1074 1314303581000000 rgrp Closed in cset:18a5b48bbee6. Note the templating isn't completely reused but rather uses common methods from _util.html. Likely that a bit more refactoring could be done to share common code but not worth it at present.
#1073 1302185825000000 dread Done in cset:9dfc60db90ed on default branch.
#1072 1302106474000000 dread Done in cset:2a97d2d9ba4a for release 1.3.3.
#1071 1301943180000000 dread Done in cset:db9e2c4f65bb for release-v1.3.3
#1070 1310117129000000 rgrp Added link to http://wiki.ckan.net/Domain_Model and closing as work mostly done (and nothing clear remaining to be done -- agreement perhaps!)
#1069 1301909423000000 thejimmyg This is what the new "Ideas" section in the ckanext-community extension is for. Marking as duplicate of #941, can we have discussion there please.
#1069 1302510609000000 rgrp Mistakenly assigned to this sprint.
#1069 1310133794000000 thejimmyg Yes, and this will be more important in thedatahub.org
#1069 1340632215000000 icmurray Assigned to @tobes as he's looking at publication workflows.
#1068 1302109505000000 dread The problem was the use of mktime which is localised. Also spotted a problem with the use of localised time stored in the datestamp created in migration script 29, when initialising the repo. Fixed in a2094932e5e4 in release 1.3.3 branch.
#1067 1302186503000000 dread Done in cset:d75ab5fc3311 for release 1.3.3
#1066 1301904246000000 dread Need a new role 'ANON_EDITOR' which is the default role for Visitor, which can create packages, but not groups.
#1066 1301930311000000 dread Migrations: * Default (open) CKAN instances will have visitor as a reader on the system, and will have to upgrade them to anon_editor. * DGU & DataGM instances have visitor as a reader on system and must stay like that. * Pudo's specially locked instance, where editor has been changed to only read can now use the 'reader' role (assuming he's happy for them to create users) Migration script (37) is designed to cope with the default (open) setup, and the other special cases must be dealt with using CLI at the time of upgrade: DGU & DataGM must run: {{{ paster rights remove visitor anon_editor system: paster rights make visitor reader system: }}}
#1066 1301932136000000 dread Done on branch defect-1066-reader-too-permissive and merged into release-1.3.3
#1065 1301914004000000 sebbacon To reflect further conversations: * We are parking this ticket until dictization is complete * We would prefer to see roles as asserted globally by default, with packages just storing exceptions. E.g. If I am a "reader" globally, then I have "read-package" permission on all packages new and existing, unless otherwise asserted locally on a package. * Also w.r.t. algorithm above, consider repoze.what's model; "possible" is analagous to "has_permission". See http://what.repoze.org/docs/1.0/Manual/Predicates/Builtin.html
#1065 1302033244000000 dread Wow, lots of solutions here, and not enough evidence of the problems encountered / difficult use cases. I have tried here to extract what John and Seb might be suggesting is difficult with our current http://en.wikipedia.org/wiki/Role-based_access_control system. 1. (Seb) It seems crazy to change the User-Object-Roles for every single package to 'lockdown' a CKAN instance. Instead of using Roles 'reader' & 'editor' we start using Roles 'logged_in_user' and 'anon_user'. Then, with only changing a couple of lines of the Role-Action table for these Roles, you can give or remove permissions to edit / create packages, groups etc. 2. (John) Actions are being added all the time by migrations and extensions. I'm not sure what the problem is here - can someone explain? The separation of Users and the new Actions by adding the Role 'join' means the migration/extension can add existing Users with the new Actions. For example when we added the 'Group' protection object, logged in users could previously create groups, so it is natural to add this action to the 'editor' role. If you get rid of Roles, as John suggests, then you end up having to add as many Rights objects as users. And you might end up trying to infer new Rights on the basis of old Rights, rather than a role, which would be more natural. (Is the only reason to denormalise the UOR and RA tables the sake of ease of understanding? I would think we can explain the concept better now...!) 3. (John) This Group Hierarchy description sounds a bit like earlier incarnations of the DGU requirements. "or any of his groups group-children (but not user-children)" I'm not sure I understand the user-children bit, and I'm wary of any difficult-to-grasp concept. This modelling seems to take the UserGroup/User hierarchy model and use that as a hard-coded interpretation of the Authorized permission. In contrast, in DGU Evan split the Organisation Hierarchy model from the Authorization model. Each User has explicit permissions for each Organisation he is allowed to add/edit packages for. This helps for these two use cases we have to contend with: when a user is an admin for unrelated branches of the Organisation hierarchy, and when an Organisation is actually in two branches of the Organisation hierarchy. It also seems more generally flexible.
#1065 1302075994000000 sebbacon Re the point against my name, yes -- I think the fundamental principles of the current system are fine, but the implementation means asserting things for every single object, whereas we should be able to optimise it for the general cases -- something along the lines you suggest. I would be very happy to write up a full, detailed proposal for the system before we implement anything, if only as a proper straw man to have debates around.
#1065 1302081747000000 dread Great stuff Seb, cheers for that.
#1065 1303118756000000 thejimmyg This is now more urgent and I think we have enough consensus to go ahead. See #1094 too.
#1065 1311174208000000 thejimmyg Merging with #1094 so see the discussion there too.
#1065 1318528721000000 rgrp Reassigning to zephod as he is looking at this. I think most of this is wontfix or will become obsolete with other stuff but worth looking at. Also moving to v1.6 at the same time.
#1065 1324550041000000 dread All subtickets are done now, apart from #1198 which I've moved into superticket #1477 Group refactor Change name of AuthzGroup? to UserGroup? to reflect what it is for I think this is completely covered off in #1477 Group refactor Get rid of Roles, and replace them with direct assignment of actions, even though there are many actions, and extensions can add arbitrary ones. Debatable whether we should cut the number of actions to correspond to the three roles defined by the base system. This is not clear - please raise a ticket for this if still promising. Have a method of finding roles (or, in future, actions) relevant to a given protection object (e.g. FILE-UPLOAD(ER) not relevant to Packages) These three points I've moved into a new ticket #1596 as it was getting lost rather in this one. Change UserGroups? so that they can have a hierarchical structure, I think this is completely covered off in #1477 Group refactor Conclusion: closing this ticket as all points are covered or moved into tickets elsewhere
← 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 →
Note: See TracReports for help on using and creating reports.