{23} Trac comments (3729 matches)

Results (2301 - 2400 of 3729)

← 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 →
Ticket Posixtime Author Newvalue
#929 1297686088000000 thejimmyg The licenses service was down, it is back up now. We should be able to cope with this situation better though. Renaming the ticket.
#738 1297685069000000 thejimmyg It may be handy to have a history of harvested documents and also be able to delete documents but still get their revisions. The package comparison code will need to look at these revisions.
#496 1297684298000000 thejimmyg The latest plan after update with PP is as follows: * CKAN will have a CSW interface * OS GenoNetwork will use this interface to determine: * New documents * Modified documents * Removed documents * OS will then handle the serving back to the EU since GeoNetwork already implements the custom filters the EU may require (their docs are ambiguous). This means the creation of the CSW server extension is now a high priority but it only needs to know about documents in the harvested_documents table. I've already implemented a REST API to get the those documents (but depending on the implementation it may need changing).
#981 1297682773000000 kindly fixed see cset:3d1f720a2e5b
#965 1297682632000000 kindly added with cset:553421d05ce8
#984 1297682116000000 kindly fixed see https://bitbucket.org/okfn/ckan/changeset/d56ea86d4303
#877 1297680579000000 rgrp Basic pass on an implementation (no permissions yet etc): https://bitbucket.org/okfn/ckanext-upload/changeset/9ae543f0645f
#810 1297679091000000 pudo At the moment, this crashes the groups field for some mysterious reason. Since this is going to be redundant with the new forms and the ticket has a low priority, I'm bumping this back 2 weeks.
#962 1297678925000000 rgrp In progress but not yet completed so moving to next sprint. Estimate remaining time at: 2h.
#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)
#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
#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 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.
#980 1297503120000000 pudo Re package editing issue, that was a "double error" fixed by the first two changesets mentioned.
#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 ...
#958 1297430602000000 dread Apologies, #978 is subtly different - reopening.
#958 1297430414000000 dread Sorry I didn't see this and created #78. Closing this one as #978 is fuller.
#826 1297429910000000 dread Merged into default in cset:613d7bd5fc96. Future tickets in this area include: * #978 Full edit in Web UI * #979 Edit Resource extras in the API
#826 1297423342000000 kindly This would be too much of a hack. You do not want users overwriting any attributes on the object. If they called the attribute "__init__" it would write over the actual __init__.
#826 1297421022000000 dread Ah - I understand. I'd like it if you could make all the extra fields work as attributes and be searchable - is that possible?
#977 1297420742000000 dread Fixed in cset:8809fbefaf8c for 1.3 and merged to default.
#826 1297417900000000 kindly I forgot to mention that he main advantage of the fixed fields, is that we can make them properly searchable i.e the values searchable. This currently does not work for package extra values as they are jsons. I have added this searchability for the sql backend.
#826 1297416879000000 kindly There is nothing to stop anyone from putting any extra attributes in the extra_info field dict. So any have the flexibility you need. The config option is to add some fields that act in exactly the same way as python attributes, having the same semantics as them. i.e if you have an extra field called alturl, you can do obj.alturl = 'fdsffs'. This is the best of both worlds as far as I can tell.
#826 1297415095000000 pudo I want to strongly support david in his call for fully flexible extras: one of my use cases for them is to store the various bits of fallout from an archiving process, such as: * last-status * last-crawled * last-etag * last-expires * last-md5 * failure-count * fall-back-url These are things needed to really archive the data well, but they have nothing to do with CKAN core ops. Essentially, the archiver is a seperate concern and it need not appear in the CKAN config.
#826 1297414412000000 dread It's great that the extras are added in-line with other Resource properties (as opposed to package extras which are a dict not off 'package' but off 'package.extras'). However, the resource extra field keys are defined in config option "ckan.extra_resource_fields". This config option should be removed - extras need to be entirely flexible for our purposes. (In the next ticket we should make it possible to add/remove both keys and values from the Web UI or API.) It would also be good to tidy things in this direction: http://wiki.okfn.org/Coding_Standards I've merged from default to the branch enhancment_826_resource_extra_fields ready for you.
#682 1297358266000000 dread Various improvements to ckanclient to enable this: cset:1bfefd7596d3 and cset:47fd07087547 and installed on buildbot now.
#933 1297348975000000 dread Done on enh_933_get_rid_self_in_cls_meth and merged into default cset:5750c77e580d ready for ckan 1.4.
#569 1297347214000000 thejimmyg This is now complete in ckanext-csw.
#976 1297346954000000 dread Done in cset:1566d08d529f for release 1.3
#92 1297344859000000 rgrp wontfix at the moment as we have the separate RDF service and RDFa is probably not the best option as always a bit incomplete.
#662 1297344790000000 rgrp Now part of 'model/validation/forms' meta-ticket #961 so reassigning to Seb.
#975 1297344448000000 rgrp Fixed in cset:a4caf6b8ce3d.
#974 1297342599000000 dread Fixed in cset:9dc20731d0fd and cset:5149f503e741 for 1.3 release.
#955 1297342534000000 dread Fixed on cset:b65b9830571c and merged into default in time for 1.3 release.
#665 1297268097000000 thejimmyg The latest version of the DMS collection interface spec says that this should be a manual process. No work to be done.
#232 1297246297000000 thejimmyg This has been here for over a year and is not a technical ticket. Suggest we close it?
#941 1297246005000000 thejimmyg This will be implemented in http://bitbucket.org/okfn/ckanext-community by Wayne.
#405 1297214833000000 rgrp (That is did the interactive version)
#405 1297214793000000 rgrp Completed in cset:a7df5071f200
#964 1297211237000000 rgrp Done in cset:fd0e2edf03b1
#405 1297211204000000 rgrp By mime-type and all resources done in cset:7bd693614c80 and previous (with other improvements to download system).
#171 1297210925000000 rgrp A lot of work on config was done in 0.7 and these refactorings and improvements either fix or render this ticket invalid so marking as fixed.
#98 1297210774000000 rgrp Done in cset:b7d8786614c0 - removed pastescript and just do 'by hand'.
#569 1297177695000000 wwaites *sigh* again. the gemini schematron schema isn't compatible with the amara scimitar... despite the instructions to use the implementation from schematron.com...
#569 1297177522000000 wwaites *sigh* but it relies on 4suite in version 1.x and amara2 doesn't have the schematron anymore...
#569 1297177220000000 wwaites so this means a dependency on amara (finally). on the plus side it is one of the better xml python libraries, xpath, xslt, etc. on the down side it how many xml libraries do we depend on and use now? this is for the schematron...
#960 1297169056000000 pudo fixed in cset:8cb94dcdecb2
#928 1297115136000000 rgrp Forgot to say moved contributors material to http://ckan.org/wiki/Contributors for the time being.
#928 1297115097000000 rgrp Fixed in cset::540e8e548d84
#875 1297085261000000 pudo So far opting for route 1) (not implementing facets), therefore this can be closed!
#560 1297084192000000 kindly changeset https://bitbucket.org/okfn/ckan/changeset/b899085071a8 cset:b899085071a8
#99 1297081088000000 rgrp Won't fix as we are not using sqlalchemy any longer.
#960 1297080672000000 pudo Test this with a dedicated test using a unicode user name.
#902 1297078885000000 rgrp Fixed in cset:42102bf7f922 and cset:42102bf7f922 by switching to a new 'tabs' look that has none of these issues. (See branch feature-902-submenu).
#950 1297076647000000 rgrp Reopen to set an owenr.
#943 1297076498000000 rgrp Done see http://wiki.ckan.net/
#809 1297075561000000 thejimmyg This is something to think about more in the future.
#807 1297075372000000 rgrp wontfix as with traffic we have this is not a massive issue and these are very minor items (we can reopen later if this comes up again).
#511 1297075354000000 thejimmyg There have been quite a lot of improvements, this is now OK.
#366 1297075053000000 rgrp Now #938 is done this is straightforward.
#949 1297074827000000 rgrp Hocus pocus so set owner after being fixed!
#409 1297074067000000 rgrp Done item (2) http://packages.python.org/datapkg/extending.html#commands and Command class is already pluggable.
#817 1297073724000000 thejimmyg This appears to be fixed now.
#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.
#404 1297072955000000 rgrp Nothing more required here I think.
#907 1297072303000000 rgrp Closing this now and improvements can go in a new ticket.
#940 1297071748000000 rgrp Listing as wontfix now since: 1. Have workaround 2. Better for most sites to converge on a single domain anyway (for SEO etc) -- via std redirect approach or otherwise 3. Seems problematic to fix this via openid realm
#667 1297069121000000 rgrp Actually marking as wontfix!
#205 1297068450000000 rgrp wontfix as: 1. Easier to just to an import from google docs for which we have several importer examples in ckanclient 2. (More important) importing is something that is quite bespoke (changes for each cirumstance). As a result pre-written importers tend to be very fragile and it is not a good use of time to try and some customizable WUI one when you can just write a custom importer in code (code is much more flexible than whatever we can write!)
#916 1297066902000000 rgrp Moved to https://bitbucket.org/okfn/vdm/issue/4/port-new-vdm-to-mongodb
#776 1297066840000000 rgrp Moved to https://bitbucket.org/okfn/vdm/issue/3/avoid-generating-vdm-warnings
#246 1297066757000000 rgrp Moved to https://bitbucket.org/okfn/vdm/issue/2/support-for-primary-key-not-named-id
#245 1297066620000000 rgrp Closed in favour of https://bitbucket.org/okfn/vdm/issue/1/support-for-composite-primary-keys
#930 1297066292000000 rgrp Just want to agree with wwaites assessment here. dubious this code is currently useful as a) not used b) (more importantly) probably better ways to achieve this functionality.
#946 1296833368000000 dread Fixed in cset:a30c31b9009d
#955 1296833234000000 dread Fixed in cset:9a45a07ad95e
#953 1296809834000000 rgrp Done in cset:3275d2fc9e43
#940 1296807699000000 rgrp I agree with pudo (though it would not be the end of the world if these were treated as the same realm!). I've now created a permanent redirect for www.ckan.net to ckan.net. {{{ RewriteEngine on RewriteCond %{HTTP_HOST} ^www\.ckan\.net$ [NC] RewriteRule ^(.*)$ http://ckan.net$1 [R=301,L] }}}
#938 1296753055000000 pudo fixed in https://bitbucket.org/okfn/ckan/changeset/064d74a1ead8
#950 1296732042000000 dread Done in: * ckan cset:e68d0704e57b * ckanext cset:0d7d223e4302 * dgu cset:c633d2608c29 Importer controller now in new repo ckanext-importer (mothballed)
#908 1296730578000000 pudo I've moved the uswgi/nginx part to #952, closing this issue since the problem it describes has been fixed.
#949 1296730355000000 pudo Fixed in: * https://bitbucket.org/okfn/ckan/changeset/8017a6686838 * https://bitbucket.org/okfn/ckan/changeset/5e6634aab275
#48 1296663361000000 rgrp Done in cset:2a056fce7798.
#908 1296660052000000 wwaites Not fixed. Try running with: {{{ uwsgi -C -iH /path/to/your/pyenv --paste config:ckan.net.ini -s 127.0.0.1:9000 }}} Still get giant traceback relating to a circular import centered on an arbitrary plugin
#908 1296659056000000 pudo fixed in https://bitbucket.org/okfn/ckan/changeset/08c0e1a819e4 and https://bitbucket.org/okfn/ckanext-stats/changeset/6e86c071db99
#940 1296656433000000 pudo It seems like even with openid.realm set we could only create two "zones": *.ckan.net and ckan.net. We do not want *.ckan.net because it interferes with ccCKANs. My vote for the moment would be to 303 www.ckan.net to ckan.net.
#902 1296638257000000 rgrp Also confirmed in FF. David (R) and I have both had a go and fixing this and it seems to be a bit tricky (very odd css behaviour!). Rather than directly fix this I'm thinking of doing a bit of rework of that set of menu tabs as they could be much nicer anyway and hence re-titling of this ticket.
#926 1296637927000000 rgrp Comments from RP - http://lists.okfn.org/pipermail/ckan-dev/2011-January/000181.html Libraries I have used: FormEncode, FormAlchemy (what we are currently using, before that formencode). Neither seemed perfect but I think the form issue is a 'hard' problem (perhaps with no perfect answer) [1]. FormAlchemy, in retrospect, was probably a mistake as it merges too much model/validation/form generation into one thing. At least 3 functions involved: 1. Generating (or just filling) a form template with 'form data' (and errors) 2. Converting model data to form data (also happens for APIs in fact) -- let's call this 'dict-ization' 3. Converting form data to model data (and validating) (inverse of previous step) I think one can and should separate 1 from 2+3 (and one of problems with formalchemy is it doesn't -- the attraction being you don't repeat yourself as forms get generated from model but I think this is actually a false economy in medium-term). I'm not specifically recommending the following as I haven't used them but I've looked through docs, they are active and reasonably mature: 1. Flatland: http://discorporate.us/projects/flatland/docs/tip/ * Only does 2+3 which is a good thing IMO 2. WTForms: http://wtforms.simplecodes.com/ * Used in standard flask docs: <http://flask.pocoo.org/docs/patterns/wtforms/>
#770 1296593925000000 thejimmyg I don't care about this. It is too trivial. If I get around to fixing it they great but I don't need it logged as a ticket.
#801 1296593735000000 thejimmyg I don't see why we'd really need to do this. Under the current system a job would be created just before the harvesting would be run so the creation date of the job is (give or take a few seconds) the date of the harvesting. If we moved to a queue system this would be done better anyway.
#766 1296593519000000 thejimmyg This is a duplicate of #767
#767 1296593504000000 thejimmyg I haven't heard this mentioned yet, but yes, let's try to implement it if possible. Appears to expose a CSW interface? http://webhelp.esri.com/geoportal_extension/9.3.1/index.htm#ext_csw_clnts.htm
#757 1296593448000000 thejimmyg Duplicate of #754. If we added filtering we'd need to write a migration script anyway.
#795 1296593361000000 thejimmyg This is a duplicate of #794 because if we needed to do this it would be because we need to support harvest sources registered on behalf of publishers by agents,
#789 1296593257000000 thejimmyg Covered by #736 now.
#499 1296593038000000 thejimmyg Not on the SoR.
#750 1296592940000000 thejimmyg Duplicate of #728
#740 1296592889000000 thejimmyg Duplicate of #739.
#739 1296592842000000 thejimmyg Implemented today. May want a better implementation later.
#736 1296592767000000 thejimmyg We also need to check WMS URLs added to package resources to check they are genuine WMSs.
← 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 →
Note: See TracReports for help on using and creating reports.