RSVP/Event registration system integrating the Plone content management system with the Salesforce.com customer relationship management system.
Project description
Salesforce RSVP
===============
Product home is
http://plone.org/products/collective.salesforce.rsvp
A `documentation area`_ and `issue
tracker`_ are available at
the linked locations.
.. _documentation area: http://plone.org/products/collective.salesforce.rsvp/documentation
.. _issue tracker: http://plone.org/products/collective.salesforce.rsvp/issues
A Google Group, called `Plone Salesforce Integration`_
exists with the sole aim of discussing and developing tools to make Plone integrate well
with Salesforce.com. If you have a question, joining this group and posting to the
mailing list is the likely best way to get support.
.. _Plone Salesforce Integration: http://groups.google.com/group/plonesf
Failing that, please try using the Plone users' mailing list or the #plone irc channel for
support requests. If you are unable to get your questions answered there, or are
interested in helping develop the product, see the credits below for
individuals you might contact.
Overview
========
Using Plone's Archetypes system and archetypes.schemaextender, the Salesforce
RSVP add-on product enables a mechanism for "marking" pieces of content as eligible
to accept RSVPs (i.e. registrations) from site visitors. The act of "marking" content
extends the existing piece of content with several additional fields for custom RSVP
behaviors.
However, this is not a generic RSVP/registration system,
but as the name suggests, is optimized to work with the Salesforce.com
Customer Relationship Management system, which is a generic system
that can be used to manage Leads, Contacts, Campaigns, and Events. By default,
registrants are stored as Lead objects with an associated CampaignMember object
serving as the "junction" between an organization's configured "Campaign"
and those interested in participating. This can be useful in cases of in person
and/or virtual events (i.e. a training, a conference, a political rally, etc.) and
online campaigns allowing participant sign-on (signature drives, pledge drives, etc.).
The default behavior of creating a Lead and CampaignMember associated with the
configured Campaign can be fully customized with the optional add-on Plone products
PloneFormGen (and dependencies) and Salesforce PFG Adapter.
Features of Salesforce RSVP include:
- Complete integration with the robust and powerful CRM system Salesforce.com
- Ability to mark and configure any Archetypes content object as RSVP-aware
- Default registration form requiring minimal attendee information and completely free of complex configuration demands.
- Optional maximum capacity for RSVP-enabled activities
- Optional acceptance of "waitlist" registrations in the event of cancellations
- Optional expiration date for the automatic disabling of RSVP
- Ability to model "first come first served" or "apply for acceptance after further consideration" type events. This can be done by setting the default signup "status" from within Salesforce.com for the RSVP-enabled event (i.e. the status for a newly created CampaignMember could be "sent", "applied", "responded", etc. depending upon how event attendance is modeled in each case.
- Optional Add-on Capability: Using PloneFormGen with Salesforce PFG Adapter create enhanced and completely customizable registration forms requesting and/or requiring arbitrary sign-up data that can be mapped to arbitrary Salesforce.com objects. The referring "RSVP" accepting Salesforce.com object id is passed to the custom form for appropriate association.
What this isn't...
==================
... and may or may not ever be:
- A general, feature complete ticketing, online registration system. This is simple and optimized to integrate well with Salesforce.com and is optimized towards events with a flexible amount of capacity. While one can certainly use this to lock down capacity a bit more tightly, the burden is upon a correct configuration of the capacity related fields.
- A system for accepting online payment to secure event attendance -- though we're placing bets internally on how long it will be until this feature is requested.
- A fail safe system for absolutely capping attendance at a hard capacity. Because a greater than max capacity # of participants could load a custom PloneFormGen-based registration form (or the default registration form for that matter) that suggests available capacity, we advise you to set expectations appropriately during the signup process and via any auto-response emails that are sent. In other words, text like the following goes a long way towards expectation management: "Thanks for expressing your interest in attending our event. A follow-up email will be sent within 24 hours confirming your space for the event."
INSTALL
=======
See ./docs/INSTALL.txt
Known Problems
==============
The following are known problems:
The version of ATReferenceBrowserWidget that ships with Plone 3.0.x does
not allow users to "Remove reference" for Archetype ReferenceFields where
only one value can be added. This has been fixed in the trunk of
ATReferenceBrowserWidget and should be included with the Plone 3.1 release cycle.
In the meantime, you need to patch your Plone site's with the following if you
would like your users to be able to both set AND remove references to custom
PloneFormGen registration forms::
$ svn diff
Index: referencebrowser.pt
===================================================================
--- referencebrowser.pt (revision 9525)
+++ referencebrowser.pt (working copy)
@@ -176,6 +176,13 @@
onClick=""
i18n:attributes="value label_add;"
tal:attributes="onClickstring:javascript:referencebrowser_openBrowser('${startup_directory}','${fieldName}', '${at_url}', '${fieldRealName}')" />
+ <input type="button"
+ class="destructive"
+ value="Remove reference"
+ onClick=""
+ i18n:attributes="value label_remove_reference;"
+ tal:condition="not: multiVal"
+ tal:attributes="onClick string:javascript:referencebrowser_removeReference('${fieldName}', ${multiVal})" />
</div>
<!-- Todo? -->
<metal:addable metal:use-macro="here/widgets/addable_support/macros/addable"/>
Complete and utter lockdown of registrations to RSVP-enabled content
after max capacity is exceeded is difficult and not supported at this time.
Communicate accordingly and see "What this isn't..." above. The accuracy of
availability can be further decreased if you aggressively cache the HTML
Credits
=======
The Plone & Salesforce crew in Seattle and Portland:
- Jon Baldivieso <jonb --AT-- onenw --DOT-- org>
- Andrew Burkhalter <andrewb --AT-- onenw --DOT-- org>
- Brian Gershon <briang --AT-- webcollective --DOT-- coop>
- David Glick <davidglick --AT-- onenw --DOT-- org>
- Jesse Snyder <jesses --AT-- npowerseattle --DOT-- org>
Salesforce.com Foundation and Enfold Systems for their gift and work on beatbox
and the original proof of concept code that has become Salesforce Auth Plugin (see:
http://gokubi.com/archives/onenorthwest-gets-grant-from-salesforcecom-to-integrate-with-plone)
See the ./docs/HISTORY.txt file for the growing list of people who helped
with particular features or bugs.
License
=======
Distributed under the GPL.
See ./docs/LICENSE.txt and ./docs/LICENSE.GPL for details.
Running Tests
=============
It is strongly recommended that you run your tests
against a free developer account, rather than a real
production Salesforce.com instance. ... With that said,
to run the tests for Salesforce Auth Plugin do the following:
=======================================
Configure your Salesforce.com instance:
=======================================
In order to successfully run all of the automated unit tests,
some modifications need to happen within your Salesforce.com
instance.
In many of the tests, a dummy campaign within your Salesforce.com
instance is created. In a few cases, we test the logic for presentation
of the registration/waitlist signup/registration closed options for the
RSVP-enabled content object. This assumes that the following fields have
been added to the "Campaign" object via Setup --> Customize --> Campaigns
--> Fields --> "New" button under "Campaign Custom Fields & Relationships"::
Field Label Field Name Field Type Field Description
----------- ---------- ---------- -----------------
Allow Waitlists? Allow_Waitlists Checkbox Will you accept waitlist
registrations for this campaign?
Only required if you plan to enable
RSVPs in a capacity limited way
via your website.
Max Capacity MaxCapacity Number(18, 0)
Note: You can accept the defaults for the other field attributes.
=====
Read:
=====
Running Tests --> "To run tests in a unix-like environment" from
`SalesforceBaseConnector`_, which is a dependency, so you should have it :)
.. _SalesforceBaseConnector: http://plone.org/products/salesforcebaseconnector
=================
Do the following:
=================
Rather than running the test suite for salesforcebaseconnector
do the following:
$INSTANCE/bin/zopectl test -s collective.salesforce.rsvp
=======================
FAQ about running tests
=======================
If you have trouble running tests, consult "FAQ about running tests" from
SalesforceBaseConnector.
Detailed Documentation
**********************
Salesforce RSVP
===============
Product home is
http://plone.org/products/collective.salesforce.rsvp
A `documentation area`_ and `issue
tracker`_ are available at
the linked locations.
.. _documentation area: http://plone.org/products/collective.salesforce.rsvp/documentation
.. _issue tracker: http://plone.org/products/collective.salesforce.rsvp/issues
A Google Group, called `Plone Salesforce Integration`_
exists with the sole aim of discussing and developing tools to make Plone integrate well
with Salesforce.com. If you have a question, joining this group and posting to the
mailing list is the likely best way to get support.
.. _Plone Salesforce Integration: http://groups.google.com/group/plonesf
Failing that, please try using the Plone users' mailing list or the #plone irc channel for
support requests. If you are unable to get your questions answered there, or are
interested in helping develop the product, see the credits below for
individuals you might contact.
Overview
========
Using Plone's Archetypes system and archetypes.schemaextender, the Salesforce
RSVP add-on product enables a mechanism for "marking" pieces of content as eligible
to accept RSVPs (i.e. registrations) from site visitors. The act of "marking" content
extends the existing piece of content with several additional fields for custom RSVP
behaviors.
However, this is not a generic RSVP/registration system,
but as the name suggests, is optimized to work with the Salesforce.com
Customer Relationship Management system, which is a generic system
that can be used to manage Leads, Contacts, Campaigns, and Events. By default,
registrants are stored as Lead objects with an associated CampaignMember object
serving as the "junction" between an organization's configured "Campaign"
and those interested in participating. This can be useful in cases of in person
and/or virtual events (i.e. a training, a conference, a political rally, etc.) and
online campaigns allowing participant sign-on (signature drives, pledge drives, etc.).
The default behavior of creating a Lead and CampaignMember associated with the
configured Campaign can be fully customized with the optional add-on Plone products
PloneFormGen (and dependencies) and Salesforce PFG Adapter.
Features of Salesforce RSVP include:
- Complete integration with the robust and powerful CRM system Salesforce.com
- Ability to mark and configure any Archetypes content object as RSVP-aware
- Default registration form requiring minimal attendee information and completely free of complex configuration demands.
- Optional maximum capacity for RSVP-enabled activities
- Optional acceptance of "waitlist" registrations in the event of cancellations
- Optional expiration date for the automatic disabling of RSVP
- Ability to model "first come first served" or "apply for acceptance after further consideration" type events. This can be done by setting the default signup "status" from within Salesforce.com for the RSVP-enabled event (i.e. the status for a newly created CampaignMember could be "sent", "applied", "responded", etc. depending upon how event attendance is modeled in each case.
- Optional Add-on Capability: Using PloneFormGen with Salesforce PFG Adapter create enhanced and completely customizable registration forms requesting and/or requiring arbitrary sign-up data that can be mapped to arbitrary Salesforce.com objects. The referring "RSVP" accepting Salesforce.com object id is passed to the custom form for appropriate association.
What this isn't...
==================
... and may or may not ever be:
- A general, feature complete ticketing, online registration system. This is simple and optimized to integrate well with Salesforce.com and is optimized towards events with a flexible amount of capacity. While one can certainly use this to lock down capacity a bit more tightly, the burden is upon a correct configuration of the capacity related fields.
- A system for accepting online payment to secure event attendance -- though we're placing bets internally on how long it will be until this feature is requested.
- A fail safe system for absolutely capping attendance at a hard capacity. Because a greater than max capacity # of participants could load a custom PloneFormGen-based registration form (or the default registration form for that matter) that suggests available capacity, we advise you to set expectations appropriately during the signup process and via any auto-response emails that are sent. In other words, text like the following goes a long way towards expectation management: "Thanks for expressing your interest in attending our event. A follow-up email will be sent within 24 hours confirming your space for the event."
INSTALL
=======
See ./docs/INSTALL.txt
Known Problems
==============
The following are known problems:
The version of ATReferenceBrowserWidget that ships with Plone 3.0.x does
not allow users to "Remove reference" for Archetype ReferenceFields where
only one value can be added. This has been fixed in the trunk of
ATReferenceBrowserWidget and should be included with the Plone 3.1 release cycle.
In the meantime, you need to patch your Plone site's with the following if you
would like your users to be able to both set AND remove references to custom
PloneFormGen registration forms::
$ svn diff
Index: referencebrowser.pt
===================================================================
--- referencebrowser.pt (revision 9525)
+++ referencebrowser.pt (working copy)
@@ -176,6 +176,13 @@
onClick=""
i18n:attributes="value label_add;"
tal:attributes="onClickstring:javascript:referencebrowser_openBrowser('${startup_directory}','${fieldName}', '${at_url}', '${fieldRealName}')" />
+ <input type="button"
+ class="destructive"
+ value="Remove reference"
+ onClick=""
+ i18n:attributes="value label_remove_reference;"
+ tal:condition="not: multiVal"
+ tal:attributes="onClick string:javascript:referencebrowser_removeReference('${fieldName}', ${multiVal})" />
</div>
<!-- Todo? -->
<metal:addable metal:use-macro="here/widgets/addable_support/macros/addable"/>
Complete and utter lockdown of registrations to RSVP-enabled content
after max capacity is exceeded is difficult and not supported at this time.
Communicate accordingly and see "What this isn't..." above. The accuracy of
availability can be further decreased if you aggressively cache the HTML
Credits
=======
The Plone & Salesforce crew in Seattle and Portland:
- Jon Baldivieso <jonb --AT-- onenw --DOT-- org>
- Andrew Burkhalter <andrewb --AT-- onenw --DOT-- org>
- Brian Gershon <briang --AT-- webcollective --DOT-- coop>
- David Glick <davidglick --AT-- onenw --DOT-- org>
- Jesse Snyder <jesses --AT-- npowerseattle --DOT-- org>
Salesforce.com Foundation and Enfold Systems for their gift and work on beatbox
and the original proof of concept code that has become Salesforce Auth Plugin (see:
http://gokubi.com/archives/onenorthwest-gets-grant-from-salesforcecom-to-integrate-with-plone)
See the ./docs/HISTORY.txt file for the growing list of people who helped
with particular features or bugs.
License
=======
Distributed under the GPL.
See ./docs/LICENSE.txt and ./docs/LICENSE.GPL for details.
Running Tests
=============
It is strongly recommended that you run your tests
against a free developer account, rather than a real
production Salesforce.com instance. ... With that said,
to run the tests for Salesforce Auth Plugin do the following:
=======================================
Configure your Salesforce.com instance:
=======================================
In order to successfully run all of the automated unit tests,
some modifications need to happen within your Salesforce.com
instance.
In many of the tests, a dummy campaign within your Salesforce.com
instance is created. In a few cases, we test the logic for presentation
of the registration/waitlist signup/registration closed options for the
RSVP-enabled content object. This assumes that the following fields have
been added to the "Campaign" object via Setup --> Customize --> Campaigns
--> Fields --> "New" button under "Campaign Custom Fields & Relationships"::
Field Label Field Name Field Type Field Description
----------- ---------- ---------- -----------------
Allow Waitlists? Allow_Waitlists Checkbox Will you accept waitlist
registrations for this campaign?
Only required if you plan to enable
RSVPs in a capacity limited way
via your website.
Max Capacity MaxCapacity Number(18, 0)
Note: You can accept the defaults for the other field attributes.
=====
Read:
=====
Running Tests --> "To run tests in a unix-like environment" from
`SalesforceBaseConnector`_, which is a dependency, so you should have it :)
.. _SalesforceBaseConnector: http://plone.org/products/salesforcebaseconnector
=================
Do the following:
=================
Rather than running the test suite for salesforcebaseconnector
do the following:
$INSTANCE/bin/zopectl test -s collective.salesforce.rsvp
=======================
FAQ about running tests
=======================
If you have trouble running tests, consult "FAQ about running tests" from
SalesforceBaseConnector.
Change history
**************
Changelog for collective.salesforce.rsvp
(name of developer listed in brackets)
collective.salesforce.rsvp - 1.0a1
- Initial experimental release of Salesforce RSVP feature allowing for
Plone content objects to be tied to "registerable" Salesforce.com objects [andrewb]
Todo
************
TODOs
=====
The initial 1.0a1 release of Salesforce RSVP 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.
Additional potential enhancements:
- 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']]
Download
********
===============
Product home is
http://plone.org/products/collective.salesforce.rsvp
A `documentation area`_ and `issue
tracker`_ are available at
the linked locations.
.. _documentation area: http://plone.org/products/collective.salesforce.rsvp/documentation
.. _issue tracker: http://plone.org/products/collective.salesforce.rsvp/issues
A Google Group, called `Plone Salesforce Integration`_
exists with the sole aim of discussing and developing tools to make Plone integrate well
with Salesforce.com. If you have a question, joining this group and posting to the
mailing list is the likely best way to get support.
.. _Plone Salesforce Integration: http://groups.google.com/group/plonesf
Failing that, please try using the Plone users' mailing list or the #plone irc channel for
support requests. If you are unable to get your questions answered there, or are
interested in helping develop the product, see the credits below for
individuals you might contact.
Overview
========
Using Plone's Archetypes system and archetypes.schemaextender, the Salesforce
RSVP add-on product enables a mechanism for "marking" pieces of content as eligible
to accept RSVPs (i.e. registrations) from site visitors. The act of "marking" content
extends the existing piece of content with several additional fields for custom RSVP
behaviors.
However, this is not a generic RSVP/registration system,
but as the name suggests, is optimized to work with the Salesforce.com
Customer Relationship Management system, which is a generic system
that can be used to manage Leads, Contacts, Campaigns, and Events. By default,
registrants are stored as Lead objects with an associated CampaignMember object
serving as the "junction" between an organization's configured "Campaign"
and those interested in participating. This can be useful in cases of in person
and/or virtual events (i.e. a training, a conference, a political rally, etc.) and
online campaigns allowing participant sign-on (signature drives, pledge drives, etc.).
The default behavior of creating a Lead and CampaignMember associated with the
configured Campaign can be fully customized with the optional add-on Plone products
PloneFormGen (and dependencies) and Salesforce PFG Adapter.
Features of Salesforce RSVP include:
- Complete integration with the robust and powerful CRM system Salesforce.com
- Ability to mark and configure any Archetypes content object as RSVP-aware
- Default registration form requiring minimal attendee information and completely free of complex configuration demands.
- Optional maximum capacity for RSVP-enabled activities
- Optional acceptance of "waitlist" registrations in the event of cancellations
- Optional expiration date for the automatic disabling of RSVP
- Ability to model "first come first served" or "apply for acceptance after further consideration" type events. This can be done by setting the default signup "status" from within Salesforce.com for the RSVP-enabled event (i.e. the status for a newly created CampaignMember could be "sent", "applied", "responded", etc. depending upon how event attendance is modeled in each case.
- Optional Add-on Capability: Using PloneFormGen with Salesforce PFG Adapter create enhanced and completely customizable registration forms requesting and/or requiring arbitrary sign-up data that can be mapped to arbitrary Salesforce.com objects. The referring "RSVP" accepting Salesforce.com object id is passed to the custom form for appropriate association.
What this isn't...
==================
... and may or may not ever be:
- A general, feature complete ticketing, online registration system. This is simple and optimized to integrate well with Salesforce.com and is optimized towards events with a flexible amount of capacity. While one can certainly use this to lock down capacity a bit more tightly, the burden is upon a correct configuration of the capacity related fields.
- A system for accepting online payment to secure event attendance -- though we're placing bets internally on how long it will be until this feature is requested.
- A fail safe system for absolutely capping attendance at a hard capacity. Because a greater than max capacity # of participants could load a custom PloneFormGen-based registration form (or the default registration form for that matter) that suggests available capacity, we advise you to set expectations appropriately during the signup process and via any auto-response emails that are sent. In other words, text like the following goes a long way towards expectation management: "Thanks for expressing your interest in attending our event. A follow-up email will be sent within 24 hours confirming your space for the event."
INSTALL
=======
See ./docs/INSTALL.txt
Known Problems
==============
The following are known problems:
The version of ATReferenceBrowserWidget that ships with Plone 3.0.x does
not allow users to "Remove reference" for Archetype ReferenceFields where
only one value can be added. This has been fixed in the trunk of
ATReferenceBrowserWidget and should be included with the Plone 3.1 release cycle.
In the meantime, you need to patch your Plone site's with the following if you
would like your users to be able to both set AND remove references to custom
PloneFormGen registration forms::
$ svn diff
Index: referencebrowser.pt
===================================================================
--- referencebrowser.pt (revision 9525)
+++ referencebrowser.pt (working copy)
@@ -176,6 +176,13 @@
onClick=""
i18n:attributes="value label_add;"
tal:attributes="onClickstring:javascript:referencebrowser_openBrowser('${startup_directory}','${fieldName}', '${at_url}', '${fieldRealName}')" />
+ <input type="button"
+ class="destructive"
+ value="Remove reference"
+ onClick=""
+ i18n:attributes="value label_remove_reference;"
+ tal:condition="not: multiVal"
+ tal:attributes="onClick string:javascript:referencebrowser_removeReference('${fieldName}', ${multiVal})" />
</div>
<!-- Todo? -->
<metal:addable metal:use-macro="here/widgets/addable_support/macros/addable"/>
Complete and utter lockdown of registrations to RSVP-enabled content
after max capacity is exceeded is difficult and not supported at this time.
Communicate accordingly and see "What this isn't..." above. The accuracy of
availability can be further decreased if you aggressively cache the HTML
Credits
=======
The Plone & Salesforce crew in Seattle and Portland:
- Jon Baldivieso <jonb --AT-- onenw --DOT-- org>
- Andrew Burkhalter <andrewb --AT-- onenw --DOT-- org>
- Brian Gershon <briang --AT-- webcollective --DOT-- coop>
- David Glick <davidglick --AT-- onenw --DOT-- org>
- Jesse Snyder <jesses --AT-- npowerseattle --DOT-- org>
Salesforce.com Foundation and Enfold Systems for their gift and work on beatbox
and the original proof of concept code that has become Salesforce Auth Plugin (see:
http://gokubi.com/archives/onenorthwest-gets-grant-from-salesforcecom-to-integrate-with-plone)
See the ./docs/HISTORY.txt file for the growing list of people who helped
with particular features or bugs.
License
=======
Distributed under the GPL.
See ./docs/LICENSE.txt and ./docs/LICENSE.GPL for details.
Running Tests
=============
It is strongly recommended that you run your tests
against a free developer account, rather than a real
production Salesforce.com instance. ... With that said,
to run the tests for Salesforce Auth Plugin do the following:
=======================================
Configure your Salesforce.com instance:
=======================================
In order to successfully run all of the automated unit tests,
some modifications need to happen within your Salesforce.com
instance.
In many of the tests, a dummy campaign within your Salesforce.com
instance is created. In a few cases, we test the logic for presentation
of the registration/waitlist signup/registration closed options for the
RSVP-enabled content object. This assumes that the following fields have
been added to the "Campaign" object via Setup --> Customize --> Campaigns
--> Fields --> "New" button under "Campaign Custom Fields & Relationships"::
Field Label Field Name Field Type Field Description
----------- ---------- ---------- -----------------
Allow Waitlists? Allow_Waitlists Checkbox Will you accept waitlist
registrations for this campaign?
Only required if you plan to enable
RSVPs in a capacity limited way
via your website.
Max Capacity MaxCapacity Number(18, 0)
Note: You can accept the defaults for the other field attributes.
=====
Read:
=====
Running Tests --> "To run tests in a unix-like environment" from
`SalesforceBaseConnector`_, which is a dependency, so you should have it :)
.. _SalesforceBaseConnector: http://plone.org/products/salesforcebaseconnector
=================
Do the following:
=================
Rather than running the test suite for salesforcebaseconnector
do the following:
$INSTANCE/bin/zopectl test -s collective.salesforce.rsvp
=======================
FAQ about running tests
=======================
If you have trouble running tests, consult "FAQ about running tests" from
SalesforceBaseConnector.
Detailed Documentation
**********************
Salesforce RSVP
===============
Product home is
http://plone.org/products/collective.salesforce.rsvp
A `documentation area`_ and `issue
tracker`_ are available at
the linked locations.
.. _documentation area: http://plone.org/products/collective.salesforce.rsvp/documentation
.. _issue tracker: http://plone.org/products/collective.salesforce.rsvp/issues
A Google Group, called `Plone Salesforce Integration`_
exists with the sole aim of discussing and developing tools to make Plone integrate well
with Salesforce.com. If you have a question, joining this group and posting to the
mailing list is the likely best way to get support.
.. _Plone Salesforce Integration: http://groups.google.com/group/plonesf
Failing that, please try using the Plone users' mailing list or the #plone irc channel for
support requests. If you are unable to get your questions answered there, or are
interested in helping develop the product, see the credits below for
individuals you might contact.
Overview
========
Using Plone's Archetypes system and archetypes.schemaextender, the Salesforce
RSVP add-on product enables a mechanism for "marking" pieces of content as eligible
to accept RSVPs (i.e. registrations) from site visitors. The act of "marking" content
extends the existing piece of content with several additional fields for custom RSVP
behaviors.
However, this is not a generic RSVP/registration system,
but as the name suggests, is optimized to work with the Salesforce.com
Customer Relationship Management system, which is a generic system
that can be used to manage Leads, Contacts, Campaigns, and Events. By default,
registrants are stored as Lead objects with an associated CampaignMember object
serving as the "junction" between an organization's configured "Campaign"
and those interested in participating. This can be useful in cases of in person
and/or virtual events (i.e. a training, a conference, a political rally, etc.) and
online campaigns allowing participant sign-on (signature drives, pledge drives, etc.).
The default behavior of creating a Lead and CampaignMember associated with the
configured Campaign can be fully customized with the optional add-on Plone products
PloneFormGen (and dependencies) and Salesforce PFG Adapter.
Features of Salesforce RSVP include:
- Complete integration with the robust and powerful CRM system Salesforce.com
- Ability to mark and configure any Archetypes content object as RSVP-aware
- Default registration form requiring minimal attendee information and completely free of complex configuration demands.
- Optional maximum capacity for RSVP-enabled activities
- Optional acceptance of "waitlist" registrations in the event of cancellations
- Optional expiration date for the automatic disabling of RSVP
- Ability to model "first come first served" or "apply for acceptance after further consideration" type events. This can be done by setting the default signup "status" from within Salesforce.com for the RSVP-enabled event (i.e. the status for a newly created CampaignMember could be "sent", "applied", "responded", etc. depending upon how event attendance is modeled in each case.
- Optional Add-on Capability: Using PloneFormGen with Salesforce PFG Adapter create enhanced and completely customizable registration forms requesting and/or requiring arbitrary sign-up data that can be mapped to arbitrary Salesforce.com objects. The referring "RSVP" accepting Salesforce.com object id is passed to the custom form for appropriate association.
What this isn't...
==================
... and may or may not ever be:
- A general, feature complete ticketing, online registration system. This is simple and optimized to integrate well with Salesforce.com and is optimized towards events with a flexible amount of capacity. While one can certainly use this to lock down capacity a bit more tightly, the burden is upon a correct configuration of the capacity related fields.
- A system for accepting online payment to secure event attendance -- though we're placing bets internally on how long it will be until this feature is requested.
- A fail safe system for absolutely capping attendance at a hard capacity. Because a greater than max capacity # of participants could load a custom PloneFormGen-based registration form (or the default registration form for that matter) that suggests available capacity, we advise you to set expectations appropriately during the signup process and via any auto-response emails that are sent. In other words, text like the following goes a long way towards expectation management: "Thanks for expressing your interest in attending our event. A follow-up email will be sent within 24 hours confirming your space for the event."
INSTALL
=======
See ./docs/INSTALL.txt
Known Problems
==============
The following are known problems:
The version of ATReferenceBrowserWidget that ships with Plone 3.0.x does
not allow users to "Remove reference" for Archetype ReferenceFields where
only one value can be added. This has been fixed in the trunk of
ATReferenceBrowserWidget and should be included with the Plone 3.1 release cycle.
In the meantime, you need to patch your Plone site's with the following if you
would like your users to be able to both set AND remove references to custom
PloneFormGen registration forms::
$ svn diff
Index: referencebrowser.pt
===================================================================
--- referencebrowser.pt (revision 9525)
+++ referencebrowser.pt (working copy)
@@ -176,6 +176,13 @@
onClick=""
i18n:attributes="value label_add;"
tal:attributes="onClickstring:javascript:referencebrowser_openBrowser('${startup_directory}','${fieldName}', '${at_url}', '${fieldRealName}')" />
+ <input type="button"
+ class="destructive"
+ value="Remove reference"
+ onClick=""
+ i18n:attributes="value label_remove_reference;"
+ tal:condition="not: multiVal"
+ tal:attributes="onClick string:javascript:referencebrowser_removeReference('${fieldName}', ${multiVal})" />
</div>
<!-- Todo? -->
<metal:addable metal:use-macro="here/widgets/addable_support/macros/addable"/>
Complete and utter lockdown of registrations to RSVP-enabled content
after max capacity is exceeded is difficult and not supported at this time.
Communicate accordingly and see "What this isn't..." above. The accuracy of
availability can be further decreased if you aggressively cache the HTML
Credits
=======
The Plone & Salesforce crew in Seattle and Portland:
- Jon Baldivieso <jonb --AT-- onenw --DOT-- org>
- Andrew Burkhalter <andrewb --AT-- onenw --DOT-- org>
- Brian Gershon <briang --AT-- webcollective --DOT-- coop>
- David Glick <davidglick --AT-- onenw --DOT-- org>
- Jesse Snyder <jesses --AT-- npowerseattle --DOT-- org>
Salesforce.com Foundation and Enfold Systems for their gift and work on beatbox
and the original proof of concept code that has become Salesforce Auth Plugin (see:
http://gokubi.com/archives/onenorthwest-gets-grant-from-salesforcecom-to-integrate-with-plone)
See the ./docs/HISTORY.txt file for the growing list of people who helped
with particular features or bugs.
License
=======
Distributed under the GPL.
See ./docs/LICENSE.txt and ./docs/LICENSE.GPL for details.
Running Tests
=============
It is strongly recommended that you run your tests
against a free developer account, rather than a real
production Salesforce.com instance. ... With that said,
to run the tests for Salesforce Auth Plugin do the following:
=======================================
Configure your Salesforce.com instance:
=======================================
In order to successfully run all of the automated unit tests,
some modifications need to happen within your Salesforce.com
instance.
In many of the tests, a dummy campaign within your Salesforce.com
instance is created. In a few cases, we test the logic for presentation
of the registration/waitlist signup/registration closed options for the
RSVP-enabled content object. This assumes that the following fields have
been added to the "Campaign" object via Setup --> Customize --> Campaigns
--> Fields --> "New" button under "Campaign Custom Fields & Relationships"::
Field Label Field Name Field Type Field Description
----------- ---------- ---------- -----------------
Allow Waitlists? Allow_Waitlists Checkbox Will you accept waitlist
registrations for this campaign?
Only required if you plan to enable
RSVPs in a capacity limited way
via your website.
Max Capacity MaxCapacity Number(18, 0)
Note: You can accept the defaults for the other field attributes.
=====
Read:
=====
Running Tests --> "To run tests in a unix-like environment" from
`SalesforceBaseConnector`_, which is a dependency, so you should have it :)
.. _SalesforceBaseConnector: http://plone.org/products/salesforcebaseconnector
=================
Do the following:
=================
Rather than running the test suite for salesforcebaseconnector
do the following:
$INSTANCE/bin/zopectl test -s collective.salesforce.rsvp
=======================
FAQ about running tests
=======================
If you have trouble running tests, consult "FAQ about running tests" from
SalesforceBaseConnector.
Change history
**************
Changelog for collective.salesforce.rsvp
(name of developer listed in brackets)
collective.salesforce.rsvp - 1.0a1
- Initial experimental release of Salesforce RSVP feature allowing for
Plone content objects to be tied to "registerable" Salesforce.com objects [andrewb]
Todo
************
TODOs
=====
The initial 1.0a1 release of Salesforce RSVP 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.
Additional potential enhancements:
- 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']]
Download
********
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Close
Hashes for collective.salesforce.rsvp-1.0a1.tar.gz
Algorithm | Hash digest | |
---|---|---|
SHA256 | 03ffacf4d058e2468b632ea592ab1599ec29f9da1972da28e8f6563dc625653c |
|
MD5 | 21a4dfb48542c04b606fba1050d6c87d |
|
BLAKE2b-256 | 731729011638cdae6e4e7f61d432a68db510236c880c5b548a09024e00be6d69 |
Close
Hashes for collective.salesforce.rsvp-1.0a1-py2.4.egg
Algorithm | Hash digest | |
---|---|---|
SHA256 | 3dc623764419d1b25f5de8c5c3861ffe69b4d180cbacb79b3bdfd93408e8fc59 |
|
MD5 | 1f4b2b487ee557bca56411851d6137cc |
|
BLAKE2b-256 | cb07f8d2caa68aeddda3e15bc990eae8c7891c02cabf23d17e6d58d5609b4c3b |