{23} Trac comments (3729 matches)

Results (901 - 1000 of 3729)

← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 →
Ticket Posixtime Author Newvalue
#1734 1332167315000000 amercader All sub tickets have been implemented, so closing it now.
#1819 1332163324000000 kindly Currently using package_show_rest. Should be moved to just use package_show but that is another ticket.
#2226 1332159640000000 seanh These deployment docs seem worth moving into sphinx as well: http://wiki.ckan.org/Deployment
#2236 1332153688000000 rgrp Done. See https://github.com/okfn/ckan/commit/0d970d3a0e523a1695830e8c8c28c0ba10a8d8b9
#2212 1331720191000000 johnglover Deployed on test server, where it imported 4087 datasets. A small number of datasets were not created as they failed CKAN validation - most of which had strange values such as 9999 and 0 for date fields (some also didn't have unique names).
#2212 1331719868000000 johnglover Added as a new paster command in ckanext-ecportal (run 'paster ecportal' for a list of commands and arguments).
#1831 1331655458000000 ross Decided to delay this until later but code is in feature-1831-login-by-email
#2221 1331561095000000 ross Fixed in https://github.com/okfn/ckan/compare/1eeda11...ad2358a
#2223 1331558791000000 rgrp Have introduced boostrap js and css on merge of #1797 https://github.com/okfn/ckan/commit/476a5bd32a3fac5d2dd85614f5d86c79f4ff6547 However need to remove blueprint and make sure we keep our original theme.
#2209 1331551393000000 ross Can't edit comments .. so Current thinking is that option 4 is a default (as per ckanext-rdf) rdf output that is generated not in code (as currently) but using a genshi xml template to read the package into an RDF format (as if it were HTML). This would then be overrideable so that for ecportal where the format of the RDF is different (change of vocabs etc) we can just point the config to a new template. Pros: Easy to implement Easy to use Not hard-coded as currently Fast execution Cons: Requires knowledge of required RDF output if default is not useful RDF and not any of the other formats yet. Only works with package/resource/tags unless more work is done
#2209 1331551170000000 ross Current thinking is that option 4 is a default (as per ckanext-rdf) rdf output that is generated not in code (as currently) but using a genshi xml template to read the package into an RDF format (as if it were HTML). This would then be overrideable so that for ecportal where the format of the RDF is different (change of vocabs etc) we can just point the config to a new template. Pros: Easy to implement Easy to use Not hard-coded as currently Fast execution Cons: Requires knowledge of required RDF output if default is not useful RDF and not any of the other formats yet. Only works with package/resource/tags unless more work is done
#1649 1331550598000000 rgrp Can you elucidate on this template idea? I was thiking we want specification/configto be in the form of mappings (e.g. field X is really type Y etc rather than a specific piece of rdf/xml or n3) though perhaps that makes more sense. Let's centralize discussion on this in #2209.
#2210 1331549350000000 ross This is now done through the logic layer member_create/member_list/member_delete
#1831 1331549284000000 ross Email is not currently 'unique' in the user model. Find out if this is intentional or not.
#2209 1331547674000000 ross Previous comment should read: Option 4 is the most appealing at this point, although you probably should look at #1649
#2209 1331547639000000 ross Option 4 is the most appealing at this point, although you probably should look at #2209
#1649 1331547577000000 ross After looking at some options via http://trac.ckan.org/ticket/2209 I think a simple RDF template or triple in an internal ckanext-semweb might indeed be the most appropriate way forward with this. n3 sounds useful, but given we could allow people to specify an RDF template we may as well do that as well as it would then suffice for ecportal who appear to want rdf as well. Will check out json-ld as an option too.
#1400 1331544816000000 johnglover I'll have a look thanks. I'm +1 on using main docs instead (if we move everything), I was just trying to keep things consistent for now.
#1400 1331544485000000 rgrp Hmmm. Emerging consensus from discussions in last few months is that wiki is fairly confusing and we should move core, solid docs (from whichever area) to the main docs. Furthermore, key dev info like how to setup and do extensions *is* already in the main docs (see http://docs.ckan.org/en/latest/writing-extensions.html) and has been for 6m+. I've created #2226 for more work on docs and you may wish to comment there.
#1400 1331543941000000 johnglover I thought that we had some sort of consensus that the official docs were aimed more at system admins and people using the CKAN WUI/API, with the wiki aimed more at developers? It would be easy to move of course, but there is no real "developers" section in the official docs that I can see, and it's even called "CKAN's Administration Guide".
#1400 1331481461000000 rgrp Great to see this is done. I do have one question: why did we put this on the wiki rather than in the proper CKAN docs? In general, I think it would be better to use the wiki less and our proper docs more ...
#1797 1331412644000000 rgrp Merge fix https://github.com/okfn/ckan/commit/476a5bd32a3fac5d2dd85614f5d86c79f4ff6547
#1797 1331412469000000 rgrp All done!! Help for data api done in https://github.com/okfn/ckan/commit/1d8e464f8542d4c33286bb93f4de50060665799f Checkbox for datastore enabled in https://github.com/okfn/ckan/commit/3f1320cd92ae0e775fde1b5eada156260c55e0a6
#1816 1331302835000000 amercader +1 to a new, more flexible extension. But in the meantime I've just spent a couple of hours making it work with latest CKAN, which was easier than expected, so we can deploy it with the new version of PDEU.
#1806 1331295310000000 toby closing as initial work has been done if we need to amend then create a new ticket
#2220 1331291241000000 toby issues: 1) want to cache static files long term - need to add a ?ver=xxx to allow changes - this will need a change to all templates etc - could be seen as a good thing 2) we can only purge specific pages not whole cache so we need to know all the urls which want to be invalidated - including language variants 3) urls should be consistent so we should use id not name for datasets etc 4) for now we can just use short expiry times as this prevents some of these problems
#1703 1331142926000000 johnglover Marking this stage as complete. Keywords can be added/updated via WUI and API, but are still labelled 'tags' when called via package_show API call, but this will be addressed in a separate ticket.
#2206 1331046486000000 johnglover Close enough for now. Still have to restyle language drop-down to match template, but will fix when updating the list of languages. Also still to decide on menu styles/locations (for CKAN login and main menu, and ODP main menu).
#1831 1330956631000000 ross Already have a branch for this.
#1703 1330956340000000 johnglover Nearly done, need to write converter to rename tags to keywords, waiting for Toby's API work to be finished.
#1731 1330942924000000 amercader The underlying auth layer is done, still there isn't UI integration (list of publishers in index page, publisher field in form...). Needs to be moved to the next sprint.
#1806 1330942356000000 toby version one completed
#1753 1330908337000000 rgrp As of today kindly has this working in https://github.com/okfn/ckanext-webstorer/tree/webstorer-for-datastore and deployed on the DataHub. Need to merge into master and to possible rename of extension, update docs and we are done.
#1737 1330908235000000 rgrp Did not get to this sprint as focused on #1797.
#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.
#1797 1330863639000000 rgrp Data Viewer support for new DataStore in https://github.com/okfn/ckan/commit/9ab8b0283bb086eb4cd663ff73c27066bdd3c79a
#1654 1330863104000000 rgrp I'd vote -1 on SPARQL endpoint and doing the simple version of #1649 as proposed in my comment http://trac.ckan.org/ticket/1649#comment:2
#1816 1330863079000000 rgrp As per detailed comments in http://wiki.ckan.org/Proposals#Apps_in_CKAN I think Apps is a confusing name. What we are talking about here is the "Related Stuff" item mentioned in that ticket. Rather than update ckanext-apps I suggest we do a rewrite. I've created a detailed super ticket at #2204 and assigned to you Adria for review and thoughts. (While I understand #2204 may involve more work which we maybe cannot do before relaunch I'd still recommend starting on that rather than spending time upgrading this extension -- if we have to disable it for relaunch I don't think that is a big deal ...)
#1649 1330860766000000 rgrp A general comment: I wonder if we can pull the *core* part of that extension into core and strip out any external dependencies like rdflib. Specifically the 80% use of this extension is the DCAT read/write: * Get a Dataset / Resource etc as DCAT RDF (I'd suggest we *just* supply something simple like n3 or even json-ld (see below)) * (Possibly not even essential) Consuming Dataset info in that format And even more radical solution would be to simply use json-ld: http://json-ld.org/ which would then just involve minors mods to our json output. Having this in core (with option to enable?) would be a nice 80/20 (it was this feature that everyone asked for at the LOD meetup -- no-one mentioned SPARQL).
#1807 1330809641000000 seanh Implemented the recently-changed-datasets activity stream on branch feature-1807-recently-changed-datasets in CKAN and merged it into master (but the default templates don't make use of it). Added the recently-changed-datasets activity stream to the front page template on branch master in ckanext-ecportal.
#407 1330769956000000 rgrp Long out of date ...
#2201 1330765400000000 rgrp Duplicate of #1171.
#1788 1330644056000000 rgrp Re the Upload file button not sure what's best. We do have plans to replace jquery-tmpl with mustache in the near future (but not clear exactly *how* near). We'll think about this and get back to you. Thanks for the detailed debug report.
#1648 1330632344000000 zephod Done in the #1506 branch
#1788 1330624155000000 zydio Erh...sorry for some formatting errors in my comment. I used markdown formatting for links, and used the #NUMBER format to cite issues, which obviously is interpreted by Trac as references to his own issues...my bad.
#1788 1330623913000000 zydio Replying to [comment:1 rgrp]: > Believe most of these are resolved by https://github.com/okfn/ckan/commit/27f4fc776b9199621d259749cf20787328df101f > > @zephod: could you check again and see if anything remains? I noticed that Thedatahub with latest code is still messed up..I was working with absolute paths in my environment without the h.url_for_static() to include the html5shiv.js script so I missed a problem, which can be fixed with my new [pull request #4](https://github.com/okfn/ckan/pull/4). I'm aware of only one problem left: when you hit the "Upload a File" button inside the Dataset Edit/Resources tab nothing happens in IE < 9. This is related to those IE versions not being able to dynamically insert HTML 5 tags, which breaks some jquery-tmpl (actually JQuery) operation (if you debug the code everything works in jquery-tmpl until one of the latest operation involving JQuery returns null instead of the expected object). I was able to fix the issue in my environment by adding the following conditional comment: {{{ </script> <!--[if lt IE 9]> <script type="text/javascript" src="/scripts/jquery.html5.preie9fix.js"> </script> <![endif]--> }}} where the jquery.html5.preie9fix.js is simply the [gist](https://gist.github.com/887560) published by Akkuma in a [jquery-tmpl issue (#36)](https://github.com/jquery/jquery-tmpl/issues/36#issuecomment-918495). This script patches JQuery on the fly on IE < 9 to rework in memory html 5 blocks handled by JQuery, so that it doesn't break. And this fixes the "Upload a File" button on IE. I didn't commit/pull this specific fix for the following reasons: * the script embeds innerShiv, which is a previous incarnation of html5shiv (now included in CKAN). It doesn't sound fine to include 2 pieces of code with similar effect, but I couldn't reproduce the fix with html5shiv! * in my environment I have included this fix sitewide even if I didn't spot other problematic features..I don't know if it would be better to include it only on the dataset edit page in the official CKAN code. Summary: I leave to you guys the choice on how to deal with this problem.
#1670 1330603657000000 ross Explanation of how to work with the auth profile now at http://wiki.ckan.org/Working_with_the_publisher_auth_profile Needs reading/testing. Started admin guide documentation in branch feature-1670-publisher-profile-docs
#1797 1330550304000000 rgrp New API endpoint, Authorization and documentation done and merged to master. Time so far. 1.5d. https://github.com/okfn/ckan/commit/a054071e2e29e70e7cfa69df8c117ad5d5871a24
#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
#1809 1330528828000000 johnglover Caught exceptions in QA instead, error message stored as openness_score_reason
#1828 1330525412000000 rgrp Fixed in https://github.com/okfn/ckan/commit/e6da48d9337575a83bc6a30896e68d1081b43847
#1400 1330524586000000 johnglover Async task docs are at: http://wiki.ckan.org/Writing_asynchronous_tasks Archiver readme at: http://github.com/okfn/ckanext-archiver Emailing Mark RE blog post.
#1744 1330349472000000 zephod Massive refactor of parent ticket mean this is all done and can be closed off. See #1506 for remaining UX work.
#1032 1330348463000000 zephod Streamlining supertickets. #1506 is the new parent of #978; all tasks remaining in this ticket are complete.
#1804 1330347185000000 toby This has been fixed in master for a while and was only a 1.6 issue
#1788 1330111162000000 rgrp Believe most of these are resolved by https://github.com/okfn/ckan/commit/27f4fc776b9199621d259749cf20787328df101f @zephod: could you check again and see if anything remains?
#1830 1330089912000000 dread Now if you set openid_enabled to false, you are not given the option in user settings to associate your account with openid. Cset: [master b295bde] I looked at removing the openid middleware, but we use it for logging out users, whether they logged in or not - it looks like friendly form plugin is not as good as the openid one in this respect! We could hack the logout function into the friendly form to sort this out, but not sure the effort is worth it at the moment.
#1447 1330089662000000 nils.toedtmann OK i fixed a bug in my script and refactored it so that it can now be dropped into /etc/cron.daily/ while still deleting as unprivileged user. It is now running on s025, removing everything older than 7 days. Please verify in 9 days or so that it's working. Consider to add [https://bitbucket.org/okfn/sysadmin/src/default/etc/cron/remove_old_files this cron job] to the ckan deb package e.g. as "/etc/cron.daily/ckan-cleanup"
#1717 1330088539000000 zephod 1. Already exists; "tags:csv" rather than "tag:csv" 2. Format is user selected; we just show the most popular choices. Perhaps an effort should be made to force people to homogenize their format choices (my work with automatic icons will do this to an extent). Also, res_format doesn't appear on thedatahub.org, but for some reason it does on test... 3. There are thousands. We just show the most popular/relevant tags for your search. This could break out into another ticket though - eg. autocompleting tag input on the page? 4. Can't remember what this is... 5. I did this a while ago and popular opinion was that it should change back. This gives us room for expanded options like on thedatahub's live search page right now, and matches the layout of the Groups view page. 6. They should maybe be ordered by relevance, which includes popularity in some metric? This should be broken into a seperate ticket if you want it to go ahead and given to a Solr expert.
#1515 1330086273000000 dread The main body of this went into CKAN 1.6, including: #1298, #1299, #1495, #1511, #1623, #1631, #1637, #1663, #1666, #1686, #1639, #1694
#1396 1330086237000000 dread Went into CKAN 1.6
#1738 1330086105000000 dread Cset is actually dd2c0c677117f06a52aa22b3b2717bb605263570 and went into CKAN 1.6
#1630 1330085600000000 dread Went into CKAN 1.6
#1701 1330085360000000 amercader Sorry, this ticket referred to the EC Portal project, the changesets are from ckanext-ecportal. This hasn't gone into core yet, which is ticket #906
#1425 1330085282000000 dread Went into CKAN 1.6
#1695 1330085001000000 dread Went into CKAN release 1.6
#1701 1330084925000000 dread I can't find these changesets - am not sure which release this is in.
#1521 1330084599000000 dread This went into CKAN 1.6
#1547 1330084379000000 dread Went into CKAN 1.6
#1283 1330083933000000 dread This went into CKAN 1.6
#1657 1330083881000000 dread c.f. "Mounting CKAN at a non-root URL" at http://wiki.ckan.org/Deployment
#1462 1330083671000000 dread This went into CKAN 1.5.1.
#1101 1330082908000000 dread Stats already in site nav - adjusting title to just mention google analytics.
#1447 1330082808000000 dread Yes please Nils!
#1447 1330082636000000 nils.toedtmann I had forgotten to check s019 how well my cleanup script is working (and now s019 is gone), but at least it didn't destroy it :-) You might want to give it a try on s025/PDEU. (Tell me if you want me to do that).
#1682 1330038786000000 dread Now merged into #1605
#1605 1330038773000000 dread #1682 now merged in
#1804 1330037202000000 dread Fixed this on release-v1.6 in cset 557e72330db7. Spent 0.5h. Reassigning for Toby to look at branch feature-1653-i18n_url_rewriting
#1608 1330036982000000 dread This has gone into CKAN 1.6
#191 1330020983000000 dread Replying to [comment:15 dread]: > Went into CKAN 1.6 Sorry, I meant 1.5.1
#1518 1330020742000000 dread Fix went into CKAN 1.6
#191 1330020677000000 dread Went into CKAN 1.6
#1491 1330020630000000 dread went into CKAN 1.6
#1536 1330020599000000 dread Went into CKAN 1.6
#1413 1330020486000000 dread Went into CKAN 1.6
#1528 1330020444000000 dread Went into CKAN 1.6
#1450 1330019974000000 dread In CKAN 1.6.
#1445 1330019916000000 dread This went into CKAN 1.6
#1236 1330019788000000 dread Went into CKAN 1.4.3
#1829 1330001828000000 dread This was due to https://github.com/okfn/ckan/commit/f07bfdb9#diff-1 - string "Language has been set to: English" shouldn't have been translated. I've put in a patch to make the code intentions clearer and added a test: [release-v1.6 07d3a02]. This only affected the 1.6 beta, and is fixed for the release.
#1804 1330000705000000 dread I'll fix this on release-v1.6 and then reassign to Toby to fix on feature-1653-i18n_url_rewriting too if the same issue crops up there.
#1799 1330000389000000 dread Fixed in [master ea2d824] for both logging in and registering whilst logged in. Cherry picked to release-v1.6
#1703 1329918613000000 johnglover Some metadata model info clarified at meeting today, will update ckanext-ecportal accordingly.
#1811 1329918517000000 johnglover Deferred for now, moving to backlog
#1810 1329918479000000 johnglover Deferred for now, moving to backlog.
#1737 1329916781000000 dread SOLR syntax is already accepted in: * api/3/search/package * Action API "package_search" Actually api/1/search/package and api/1/search/package accept SOLR syntax too, but they also translate old-CKAN search parameters syntax to SOLR as well. See: http://docs.ckan.org/en/latest/apiv3.html
#1802 1329830097000000 dread * Refined install without using Cygwin - this seems a little easier. * Added example Apache & modwsgi deployment. * Documented extensively at: http://wiki.ckan.org/CKAN_install_on_Windows * Have not tried SOLR on Windows - I'm not convinced this is high priority, and normal install should be fine as it is so separate from CKAN. Spent another 0.5d. Total spent 2.25d
#1805 1329760795000000 toby this is fixed in branch feature-1653-i18n_url_rewriting
#1469 1329760150000000 amercader This is mostly done (current form is http://i.imgur.com/zmfc5.png). Still some tests missing and a little bit of cleanup and documentation required.
#1553 1329755702000000 rgrp @ross: this is indeed the issue (and I explained this to dread but failed to note here). I suggested this was a limited problem as most sites would not allow anonymous editing (which is where this occurs). However, it is a UX bug for that situation.
← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 →
Note: See TracReports for help on using and creating reports.