{23} Trac comments (3729 matches)

Results (1201 - 1300 of 3729)

← 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 →
Ticket Posixtime Author Newvalue
#564 1294412714000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#691 1294412765000000 thejimmyg This is more a long term idea, taking ownership for the timebeing but happy for someone else to take this on.
#743 1294412807000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#744 1294412813000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#745 1294412820000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#746 1294412827000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#747 1294412834000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#748 1294412916000000 thejimmyg Merging with #676.
#691 1294412929000000 thejimmyg If we did implement this we'd need to link new sample package to previous sample package of continuous series. So closing #748.
#748 1294412976000000 thejimmyg Sorry, that should have been #691.
#749 1294412986000000 thejimmyg Merge with #691
#691 1294413010000000 thejimmyg We'd also fold up continuous series in search results behind newest sample package. So closing #749.
#771 1294413256000000 thejimmyg This works for me. {{{ paster help }}} and {{{ paster --help }}} both show help text for me.
#772 1294413313000000 thejimmyg Merging with #770
#770 1294413390000000 thejimmyg Running CLI harvester command without arguments or with --help would return help for the harvester (currently crashes). We can therefore close #772, #773 and #774
#773 1294413400000000 thejimmyg Merging with #770
#774 1294413412000000 thejimmyg Merging with #770
#646 1294413500000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#676 1294413641000000 thejimmyg There was discussion of this on the list a few months ago, was there a conclusion?
#664 1294413696000000 thejimmyg @pudo is this still valid?
#439 1294413903000000 thejimmyg These have been agreed and are awaiting signoff.
#691 1294413993000000 thejimmyg We'd also discuss package relationships ideas with JF so closing #444.
#444 1294414008000000 thejimmyg Merging with #691
#446 1294414077000000 thejimmyg I don't understand this ticket. Since no-one has contributed to this ticket in 5 months I'm closing it.
#438 1294414132000000 thejimmyg Any idea what this ticket means? Should we mark as invalid and close? Thanks.
#442 1294414214000000 thejimmyg Is this still important? Do we need to set aside some time for it? Thanks.
#489 1294414420000000 thejimmyg Which RDF service? Why does it need model events? Will, any ideas or shall I close it? Thanks.
#538 1294414537000000 rgrp We don't use reports any more -- just the query module -- so closing as wontfix.
#865 1294414639000000 thejimmyg Isn't this in there now? Can we close? Thanks
#667 1294414834000000 thejimmyg This is something we'll shortly be looking into for DGU work anyway once we switch to the "thin" system so don't need a separate ticket for it here too. Also, the upgrade of SQLAlchmey and test performance improvements may also make this less of a problem now anyway. Marking wontfix.
#663 1294414953000000 thejimmyg This is still an issue. Who is best to look into it? Assigning to me for timebeing.
#781 1294415081000000 thejimmyg This is a duplicate of #812 so closing.
#811 1294415158000000 thejimmyg See also related extras field tickets #811 and #893
#458 1294415537000000 thejimmyg N/a anymore.
#404 1294415587000000 thejimmyg Duplicate of #896
#404 1294415965000000 rgrp This is in datapkg, not a duplicate. Partly done in fact but not complete (Indexes are now pluggable).
#489 1294416189000000 wwaites We still do need something like this. Right now the rdf generation is a cron job that crawls the API. Really we want two things: * only generate RDF for those packages that have changed * enable multiple client/worker processes, potentially run by third parties, to generate different parts of the RDF description. For example, it is reasonable that we generate the DCat representation ourselves, however the voiD authors (DCat is generic, voiD is about RDF datasets in particular) want to generate the voiD-specific annotations themselves and contribute it back to augment the catalogue. Another example: group curators may also want to annotate packages in their group with group-specific metadata. Yet another example: checks on the coherence, availability, quality, openness, etc. of a package should be done from time to time or when a package changes, which can result in further annotations (see the curate tool). Because of the "third party" aspect we cannot do this with the internal package representation and the rabbit queue. Most likely it is feasible to do this by looking at the revisions in the API to get all changes since the last time a script was run in which case most likely the answer is, yes, there is nothing to do here and the ticket can be closed.
#277 1294416367000000 thejimmyg My opinion is that having configuration in a database is a bad idea. We are currently considering moving to a system where CKAN is installable using apt-get. Since we're already moving functionality into CKAN extensions, choosing what you want kind of CKAN you would like would then be as simple as chosing the package to install. Configuring it would just be editing the config file. I don't think this is as relevant as it was 10 months ago. Anyone mind if I change this to wontfix?
#778 1294416567000000 thejimmyg This is now done.
#779 1294416581000000 thejimmyg This is now done.
#780 1294416608000000 thejimmyg This is now done.
#448 1294417061000000 thejimmyg We do this on an ongoing basis. I don't think we need a ticket for it too.
#483 1294417216000000 thejimmyg There isn't a catalogue web UI, just CKAN. I don't understand this, marking invalid. See instead #482 and #484.
#484 1294417248000000 thejimmyg There isn't a catalogue web UI, just CKAN. I don't understand this, marking invalid. See instead #482.
#482 1294417310000000 thejimmyg At some point we may want to introduce rate limiting on the CKAN API.
#371 1294417434000000 thejimmyg From #440 we'll also need to "Write and pass comprehensive performance tests"
#440 1294417436000000 thejimmyg Merging with #371. We'll do this as part of the move to the new DGU servers.
#395 1294417538000000 thejimmyg Merging with #371
#371 1294417553000000 thejimmyg From #395: At the moment, some pages within CKAN tend to load slowly. We should create a profiling setup in which we can measure response times for complete requests and individual methods calls. This could be used to identify bottlenecks and find an appropriate caching or tuning strategy to improve CKAN performance. NB: We should also agree on a maximum request latency. TODO: Read up on all those QoS tickets to avoid overlapping efforts.
#565 1294417752000000 thejimmyg OK, just looked this up. We are moving to a publisher/provider model as a first step, not moving to code lists. Marking invalid.
#853 1294594581000000 wwaites we don't need a policy document exchange. it's simpler than that. the "server" instance has already permissions to upload. it just calculates the headers and such that are needed (based on the "client"'s initial headers) and gives them to the "client" the client then uploads without knowing the "server"'s credentials. The "client" never needs any of its own goostor credentials at all. the only separate step is to make the widget readable by the world. ticket #879 is to expose this as a small set of API calls.
#879 1294604066000000 wwaites first cut: https://bitbucket.org/ww/ckanext-storage/src
#234 1294657094000000 memespring @ rgrp - No, I think I suggested something simular for adding new tags to a package though.
#812 1294658293000000 dread Just added stuff from duplicate #781
#898 1294659537000000 dread From David Raznick
#663 1294660906000000 dread This is my domain, but I suggest you don't assign it to me until it becomes important.
#442 1294661028000000 dread I'll close this now. Only thing to note is the importer code pudo wrote in ckanclient that could usefully be merged with the ckanext importer code.
#438 1294661079000000 dread This was to ensure it didn't parse ONS data on the CKAN server, which is complete.
#898 1294662408000000 dread Merged in cset:89bf917f9b46
#899 1294662417000000 dread Merged in cset:89bf917f9b46
#900 1294662424000000 dread Merged in cset:89bf917f9b46
#901 1294662466000000 dread Merged in cset:b8a649f51cab from Seb's changes.
#371 1294676093000000 anonymous Mainly handled in http://knowledgeforge.net/okfn/tasks/ticket/564 now. Close here?
#868 1294753596000000 dread I've merged in David Raznick's patches: * no_autoflush_deletes.diff cset:2b9591172182 * postgres_speed.diff cset:fa1b7e3a4e0f * vdm_purge_no_autoflush.diff vdm cset 8accdd0b9b7f I've also merged in Seb's fork: cset:68d63fda4814 which closes this ticket, achieving test speeds of under 3 minutes!
#576 1294753848000000 dread Seb's completed this now I believe. It's merged into head CKAN cset:68d63fda4814.
#876 1294753889000000 dread Seb and David have completed this I believe. I've merged the changes into core CKAN in cset:68d63fda4814.
#888 1294830297000000 Stiivi Chages to Data Proxy: * tests added with configurable list of known URLs * use brewery for transformations (included reference to brewery framework in a new vendor directory) * side effect: code to make google find external packages in vendor directory (from now on, all external packages should go there and be referenced from .hgsub if they are mercurial repositories) * changed response contents: moved from 'headers' to root, renamed 'response' to 'data', added field list as 'fields' * changed way of registering transformers (now class object is used instead of name) * added 'encoding' and 'dialect' parameters for CSV * added optional data audit (parameter 'audit') Changes: https://bitbucket.org/Stiivi/dataproxy/changeset/fccbdd275be5 Data information: http://databrewery.org/doc/data_quality.html#brewery.dq.FieldStatistics
#466 1294835610000000 dread Agreed
#870 1294862485000000 [email protected] A patch is available here. https://bitbucket.org/kindly/ckan/changeset/9a1d6f55587b
#870 1294914243000000 anonymous Merged into default in cset:54ae110094be
#897 1294914333000000 dread Same as #870
#219 1294914901000000 dread "three-column package listing" has not been prioritised for over a year now - marking won't fix.
#463 1294916148000000 dread Haven't seen this for ages.
#806 1294916284000000 dread This looks finished
#886 1294916538000000 dread Being done as part of DGU ticket: https://trac.dataco.coi.gov.uk/projects/datagov/ticket/757
#474 1294916760000000 dread Questions are out of date now
#798 1294916973000000 dread This was done a while ago.
#512 1294917121000000 dread Same as #513
#541 1294924872000000 wwaites this is implemented with the cookie javascript technique. not so suitable for pages where content is radically differerent depending on the logged in user but for small bits like the logged in status works perfectly well, likewise for edit links.
#852 1295259620000000 rgrp Removing from sprint and moving to release as a master ticket.
#838 1295259773000000 rgrp I'm going to close this ticket as almost everything done and remaining ticket can be done on its own.
#865 1295259773000000 pudo This has been fixed on the respective branch and merged into default..
#863 1295259827000000 rgrp Removing milestone as not certain when we'll do this.
#847 1295259902000000 pudo This is now functional, minus the index testing tool.
#775 1295260144000000 pudo fixed in cset:98c9997e80e8
#833 1295263447000000 rgrp Have repo https://bitbucket.org/okfn/ckanext-admin
#903 1295265645000000 pudo This is now partially solved by filtering for deleted packages. As two further measures, we should also add a package deletion method to the Solr backend and skip deleted packages when indexing.
#917 1295280232000000 dread Fixed in cset:f2865f43d8ee
#920 1295355318000000 [email protected] my first email address was wrong...
#691 1295610145000000 rgrp Most of package relationships was implemented in ticket:253 and its subtickets. Therefore closing this as duplicate.
#253 1295610188000000 rgrp Re-opening as this is a useful meta-ticket and should only be closed when all subtickets done.
#676 1295869107000000 rgrp Closing as wontfix. For dev/sysadmin documentation people can follow the link in the CKAN footer to ckan.org where we are consolidating documentation.
#930 1296062391000000 wwaites This is for HMG to prove to them that requests are being serviced in a timely manner * move this functionality to a plugin * make it use rrdtool instead of lots of itty bitty files
#930 1296070197000000 wwaites actually, this is a configuration variable ckan.enable_call_timing cleaned up the code a bit, make sure this variable unset or set to false or no and there should be no millions of files as it is unclear if this is actually used or necessary, not doing the rrdtool part just yet. if there is call for it, make a new ticket for this.
#932 1296159225000000 dread Initial work done on branch: enh_932_sql_migrate_upgrade Not working yet - hopefully kindly will be able to help tomorrow.
#832 1296334980000000 rgrp Done (~4w ago). See https://bitbucket.org/okfn/ckanext-stats and remove from core cset:311313e4afdb.
#881 1296335072000000 rgrp Closing due to lack of clarification.
#907 1296335337000000 rgrp Basic implementation done and deployed. However plenty to improve, e.g. * Support more formats (use external systems for preview?) * json (!) * html (trivial!) * sparql * ... * Do not display preview if no preview
#181 1296339510000000 rgrp Uncertain we want to do this and rather overtaken by other events, see e.g. http://ckan.org/wiki/UIRedesignHome
#844 1296340486000000 rgrp Looking at DNS this apparently has been fixed.
← 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 →
Note: See TracReports for help on using and creating reports.