TODO.txt 
  CalendarX 0.5.3(dev)  March 26 2005
  (last modified for CalendarX 0.5.3)
by +lupa+ (lupaz on sf.net, lupa at zurven dot com)
Released under the GPL (see LICENSE.txt)

CalendarX by Lupa Zurven (lupa at zurven dot com)
  A metacalendar for Plone.
This ToDo list refers to goals for the current branch, and is not a more
  general ToDo wishlist for CalendarX in future branches.  Go see the 
  CalendarX.org website for more complete wishlist ideas for the future
  of CalendarX.


ToDo list as seen at launch for CalendarX 0.5.3(dev)  
New #1. Get portal_factory working properly with the +link addNewEvent 
   feature.  Currently it does NOT send through the proper date and time
   to the temporary Event.  Bleah.  Also there should be better configuration
   of options in the CX_props_addeventlink.props sheet once this is fixed.
1-11. same as below.  Made some progress on #12, but needs a more thorough
   treatment.
13. Get the new prototype repeat events working well enough to use with 
   CalendarX. Add an "allday" property to the Events and use it in the displays.   


ToDo list as seen at launch for CalendarX 0.5.2(dev)  
1-6. same as below
7. Clean up code and naming in a number of places.  For example, make it
   clear from names of things that eventstoallow are really where we are 
   allowing and not restricting events, and eventstorestrict is where we
   are restricting events, not allowing them.  Or if it is different than 
   that then make it sensible sounding.
8. Would really like a nice recoding of the property sheets.  Specifically, 
   I want to be able to nicely create a repurposed type in portal_types, and
   give owners (ordinary users) the opportunity to do a limited amount of 
   configuring the calendar themselves, without needing ZMI access and 
   manager privileges.  Can't do that with regular property sheets... got 
   some thinking to do on what it should look like.
9. BUG: JumpToDate widget throws an error if the date is illegal, like April 31
   of any year.  And I don't like the crazy URL it uses... it would be nice to
   be a standard CalendarX URL instead.  So should use a Controller Python 
   Script with metadata as a redirct... catch the bad dates in the script, then 
   use the redirect to get *nice* URLs.
10. Use TALES in a property to control several more of the special features 
   that should be controlled there, by the Admin, instead of hardwiring 
   permissions into the code... things like isMember stuff should be TALES
   strings properties that get checked out by the checkCondition method.
11. getDictCommon isn't really *common*.  Instead there are things in there
   that are specific to each view... that's silly, they should be back in
   the separate getDictViewname scripts, right?  I think there's a reason 
   that they are not, but there should be a decent workaround to make that
   more intuitive.
12. Make sure all URLs are properly formatted and quoted so that they meet 
   all standards for web URLs.  Probably not right now, especially not the
   new +links for event creation.  Not hard, but needs to be learned and done
   correctly throughout the code.
 

ToDo list as seen at launch for CalendarX 0.5.1(dev)  
1. Need more systematic testing of all the 0.5 properties, and work with them
   on some real calendars to see what else is needed (a few other properties,
   likely).
2. Extend, improve handling of groups for group calendars.
3. Try to make a config page that allows admins to give owners of 
   CalendarX instances the ability to make some (limited) configuration
   changes of their own.  Admins decide how much to let them do.  Done
   right, this will GREATLY simplify configuration, both for Admins and
   for owners, and it will make it easy to make a new Calendar type that
   is useful for certain groups of users (and be specially configged 
   just for them).
4. Finish documenting all the new restrict/allow properties.  Make up more
   silly use cases and helpful hints.  
5. Work on new manual for 0.5 branch.
6. Integrate Max's new iCal tool.