{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
#2551 1343042712000000 johnglover All done (in master and release-v1.8 of ckanext-googleanalytics), with the exception of the download and data api buttons which should be tracked already in download stats. Untested, but will probably remain so for the near future at least as this doesn't seem to be a high priority any more.
#854 1304351843000000 johnlawrenceaspden Coverage now up to 84% and 81%. Remaining untested code is error conditions, which we decided weren't worth the effort of locking down. fixed on feature-854-tests-for-authz-groups, now merged into default code.
#1050 1300452200000000 johnlawrenceaspden there's already a file ckan/tests/test_authz.py, which looks like the appropriate place for new tests.
#1075 1303227982000000 johnlawrenceaspden closing ticket see http://wiki.ckan.net/Authorization and https://bitbucket.org/okfn/ckanext-admin
#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.
#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.
#1086 1303381200000000 johnlawrenceaspden There is no (obvious) way to delete an authzgroup.
#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?
#2446 1352206530000000 johnmartin I can't get access to said project. Can someone please give me access so I can triage this?
#2451 1352206567000000 johnmartin I can't get access to said project. Can someone please give me access so I can triage this?
#2457 1352206516000000 johnmartin I can't get access to said project. Can someone please give me access so I can triage this?
#2471 1352206679000000 johnmartin I can't context on this. Closing.
#2562 1352206599000000 johnmartin I'm closing this because I can't get context on this.
#2599 1346236806000000 johnmartin FYI: My methodology for getting the demo working in IE7 will be: get it functioning and not get it perfect
#2599 1346756230000000 johnmartin This is now closed and waiting pull request merge back in.
#2616 1352206282000000 johnmartin Old and not sure of context. Closing.
#2631 1352205778000000 johnmartin This has been fixed with the LOD2 work on activity streams.
#2641 1352206794000000 johnmartin I can't get access to the project... can someone link me?
#2658 1352205894000000 johnmartin This is now invalid due to the work with orgs.
#2676 1352205920000000 johnmartin Fixed in master
#2704 1352205939000000 johnmartin Fixed in master
#2705 1352205954000000 johnmartin Fixed in master
#2711 1352205968000000 johnmartin Fixed in master
#2714 1352206138000000 johnmartin This seems fixed... I'm closing this.
#2741 1346841059000000 johnmartin Awaiting merge into demo branch
#2741 1352205988000000 johnmartin Fixed in master
#2742 1352206081000000 johnmartin Fixed in master
#2806 1352206005000000 johnmartin Fixed with new group pages.
#2907 1352206307000000 johnmartin Fixed in master
#2956 1349278531000000 johnmartin OK, this was simple... I just added an already made snippet to the page. Ira: Can you confirm that the attached screenshots satisfy fixing the problem?
#3021 1353411968000000 johnmartin In code review
#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.
#358 1303122109000000 kindly This ticket needs to have a more thorough spec which needs to include. * Examples of put/post requests to resources and if they are needed. * Dealing with resources that do not have a related packages in terms of authorization. Do they have a new action? how granular is the authorization? per resource? system level? etc. * The rules related to authorization for resources attached to packages. i.e you only get read permissions when the related package has read permissions? do they have their own rules?
#363 1298840718000000 kindly revision objects are made everytime a new revision is made even if their are no changes.
#560 1297084192000000 kindly changeset https://bitbucket.org/okfn/ckan/changeset/b899085071a8 cset:b899085071a8
#663 1298913603000000 kindly cset:76a77439ecd0
#664 1300371645000000 kindly fixed cset:a5f4a49190e2
#826 1297416879000000 kindly There is nothing to stop anyone from putting any extra attributes in the extra_info field dict. So any have the flexibility you need. The config option is to add some fields that act in exactly the same way as python attributes, having the same semantics as them. i.e if you have an extra field called alturl, you can do obj.alturl = 'fdsffs'. This is the best of both worlds as far as I can tell.
#826 1297417900000000 kindly I forgot to mention that he main advantage of the fixed fields, is that we can make them properly searchable i.e the values searchable. This currently does not work for package extra values as they are jsons. I have added this searchability for the sql backend.
#826 1297423342000000 kindly This would be too much of a hack. You do not want users overwriting any attributes on the object. If they called the attribute "__init__" it would write over the actual __init__.
#890 1318599247000000 kindly Invalid due to #1397, We will be using celery instead.
#920 1300319140000000 kindly The only issue here is that we are listing tags that relate to 'inactive' packages. We are already not listing tags that relate to NO packages. I have fixed this. cset:cd0347eed69f The tag in the example is related to a deleted package so should not be deleted. With this patch it no longer gets displayed.
#954 1320142744000000 kindly This is basically the complete now with documentation. The child tickets no longer seem to fit and are not essential for completion.
#956 1299489084000000 kindly cset:1305b9192d49
#965 1297682632000000 kindly added with cset:553421d05ce8
#981 1297682773000000 kindly fixed see cset:3d1f720a2e5b
#984 1297628554000000 kindly These are the errors listed in severity order. * group revision tables joins wrong in many ways. * changemask table not added. * licence_id wrong type. * package_revision.download_url and changset.status not dropped. * package.name and tag.name unique constraint not added. * update cascaded defined wrongly. Attached are the fixes that will need to be run in ckan_migration_fixes.sql
#984 1297682116000000 kindly fixed see https://bitbucket.org/okfn/ckan/changeset/d56ea86d4303
#989 1297700363000000 kindly It would be nice to know some use cases. I think that plugins should control their own storage, or share a storage that is designed to be flexible (mongo, redis ...). We do not seem to be able to keep our current migrate repository in sync let alone add plugins to the mix.
#989 1297706620000000 kindly I do not think we need to 'extend the model' if you intend to make the migrations separate. If the schema is decoupled, then there are no problems. So each plugin can have its own model and use sqlalchemy independently i.e have their own metadata, classes and mappers. They do not have to even use sqlalchemy. What I mean is that there is no need to do anything apart from. * Agree on a naming convention of the plugin tables (including their own migrate table each) * Agree to the rule that no plugin can add a column to an existing table. * Agree that no table can have a (database level) foreign key constraint between the core tables and itself in either direction. They *can* have implied sqlalchemy level joins. * Maybe have a hook that on db upgrade all plugins are upgraded. Each plugin will have to redefine the tables, classes and mappers they need to join onto the core tables themselves. reusing/extending the core model will not be worth the trouble. This seems to cover your use cases and this way everything is nicely decoupled. Best of all there is very little work to do...
#994 1298912830000000 kindly see cset:93188d42fc12
#1000 1298912726000000 kindly fixed cset:630513f550d5
#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"}] }}}
#1015 1298902753000000 kindly The migration fixes should sort this out, but I will keep the ticket open to check.
#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.
#1046 1302777668000000 kindly cset:35ba6ad033ae
#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.
#1078 1305828965000000 kindly complete: cset:843b78bae016
#1079 1302777496000000 kindly Complete see cset:35ba6ad033ae
#1092 1305570822000000 kindly completed cset: ca1ac4112ea2
#1109 1303862352000000 kindly It is fixed now in 1.3.4.1.
#1109 1305124697000000 kindly I am happy this is fixed in cset:445fc04333dd.
#1113 1304024611000000 kindly cset: 52a3fb230074
#1129 1305212467000000 kindly > * There seems some misunderstanding: change to have logic layer has almost nothing to do with being able to remove main stateful stuff in vdm. To be able to remove most of stateful stuff in vdm requires us to make some other changes (re foreign keys from revision objects to continuity) The logic layer does not automatically help out, however it makes our life easier if we want to handle state ourselves. For example take package tags, if we remove the stateful_m2m properties and just use normal sqlalchemy relations. We will still want statefullness (i.e active, pending, deleted) on the package_tags table. We should update those on the table ourselves in the logic layer. > * There are other simplifications we should make to vdm before embarking on this (e.g. move to SessionExtension from MapperExtension). This is easy as that work has been done in changeset branch and can be backported. I agree but event thought the MapperExtension way is not great, it is very well field tested.
#1136 1305216218000000 kindly This would be nice but it is not necessary. The current mapper implementation may be nice but not is battle tested..
#1136 1305217553000000 kindly Replying to [comment:2 kindly]: > This would be nice but it is not necessary. The current mapper implementation may be nice but not is battle tested.. I meant the mapper extension "IS" battle tested.
#1137 1305217449000000 kindly I am not sure this needs to be done. I think we should keep the continuity object always in the table, even if it is deleted. The querying should be done through the logic layer so the deleted state should not be an issue. The clients should be entirely state aware. The only thing that needs to be done is to remove all statefullness of relations. These are the only things that are complicated. This would make vdm just a simple copy on write mechanism, with the client controlling the state.
#1140 1312491320000000 kindly fixed cset:987da68ea4f6 The package group table needed to trigger a reindex of the package.
#1148 1305969925000000 kindly complete cset:96a43c9d8bd7
#1149 1305971672000000 kindly cset:b1634d405066
#1149 1306090663000000 kindly Failed dgu tests due to as_dict not working on deleted objects. fixed by cset:c9b9cf513e44
#1193 1309768960000000 kindly fixed cset:87d6140e06ad
#1205 1309768720000000 kindly fixed in default cset:5e2070688e54 The upgrade now works locally, so the upgrade should work now.
#1215 1310335541000000 kindly fixed cset: 8a317eadbb36 If you delete the last row then it just clears it instead of deleting the row.
#1230 1311154142000000 kindly The standard way to add tables in a plugin has converged upon putting the tables in the iconfigurable plugin. This runs at the correct point for when the application runs normally. For testing however there are issues due to the tables potentially being dropped, especially for the sqlite case. The fix is to make sure the iconfigurables are run at the start of each set of tests, hence adding it to the ckan_nose_plugin. This is not pretty, but good enough. cset:8531b9fc1ee2
#1238 1311583876000000 kindly I cannot reproduce this, to me it looks like it does get the correct revision. If you for example look at the package a millisecond before i.e http://ckan.net/package/osm%402010-11-30%2000%3A21%3A49.627829 the tags are no longer there that were added in that revision.
#1256 1312409296000000 kindly This has also caused problems in authorization for deleted packages.
#1256 1312813529000000 kindly fixed cset:357cf9377b25
#1258 1312813614000000 kindly cset:e22d4e385fc8
#1268 1317212499000000 kindly fixed cset:eebbe6071741
#1316 1338193724000000 kindly now get_or_bust function handles this.
#1339 1316010607000000 kindly I have fixed the isodata and made a slightly modified int_converter for this case. In the correct place and raises invalids on not being an int. cset:a4af115116bb The thinking was that the input of these fields would be through the api so the empty string case did not arise. These should clearly be converted to None (Null). What issues in general? Having done this lots of times before you always end up needing to write your own little validators as the standard ones never do what you want. Thats the point of them. Look in ckan/lib/validators if you need examples. So what you did was correct...
#1341 1315996368000000 kindly This was run to delete the users and their mistaken revisions that where created. {{{ BEGIN; delete from revision r where r.id in ( select r.id from "user" join revision r on r.author = "user".name left join resource_revision rr on rr.revision_id = r.id left join package_revision pr on pr.revision_id = r.id left join group_revision gr on gr.revision_id = r.id where "user".created between '2011-08-15' and '2011-09-06' and gr.id is null and rr.id is null and pr.id is null and ("user".name similar to '%[0-9]' or "user".fullname similar to '[A-Z][a-z]*[A-Z]%') and "user".name not like 'http%' ); delete from "user" u where u.id in ( select "user".id from "user" left join revision r on r.author = "user".name where r.id is null and "user".created between '2011-08-15' and '2011-09-06' and ("user".name similar to '%[0-9]' or "user".fullname similar to '[A-Z][a-z]*[A-Z]%') and "user".name not like 'http%' ); COMMIT; }}}
#1344 1316078757000000 kindly fixed cset:f08215845dab
#1356 1317220284000000 kindly fixed cset:1defa48097f5
#1364 1318199135000000 kindly fixed cset:294a0b6577b0
#1376 1318091245000000 kindly fixed cset:39acf62f30b0
#1383 1319405579000000 kindly We only added the Iresourceurlchange interface as we made the IDomainObjectModification include the Package.
#1383 1320141781000000 kindly fixed cset:ecfb0f8b633c
#1398 1321826380000000 kindly deployed on test.ckan.net docs added cset:47216c49fcec881f4eacc7170cb02d0a443500a2
#1408 1320141847000000 kindly fixed cset:51c7d51f3c17
#1433 1320666509000000 kindly Done but waiting to merge after 1.5 release.
#1433 1321827123000000 kindly cset: 68c37312ef70349431213465005761edf434d27e
#1474 1321826753000000 kindly fixed cset:8f3d917e24390f91db577fdbd8b8c6a1d6228505
#1477 1328016209000000 kindly This is done pending new superticket publihser_profile. (#1669)
#1478 1323161054000000 kindly completed in about 2.8 days. cset:58b7a09328111b97da7d8ac65b4710b94dac54e3
← 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.