{23} Trac comments (3729 matches)

Results (1401 - 1500 of 3729)

← 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 →
Ticket Posixtime Author Newvalue
#949 1297074827000000 rgrp Hocus pocus so set owner after being fixed!
#950 1297076647000000 rgrp Reopen to set an owenr.
#953 1296809834000000 rgrp Done in cset:3275d2fc9e43
#954 1315948855000000 rgrp @kindly: can you update here. My impression is that lots was done but the current ticket description bears little relation to what was done. Suggest we move current content to a new ticket and update this with a short description of what *was* done and then close -- does this sound sensible?
#957 1314218701000000 rgrp I'm closing this as wontfix as we now have arbitrary metadata for resources so probably won't need a specific field. That said we probably will want a schema but that is not yet finalized and would be a separate and wider ticket. For current proposal of the attributes generally wanted for resources see http://wiki.ckan.net/Domain_Model/Resource (recently updated).
#958 1320664462000000 rgrp This was done as part of dataset resource editing in #1294 (duplicate)
#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.
#962 1297678925000000 rgrp In progress but not yet completed so moving to next sprint. Estimate remaining time at: 2h.
#962 1298889078000000 rgrp Nearly done.
#962 1301364987000000 rgrp Closing as have now reworked to: * Support plain text previews for many formats (including xml based formats) * Try to handle everything else as html with an iframe ... * Do not show preview button where not useful * Normalize formats for better recognition (e.g. text/csv, application/xls) See: https://bitbucket.org/okfn/ckanext-datapreview/changeset/c1d672a6c368 and previous. Also re-updated the dataproxy so it works again (had got out of sync when mistakenly reverted the dataproxy a couple of weeks ago). Could still do api/sparql (using sparql js wrapper) and handle json (as plain text ...?) but these can be new tickets.
#964 1297211237000000 rgrp Done in cset:fd0e2edf03b1
#973 1297678851000000 rgrp Done. See http://licenses.opendefinition.org/ the new licenses release (0.6) http://pypi.python.org/pypi/licenses/0.6 and cset:b8e54186faee Actual cost: 4-6h (as i refactored the licenses package heavily)
#975 1297344448000000 rgrp Fixed in cset:a4caf6b8ce3d.
#978 1314404858000000 rgrp Suggest we either a) get rid of columnar layout or b) (preferable) get a dedicated page for resource. That way summary on package page just shows main attributes.
#978 1325259266000000 rgrp Think this should be part of a larger refactor of resource editing now that #1445 (resource page in WUI) is done
#978 1328530459000000 rgrp We already have basic editing in the Resource section of dataset edit. However, need to extend this to additional fields such as webstore_url and "extras".
#979 1314404905000000 rgrp Change from Edit Resource extras in the API to Edit Resource extras in the WUI as believe we already have API editing and reference to #978 implies this is about the WUI.
#979 1315222244000000 rgrp Is this already done? Is it under test?
#980 1297501755000000 rgrp No owner :) -- also what about the issue that when trying to edit a package for which you did not have permission you got a 500 ...
#982 1297525477000000 rgrp I don't think i understand why this has been closed (and it would surely be wontfix rather than invalid ...). Let me explain in more detail: we would move to having one and only one pip-requirements.txt in the repo at any given revision and it would simply have the correct info for whatever branch/revision it was on. At the moment we are having extra pip-requirements-....txt for labelling branch pip-requirements when we could just the branching facility of mercurial. You'd do {{{ wget http://bitbucket.org/okfn/ckan/src/metastable/pip-requirements.txt }}} rather than {{{ wget http://bitbucket.org/okfn/ckan/src/default/pip-requirements-metastable.txt }}}
#992 1298060474000000 rgrp Fixed in cset:08548ef8f0e9
#999 1300707328000000 rgrp Done. See https://bitbucket.org/okfn/ckan-ckan.net and updated ckan.net.ini.
#1001 1300703779000000 rgrp First work in cset:6b8cbe465b61
#1001 1301229082000000 rgrp Completed and merged into default in cset:cb200f339dbb. At the moment have done the very simple option but pudo's approach seems better and we could refactor towards that going forward.
#1001 1301310351000000 rgrp This ticket did not include CSRF matters - please raise in a separate ticket if you wish. I looked in some detail at the testing options and nothing seemed simple to do that didn't duplicate code we already have (since no way to access the base controller halfway through a request). This can be tested as necessary as part of the development of the new js work.
#1003 1298490126000000 rgrp Work so far in http://bitbucket.org/rgrp/ckanjs
#1003 1298889293000000 rgrp Have now started refactor to use backbone and have basic inline editing working and started on Add dataset view.
#1003 1300100411000000 rgrp Converted completely to backbone and now have fully-operational add dataset functionality. I'm closing this ticket now - further improvements can be in there own tickets.
#1006 1300105927000000 rgrp Not sure when i described that other process but I'm definitely of the opinion that we should: * Deprecate and remove stable branch * Deprecate and remove metastable branch (going forward we can use release branches for what we did with metastable in the past) May want to update BranchingPolicy to reflect this (also should probably have some statement about closing release branches and tagging) Reassigning to David Raznick as he is our release guru now.
#1008 1298821826000000 rgrp I've removed the eval in cset:1b8fedeb7ab0 - the more general question about caching should go in a separate ticket.
#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
#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
#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.
#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).
#1031 1299863222000000 rgrp Done, see cset:78d96b520679
#1032 1300380606000000 rgrp This is urgent for me as without upload does not really function.
#1032 1304094162000000 rgrp Agreed to defer this. Resource editing, to the extent it happens can be kept very simple and part of package editing.
#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.
#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).
#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)
#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.
#1069 1302510609000000 rgrp Mistakenly assigned to this sprint.
#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!)
#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.
#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 ).
#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.
#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
#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.
#1102 1303744552000000 rgrp (Same ticket created 3 times by accident I think -- see #1104).
#1103 1303744575000000 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.
#1106 1303834069000000 rgrp fixed in branch:defect-1106-bugs-with-routing.
#1108 1315140879000000 rgrp Completed in https://bitbucket.org/okfn/ckan/changeset/9be1ae232ec3 cset:9be1ae232ec3
#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.
#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 :-) )
#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.
#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
#1129 1325268100000000 rgrp More UI work remains in #1141
#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/
#1138 1316965357000000 rgrp Cannot see this issue any more on default (as deployed on e.g. test).
#1142 1313775665000000 rgrp This was completed 4 weeks ago and can now be marked as complete. See http://docs.ckan.org/ and http://wiki.ckan.net/ and http://ckan.org/
#1151 1330908188000000 rgrp Not sure we will be able to fix this easily as we need a dataproxy for general case. Think it better to focus on the case where data in DataStore and we use Recline. As such closing as wontfix for the present.
#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 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 & Questions'), controller='package', action='comments', id=c.pkg.name)} }}}
#1178 1308045351000000 rgrp Fixed. This was due to incorrect config of bucket option.
#1190 1320143592000000 rgrp A very substantial portion of this got done as part of 0.5 including the webstore #1208 and the majority of automated conversion #1398. #1432 is currently deferred so we're going to close this ticket on basis that item (3) is now out of scope.
#1192 1312191462000000 rgrp Marking this as closed as Anna has completed and this is now deployed at http://docs.ckan.org/.
#1195 1311841763000000 rgrp Fixed in https://bitbucket.org/okfn/ckanext-storage/changeset/49734285f1ef
#1199 1308822557000000 rgrp Not sure we need exposure this via the API (at least at this point) as things like auto mass emailing could be in done in separate component (that talks to CKAN).
#1202 1315821804000000 rgrp This now irrelevant and relevant content has gone from thedatahub theme.
#1208 1311525306000000 rgrp Propose this ticket can be closed as webstore is now functional and being used. Can open new tickets for specific improvements / adaptations as the need arises.
#1211 1315948703000000 rgrp Let's close and re-open (or open a new ticket) for future work.
#1231 1315948921000000 rgrp @kindly: Does this fit in with current plans? If not suggest we close as invalid/wontfix or put into the backlog (though given lack of content not sure that is very useful ...)
#1231 1325474087000000 rgrp Closing as wontfix (or duplicate). We now have stats in footer as of #1576. googleanalytics (e.g. http://thedatahub.org/analytics/dataset/top) would be nice to have but should be part of stats
#1231 1325474447000000 rgrp See #1101 for other duplicate ...
#1232 1315948536000000 rgrp Removing from ckan-v1.5 as do not think any of this is top priority (correct me if I'm wrong!)
#1233 1315948668000000 rgrp Removing from v1.5 as not a priority atm.
#1239 1311442163000000 rgrp Fixed in cset:adf254b7c507 (see https://bitbucket.org/okfn/ckan/changeset/adf254b7c507)
#1240 1316022145000000 rgrp add autocomplete
#1240 1324319119000000 rgrp assigning to kindly for review
#1240 1325473312000000 rgrp IMO this is non-urgent and can move out of v1.6 as we have enough more important stuff to do.
#1243 1328000405000000 rgrp invalid as things have changed and this has been fixed or obsoleted.
#1245 1317422640000000 rgrp Closing as now mostly done and not really a ticket item.
#1247 1311955176000000 rgrp Done. See http://ckan.readthedocs.org/ and http://docs.ckan.org/ will propagate soon.
#1251 1314406332000000 rgrp Really non-urgent and can be done once #1252 is done (which is dependent on v1.5)
#1252 1314406271000000 rgrp Move to v1.5 since this will coincide with release.
#1252 1316876747000000 rgrp Announced. thedatahub.org now running for 2+ months. Today did wiki.ckan.net redirect and hope to do thedatahub.org redirect.
#1252 1318160334000000 rgrp This was done ~2 weeks ago.
#1264 1314406294000000 rgrp Nothing urgent about this so moving to backlog.
#1271 1313753663000000 rgrp Closed in cset:749cb3a087e3
#1272 1313745867000000 rgrp Assume these are the 3 spatial fields listed on http://wiki.ckan.net/Geospatial_Capabilities. I'm a big +1 here. Starting point would be a bit more documentation on that wiki page. Questions: * Is this work going in ckanext-spatial? * What is being proposed here, I assume, is to automatically index those fields in our geospatial search. * Should we develop a simple display widget using google maps or similar (this is orthogonal to the WMS preview i think) which *just* uses the core fields. This is probably a separate ticket and possibly separate from ckanext-spatial extension.
← 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 →
Note: See TracReports for help on using and creating reports.