django-schedule - Project Hosting on Google Code

Older May 12, 2009 issue 45 (Github URL) reported by alvin.mites - http://github.com/thauber/django-schedule/tree/master http://github.com/thauber/django-schedule/tree/master Apr 09, 2009 issue 44 (There's no link on Google Code to the GitHub repository) reported by brianmhunt - What steps will reproduce the problem? 1. Searching for django-schedule on Google points to here 2. There is no direct link to the GitHub django-schedule repository. It'd be wonderful if the Project Home on Google Code pointed directly to the GitHub repository, here: http://github.com/thauber/django-schedule Just a suggestion. :) Thanks & cheers! What steps will reproduce the problem? 1. Searching for django-schedule on Google points to here 2. There is no direct link to the GitHub django-schedule repository. It'd be wonderful if the Project Home on Google Code pointed directly to the GitHub repository, here: http://github.com/thauber/django-schedule Just a suggestion. :) Thanks & cheers! Apr 06, 2009 r108 (For the atom feed, setting each item's last updated value to...) committed by z...@inzain.net - For the atom feed, setting each item's last updated value to Occurrence.start instead of Event.created_on For the atom feed, setting each item's last updated value to Occurrence.start instead of Event.created_on Apr 03, 2009 issue 41 (iCal compatibility?) commented on by thauber - This has been handled and is available on django-schedule on github Be careful it may still be an unstable project This has been handled and is available on django-schedule on github Be careful it may still be an unstable project Apr 01, 2009 r107 (Broken State, switching to git-hub. Bye Bye google code.) committed by thauber - Broken State, switching to git-hub. Bye Bye google code. Broken State, switching to git-hub. Bye Bye google code. Apr 01, 2009 r106 (Added tests directory module. For the last time.) committed by thauber - Added tests directory module. For the last time. Added tests directory module. For the last time. Apr 01, 2009 r105 (Added tests directory module) committed by thauber - Added tests directory module Added tests directory module Apr 01, 2009 r104 (Added tests directory module) committed by thauber - Added tests directory module Added tests directory module Apr 01, 2009 r103 (Added tests directory module) committed by thauber - Added tests directory module Added tests directory module Apr 01, 2009 r102 (changed tests to a directory module) committed by thauber - changed tests to a directory module changed tests to a directory module Apr 01, 2009 r101 (Added Views for egetting periods) committed by thauber - Added Views for egetting periods Added Views for egetting periods Apr 01, 2009 r100 (support to export a calendar in iCal at /schedule/ical/calen...) committed by z...@inzain.net - support to export a calendar in iCal at /schedule/ical/calendar/<id>/ support to export a calendar in iCal at /schedule/ical/calendar/<id>/ Mar 31, 2009 r99 (updating the sample project with a link to the feed) committed by z...@inzain.net - updating the sample project with a link to the feed updating the sample project with a link to the feed Mar 31, 2009 r98 (Atom feeds for upcoming events ) committed by z...@inzain.net - Atom feeds for upcoming events Atom feeds for upcoming events Mar 31, 2009 r97 (Fixing bad import statements ) committed by z...@inzain.net - Fixing bad import statements Fixing bad import statements Mar 31, 2009 r96 (Added the file to the repo) committed by thauber - Added the file to the repo Added the file to the repo Mar 31, 2009 r95 (Added a utility class called EventListManager, which produce...) committed by thauber - Added a utility class called EventListManager, which produces the next occurrence for a list of Event instances Added a utility class called EventListManager, which produces the next occurrence for a list of Event instances Mar 31, 2009 r94 (added occurrences after) committed by thauber - added occurrences after added occurrences after Mar 31, 2009 r93 (models have been moved to a module) committed by thauber - models have been moved to a module models have been moved to a module Mar 31, 2009 r92 (* Added the start to the documentation. * Started moving eve...) committed by thauber - * Added the start to the documentation. * Started moving event occurrence generation to the generator methodology * Added the start feeds * Added the start to the documentation. * Started moving event occurrence generation to the generator methodology * Added the start feeds Mar 30, 2009 r91 (Tests added to test db-occurrences) committed by thauber - Tests added to test db-occurrences Tests added to test db-occurrences Mar 24, 2009 issue 35 (Replace most templates with AJAX functionality) commented on by bartek.gorny - About datepicker - from what I see, Rock has included jQuery's datepicker source code in the project_sample tree, and there is already a template (event_form_base.html) which uses it. So it is already part of the project, only not working out-of-the-box. Will probably take one or two lines of code to make the default project_sample event form use it, and indeed this'd be a step change in user experience. If you mean a real full-blown AJAX interface, with drag-and-drop event modification etc., that's a different story. I'm considering doing something like that too, but this could indeed be a separate project. About datepicker - from what I see, Rock has included jQuery's datepicker source code in the project_sample tree, and there is already a template (event_form_base.html) which uses it. So it is already part of the project, only not working out-of-the-box. Will probably take one or two lines of code to make the default project_sample event form use it, and indeed this'd be a step change in user experience. If you mean a real full-blown AJAX interface, with drag-and-drop event modification etc., that's a different story. I'm considering doing something like that too, but this could indeed be a separate project. Mar 20, 2009 issue 43 (Performance issue) reported by bartek.gorny - Rendering month and year view takes long - on my PC rendering a year takes over 6 seconds. This is because every month, week and day upon instantiation builds its own list of occurrences, which results in hundreds of redundant calls to Event.get_occurrences and to dbase. The attached patch cuts the time by over 85% - it does so by passing a period's occurrence list to its sub-period's constructor. The template patch cuts another 1-2% for year view by eliminating redundant calls to has_occurrences. Rendering month and year view takes long - on my PC rendering a year takes over 6 seconds. This is because every month, week and day upon instantiation builds its own list of occurrences, which results in hundreds of redundant calls to Event.get_occurrences and to dbase. The attached patch cuts the time by over 85% - it does so by passing a period's occurrence list to its sub-period's constructor. The template patch cuts another 1-2% for year view by eliminating redundant calls to has_occurrences. Mar 17, 2009 issue 42 (Provide a Form for editing an Event and multiple Occurrences) reported by kubasik.kevin - django-swingtime has such a form, porting it should not be too difficult. django-swingtime has such a form, porting it should not be too difficult. Mar 16, 2009 issue 34 (Proposed handling of event exceptions) Status changed by thauber - Status: Fixed Status: Fixed Mar 16, 2009 issue 34 (Proposed handling of event exceptions) commented on by thauber - This has been handled in db-occurrences branch. This has been handled in db-occurrences branch. Mar 16, 2009 issue 41 (iCal compatibility?) commented on by thauber - That is something we have planned for, but the project has slowed down a bit. It should be fairly straightforward, if you would like to submit a patch I will look it over, and merge it into the project. That is something we have planned for, but the project has slowed down a bit. It should be fairly straightforward, if you would like to submit a patch I will look it over, and merge it into the project. Mar 14, 2009 issue 41 (iCal compatibility?) reported by bob.haugen - What would it take to do an iCal-compatible export from a django-schedule calendar? Or an import from an iCal-compatible calendar? (I'm asking for one of the users of pinax-cohousing, which uses django-schedule.) What would it take to do an iCal-compatible export from a django-schedule calendar? Or an import from an iCal-compatible calendar? (I'm asking for one of the users of pinax-cohousing, which uses django-schedule.) Mar 04, 2009 r90 (Added a way to determine excpetions for Events) committed by thauber - Added a way to determine excpetions for Events Added a way to determine excpetions for Events Mar 02, 2009 issue 28 (Unexpected behavior of links on event viewing page.) commented on by bartek.gorny - (corrected version - it is very fresh so may still contain some bugs) (corrected version - it is very fresh so may still contain some bugs) Mar 02, 2009 issue 40 (Calendar links to events, not occurrences) commented on by bartek.gorny - This issue can be solved even without persistent occurrences - actually, I just submitted a patch to issue 28 which solves also this issue: if you click on an occurrence you see start/end dates of the occurrence, plus information about the original event. This issue can be solved even without persistent occurrences - actually, I just submitted a patch to issue 28 which solves also this issue: if you click on an occurrence you see start/end dates of the occurrence, plus information about the original event. Mar 02, 2009 issue 28 (Unexpected behavior of links on event viewing page.) commented on by bartek.gorny - The attached patch solves this issue by passing around a period data (as encoded start/end time) so that the view can figure out where to go. It provides three improvements: * links to day, month and year from event view go where they should * after deleting an event the view redirects to a daily calendar it came from (instead of an unbound "create" form) * the view of a recurring event gives start/end dates of a chosen occurrence (plus info about recurrence) The attached patch solves this issue by passing around a period data (as encoded start/end time) so that the view can figure out where to go. It provides three improvements: * links to day, month and year from event view go where they should * after deleting an event the view redirects to a daily calendar it came from (instead of an unbound "create" form) * the view of a recurring event gives start/end dates of a chosen occurrence (plus info about recurrence) Feb 27, 2009 issue 34 (Proposed handling of event exceptions) commented on by bartek.gorny - I think that in db-occurrences branch we need these two lines of code to handle calendar exceptions. If we define "the same occurrence" as "occurrence of the same event which take place the same day" (which probably makes sense for calendaring app), then a db-occurrence is an exception. Plus we need a way to state that a particular occurrence is cancelled. I think that in db-occurrences branch we need these two lines of code to handle calendar exceptions. If we define "the same occurrence" as "occurrence of the same event which take place the same day" (which probably makes sense for calendaring app), then a db-occurrence is an exception. Plus we need a way to state that a particular occurrence is cancelled. Feb 12, 2009 issue 40 (Calendar links to events, not occurrences) commented on by yann.malet - In fact it is working as designed. The Occurrences do not persist in the database only Events do. If you are interested by this particular feature there is a branch that intend to implement it : http://code.google.com/p/django-schedule/source/browse/#svn/branches/db-occurrences I haven't yet had a chance to work with it so I don't know how stable it is. In fact it is working as designed. The Occurrences do not persist in the database only Events do. If you are interested by this particular feature there is a branch that intend to implement it : http://code.google.com/p/django-schedule/source/browse/#svn/branches/db-occurrences I haven't yet had a chance to work with it so I don't know how stable it is. Feb 10, 2009 issue 40 (Calendar links to events, not occurrences) reported by ian.eure - What steps will reproduce the problem? 1. Create a recurring event 2. View the calendar containing it 3. Click one of the recurrences, rather than the original event. Rather than seeing the occurrence of the event you clicked, you see the original event, which has it's date rather than the date of the occurrence. This is confusing and inaccurate. What steps will reproduce the problem? 1. Create a recurring event 2. View the calendar containing it 3. Click one of the recurrences, rather than the original event. Rather than seeing the occurrence of the event you clicked, you see the original event, which has it's date rather than the date of the occurrence. This is confusing and inaccurate. Feb 08, 2009 issue 37 (Reviewing Upcoming Events) commented on by yann.malet - django-gatekeeper seems to be what you are looking for. If you end up implementing it and would like to contribute a recipe. I would see it as a nice addition for the wiki. http://github.com/sunlightlabs/django-gatekeeper/tree/master --yml django-gatekeeper seems to be what you are looking for. If you end up implementing it and would like to contribute a recipe. I would see it as a nice addition for the wiki. http://github.com/sunlightlabs/django-gatekeeper/tree/master --yml Feb 08, 2009 issue 39 ( "Weekly" and "Daily" in calendar_list.html should be "Week"...) commented on by thauber - You are going to have to give a better description of where you think this discrepancy is happening. This project is large, and I am not aware of what chunk of code you are talking about. You are going to have to give a better description of where you think this discrepancy is happening. This project is large, and I am not aware of what chunk of code you are talking about. Feb 08, 2009 issue 35 (Replace most templates with AJAX functionality) Status changed by thauber - If you would like to make an Ajax implementation, We would be happy to link to it. Sadly this is not a requirement of the app at this point. Status: WontFix If you would like to make an Ajax implementation, We would be happy to link to it. Sadly this is not a requirement of the app at this point. Status: WontFix Feb 08, 2009 issue 37 (Reviewing Upcoming Events) Status changed by thauber - This itself could be its own app. It is not part of the requirements of this app to do Event Moderation. Status: WontFix This itself could be its own app. It is not part of the requirements of this app to do Event Moderation. Status: WontFix Feb 08, 2009 issue 36 (Add model definition for get_ending_events) Status changed by thauber - Status: Done Status: Done Feb 02, 2009 issue 36 (Add model definition for get_ending_events) commented on by arockinit - Ok, this can be closed I guess. It would helpful to put this info on the homepage with recommendations. I'll see what I find - thanks. Ok, this can be closed I guess. It would helpful to put this info on the homepage with recommendations. I'll see what I find - thanks. Feb 01, 2009 issue 39 ( "Weekly" and "Daily" in calendar_list.html should be "Week"...) reported by f...@gruwier.dk - "Weekly" and "Daily" are frequencies (like "Yearly" and "Monthly"). These terms are not meaningful here, where it should be just "Week" and "Day". "Weekly" and "Daily" are frequencies (like "Yearly" and "Monthly"). These terms are not meaningful here, where it should be just "Week" and "Day". Jan 24, 2009 r89 (Added setup.py (needed by Pinax)) committed by rockmhoward - Added setup.py (needed by Pinax) Added setup.py (needed by Pinax) Jan 24, 2009 issue 37 (Reviewing Upcoming Events) reported by goober20136 - I would like to see the owner/admin to at least review the additions/deletions in the calendar of events prior to public viewing when posted by registered users. I think this added functionality comes in handy particular what events are relevant or applicable. The owner/admin should have the final say if the event is suitable for public viewing. I would like to see the owner/admin to at least review the additions/deletions in the calendar of events prior to public viewing when posted by registered users. I think this added functionality comes in handy particular what events are relevant or applicable. The owner/admin should have the final say if the event is suitable for public viewing. Jan 19, 2009 r88 (Added first try at persisted occurrences. This could is not...) committed by thauber - Added first try at persisted occurrences. This could is not stable, and should not be used in production of any kind. Added first try at persisted occurrences. This could is not stable, and should not be used in production of any kind. Jan 19, 2009 issue 36 (Add model definition for get_ending_events) commented on by thauber - I just want to be clear here, and say, that your patch you wrote here doesn't take into consideration occurrences of events, just events themselves. If all the events you are using are non recurring events then you are using the wrong app, there are better apps out there that deal with non-recurring events in a better way. I just want to be clear here, and say, that your patch you wrote here doesn't take into consideration occurrences of events, just events themselves. If all the events you are using are non recurring events then you are using the wrong app, there are better apps out there that deal with non-recurring events in a better way. Jan 15, 2009 issue 36 (Add model definition for get_ending_events) reported by arockinit - This patch adds a definition for get_ending_events to models.py. It does the same thing as get_upcoming_events but is based off of the end date. I think it's best that this is a separate function from get_upcoming_events because there could be logic differences between the two in the future. Take it if you would like. This patch adds a definition for get_ending_events to models.py. It does the same thing as get_upcoming_events but is based off of the end date. I think it's best that this is a separate function from get_upcoming_events because there could be logic differences between the two in the future. Take it if you would like. Jan 14, 2009 issue 35 (Replace most templates with AJAX functionality) reported by arockinit - What steps will reproduce the problem? 1. Go to most of the pages 2. They would be better off using jQuery <a href="http://ui.jquery.com/demos/datepicker">Datepicker</a> What is the expected output? What do you see instead? I see fine HTML tables for demonstration purposes, but I can't imagine people are using them on real sites. Please provide any additional information below. I'm fine with the idea of creating a jQuery implementation outside of the main project, but I also think that since Pinax depends on jQuery at this point, that we should just consider making it a dependency for the templates on this project. Of course, none of the views, models, forms, would be affected and we could keep a folder for the existing templates, but I think using Datepicker would be a far superior user experience. I'm willing to do a large chunk of the implementation. What steps will reproduce the problem? 1. Go to most of the pages 2. They would be better off using jQuery <a href="http://ui.jquery.com/demos/datepicker">Datepicker</a> What is the expected output? What do you see instead? I see fine HTML tables for demonstration purposes, but I can't imagine people are using them on real sites. Please provide any additional information below. I'm fine with the idea of creating a jQuery implementation outside of the main project, but I also think that since Pinax depends on jQuery at this point, that we should just consider making it a dependency for the templates on this project. Of course, none of the views, models, forms, would be affected and we could keep a folder for the existing templates, but I think using Datepicker would be a far superior user experience. I'm willing to do a large chunk of the implementation. Jan 14, 2009 issue 33 (Removing legacy code) commented on by arockinit - Also, here is an events template with voting code. I could make one without voting code if there's an interest. Also, here is an events template with voting code. I could make one without voting code if there's an interest. Jan 14, 2009 issue 33 (Removing legacy code) commented on by arockinit - This is just for events. I also "cleaned" up the urls.py but you can disregard those except the events url. Oh, there is some voting code in urls.py as well which works in Pinax but would be out of scope for just the schedule app. Right now this is just events unordered. I may add more logic based on feedback or my own needs. Feel free to give ideas. This is just for events. I also "cleaned" up the urls.py but you can disregard those except the events url. Oh, there is some voting code in urls.py as well which works in Pinax but would be out of scope for just the schedule app. Right now this is just events unordered. I may add more logic based on feedback or my own needs. Feel free to give ideas.

issue 35 (Replace most templates with AJAX functionality) reported by arockinit - What steps will reproduce the problem? 1. Go to most of the pages 2. They would be better off using jQuery <a href="http://ui.jquery.com/demos/datepicker">Datepicker</a> What is the expected output? What do you see instead? I see fine HTML tables for demonstration purposes, but I can't imagine people are using them on real sites. Please provide any additional information below. I'm fine with the idea of creating a jQuery implementation outside of the main project, but I also think that since Pinax depends on jQuery at this point, that we should just consider making it a dependency for the templates on this project. Of course, none of the views, models, forms, would be affected and we could keep a folder for the existing templates, but I think using Datepicker would be a far superior user experience. I'm willing to do a large chunk of the implementation.

What steps will reproduce the problem? 1. Go to most of the pages 2. They would be better off using jQuery <a href="http://ui.jquery.com/demos/datepicker">Datepicker</a> What is the expected output? What do you see instead? I see fine HTML tables for demonstration purposes, but I can't imagine people are using them on real sites. Please provide any additional information below. I'm fine with the idea of creating a jQuery implementation outside of the main project, but I also think that since Pinax depends on jQuery at this point, that we should just consider making it a dependency for the templates on this project. Of course, none of the views, models, forms, would be affected and we could keep a folder for the existing templates, but I think using Datepicker would be a far superior user experience. I'm willing to do a large chunk of the implementation.

Older