{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
#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?
#1112 1304358643000000 dread This is complete in the branch feature-1112-allow-search-all for release 1.3.5
#1116 1304358664000000 dread This is complete in branch defect-1116-boolean-search-options for release-1.3.5
#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?
#1126 1304587078000000 dread Fixed in cset:61bb142a6b7c for ckan v1.3.5.
#1124 1304601771000000 nils.toedtmann I installed the python-ckanext-solr package rom http://apt-alpha.ckan.org/datanl-dev onto us10/DataGM too, and it seems to work just fine, see http://datagm.test.ckan.net/package?q=manchester
#1127 1304602084000000 wwaites The proposal is not comparable to PEP and DEP because the projects have vastly different requirements. The API stability needs of a programming language or an operating system (e.g. fundamental building blocks that you don't expect to change often or radically) are very different from a web application. The plone one is comparable. The idea itself is a double-edged sword. It will promote stability which is good but can also tend towards rigidity and stagnation which is bad. Each added bit of bureaucracy and process means fewer people will be willing to collaborate or participate in improving the software. Overall, -1.
#1127 1304606094000000 dread Fixed links
#1109 1304698621000000 dread Did we decide that this facility for storing non-strings via the API is a new feature, rather than a bug?
#728 1304934653000000 wwaites filters not properly supported by e.g. geonetwork. so we defer.
#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.
#784 1304936251000000 thejimmyg The UKLP test manager is looking at a new test proposal, we have had approval to go live without this, we can re-open later if necessary.
#767 1304936413000000 thejimmyg We are now live and have used a variety of servers in testing.
#728 1304936482000000 thejimmyg Actually, these are a different type of filter. We need to send a filter to only get modified documents, to save processing our end.
#1037 1304937601000000 thejimmyg Closing this now, any outstanding small issues will be logged in new tickets.
#736 1304937755000000 thejimmyg We now check WMS links. The CSW link checking could be more robust. New proposal is: Check that a URL with a / is treated the same way as one without. Treated as the same if same port, scheme, domain and path (ie query string and fragment are ignored, port is normalised away)
#736 1304963598000000 amercader See https://bitbucket.org/okfn/ckanext-harvest/changeset/a7b6d8c0dde7 https://bitbucket.org/okfn/ckanext-harvest/changeset/40de12fada74
#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.
#1129 1305116419000000 thejimmyg Great proposal, here's my thinking: * The current VDM model (where we have things like a single package table which logs changes to a package_revision table) is very well tested and works well and we should only consider a radical change with good reason * Although we are making a move from *model objects* being the central components to the *logic layer functions* being the central components, there is no need yet to have the database structures we store (for revisioning or otherwise) start to look like the dictized representation. The logic layer itself is designed to do that mapping. * Since we do have this logic layer though, there is less need for "magic" SQLAlchemy objects to support dicts and lists (eg the stateful objects used to make a list of tags on a package behave like a list), a few simple (and easily debuggable) queries in the logic layer would work better. In the longer term we may want to look at serialising more dictized-looking objects and that may lend itself to a more dictized changeset model or even a more dictized storage system (eg no-SQL) but for the time being we are not at that point. I recommend the following: * We continue to use the current default branch of VDM (not the changeset branch) * We continue to treat the package table (and other non-revision tables) as the most recent revision (even though the *active* revision displayed in CKAN might well be in the revision tables because more recent changes haven't been moderated yet) * We slowly stop using stateful lists and dicts in CKAN because we have move control with explicit queries in the logic layer Sound good?
#1109 1305123852000000 dread What's the status?
#1109 1305124697000000 kindly I am happy this is fixed in cset:445fc04333dd.
#1134 1305125228000000 thejimmyg Great stuff. Yes, I agree with all this, but as initial thoughts I suggest that for phase 1, the info() method returns one more key called "form_config_interface" which takes a string representing a the type of interface for the config field on the form. If the key is missing it is treated as "None". The two possible values are: None - the field is not present and must always be stored as NULL Text - a single text field will be provided on the interface Whatever the interface, the value built will always be stored in the config column of the table. We then also provide a "get_schema()" method that returns a schema cablable of parsing the data submitted by the form and storing it as a single key named "config". ckanext-inspire will then add other functions to the schema for URL etc so that regardless of what the harvest plugin does, the key fields ckanext-harvest are always there. This then allows: * Customiseable config interfaces * Customisable valiation * A consistent place to store config in the database Sound good?
#1127 1305128000000000 thejimmyg This is great idea and it has taken on well. +1 from me. We can update/create new CREP policies as needed.
#1129 1305139980000000 rgrp It seems like this ticket is getting a bit confused with ticket:1076 (changes re vdm) :-) Some general conclusions relevant to both: * General feeling is not to change to changeset model * I'm personally +0 on changeset model * I would note main benefit is simplicity and orthogonality of changesets to core system. I also think cost of change is small. * That said we can simplify current model as well. * 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) * 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. What I don't see in this CEP as yet is any discussion of the complexities around pending stuff (e.g. do we allow multiple pending, do new edits get shown current or latest pending). I'll try and comment more on this but a lot of this was in original vdm discussion last summer.
#1129 1305209601000000 rgrp Replying to [comment:2 rgrp]: > It seems like this ticket is getting a bit confused with ticket:1076 (changes re vdm) :-) I of course ;0 meant ticket:1077
#1135 1305210134000000 rgrp Work on this is largely complete in changeset branch: https://bitbucket.org/okfn/vdm/src/changeset/ Overview docs: https://bitbucket.org/okfn/vdm/src/changeset/doc/changeset.rst
#1136 1305210925000000 rgrp Most of this change has been implemented in the changeset branch [1] but could be backported reasonably easily to main. [1]: https://bitbucket.org/okfn/vdm/src/changeset/
#1137 1305211672000000 rgrp Most of this change has been implemented in the changeset branch [1] but could be backported reasonably easily to main. [1]: https://bitbucket.org/okfn/vdm/src/changeset/
#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..
#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.
#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.
#1127 1305458020000000 rgrp I'm obviously a strong +1 but feel we should stick with the CEP name (we have PEP and DEP and CREP really does sound weird compared to CEP). Also I think we may need to do a bit more to clarify when you just do a good ticket and when one does a CEP (looking at what has occurred already). I think this may be one reason to keep CEPs separate in drafting from trac as will clearly distinguish CEPs from standard tickets.
#1127 1305458489000000 rgrp one other thing: i think the plan is for CEPs to be in restructured text (for easy transfer to docs). This should be mentioned and the template in the wiki should be in ReST.
#1131 1305537897000000 dread Fixed on branch release-v1.3.5 cset:3461ed6bab0c
#818 1305559442000000 dread 1.4 complete
#1092 1305570822000000 kindly completed cset: ca1ac4112ea2
#1134 1305623531000000 sebbacon Agreed with James that we should consider *from the start* how to provide for a nice UI -- my worry is if we start out with people editing raw JSON we'll end up keeping that for years :)
#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.
#191 1305732285000000 dread Will's suggestion is to have "modified_since" param, just as we have for Revision Search. Maybe we don't need a range. 'Order by modification' should be on by default for queries with 'modified_since' param.
#191 1305732414000000 dread Do this after refactor #1129
#191 1305814900000000 dread Maybe allow searching by package creation date too? Suggestion from kindly: when indexing a package, have the search backend also store the metadata_modified value, to make it easy to search on it.
#1078 1305828965000000 kindly complete: cset:843b78bae016
#1142 1305880901000000 sebbacon The guys at Wikimedia also produced this spreadsheet including notable users and features of other software. Could be useful.: https://spreadsheets2.google.com/ccc?authkey=CLWu1cgP&hl=en&key=tYiwc9kUVLLlALOQEzFqujw&hl=en&authkey=CLWu1cgP#gid=0
#1142 1305881244000000 lucychambers Replying to [ticket:1142 rgrp]: > Previous super ticket (from 3m ago): http://trac.ckan.org/ticket/927 > > * CKAN 1-page overview (for enterprise and for data hackers) > * Administrator's Guide (including install) > * Extensions Guide > * Separate CKAN.net info from Software Documentation (?) > > == Minor Items == > * Include guide on how to configure local filesystem storage, instead of Google storage. (http://lists.okfn.org/pipermail/ckan-discuss/2011-May/001235.html)
#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
#985 1306407617000000 amercader Moving this to the PDEU (publicdata.eu) project
#1161 1306408026000000 amercader Duplicate of #1157
#985 1306408134000000 amercader Duplicate of #1155 and #1156
#1165 1306413953000000 nils.toedtmann this is similar, but not equal to #1096
#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
#1169 1306754833000000 dread Done on default. Will appear on ckan.net next time it is branched and updated.
#826 1306766057000000 dread This went into ckan release 1.3.2.
#1155 1306773174000000 pudo Now implemented based on CSV export available on the catalogue page: * http://data.london.gov.uk/catalogue
#944 1306774766000000 pudo done at iati.ckan.net
#912 1306774876000000 pudo moving to ckan
#913 1306774962000000 pudo moving to CKAN, still need a resolver
#1166 1306847326000000 thejimmyg Also, rather than INSPIRE=true we should probably have information about the harvesting mechanism and the harvest object type? This also relates to our use of the kind field on the resource.
#1156 1306855111000000 pudo Both are now implemented but may need further work to adhere to developing conventions wrt to location etc.
#1167 1306856992000000 sebbacon Yes to all the above. Further question: which extensions should be installed as standard? I would argue: * ckanext-stats * ckanext-googleanalytics * ckanext-disqus * ckanext-solr (implies installing a running solr, too...) * ckanext-follower * ckanext-admin Note that googleanalytics and disqus both require user accounts set up at the corresponding service. Not sure how we would handle this in the instance setup.
#1167 1306857142000000 sebbacon Another thing to consider: how do we ensure we keep a single, up-to-date version available? (I'm thinking wrt developer / sysadmin workflow)
#1167 1306857750000000 thejimmyg Creating the AMI is really just the icing on the cake. The hard bit is getting the packaging right so that's where we need to concentrate first. Once the packaging works we just make sure apt-get upgrade is run regularly. +1 to the list above. I also agree we should install solr by default. Who has actually done a CKAN solr install? I haven't but together with whoever has I can try to package it up. Wrt to usernames and passwords, I'll look into how dpkg manages those blue pop-up screens for entering configuration options.
#1170 1306864422000000 dread Done in cset:4d2d0857281f on default
#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?
#1143 1307024681000000 dread All done in ckanext-stats cset:bc54790cacd4 (apart from "fix x axis to start at first revision" which was not a problem after all)
#1175 1307350866000000 dread Flavio, can you post here the exception that you get?
#1152 1307352165000000 amercader Bumping to ckan-v1.5-sprint-3 and updating the CC email addresses so people actually get any updates.
#888 1307352537000000 thejimmyg I don't think any progress has been made on this for a bit so I'm assigning it to me.
#1132 1307352675000000 dread Yes, these are apparently search-related and so are skipped when testing under sqlite. See README.rst for more info. Compare with this: {{{ $ nosetests --ckan --with-pylons=test-core.ini ckan/tests/functional/test_authz.py ............................................ ---------------------------------------------------------------------- Ran 44 tests in 69.287s OK }}}
#1167 1307358318000000 dread debconf seems the preferred way to question the user post-install and run setup scripts. It seems a bit of a faff. The person that is able to spin up an EC2 instance is no doubt technically able enough to follow a couple of instructions in README.txt saying edit /etc/ckan/<instancename>/<instancename>.ini and add your Google Analytics credentials. So I don't think this ticket is the driver for a debconf setup.
#1121 1307358426000000 dread We don't need to support JSON extras at the moment.
#1177 1307360643000000 rgrp What revision of the CKAN code are you using (do hg id to get revision if installing from source). Have you modified the package template in any way? Have you restarted apache after upgrading?
#1177 1307361157000000 fccoelho to upgrade I used the method describeb on bitbucket, after upgrading pip-requirements: pip -E pyenv install -r pip-requirements.txt after that I did a paster --plugin ckan db upgrade --config ckan.emap.fgv.br.ini the revision id on my pyenv/src/ckan is: 5730c79db461+ tip yes, I have restarted apached after upgrading
#1177 1307365496000000 rgrp The issue here is that the line should never be reached because g.has_commenting should be False: https://bitbucket.org/okfn/ckan/src/5730c79db461/ckan/lib/app_globals.py @Flavio: have you modded your code in any way? is self.has_commenting False in your app_globals.py A quick fix would be to remove the template lines calling to remove the lines in the template: {{{ ${h.subnav_link(c, h.icon('comments') + _('Comments &amp; Questions'), controller='package', action='comments', id=c.pkg.name)} }}}
#1177 1307366621000000 fccoelho I have not modded the code in any way... I'll look for those lines in the template.which template is it? read.html does not have a line such as this.
#1177 1307367354000000 fccoelho OK I did an fgrep on all package template and found the line on layout.html, I'll comment the block and test.
#1177 1307367923000000 fccoelho Ok it fixed it! thanks a lot!! Is there any side effects to the removal of this line, I should know of?
#1175 1307372833000000 fccoelho Thats the thing, I don't get any error message, no even in the logs. But I can't even load a page.
#1123 1307374691000000 dread I'll change the architecture to "all" as per this article: http://linuxreviews.org/man/deb-control/
#1177 1307374897000000 dread I think rgrp was suggesting you have mistakenly set has_commenting to "True" in app_globals or elsewhere. But either way, this should have no side-effects.
#1096 1307444626000000 nils.toedtmann See also http://ckan.okfnpad.org/multisite
#1165 1307444733000000 nils.toedtmann See also http://ckan.okfnpad.org/multisite
#1181 1307532816000000 dread Fixed in ckan default in cset:72f7d48d7f31. Have left Package url and Resource url links though, as these are the key links we want google to see. So we need to check these carefully for spam.
#1180 1307544223000000 dread Both issues solved using a whitelist on anchor tags. Second issue was a link with unicode expression of the quote. e.g. <a href=\u201dsomelink\u201d>somelink</a>
#1159 1307615133000000 pudo Rudimentary RDFa has been added with seeAlso to API.
#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.
#1173 1307615271000000 pudo Now available in ckanext-rdf and linked to from WUI.
#1123 1307790563000000 thejimmyg This isn't necessarily a trivial thing. Let's get the build system for the packages stable before we start changing it all to support alternative architectures. Once the packaging is working well it would be trivial to switch those servers to amd64. I'm sorry, but this isn't worth the investment in manpower at the moment.
#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 :-) )
#1178 1308045351000000 rgrp Fixed. This was due to incorrect config of bucket option.
#1187 1308143605000000 dread Also stopped creating revision for user edits. Done in cset:795ccd6405ba for 1.4.1 release
#961 1308230058000000 rgrp @kindly: can we close this ticket now. All the meat is done and the remaining related tickets are either low priority or possibly wontfix.
#1033 1308310446000000 dread Fixed in 5c7caca30737 for v1.4.1
#1142 1308326118000000 annapowellsmith List of new docs tasks agreed by APS and RGRP: * Tutorial on the wiki (long-term): Integration with Wordpress and Drupal and Javascript * Overview of domain model both for average users and for devs * 2-page glossy brochure * Vision for CKAN http://notebook.okfn.org/2011/04/27/data-hubs-data-management-systems-and-ckan/ * Comparison : use http://wiki.ckan.net/Related_Software as starting point - build on wiki - Socrata and OGDI * Renaming: separation between ckan.org and ckan.net * More documentation in the code ... * Config options generated from code or move this to WUI ... See also proposed overhaul at http://wiki.ckan.net/Documentation_Plans
#1192 1308337652000000 dread I really think forms are a key asset of CKAN, and keeping the docs about customising and integrating them is important - i.e. forms.rst and forms-integration.rst. There are ideas being suggested for replacing bits of front-end, but forms hard to do, and David's new system is a significant offering on top of the CKAN back-end, so it seems crazy to me to abandon it. forms.rst has been updated by David Raznick in the release_v1.4.1 branch. i18n.rst - include here the creation of the pot file, deploying a translation, transifex admin load-testing.rst - I think performance should be mentioned in the glossy guide (some sort of basic metrics of speed profile, to return web pages, run searches and API operations, for 100 or 1000 packages, on a given spec machine) and have it based on a report showing how we measured it. The report would look a bit like this file, and it might do as a stub, but it seems pretty lacking. distributed.rst - agreed, remove. design.rst - agreed, delete. loaders.rst / loader_scripts.rst - yes move to wiki feeds.rst - this should be split into a tutorial for the wiki and the reference page left in sphinx importer.rst - this should be moved to ckanext-importer/doc admin.html - this has already gone in 1.4.1 authorization.rst - This is a bit jumbled. We're talking about changes to the code, so maybe not worth working hard to make this good, so I suggest leaving it, but delete the boring section "Requirements and Use Cases". deb.rst - this is an administrator task, so should stay why move this to the wiki? buildbot.rst - ok to stay here? vm.rst - I assume there's no problem with this
← 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.