{23} Trac comments (3729 matches)

Results (3201 - 3300 of 3729)

← 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 →
Ticket Posixtime Author Newvalue
#817 1297073724000000 thejimmyg This appears to be fixed now.
#819 1323171435000000 thejimmyg This issue is fixed. Further improvements to the UX of the autocomplete will be dealt with in other tickets.
#829 1303118864000000 thejimmyg Is this still relevant?
#830 1311180263000000 thejimmyg We can now implement themes via extensions or change them via config options. See https://bitbucket.org/okfn/ckanext-exampletheme/ for an example.
#841 1300364333000000 thejimmyg See #995
#842 1303474131000000 thejimmyg As a user I come to a package: Have a todo count at that top that takes you down to the todo list (which may say nothing todo) At the bottom is a section of the package display titled "ToDo" where I see a list of all toDos for the package most recent at the top If I am logged in see a form for "Add to do" at the top of the todo section and can add one straight away I see a "now resolved" button next to each which goes green when you hover. When clicked the todo fades away. Otherwise I see a button that says "login to add todo" expands out the form The form One of the fields is category -> autocomplete the category (not constrained) Add a description Submit, the todo gets added via AJAX to the list at the top as the most recent todo Model: todo id package_id todo_category_id (required) description (required) date=NOW() resolved=False todo_category id name Prepopulate with: broken-resource-link, no-author, bad-format
#842 1303474228000000 thejimmyg > Otherwise I see a button that says "login to add todo" > > expands out the form > Actually rather than expanding the form, you will go away to the login page and come back to see the expanded form (question: how does this redirect you back to the bottom?)
#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.
#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.
#861 1311168845000000 thejimmyg This ticket has been open for than 6 months so I'm closing it.
#865 1294414639000000 thejimmyg Isn't this in there now? Can we close? Thanks
#881 1294410574000000 thejimmyg Hello fccoelho, Could you please post the output you get from running pip? Thanks, James
#883 1300196622000000 thejimmyg Now complete.
#884 1294247654000000 thejimmyg Related to ticket #665, reopening so that I can close it once I've got it working with Drupal too.
#884 1296592140000000 thejimmyg OK, I've implemented an API call for this too now and all is merged into default.
#887 1300196600000000 thejimmyg This is done. See https://bitbucket.org/okfn/ckanext-harvest At the moment we are not adding migrations to remove the harvesting tables. We are designing a harvesting refactor and will write migrations once the refactor is complete so that instances that use harvesting get upgraded, and those that don't get their harvesting tables removed. Also, see this #1030 for the moving harvesting out of the REST API.
#888 1307352537000000 thejimmyg I don't think any progress has been made on this for a bit so I'm assigning it to me.
#893 1298293527000000 thejimmyg We don't understand the use case for this requirement. Closing for now until a use case can be demonstrated.
#894 1300196388000000 thejimmyg All test CSWs have been successfully harvested from. CSW harvesting is disabled on that source so we can't harvest from it. I don't think we need a ticket for this now do we?
#896 1300217375000000 thejimmyg Actually, I think this should be implemented instead by considering a different CKAN instance as a potential harvest source and then harvesting from it. By thinking of it this way in the first instance, we effectively get a read-only copy of other data in CKAN but one which will be kept up to date. Marking as duplicate. Discussion can now carry on via #987 Common harvesting framework.
#910 1310128544000000 thejimmyg Not enough information and over 6 months old so closing.
#920 1300217199000000 thejimmyg @David Should we implement this as a change to the way tags work or via a tidy up cron job?
#921 1300197629000000 thejimmyg Seb started this, I completed it and the code is now live. Further refactoring will be done first in #1037 and then in #987.
#922 1310128789000000 thejimmyg See also #358 which I'm closing because it gets merged into this ticket. The reason we were blockd on #358 was to do with issues around authorization.
#925 1323168588000000 thejimmyg This is fixed in CKAN 1.5
#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.
#934 1323171047000000 thejimmyg We have other ways of solving this problem now rather than a key value store for plugins. Marking as invalid.
#936 1298283172000000 thejimmyg Hi Wayne, I'm assigning this to you but it isn't a priority yet. We'll put it in a sprint when it is time to do it. Cheers, James
#936 1303117147000000 thejimmyg How is this coming on John?
#939 1323171158000000 thejimmyg This is now implemented, the notification links to the about page. We might want to update that page with better information, but that would be a different ticket.
#941 1297246005000000 thejimmyg This will be implemented in http://bitbucket.org/okfn/ckanext-community by Wayne.
#941 1297689750000000 thejimmyg The system will need some way of plugging in the model. See ticket #989 for progress on this. Other ideas: * The apps will need an image upload * We might like a voting system for apps and ideas, potentially that could be re-used later. Let's discuss the above ideas after the basic functionality is in place.
#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.
#948 1323172859000000 thejimmyg Re-assigning to me temporarily to investigate now that Seb has left.
#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.
#957 1300216958000000 thejimmyg Let's come back to this later. There are larger UKLP refactors going on. Sorry to mess you around.
#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
#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.
#985 1303118298000000 thejimmyg We'd like CKAN to CKAN harvesting this week if possible.
#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.
#990 1311180850000000 thejimmyg This now works.
#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.
#1001 1300367555000000 thejimmyg Yes, I think the two should be consolidated, but as was noted elsewhere (I think) we don't want the API to ever be authenticated via a cookie, otherwise we open ourselves to CSRF attacks. Instead we could support the API key as a query parameter as an alternative to via the HTTP header if it is hard to set an HTTP header in JS libraries?
#1002 1311173185000000 thejimmyg I've done this in my branch and it will get merged in.
#1004 1311173560000000 thejimmyg At the moment it says "Create a new group" and clicking it takes you to the login page. We want it to do the same thing but if you aren't logged in the label should say "Log in to create a group".
#1004 1323171375000000 thejimmyg The yellow box on the right is now back and you don't get taken to the login page. We'll write more detailed instructions once the group refactor is done.
#1004 1323174597000000 thejimmyg I don't understand. We just had a team meeting about this, all discussed it and agreed to close it. Yes, you get taken to the login page, but that is the correct behaviour. The problem in the past was that the link was in the yellow box and there was no explanation as to why you had to login. This time you click from the header bar and there is a clear message saying "Unauthorized to create a group" - exactly as a user would expect. Even if the exact text of the ticket description isn't fully implemented in the current release, the UX isn't broken anymore. Yes, it might be even nicer to have a message warning them in advanced but these improvements will be taken forward in the UX work - maybe there is an even better solution than a message? Since you are unhappy about closing it I'm marking it as "Duplicate" of #1521. As agreed earlier with the entire team, we'll take this forward as part of the groups refactor. See #1521 for more information.
#1006 1300372286000000 thejimmyg I'm updating the branching policy now. David has closed stable and closed metastable. Marking as fixed.
#1012 1300217601000000 thejimmyg See also #103 which says: As a user I want to view a package at a given revision: * When I visit /package/read/xyz?rev=yyy I should be shown package at revision yyy * package history page should provide links to these pages Could you please investigate how doable this would be given the current package read.html page. I expect it could be very easy once the revision API is in place because we could build a c.pkg object from the revision data instead of the model data. Perhaps another case where we could try introducing the dictization?
#1012 1300364620000000 thejimmyg The API part is now done. Bumping the view history part to 1.5
#1012 1301909937000000 thejimmyg No-one really seems to have requested this part.
#1020 1300196215000000 thejimmyg This is now on DGU live.
#1029 1301311643000000 thejimmyg This was fixed by kindly as part of the 1.3.2 release.
#1030 1300209975000000 thejimmyg Also: * Delete harvest sources * Implement a Genshi template filter so that if there is an INSPIRE package_extra set to True, you can link to the XML and HTML generation API calls in ckanext-csw * Write tests in ckanext-dgu for all the API calls that Drupal is making
#1032 1303117292000000 thejimmyg Rufus, I think this is potentially quite a big change and needs to be done as part of the entity refactor rather than as a quick hack. I'd like David Raznick to work on timeseries this week so I'd like to understand a bit more about this ticket. Could you flesh it out please or let's discuss in the catch up?
#1032 1303118226000000 thejimmyg See related ticket #922
#1035 1323172908000000 thejimmyg Re-assigning to me temporarily to investigate now that Seb has left. It may be that this should be deleted given that it is over 6 month's old.
#1037 1303117000000000 thejimmyg We spent last week integrating the new harvesting architecture and testing the code but there are still some areas that need looking at * The source type and label should be part of the plugin, not named in DGU. * Need warnings if a document changes but its date doesn't -> do we have these? * I noticed there are some tests in DGU, should these perhaps be in ckanext-harvest? * If active is False, the job should not be put on the queue * Log if the wrong type of URL is entered as an error the user can see * Deny if the source is already registered * Overwrite all extras, not just merge new ones. * During the import stage use iswms.py to add an extra during import if it is a WMS so that we can add a link to the WMS later https://gist.github.com/900878 * Can errors/warnings be logged in the import stage? Do all fetched documents get passed to import in one go?
#1037 1304937601000000 thejimmyg Closing this now, any outstanding small issues will be logged in new tickets.
#1041 1300284809000000 thejimmyg Also, this means moving documentation out of the current CKAN dev wiki at trac.ckan.org and into the community wiki. Core developer docs should remain in the Sphinx-based .rst format in CKAN. Much-needed new tutorials go on the community wiki.
#1041 1310135309000000 thejimmyg Child ticket of #1142
#1049 1323169424000000 thejimmyg This is over 6 months old. In accordance with wiki policy, closing.
#1050 1303118188000000 thejimmyg This should also feed into #1075 which will be being worked on this week.
#1053 1310125444000000 thejimmyg This is now fixed as part of the API refactor and revisioning updates David Raznick has done.
#1062 1311178145000000 thejimmyg Hi John, Can you please check that the new webstore+preview works correctly with this one please? Cheers, James
#1064 1323169787000000 thejimmyg Marking as duplicate because #1464 will take it on.
#1065 1303118756000000 thejimmyg This is now more urgent and I think we have enough consensus to go ahead. See #1094 too.
#1065 1311174208000000 thejimmyg Merging with #1094 so see the discussion there too.
#1069 1301909423000000 thejimmyg This is what the new "Ideas" section in the ckanext-community extension is for. Marking as duplicate of #941, can we have discussion there please.
#1069 1310133794000000 thejimmyg Yes, and this will be more important in thedatahub.org
#1087 1310134714000000 thejimmyg Child ticket of #954
#1094 1311173649000000 thejimmyg Merging with #1065 and closing.
#1096 1310125173000000 thejimmyg Renaming to CKAN Hosted because whether we introduce a site domain object for subdomain tenants or not is an implementation detail. As far as progress on CKAN hosted goes, we now have: * A build tool to package ckanext-dgu, ckanext-std etc into .deb files * The ability to apt-get install CKAN * A script that can set up multiple non-conflicting CKAN instances on the same machine What we need next is the ability to generate a ckanext-xxx repository for each new instance we want to host. At that point most of the underlying techniques for hosting multiple CKAN instances concurrently will be in place. Once we have that working and know what clients want, we can look at going further and speccing up a multisite solution off a single DB, rather than the multi-instance solution proposed here.
#1096 1311182262000000 thejimmyg Milestone ckan-v-future deleted
#1107 1310134646000000 thejimmyg Child ticket of #954
#1108 1310128678000000 thejimmyg Now that we are using ckan.net as thedatahub.org we should go full steam ahead and create a brand new UI to reflect thedatahub.org's new role. See http://ckan.org/2011/07/08/ckan-vision-update/
#1108 1311180204000000 thejimmyg See also comment on #1200 about using the pdeu theme.
#1118 1311174062000000 thejimmyg We haven't ever come across this. Perhaps if you could provide an example we can re-open it. Cheers, James
#1123 1307790563000000 thejimmyg This isn't necessarily a trivial thing. Let's get the build system for the packages stable before we start changing it all to support alternative architectures. Once the packaging is working well it would be trivial to switch those servers to amd64. I'm sorry, but this isn't worth the investment in manpower at the moment.
#1124 1323168132000000 thejimmyg Solr is now properly supported in the ckan-1.5 repository.
#1124 1323168156000000 thejimmyg Re-open this if it still affects DataGM.
#1127 1305128000000000 thejimmyg This is great idea and it has taken on well. +1 from me. We can update/create new CREP policies as needed.
#1129 1305116419000000 thejimmyg Great proposal, here's my thinking: * The current VDM model (where we have things like a single package table which logs changes to a package_revision table) is very well tested and works well and we should only consider a radical change with good reason * Although we are making a move from *model objects* being the central components to the *logic layer functions* being the central components, there is no need yet to have the database structures we store (for revisioning or otherwise) start to look like the dictized representation. The logic layer itself is designed to do that mapping. * Since we do have this logic layer though, there is less need for "magic" SQLAlchemy objects to support dicts and lists (eg the stateful objects used to make a list of tags on a package behave like a list), a few simple (and easily debuggable) queries in the logic layer would work better. In the longer term we may want to look at serialising more dictized-looking objects and that may lend itself to a more dictized changeset model or even a more dictized storage system (eg no-SQL) but for the time being we are not at that point. I recommend the following: * We continue to use the current default branch of VDM (not the changeset branch) * We continue to treat the package table (and other non-revision tables) as the most recent revision (even though the *active* revision displayed in CKAN might well be in the revision tables because more recent changes haven't been moderated yet) * We slowly stop using stateful lists and dicts in CKAN because we have move control with explicit queries in the logic layer Sound good?
#1134 1305125228000000 thejimmyg Great stuff. Yes, I agree with all this, but as initial thoughts I suggest that for phase 1, the info() method returns one more key called "form_config_interface" which takes a string representing a the type of interface for the config field on the form. If the key is missing it is treated as "None". The two possible values are: None - the field is not present and must always be stored as NULL Text - a single text field will be provided on the interface Whatever the interface, the value built will always be stored in the config column of the table. We then also provide a "get_schema()" method that returns a schema cablable of parsing the data submitted by the form and storing it as a single key named "config". ckanext-inspire will then add other functions to the schema for URL etc so that regardless of what the harvest plugin does, the key fields ckanext-harvest are always there. This then allows: * Customiseable config interfaces * Customisable valiation * A consistent place to store config in the database Sound good?
#1150 1311178163000000 thejimmyg Hi John, Can you please check that the new webstore+preview works correctly with this one too please? Cheers, James
#1166 1306847326000000 thejimmyg Also, rather than INSPIRE=true we should probably have information about the harvesting mechanism and the harvest object type? This also relates to our use of the kind field on the resource.
#1167 1306857750000000 thejimmyg Creating the AMI is really just the icing on the cake. The hard bit is getting the packaging right so that's where we need to concentrate first. Once the packaging works we just make sure apt-get upgrade is run regularly. +1 to the list above. I also agree we should install solr by default. Who has actually done a CKAN solr install? I haven't but together with whoever has I can try to package it up. Wrt to usernames and passwords, I'll look into how dpkg manages those blue pop-up screens for entering configuration options.
#1167 1311178516000000 thejimmyg I've now written a 20 page guide on using CKAN on Amazon EC2. I haven't explicitly created an AMI, but I don't think we should do that anyway for a few reasons: * it is fiddly * there is no advantage to the user as CKAN installation is so easy and so well documented * we don't want to have to maintain the image going forward * we might not want to promote a non-open approach The guide will form part of Anna PS's work on the overall documentation but you can also see the original version here: https://bitbucket.org/okfn/ckan-debs-public/src/489a5ecf369f/ec2/
#1168 1310134901000000 thejimmyg This is now working on dgu-buildbot.okfn.org. The code that manages it is partly the repo.py script from http://hg.3aims.com/public/BuildKit/ and partly the fab code in https://bitbucket.org/okfn/buildbot-scripts
← 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 →
Note: See TracReports for help on using and creating reports.