{23} Trac comments (3729 matches)

Results (601 - 700 of 3729)

← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 →
Ticket Posixtime Author Newvalue
#771 1294413256000000 thejimmyg This works for me. {{{ paster help }}} and {{{ paster --help }}} both show help text for me.
#1205 1310568631000000 dread This worked - cheers David.
#794 1294248216000000 thejimmyg This work is now underway in the underlying DGU implementation.
#1387 1320142210000000 rgrp This won't happen in v1.5.
#2407 1340633440000000 amercader This will require some thought. Bumping to 1.9.
#801 1300196714000000 thejimmyg This will now be solved as part of the larger harvesting refactor. See #921.
#740 1294408931000000 thejimmyg This will have to be done via the API though for DGU/UKLP. Should probably have it on the package interface in main CKAN too though.
#363 1310125872000000 thejimmyg This will eventually be fixed as part of braoder VDM changes. This work cannot be prioritised above other things we want to do.
#2458 1343818531000000 aron.carroll This will be up on s031 by the end of the day for feedback
#190 1280686074000000 pudo This will be solved using an external plugin and the disqus service. A current test version of the external code is at: http://bitbucket.org/pudo/ckandisqus
#318 1296467308000000 pudo This will be implicit in #852, thus not building something specific for it now.
#941 1297246005000000 thejimmyg This will be implemented in http://bitbucket.org/okfn/ckanext-community by Wayne.
#1595 1325604696000000 kindly This will be fixed when the activity stream will be in place of the revision list. There is no bug with the revisioning, it just is getting everything related to the group.
#196 1264876030000000 rgrp This will be fixed via using meta http-equiv (see ticket:90).
#2408 1341497601000000 aron.carroll This will be done as part of adding javascript in phase 2
#826 1306766057000000 dread This went into ckan release 1.3.2.
#1283 1330083933000000 dread This went into CKAN 1.6
#1445 1330019916000000 dread This went into CKAN 1.6
#1521 1330084599000000 dread This went into CKAN 1.6
#1462 1330083671000000 dread This went into CKAN 1.5.1.
#438 1294661079000000 dread This was to ensure it didn't parse ONS data on the CKAN server, which is complete.
#1451 1322567112000000 johnglover This was taken from the UX pad. I'm looking at it now to make sure that it's working and that we can use it on the new dataset view page. Is it really a good idea to move it to core though? There was no reason given on the pad so I'm not sure why this should be moved to core?
#575 1288012749000000 johnbywater This was supported with harvesting jobs.
#1341 1315996368000000 kindly This was run to delete the users and their mistaken revisions that where created. {{{ BEGIN; delete from revision r where r.id in ( select r.id from "user" join revision r on r.author = "user".name left join resource_revision rr on rr.revision_id = r.id left join package_revision pr on pr.revision_id = r.id left join group_revision gr on gr.revision_id = r.id where "user".created between '2011-08-15' and '2011-09-06' and gr.id is null and rr.id is null and pr.id is null and ("user".name similar to '%[0-9]' or "user".fullname similar to '[A-Z][a-z]*[A-Z]%') and "user".name not like 'http%' ); delete from "user" u where u.id in ( select "user".id from "user" left join revision r on r.author = "user".name where r.id is null and "user".created between '2011-08-15' and '2011-09-06' and ("user".name similar to '%[0-9]' or "user".fullname similar to '[A-Z][a-z]*[A-Z]%') and "user".name not like 'http%' ); COMMIT; }}}
#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
#806 1324034356000000 dread This was introduced in CKAN 1.3
#714 1291733788000000 dread This was implemented with DGU ticket 614
#1263 1314029279000000 dread This was fixed in cset:8d293393a9f2 for release 1.4.3.
#1310 1315820419000000 dread This was fixed cset:e49781cb74fd for 1.4.3.
#1029 1301311643000000 thejimmyg This was fixed by kindly as part of the 1.3.2 release.
#241 1270569769000000 dread This was fixed by John a couple of weeks ago with his new license stuff.
#132 1273254514000000 dread This was fixed before and now works.
#1718 1340703280000000 aron.carroll This was fixed at some point.
#437 1288004009000000 dread This was fixed a while ago
#198 1266837606000000 dread This was finished off by rgrp in cset:ca995c2596c6
#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.
#1252 1318160334000000 rgrp This was done ~2 weeks ago.
#667 1285925476000000 dread This was done when caching was switched off for a few hours it seems. Still, it is worth investigating this.
#207 1271250740000000 dread This was done in forms branch - merge: cset:c22854a52319
#239 1264875924000000 dread This was done in cset:d213e942245b
#1199 1310555589000000 dread This was done in branch feature-1198-mailer. No tests - ticketed here: #1222. Additional feature in this branch 'password reset' was ticket #1186.
#906 1328639465000000 dread This was done in #1701 but only in a custom SOLR schema in the ecportal extension: https://github.com/okfn/ckanext-ecportal/commit/6682926d8895f146cdf1e52ab4fbead9b065af77 Can the ASCIIFoldingFilterFactory be added to core CKAN's SOLR schema for all CKAN users to benefit from?
#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.
#1186 1310556519000000 dread This was done by pudo in branch feature-1198-mailer and went into default, lined up for release 1.4.2.
#958 1320664462000000 rgrp This was done as part of dataset resource editing in #1294 (duplicate)
#798 1294916973000000 dread This was done a while ago.
#400 1288003690000000 dread This was done a couple of weeks ago.
#282 1338206417000000 ross This was discussed with Toby who has a ticket for this same feature because of disqus requirements.
#845 1291723492000000 dread This was completed on the feature-845-required-fields branch and merged into default in cset:3b5635ffaa7d
#931 1298379187000000 dread This was completed in ckanclient in cset:1bfefd7596d3
#1142 1313775665000000 rgrp This was completed 4 weeks ago and can now be marked as complete. See http://docs.ckan.org/ and http://wiki.ckan.net/ and http://ckan.org/
#2271 1334567582000000 amercader This was caused by an human error.
#1056 1302882616000000 dread This was broken in cset:b681bbedfa62a68b71260ef48a0da6063109734 which was released in 1.3.2
#465 1282724701000000 dread This was an idea, to be able to monitor users overloading. It may not be required though.
#110 1252488660000000 dread This was all done in work for ticket:105
#428 1285757316000000 dread This was achieved a couple of weeks ago
#867 1299866685000000 rgrp This was a breaking change for loaders code. Obviously we don't have tests for that so would not have been noticed ... Fixed in cset:af81e54bd590/ckanclient
#1122 1305718009000000 dread This user is now storing his list as a string so is happy. But I'll leave this ticket open, for pudo to decide whether there is an issue with SOLR indexing tuples/lists, as per the previous comment.
#358 1303123611000000 dread This ticket was designed only for reading resources, following an ongoing requirement from the Scraperwiki collaboration. Assume PUT/POST is out of scope. I suggest dealing with resources that aren't attached to packages in an entirely new ticket or CEP, as the implications are wider than this aspect of the API.
#1591 1328789470000000 dread This ticket was created in response to the security issue in CKAN 1.5 only - it does not affect other versions. There is a different argument to upgrade older CKANs installed elsewhere, but there tend to be problems with extensions and themes not being compatible, so I think should be considered on a case-by-case basis and how much budget is available.
#358 1303122109000000 kindly This ticket needs to have a more thorough spec which needs to include. * Examples of put/post requests to resources and if they are needed. * Dealing with resources that do not have a related packages in terms of authorization. Do they have a new action? how granular is the authorization? per resource? system level? etc. * The rules related to authorization for resources attached to packages. i.e you only get read permissions when the related package has read permissions? do they have their own rules?
#30 1185472559000000 rgrp This ticket is partially resolved and partially irrelevant: * Since move to 'ckan2' in Jan 07 (r54 onwards) have had tag support. * Since move to versioned system (r121 and ff.) have allowed tags to be added and amended by anyone.
#810 1310128477000000 thejimmyg This ticket is over 6 months old so closing.
#449 1311182945000000 thejimmyg This ticket is now more than 6 months old so marking as invalid in line with our ticketing policy.
#78 1311181280000000 thejimmyg This ticket is now more than 6 months old so closing in line with our new ticketing policy.
#362 1311176564000000 thejimmyg This ticket is more than 6 months old so marking as invalid in line with out ticketing policy.
#668 1311176649000000 thejimmyg This ticket is more than 6 months old so marking as invalid in line with our ticketing policy. The API v1 and 2 were completely re-written as part of the logic layer refactor so it is likely this issue is resolved anyway.
#660 1311183115000000 thejimmyg This ticket is more than 6 months old so closing it in line with our ticketing policy.
#856 1311177066000000 thejimmyg This ticket is more than 6 months old so closing it in line with our new ticketing policy. We know that test coverage needs to be improved, particularly in the logic layer.
#857 1311177075000000 thejimmyg This ticket is more than 6 months old so closing it in line with our new ticketing policy. We know that test coverage needs to be improved, particularly in the logic layer.
#859 1311177461000000 thejimmyg This ticket is more than 6 months old so closing it in line with our new ticketing policy. We know that test coverage needs to be improved, particularly in the logic layer.
#855 1311176988000000 thejimmyg This ticket is more than 6 months old so closing it in line with our new ticketing policy. The auth code is in the process of a major refactor anyway.
#225 1311178276000000 thejimmyg This ticket is more than 6 months old so closing it in line with our new ticketing policy.
#312 1311176173000000 thejimmyg This ticket is more than 6 months old so closing in line with our current ticketing policy.
#1511 1323100081000000 seanh This ticket is just for getting the activity stream at the model level, not yet for rendering it in any particular output format. Estimate: one day Related user stories: #039 User I want to see the activity stream for another user when I go to their user (profile/home) page. #042 User Subscribe to RSS feeds for activity in relation to packages, users, groups, tags (?) #032 User See what status people have by seeing small bits of info next to their name, e.g. a sign to indicate being a superuser/sysadmin and/or the number of datasets they have. I know the approximate activity and authority of users I come across Also see: http://ckan.okfnpad.org/notifications
#1198 1308821489000000 pudo This ticket is essential I think. I would propose we should be a bit more radical here, though: * Introduce an "Agent" SQLAlchemy object and derive both publishers and users via single table inheritance. * Make agent the central object of authorization, e.g. by introducing c.agencies including the user account, visitor, logged_in, etc. * Abolish AuthorizationGroups in favor of publishers. Yes, they are different but the use case for what AuthzGroups do and Publishers don't is just nerdery. * Restructure URLs to be /<agent>/<package_name> rather than /package/<package_name> and have /<agent> be a useful list of managed resources rather than a revision list (users current home page). * Make Agents a primary facet for all kinds of navigation. Of course this would be done incrementally but I think we should agree on some such scheme as a marching direction.
#698 1293649815000000 rgrp This ticket is complete: * ckanext-dataapi: working /api/data/{resource-id} with tests * https://bitbucket.org/okfn/dataproxy - the dataproxy code running at http://jsonpdataproxy.appspot.com * functioning but needs tests and improvements There a whole bunch of improvements to be done but these will be in ticket:888
#861 1311168845000000 thejimmyg This ticket has been open for than 6 months so I'm closing it.
#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.
#1451 1324401792000000 johnglover This ticket again brought up the issue of a need for inversion of control for writing to CKAN templates (main templates should really ask extensions for data or provide hooks rather than having extensions overwrite sections using genshi/jquery). Have decided to defer this issue for now, as it will be looked at when looking at making our whole extension system more robust early next year. Related point: * We should provide a dashboard area (again via interfaces/hooks) that groups together report data from related extensions. So stats and googleanalytics info should be available from a similar area / url. This is also deferred until the extension overhaul/refactor. Other outstanding issues: * Location / style of download count can be improved * Download count should be shown on resource pages These should be looked at by whoever takes over frontend design.
#1242 1323173292000000 thejimmyg This text is no longer present on the login page.
#96 1311176063000000 thejimmyg This sounds like an issue with setuptools not CKAN. It has been open for more than 6 months and doesn't appear to have been an issue so closing.
#948 1300271100000000 dread This sounds like a good solution to me. This should include not just packages, but groups and all other stateful objects.
#1063 1301522483000000 rgrp This sounds absolutely sensible and suggest we even have a helper method such as lib.helpers.group_link(group) (as we do for user_link). (@Seb: apologies for misunderstanding your query on the list -- I was talking about the group listing table at /group)
#2575 1340899487000000 toby This should now have a fix do a proper fix for 1.9 - needs a more thought out approach and quite a bit of re-factoring of that bit of code
#2681 1343115619000000 toby This should be just `basic` formats csv html xls etc it's for non technical and what we output with the resources
#1804 1329491156000000 toby This should be fixed in branch feature-1653-i18n_url_rewriting as we use different logic. However it may affect other return_to calls used elsewhere like adding a new package.
#1208 1312191646000000 pudo This should be closed: * https://github.com/okfn/webstore - See README for details * Python client lib: https://github.com/okfn/webstore-client * http://webstore.thedatahub.org/ - Demo install * http://wiki.ckan.net/Webstore - Overview
#1050 1303118188000000 thejimmyg This should also feed into #1075 which will be being worked on this week.
#1419 1319795920000000 dread This seems to work better today...! myopenid works for me fine with my existing account and by reregistering. My google id works only if I reregister, and I think that is because I hadn't registered before. Closing.
#1416 1320153507000000 dread This seems to have been fixed in #1229. Added a test for this cset:5d6a3e50fe8f on default to demonstrate it displays a validation error, as rgrp suggests. Note, this ticket is about spammers missing some of the form fields, rather than any normal user usage, where the browser sends all the fields whether you fill them or not.
#2512 1339576809000000 toby This seems to be working now
#2612 1342005971000000 shevski This seems to be fixed, but needs proper testing
#291 1273254895000000 dread This seems spurious. The options.q is unicode finds foreign characters fine. The hack has since been taken out.
#2714 1352206138000000 johnmartin This seems fixed... I'm closing this.
#2608 1343125400000000 seanh This seemed to be a problem in Firefox only and only when a certain Firefox extension was enabled, nothing quite got to the bottom of it, not worth fixing given the obscureness and difficulty
#2704 1343914890000000 aron.carroll This relates to #2705. We need to decide what happens when the user clicks on one of the sidebar links. At the moment they'll get a warning if they've edited the form telling them they'll lose thier changes. Perhaps we should submit the form using ajax, showing a spinner to the user, then send them on to the next resource. This is the same situation as if we add an "add new resource" button to the listing.
#1513 1326728958000000 dread This problem is now more obvious because we display use name. If there is an user icon, but no user name then you are in this 'inbetween' state. The problem is that the cookie exists in your browser, but it is not valid, for whatever reason. The solution is to change the css/javascript that displays the Register/My Account bit in the corner to talk to Auth, rather than just check for the cookie.
#1395 1318525201000000 dread This problem is mentioned here: http://docs.ckan.org/en/latest/test.html but you're right, it really should be solved in the install instructions.
#1629 1326823222000000 dread This permission is set every time you do a db_upgrade. ckan.model.__init__.py calls init_configuration_data() which calls init_authz_configuration_data() which restores specific roles to the defaults. I agree that it doesn't seem right in this circumstance, but the way I setup roles is for 'editor', 'anon_editor' and 'reader' to have a fixed set of actions. See comment in ckan/model/authz.py: {{{ # These define what is meant by 'editor' and 'reader' for all ckan # instances - locked down or otherwise. They get refreshed on every db_upgrade. # So if you want to lock down an ckan instance, change Visitor and LoggedIn # to have a new role which for which you can allow your customised actions. }}} Basically it seemed wrong when people changed 'editor' to something that couldn't edit. They should call that role something else. But people *are* able to edit these roles (even though they are reset on upgrade) and they should be prevented. I've put this in a new ticket: http://trac.ckan.org/ticket/1679
← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 →
Note: See TracReports for help on using and creating reports.