{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
#1009 1298638447000000 pudo Some more ideas: * /user should list users, sorted by number of packages contributed/editied * /user/{name}/packages shows a list of packages to which users have contributed
#1008 1298821826000000 rgrp I've removed the eval in cset:1b8fedeb7ab0 - the more general question about caching should go in a separate ticket.
#1006 1298631145000000 dread This command is slightly different to your branch policy as of two weeks ago: {{{ stable: stable code metastable: (will soon be deprecated) for code preparing to be stable default: development HEAD }}} which I prefer. My ideal would be to get rid of the confusing name 'metastable' and unneeded 'stable' and start a new branch called 'released', which will act the same as 'master' in this diagram but with a more intuitive name: http://nvie.com/posts/a-successful-git-branching-model Then for each ckan instance we can either use the most recent release (from 'released') or choose a specific one (e.g. 'ckan-1.3' or even 'default' or 'enh-865' for getting latest features). This gives a good degree of flexibility, is more understandable to newbies and probably a more widely understood branching model.
#1006 1300098217000000 dread Reassigning to rgrp for response
#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.
#1006 1300372286000000 thejimmyg I'm updating the branching policy now. David has closed stable and closed metastable. Marking as fixed.
#1005 1300100085000000 dread Moved to dgu trac ticket 869
#1004 1311173560000000 thejimmyg At the moment it says "Create a new group" and clicking it takes you to the login page. We want it to do the same thing but if you aren't logged in the label should say "Log in to create a group".
#1004 1323171375000000 thejimmyg The yellow box on the right is now back and you don't get taken to the login page. We'll write more detailed instructions once the group refactor is done.
#1004 1323172489000000 dread There is a description of groups, but that is not the subject of this ticket. In fact if you're not logged in you do get taken to the login page (which is quite correct). I agree with your earlier comment that the text of the link needs changing. Sorry to be reopening this, but I think the previous comment misses the point. Doing this ticket would be a valuable quick fix. Putting on backlog.
#1004 1323174597000000 thejimmyg I don't understand. We just had a team meeting about this, all discussed it and agreed to close it. Yes, you get taken to the login page, but that is the correct behaviour. The problem in the past was that the link was in the yellow box and there was no explanation as to why you had to login. This time you click from the header bar and there is a clear message saying "Unauthorized to create a group" - exactly as a user would expect. Even if the exact text of the ticket description isn't fully implemented in the current release, the UX isn't broken anymore. Yes, it might be even nicer to have a message warning them in advanced but these improvements will be taken forward in the UX work - maybe there is an even better solution than a message? Since you are unhappy about closing it I'm marking it as "Duplicate" of #1521. As agreed earlier with the entire team, we'll take this forward as part of the groups refactor. See #1521 for more information.
#1004 1323177994000000 dread My suggested fix: {{{ diff --git a/ckan/templates/group/index.html b/ckan/templates/group/index.html index 8502df9..064e066 100644 --- a/ckan/templates/group/index.html +++ b/ckan/templates/group/index.html @@ -9,7 +9,15 @@ <py:match path="primarysidebar"> <li class="widget-container boxed widget_text"> <h3>What Are Groups?</h3> - <span i18n:msg="">Whilst tags are great at collecting datasets together, + <p><span i18n:msg="">Whilst tags are great at collecting datasets togethe + <p> + <span i18n:msg="" class="ckan-logged-in" style="display: none;"> + <a href="${h.url_for(controller='group',action='new', id=None)}">Creat + </span> + <span i18n:msg="" class="ckan-logged-out"> + To create a new group, please first <a href="${h.url_for(controller='u + </span> + </p> </li> </py:match> diff --git a/ckan/templates/group/layout.html b/ckan/templates/group/layout.html index 64153aa..a3f732b 100644 --- a/ckan/templates/group/layout.html +++ b/ckan/templates/group/layout.html @@ -25,9 +25,12 @@ <li py:attrs="{'class':'current-tab'} if c.action=='index' else {}"> ${h.subnav_link(c, h.icon('group') + _('List Groups'), controller='grou </li> - <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}"> + <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}" class=" ${h.subnav_link(c, h.icon('group_add') + _('Add a Group'), controller=' </li> + <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}" class=" + ${h.subnav_link(c, h.icon('group_add') + _('Log-in to add a Group'), co + </li> </ul> </py:match> }}} BUT this fix doesn't completely work. When you log-in and create a group, at this point the nav bar changes from the (correct) "Add a group" to (incorrect) "Log-in to add a group".
#1004 1323187352000000 dread Here is the unclipped version: {{{ <p> <span i18n:msg="" class="ckan-logged-in" style="display: none;"> <a href="${h.url_for(controller='group',action='new', id=None)}">Create a new group</a> </span> <span i18n:msg="" class="ckan-logged-out"> To create a new group, please first <a href="${h.url_for(controller='user',action='login', id=None)}">log-in</a>. </span> </p> }}} {{{ <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}" class="ckan-logged-in" style="display: none;"> ${h.subnav_link(c, h.icon('group_add') + _('Add a Group'), controller='group', action='new')} </li> <li py:attrs="{'class':'current-tab'} if c.action=='new' else {}" class="ckan-logged-out"> ${h.subnav_link(c, h.icon('group_add') + _('Log-in to add a Group'), controller='group', action='new')} </li> }}}
#1004 1323194016000000 zephod Dread, that fix wouldn't work because the class attribute was being defined in Genshi and again in HTML, with slighly undefined behaviour (in this case Genshi overwrites HTML). I have performed a very very simple fix which modifies the navbar text when you're not logged in. https://github.com/okfn/ckan/commit/a89a48731ba548170045a60ac2930e0019c299c7 I don't think the link should be restored in the sidebar, it was explicitly removed as part of a site-wide sweep to make the sidebar a passive, helpful element rather than an active element with action links. Site looks great to me, I'm closing this ticket.
#1004 1323195485000000 dread Great stuff zeph! Diff looks really good and cheers for the explanation. On master, cset:a89a48731ba548170045a60ac2930e0019c299c7 and I've cherry picked this for release 1.5.1. too.
#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.
#1002 1311173185000000 thejimmyg I've done this in my branch and it will get merged in.
#1002 1311675754000000 dread Can you also delete the "paster changes" in ckan/lib/cli with this removal?
#1002 1311676199000000 dread Reopening this, since it has not been pushed or merged in afaict.
#1002 1322515684000000 dread I've redone these changes in cset:91258a6296db71d78a on master, aiming for 1.5.2.
#1001 1300367555000000 thejimmyg Yes, I think the two should be consolidated, but as was noted elsewhere (I think) we don't want the API to ever be authenticated via a cookie, otherwise we open ourselves to CSRF attacks. Instead we could support the API key as a query parameter as an alternative to via the HTTP header if it is hard to set an HTTP header in JS libraries?
#1001 1300625888000000 pudo My vote on this would be to enable "httpbasic" auth via repoze.who and to add an API key challenger to ckan/lib/authenticator.py that accepts API keys, from within repoze.who. This way we won't have to work around the framework at all and can retain compatibility to the existing mechanisms.
#1001 1300703779000000 rgrp First work in cset:6b8cbe465b61
#1001 1300704249000000 pudo Wrote a WDMMG version of this yesterday: https://bitbucket.org/okfn/wdmmg/changeset/398ce0eb3901#chg-wdmmg/lib/authenticator.py
#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 1301307814000000 dread You mentioned writing tests? Also the CSRF question from James hasn't been addressed.
#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.
#1000 1298912726000000 kindly fixed cset:630513f550d5
#999 1300707328000000 rgrp Done. See https://bitbucket.org/okfn/ckan-ckan.net and updated ckan.net.ini.
#998 1298369862000000 dread 'paster db create' (or init) should do exactly what we ask. Surely we should simply tell people to use 'paster db upgrade' instead?
#998 1298371191000000 anonymous I am happy to get rid of paster db create altogether as a compromise? Or add a depreciation warning to it?
#998 1298372171000000 dread Yes I agree - either of those sounds good. I think I've always used 'db init' in preference anyway.
#996 1300364398000000 thejimmyg This is now fixed, the outcome will be used to inform #995 for the caching.
#995 1300364316000000 thejimmyg Also, update the docs: Documentation article on caching / improving performance. (To complement configuration docs.) * Different sorts of cache - beaker style, etags, package_dict in search results(?) * How each one affects performance * How to turn them on/off and configure them * Is it possible to bypass each of them in the browser or with wget/curl? Therefore closing #841.
#995 1311175353000000 thejimmyg The caching still isn't brilliant but there is less urgent need to refactor it. In the future our caching methodology should be to cache at the logic layer so we don't need to refactor the existing caching at this stage.
#995 1311179009000000 thejimmyg See also previous tickets: * #537 Caching and Performance improvement * #543 Investigate partial page caching and edge-side includes
#994 1298912830000000 kindly see cset:93188d42fc12
#993 1298373114000000 dread Fixed on 1.3 cset:7708c8b521ed and merged to default. Deployed to ckan.net.
#992 1298060474000000 rgrp Fixed in cset:08548ef8f0e9
#991 1298037717000000 dread Fixed in cset:56cccbbb9d1a in time for ckan 1.3 release. This did not affect previous releases.
#990 1311180850000000 thejimmyg This now works.
#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 1297700818000000 pudo Kindly, I agree - it would be much preferable to have independent storage for plugins and this would be easy to do if we were using another type of storage already. As it stands, however, our storage mechanism is SQL. I think we should use it for what it is as much as possible and do the weird, vertical stuff (k,v tables, swapping to redis) only if we really need it. For everything else: lets use SQL as it was intended. Examples: * We want to develop an apps catalogue as a CKAN plugin. While we could certainly put this in Redis, there is no reason why we can't have the following table: application (id, name, title, description, author, project_url, site_url, code_url, image). * A watchlist plugin could essentially work on UUIDs alone. What you'd end up with is something like this: watch (id, user, scope_id). Re migrations you're right, but my first intention would be to handle that seperatly for each plugin (i.e. they need to have their own migration repositories that they keep track of, e.g. via an apps_migrate_version table)
#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...
#987 1311177705000000 thejimmyg This has largely been implemented now for publicdata.eu. There is a CREP #1134 outstanding to take the harvesting to the next level so marking this one as duplicate for now.
#986 1297812401000000 wwitzel3 https://bitbucket.org/okfn/ckanext-qa/src/be57e20c60ef/
#985 1298571248000000 pudo digitialiser.dk has been assigned to Stefan Marsirske to get him into this Framework, everything else is delayed.
#985 1303118298000000 thejimmyg We'd like CKAN to CKAN harvesting this week if possible.
#985 1306407617000000 amercader Moving this to the PDEU (publicdata.eu) project
#985 1306408134000000 amercader Duplicate of #1155 and #1156
#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
#983 1297773407000000 dread Error was tracked down to cset:214a8f9fc1c2 (26-9-2010): upgrade_db called validate_authorization_setup() which calls setup_default_user_roles(System()) Fixed in cset:9f51a1c8ac83 for 1.3 branch and merged to default.
#982 1297518386000000 anonymous Well we could transfer all the dependencies and version numbers to a config file for the fabfile, but we don't achieve much.
#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 }}}
#982 1297850732000000 anonymous This is now rolled into #963. Marking as duplicate. People can get the pip from a branch over HTTP like this: https://bitbucket.org/okfn/ckan/src/<branch-name>/path/to/file/you/want
#982 1298482394000000 dread Need to do this for older branches which isn't subject to #963.
#982 1298887980000000 dread Buildbot scripts now fixed.
#981 1297682773000000 kindly fixed see cset:3d1f720a2e5b
#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 ...
#980 1297503120000000 pudo Re package editing issue, that was a "double error" fixed by the first two changesets mentioned.
#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 1315221162000000 dread Changed the title back - it was accurate. The comment was because with formalchemy, WUI and API ran off the same 'form' code. This functionality may already be there with the new stuff, but certainly needs tests.
#979 1315222244000000 rgrp Is this already done? Is it under test?
#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".
#978 1330547181000000 zephod This was not trivial to implement. The backend supports arbitrary key/value pairings on resources, and the frontend can now handle this. Add, edit and delete resource extras according to the form state. I had to make a modification to the backend: When saving a resource, you have to submit the complete set of extras. Unsubmitted extras are assumed to be deleted. (This matches the behaviour of the package form). https://github.com/okfn/ckan/commit/a41cd0c9b04c757f5fa37acaba6be71e345a9c1f#L0R39
#977 1297420742000000 dread Fixed in cset:8809fbefaf8c for 1.3 and merged to default.
#976 1297346954000000 dread Done in cset:1566d08d529f for release 1.3
#975 1297344448000000 rgrp Fixed in cset:a4caf6b8ce3d.
#974 1297342599000000 dread Fixed in cset:9dc20731d0fd and cset:5149f503e741 for 1.3 release.
#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)
#972 1300219509000000 thejimmyg I don't really agree with this. In fact I'd rather move further away from auto-magic key value pairs stored in JsonTypes. Can we discuss on Skype please?
#972 1310134129000000 thejimmyg Having thought about this more David Raznick and I have decided to stick with separate extras for the timebeing. Mainly because of internationalisation issues.
#971 1299245064000000 sebbacon folded into #1013
#965 1297682632000000 kindly added with cset:553421d05ce8
#964 1297211237000000 rgrp Done in cset:fd0e2edf03b1
#963 1297850773000000 thejimmyg We will also remove all the different pip files as part of this fixing #982 at the same time.
#963 1298284252000000 thejimmyg You can now get CKAN from the repository http://apt-alpha.ckan.org/debian
#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.
#961 1297073658000000 dread So you also need: 4. Converting form data to dict 5. Converting dict to model i.e. the dict is not the same as the serialized form data or model data.
#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.
#961 1310126100000000 shevski The main parts of this ticket are now done. The remaining parts can be dealt with separately as their own tickets.
#960 1297080672000000 pudo Test this with a dedicated test using a unicode user name.
#960 1297169056000000 pudo fixed in cset:8cb94dcdecb2
#958 1297430414000000 dread Sorry I didn't see this and created #78. Closing this one as #978 is fuller.
#958 1297430602000000 dread Apologies, #978 is subtly different - reopening.
#958 1320664462000000 rgrp This was done as part of dataset resource editing in #1294 (duplicate)
#957 1300216958000000 thejimmyg Let's come back to this later. There are larger UKLP refactors going on. Sorry to mess you around.
#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).
#956 1299489084000000 kindly cset:1305b9192d49
#955 1296833234000000 dread Fixed in cset:9a45a07ad95e
#955 1297342534000000 dread Fixed on cset:b65b9830571c and merged into default in time for 1.3 release.
#954 1300217106000000 thejimmyg I'll look at this for a v3 API with kindly as part of the dictization. It also addresses some potential XSS issues in the API we've discovered.
#954 1300447466000000 thejimmyg What would also be really nice is a `help` key in the response which was always returned unless a query parameter of `?help=False` was sent. The help text could explain what the response meant but more importantly would show examples of other calls you can make with the IDs returned such that the whole API is discoverable without anyone ever needing to read any docs! It also means the API documentation is more likely to be up to date since it will be obvious to developers when it isn't. With help=False, the JSON can have all whitespace stripped too for production use. I also think there should be no distinction between GET and POST so that people can easily link to API calls if they want to.
← 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.