{23} Trac comments (3729 matches)

Results (1601 - 1700 of 3729)

← 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 →
Ticket Posixtime Author Newvalue
#941 1298886391000000 wwitzel3 Continued work on the community plugin. I am still learning the layout of templates and how they work within ckan and getting figuring out Genshi templates so this is where most of the delay has been. I've been able to determine a pretty good plugin layout for extensions that create models. I am currently focusing on getting the rest of the UI in place and trying to determine the best way to get colander to do the desired validation beyond ensuring the form has all the elements. After todays work, I will push what I've done and I would like to walk through the design with someone at some point.
#941 1300295545000000 wwitzel3 https://bitbucket.org/okfn/ckanext-community/changeset/c26cc663fa00 I need to update the README to explain how to enable Edit and Delete now that I've integrated it with authorization in CKAN.
#941 1301909446000000 thejimmyg See also discussion on #1069 about stub datasets.
#941 1310134339000000 thejimmyg This is now implemented by pudo in publicdata.eu. For the portal case, apps and ideas will come from Drupal so we no longer need this ticket.
#942 1296499160000000 pudo fixed in cset:81a0f5538a5b
#943 1297076498000000 rgrp Done see http://wiki.ckan.net/
#944 1298571917000000 pudo Won't work on this for now - IATI is now running against plain CKAN but this is not deployed. We will continue work on this once IATI requests more functionality and shelf it for now.
#944 1306774766000000 pudo done at iati.ckan.net
#945 1301909147000000 dread Moving super ticket to 1.4 milestone
#945 1325259350000000 rgrp Closing as all subcomponents now done. (parts of this duplicate the other super ticket #1032). Also move to ckan-v1.6 as that is when last parts were done.
#946 1296833368000000 dread Fixed in cset:a30c31b9009d
#947 1314031310000000 dread This was done in #1025 through configuration. Happily you can setup config in an extension, so covers this ticket's aims too.
#948 1300271009000000 sebbacon I would propose a "trash can" model: a "deleted items" area where only deleted items can be viewed / searched. Deleted items should not appear anywhere else, but we could include a "also search deleted items" option in the search for admins. (In which case, deleted items should have a "div class='deleted'" or similar so they can be highlighted with CSS).
#948 1300271100000000 dread This sounds like a good solution to me. This should include not just packages, but groups and all other stateful objects.
#948 1300271268000000 dread There's also the API to consider. One edge case to consider too - currently we don't allow reuse of the name of a deleted package, which is confusing. The deleted package should be moved aside (renamed), unless the deleted package is entirely the same as the new or renamed package.
#948 1300385979000000 sebbacon Emptying the trashcan (which would amount to purging deleted objects) would probably be a function of the administrative dashboard #833
#948 1300728602000000 dread We have a use case now for DGU where if a user requests a deleted package, he is 302 redirected to another package (specified in the deleted package's extras). This is for the API, but could also be done in the Web UI if deleted packages are hidden away in a trashcan. But this suggests we need a trashcan in the API too. i.e we should keep the data model really synchronised between the Web UI and API, (even if they are becoming divorced from the ORM Model - or maybe we should have a trashcan in the ORM model too?) Ideas: * GET api/rest/package - lists active packages * GET api/rest/package/traffic_data - active package * GET api/rest/trash/package - lists deleted packages * GET api/rest/trash/traffic_data_old - deleted package
#948 1314112642000000 dread Note: Packages will now be excluded from the search view (see #1283). Also there is now no redirect requirement from DGU any more.
#948 1323172859000000 thejimmyg Re-assigning to me temporarily to investigate now that Seb has left.
#949 1296730355000000 pudo Fixed in: * https://bitbucket.org/okfn/ckan/changeset/8017a6686838 * https://bitbucket.org/okfn/ckan/changeset/5e6634aab275
#949 1297074827000000 rgrp Hocus pocus so set owner after being fixed!
#950 1296732042000000 dread Done in: * ckan cset:e68d0704e57b * ckanext cset:0d7d223e4302 * dgu cset:c633d2608c29 Importer controller now in new repo ckanext-importer (mothballed)
#950 1297076647000000 rgrp Reopen to set an owenr.
#951 1314031006000000 dread Specific problem explained by having two users with the same name - one was authorized and one wasn't. See: http://lists.okfn.org/pipermail/ckan-dev/2011-April/000550.html
#953 1296809834000000 rgrp Done in cset:3275d2fc9e43
#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.
#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.
#954 1310134531000000 thejimmyg See also this proposal about "inlining" extras fields #972. David Raznick and I have also agreed that for API 3, each call to the logic layer will return an object (basically a dictionary) rather than using Exceptions. This means the return values from the logic layer can exactly mirror the JSON data strucutres returned via the API. The help values can come from the docstrings of the logic layer functions.
#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?
#954 1320142744000000 kindly This is basically the complete now with documentation. The child tickets no longer seem to fit and are not essential for completion.
#955 1296833234000000 dread Fixed in cset:9a45a07ad95e
#955 1297342534000000 dread Fixed on cset:b65b9830571c and merged into default in time for 1.3 release.
#956 1299489084000000 kindly cset:1305b9192d49
#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).
#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)
#960 1297080672000000 pudo Test this with a dedicated test using a unicode user name.
#960 1297169056000000 pudo fixed in cset:8cb94dcdecb2
#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.
#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.
#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
#964 1297211237000000 rgrp Done in cset:fd0e2edf03b1
#965 1297682632000000 kindly added with cset:553421d05ce8
#971 1299245064000000 sebbacon folded into #1013
#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.
#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)
#974 1297342599000000 dread Fixed in cset:9dc20731d0fd and cset:5149f503e741 for 1.3 release.
#975 1297344448000000 rgrp Fixed in cset:a4caf6b8ce3d.
#976 1297346954000000 dread Done in cset:1566d08d529f for release 1.3
#977 1297420742000000 dread Fixed in cset:8809fbefaf8c for 1.3 and merged to default.
#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
#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?
#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.
#981 1297682773000000 kindly fixed see cset:3d1f720a2e5b
#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.
#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.
#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
#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
#986 1297812401000000 wwitzel3 https://bitbucket.org/okfn/ckanext-qa/src/be57e20c60ef/
#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.
#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...
#990 1311180850000000 thejimmyg This now works.
#991 1298037717000000 dread Fixed in cset:56cccbbb9d1a in time for ckan 1.3 release. This did not affect previous releases.
#992 1298060474000000 rgrp Fixed in cset:08548ef8f0e9
#993 1298373114000000 dread Fixed on 1.3 cset:7708c8b521ed and merged to default. Deployed to ckan.net.
#994 1298912830000000 kindly see cset:93188d42fc12
#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
#996 1300364398000000 thejimmyg This is now fixed, the outcome will be used to inform #995 for the caching.
#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.
#999 1300707328000000 rgrp Done. See https://bitbucket.org/okfn/ckan-ckan.net and updated ckan.net.ini.
#1000 1298912726000000 kindly fixed cset:630513f550d5
← 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 →
Note: See TracReports for help on using and creating reports.