{23} Trac comments (3729 matches)

Results (2001 - 2100 of 3729)

← 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 →
Ticket Posixtime Author Newvalue
#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/
#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
#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
#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.
#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.
#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?
#1109 1305124697000000 kindly I am happy this is fixed in cset:445fc04333dd.
#1109 1305123852000000 dread What's the status?
#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?
#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.
#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 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.
#736 1304963598000000 amercader See https://bitbucket.org/okfn/ckanext-harvest/changeset/a7b6d8c0dde7 https://bitbucket.org/okfn/ckanext-harvest/changeset/40de12fada74
#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)
#1037 1304937601000000 thejimmyg Closing this now, any outstanding small issues will be logged in new tickets.
#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.
#767 1304936413000000 thejimmyg We are now live and have used a variety of servers in testing.
#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.
#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.
#728 1304934653000000 wwaites filters not properly supported by e.g. geonetwork. so we defer.
#1109 1304698621000000 dread Did we decide that this facility for storing non-strings via the API is a new feature, rather than a bug?
#1127 1304606094000000 dread Fixed links
#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.
#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
#1126 1304587078000000 dread Fixed in cset:61bb142a6b7c for ckan v1.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?
#1116 1304358664000000 dread This is complete in branch defect-1116-boolean-search-options for release-1.3.5
#1112 1304358643000000 dread This is complete in the branch feature-1112-allow-search-all for release 1.3.5
#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?
#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.
#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.
#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.
#1032 1304094162000000 rgrp Agreed to defer this. Resource editing, to the extent it happens can be kept very simple and part of package editing.
#1114 1304085484000000 dread Done in cset:d7bd4b0f89de on default.
#1113 1304024611000000 kindly cset: 52a3fb230074
#1104 1303920791000000 dread Fixed on default cset:52a3fb230074 - create-test-data now indexes the package it creates.
#1104 1303920492000000 dread I agree this should be fixed.
#1109 1303916487000000 dread Close ticket?
#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.
#1109 1303862352000000 kindly It is fixed now in 1.3.4.1.
#936 1303838713000000 rgrp Completed it seems :-) see https://bitbucket.org/okfn/ckanext-follower
#829 1303838115000000 rgrp This is a wontfix for the present.
#1106 1303834069000000 rgrp fixed in branch:defect-1106-bugs-with-routing.
#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.
#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).
#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.
#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.
#842 1303474228000000 thejimmyg > Otherwise I see a button that says "login to add todo" > > expands out the form > Actually rather than expanding the form, you will go away to the login page and come back to see the expanded form (question: how does this redirect you back to the bottom?)
#842 1303474131000000 thejimmyg As a user I come to a package: Have a todo count at that top that takes you down to the todo list (which may say nothing todo) At the bottom is a section of the package display titled "ToDo" where I see a list of all toDos for the package most recent at the top If I am logged in see a form for "Add to do" at the top of the todo section and can add one straight away I see a "now resolved" button next to each which goes green when you hover. When clicked the todo fades away. Otherwise I see a button that says "login to add todo" expands out the form The form One of the fields is category -> autocomplete the category (not constrained) Add a description Submit, the todo gets added via AJAX to the list at the top as the most recent todo Model: todo id package_id todo_category_id (required) description (required) date=NOW() resolved=False todo_category id name Prepopulate with: broken-resource-link, no-author, bad-format
#1100 1303406103000000 dread Done in release_1.3.4 cset:580e2b11b4ef and release 1.3.3 cset:cac55b8a0bd9
#1098 1303406017000000 dread Also found problem with some tests using delete_all. Fixed in cset:f9764dd43a0a release_1.3.4.
#1098 1303387896000000 dread Fixed in b2b37e39de4d in release-1.3.4. Was only broken on this branch a few days before.
#1086 1303381200000000 johnlawrenceaspden There is no (obvious) way to delete an authzgroup.
#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.
#1097 1303293476000000 dread Done in cset:5dec7eb609ab on branch release-v1.3.4.
#833 1303236364000000 rgrp Two main tickets done so closing.
#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
#919 1303202627000000 dread Simple to fix this in the process of fixing #108. Fix went in cset:304d30d85816 for release 1.3.4.
#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.
#358 1303123611000000 dread This ticket was designed only for reading resources, following an ongoing requirement from the Scraperwiki collaboration. Assume PUT/POST is out of scope. I suggest dealing with resources that aren't attached to packages in an entirely new ticket or CEP, as the implications are wider than this aspect of the API.
#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?
#829 1303122056000000 dread Rufus originally specified it. Reassigning to him to decide whether we still want it or not.
#829 1303118864000000 thejimmyg Is this still relevant?
#1065 1303118756000000 thejimmyg This is now more urgent and I think we have enough consensus to go ahead. See #1094 too.
#954 1303118513000000 thejimmyg David Raznick has implemented JSON errors for the v1 and v2 API, we'll look at this over the next few weeks.
#539 1303118486000000 thejimmyg Old ticket, not sure exactly what it is referring to, closing.
#985 1303118298000000 thejimmyg We'd like CKAN to CKAN harvesting this week if possible.
#1032 1303118226000000 thejimmyg See related ticket #922
#1050 1303118188000000 thejimmyg This should also feed into #1075 which will be being worked on this week.
#787 1303118054000000 thejimmyg The AuthAPI now exists as an IMiddleware plugin, we really need the permission system moved into CKAN before it is useful though and this depends on a refactor of the Auth system. See #1094
#1030 1303117978000000 amercader All the points described in this ticket have been completed. Harvesting work is being done mainly under #1037
#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?
#936 1303117147000000 thejimmyg How is this coming on John?
#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?
#1088 1303035487000000 wwaites fixed in 5c091fc08474 (bug-1088-autoneg-is-wonky) tip
#836 1302882808000000 dread This has been a (minor) issue since release v1.3
#1056 1302882616000000 dread This was broken in cset:b681bbedfa62a68b71260ef48a0da6063109734 which was released in 1.3.2
#1093 1302865470000000 dread Fixed by this API call use the existing license cache. Done in cset:a95888ea39be on release-v1.3.4
#1046 1302777668000000 kindly cset:35ba6ad033ae
#1079 1302777496000000 kindly Complete see cset:35ba6ad033ae
#513 1302774329000000 dread In enh-1046-dictize-the-api we remove the distinction of extras, so we can't do this.
#515 1302774253000000 dread This is now fixed in enh-1046-dictize-the-api. Both groups and packages return the location header.
#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.
#540 1302694845000000 dread Closing - all the suggestions have been implemented: squid instance and cache headers set for high traffic pages.
#840 1302694123000000 dread Basic on/off switch added, tested & documented in cset:0da189c9630e on default.
#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 } }}}
#1056 1302626373000000 dread Fixed in cset:a025b5b3293c on default.
#1085 1302625314000000 dread Fixed in cset:01b3de5d4e31 on default.
#1085 1302624602000000 dread As discussed on IRC, the default ckan.site_url should be blank, rather than ckan.net.
#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.
#1076 1302515674000000 sebbacon See also http://trac.ckan.org/ticket/948
#1063 1302514033000000 sebbacon Fixed in https://bitbucket.org/okfn/ckan/changeset/145eaae3168a
#937 1302513831000000 sebbacon Completed; software at https://bitbucket.org/okfn/ckanext-googleanalytics/src
#1069 1302510609000000 rgrp Mistakenly assigned to this sprint.
#235 1302508788000000 pudo The first three sub-items of this ticket are done in datautil and dcat-tools: Basic GDocs-based normalizer: * https://bitbucket.org/okfn/datautil/src/8bba83b4fa45/datautil/normalization/table_based.py Example of use: * https://bitbucket.org/okfn/dcat-tools/src/0ec5012bf12a/dcat/core/normalize.py#cl-32 Spreadsheet (as referenced in datautil source, should be a kwarg): * https://spreadsheets.google.com/ccc?key=0AplklDf0nYxWdE8tVlRrN1F3bG9PdDBFUDNZcENDNEE&hl=en#gid=0 Experience so far has been that Google rate limits the current implementation so we should perform all ops in one or two big calls rather than "piece by piece".
#833 1302276855000000 rgrp Authz subsystem complete.
← 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 →
Note: See TracReports for help on using and creating reports.