Last updated by rootwork on Mon, 2014-06-02 14:33
Specifications for a proposed module "UberFundraiser"
Original Project discussion for the donations suite of modules.
http://groups.drupal.org/node/19893
Final Spec for Uberdonations and EFT
http://groups.drupal.org/node/19981
The proposed module would build upon the previous modules:
http://drupal.org/project/uc_varprice
http://drupal.org/project/uc_op_reports
http://drupal.org/project/uc_atctweaks
http://drupal.org/project/uc_echecknet
Problem Statement:
The (awesome) modules above let us set a variable (donation) price for a particular product class as default change the user interface and add to cart settings as well as provide integration with echecks. What we cannot currently do is to use these donation features in a way to raise monies toward a certain goal.
Proposed new module:
uc_fundraiser
Provide a new collapsible field set at admin/store/products/classes of "Default Fundraiser Features"
Fund Details:
- Provide a select box to select a cck integer field to be used for the "goal" amount.
- Provide a select box to select a cck user reference field to be used for the "fundraiser".
can be used with nodeaccess_userreference for access control - Provide a select box to select a cck node reference field to be used for the "project/campaign".
can be used with nodeaccess_nodereference for access control - Provide a select box to select a cck date field to be used for the "raise by date" value.
- Provide a select box to set if this fund is a "recurring" type. ie the goal amount is to be for recurring donations for monthly (or some other recurring period) donations. Perhaps we could use a date field for this as well with Date Repeat API???
Action to take once goal is met
- Checkbox un-publish product
- Checkbox remove "add to cart" button
- Checkbox select a flag to set (select box of system flags)
Action to take once time is elapsed
- Checkbox un-publish product
- Checkbox remove "add to cart" button
- Checkbox select a flag to set (select box of system flags)
User Interface or Display
- Checkbox show progress thermometer
- Checkbox show countdown to raise by date
- Checkbox show embed code
- Checkbox show customizable text (once selected it will have ways to customize text using the tokens of "goal amount" goal "raise by date" "amount raised" etc...)
Reports
A tab on nodes that show a report of all donors with amounts, dates, etc... Should be a default view that could be editable. This is a report of who gave what when to this product.
ToDo
Find a developer
Find some folks to chipin
Review Features (consider the features of CiviContribute)
Notes
- Just noticed that the e-checks module does not currently support recurring transactions this would need to be added. http://drupal.org/node/641932#comment-2420892
Comments
Drupal Seeder Project
Have you looked at the Drupal Seeder Project?
http://drupaldojo.com/session/drupals-payment-api-and-how-we-built-kicks...
Same but different...
I really like the light weight of this method. However I do not know if it will do what we need.
Perhaps you know something I don't. Is there a way to have these features without needing ubercart?
We are also using some CiviCRM/Ubercart integration modules that are pretty important for our CiviCRM db and would need to reinvent that as well.
I wish Ubercart and Commerce would consider not duplicating the payment api however and instead working with these guys to streamline payments on drupal more. Perhaps there is some technical reason for the duplication. Just saying it would be nice to have a payment api widely used in drupal.
For instance it would be great to have the e-check functionality added earlier work with payment api by default as well as uber/commerce.
Anyhow I don't think for this project it is an option for us. Am I missing something?
Craig Bertrand
Code is code, right?
It's unfair to reject one solution because it's somehow incomplete, and then suggest that the solution is to write a new module. Code is code, right?
I'm not necessarily arguing that you go one way or the other, and it looks like you are weighing your overall options. But it's well worth drawing up a good cost/benefit on a variety of options. I've seen people spend hundreds of hours working around the deficiencies of a given solution when it would only take a few hours to fix it in the first place.
I strongly agree with this, but it takes traction. Right now, there are are at least 4 major modules that are each implementing a variety of variously-incomplete backends. There are literally dozens of payment backends, which means that we're potentially burning 4 * X * dozens of in-demand Drupal talent on duplicate efforts on a moving target. That's silly and introduces a lot of inefficiencies and multiplies the potential for vulnerabilities. The Payment API was specifically designed to address this problem, but until it reaches a certain critical mass, the other developers will not want to depend on it. Thus every backend module, form module, or improvement to Pay will help advance this goal.
E-check functionality would be extremely welcome for Pay, and if that were your only argument, I would find it strange to suggest writing a module that does almost everything that the donate module already does (thus creating "competition") rather than extending the Payment API with more generalized functionality (thus creating leverage for anyone that uses it for any purpose).
As you suggest, the CiviCRM integration adds one more strike against Pay as a viable solution, which does tilt the equation. I would question the necessity for a cart, versus some other multiple-item UI, but if your primary requirement is to add donations to a shopping cart then you're definitely treading outside of this solution's intended purpose.
I guess my point is not that you should use one solution over the other, but rather to be clear about what your goals are, and weigh different solutions against the same set of goals. If what you need is customizable donations forms, goal amounts, progress thermometers, attaching to nodes, support for actions, and views support for reports and date handling, then there's a solution you can build upon today. Building on something that already exists may be easier than waiting until you can gather enough resources to duplicate it.
Actually I was more concerned with the fact that code is money.
How much would it cost me for you to code the e-check and CiviCRM integration. I would love to help you guys gain traction however we obviously have budget constraints and I assumed it would take less hours adding features to the already existing ubercart variable price module/CiviCRM Ubercart Product than it would to have to add all of those features to the pay/donate modules and the e-checks.
If you would like to I would be happy to share with you the specifications for the whole project, but I am worried that it would actually take more code to go the pay route. Having said that I am not a php developer and you may be able to shed some light on something I am missing.
Also what "other multiple-item UI" did you have in mind?
I love what you guys are trying to do with the pay module and I hope it is the standard by drupal 8.
Now on a side note. You said that the developers of ubercart and commerce would not want to rely on the pay module "until it reaches a certain critical mass" I don't understand why this would be so? Couldn't they just adopt it based on the concept of having one payment api? If there were questions of whether or not it would be maintained they could just be added as co-maintainers could they not? I mean if Ubercart and Commerce adopted it they you would by default have critical mass.
I know this is not your choice or something you could make happen. Just seems reasonable to me though.
Thanks for you hard work on the payment api and you input and help to my project.
Craig Bertrand
A few project changes
Okay so CiviCRM integration is no longer an issue. I am building the CRM features we need with content types and node refs. So far working great.
Wouldn't mind dropping the complexity of Ubercart however I am concerned about the ui of multiple donations being made. We will need some "cartish" feature.
Any comments?
Craig Bertrand
Can you elaborate?
I know it seems pretty obvious what a shopping cart does, but can you describe your use case for multiplie donations? There's no technical limitation for Pay to handle this, and the underlying database would be fine with it. But the cost/benefit comes from deciding how much work you'd have to do to "reinvent the cart" for Pay vs. how much work you'd do to "reinvent Donate's payment handling and tracking" for Ubercart/Commerce.
Also, you should totally check out the CRM and CRM-API groups here for some work that's being done on Drupal-native CRMs.