TODOs
=====
The initial 1.0a4 release of RSVP for Salesforce attempts to cover common lightweight "event registration" type features with exhaustive test coverage.  This should allow for future flexibility as things are refined.

The following are known issues that need to be resolved in the short term:

- better test coverage and experimentation of uninstallation scenarios not yet covered by CMFQuickinstallerTool's interaction with GenericSetup.  The included "uninstall" profile is experimental and possibly problematic.

- along the same line, make sure (via automated tests) stuff reinstalls correctly if either the full or partial uninstallation path is taken.

- The level of customizability of various registration templates is cruel and will be the first thing most deployments need.  Develop and document simple approaches for customizing needed templates.

- Basic non-class backed browser:page customizable via layers 

- Provide documentation of above

- Confirm customization in a layer of form

- Provide documentation of layer-based form customizations

- Add overview of current *complete* uninstallation process

Additional potential enhancements:

- Make kss tests less fragile (right now we're doing arbitrary string searches on xml calls, and there are better mechanisms for kss testing)

- Allow optional embedding of full PFG form into the page

- Ability to custom "Register" message would be good via the UI since this can be used in other use-cases (i.e. letter signing, sign-up)

- Provide a Register and Join Waitlist option as link text (we just use the former for everything now)

- The use of kss to facilitate the editing interface may prove confusing, though it's intended to simplify.  For example, the hiding/revealing those fields that can be used to limit registration numbers may be assumed to have more power than expected, when it really is only intended to streamline the editing process. We'll seek user input on this behavior and tweak as needed.

- Better "expectation management" of registrants that were possibly presented the registration form, but in the time be  set expectations around waitlisting if there's been a switch in the process

- When creating a custom signup form, provide an easier mechanism for adding a signup-object-id as a hidden string field.

- Phone Type - On the default form ask preferred phone type [EDIT NOTE: Phone fields include work, home, mobile, other]

- If a user is following the default configuration whereby the RSVP-aware Salesforce.com object is a Campaign and a Lead is created and joined to the Campaign via a CampaignMember object, present a selection list with all relevant "status" options as determined by the available CampaignMemberStatus options associated with the chosen Campaign's Id. 

  This could be trivially done via the following pseudoish-code and enabled/disabled with kss::

   >>> campaign_member_statuses = salesforce.query(['Id','Label',],'CampaignMemberStatus', "CampaignId == '%s'" % self.campaign_id)
   >>> [(k,v) for k,v in campaign_member_statuses['results']]

