Posted by EvanDonovan on July 10, 2010 at 6:46pm
1 follower
Jump to:
| Project: | CiviCRM Subscribe |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | task |
| Priority: | normal |
| Assigned: | EvanDonovan |
| Status: | closed (won't fix) |
Issue Summary
Once #249530: CiviCRM 2.1+ compatibility is complete, then I will start considering what other features would be necessary for the full release.
I believe that the version of the module I currently am using live on http://www.urbanministry.org has forked from the version that will be 6.x-1.x-beta, so I'll have to decide how many, if any, of the differences should go back in to the full release. Basically, I think I have uncommented some of the code which is commented out in the patch in #249530: CiviCRM 2.1+ compatibility.
Also the 2 feature requests currently in the queue will come in for discussion.
Comments
#1
Postponed on #850452: Release 6.x-1.x-beta.
#2
6.x-1.0 is going to be a bug fix release only. If there are no reports of issues with 6.x-1.0-beta1, it may be very similar to it (just some code cleanup, etc.).
New features will be in 6.x-1.1, so this is still postponed (now on the release of 6.x-1.0).
Here are some features to consider:
* ability to bypass CiviCRM subscription API so that emails would not be sent, and people could be added to hidden groups (this would help address #459746: Make it possible to bypass CiviCRM's standard subscription process, thus preventing standard CiviCRM emails from going out)
* subscription blocks
* integration with spam control, like CAPTCHA module & Mollom, to prevent bogus submissions
* ability to collect additional profile data (this might be out-of-scope, but I might do it anyway, since I have a project that could use it; could potentially integrate with Webform (3.0?) instead however)
Anyone who is still using this module let me know what features would be of most interest.
#3
A possible reason not to add CAPTCHA to a signup form would be that it would make it harder for people to sign up legitimately, and an email address is hard to check to see whether it is spam or not.
Two possible alternatives (both could be implemented simultaneously):
* a "honeypot" field that would be invisible & would make form submission fail if data was entered into it
* validation of the MX record to see that the email address actually exists
#4
I think that the feature set should be minimal for this module. The full 1.0 release will just contain the following:
* CiviCRM Subscribe Blocks per group (stable, pending testing)
-- Prior to doing this, lots of the additional currently unused functionality will need to be stripped out of the module
A 1.1 release would add:
* CiviCRM Subscribe Block, with the ability for the user to select which groups
* honeypot for form submission failure
1.2 (which may never happen, depending on my time & other's interest) would add:
* ability to bypass the CiviCRM Subscription process (this would address #459746: Make it possible to bypass CiviCRM's standard subscription process, thus preventing standard CiviCRM emails from going out)
* First Name & Last Name fields
#5
I'm planning on deprecating this module as soon as the CiviCRM Webform Integration comes out, so this is no longer applicable.