It would be great if we could sell sponsorships automatically through the site and have sponsors submit a sponsorship node unpublished (to be approved later) as part of the checkout process.

We should make it easy to see sponsorship privileges before buying.

uc_node_checkout might come into play here.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ezra-g’s picture

If each sponsorship level is a product node, we can add a CCK radio field for each sponsorship benefit. This would make it easy to automatically generate a table showing sponsorship level and included benefits, without having to manually create or update it.

We should provide a prompt letting people know which sponsor assets they'll have to provide. We can probably make some of these optional by default so we can still collect money if someone doesn't have the right logo file available, for example.

ezra-g’s picture

We could also include a "Buy now" link in the table.

lisarex’s picture

The only caveat is that this will probably end up being quite a wide table (not unlike a finished conference schedule table, though). Many sponsorship benefits will be the same regardless of the level, so we may be able to describe them in the view header and only table-ize the unique ones. I guess it depends on how many benefits there are...

Definitely include a Buy button next to each Sponsorship "product" to make it easy for them proceed.

We may need to limit the columns on this view, but of course if the potential sponsors wants to click through to the product node, they can buy from there too.

ezra-g’s picture

Status: Active » Needs review
FileSize
8.25 KB

Here's a start. You still need to create a 'sponsorship' product class, add some products, and configure uc_node_checkout.

ezra-g’s picture

Status: Needs review » Needs work

This is out of sync with the latest work for DrupalCon Chicago, where this feature was built. Also, this arguably be postponed for #1010020: Replace "sponsor" references with "organization".

DrewMathers’s picture

Even if sponsors can purchase their own sponsorships, the event administrator should still be able to reject potential sponsors. There are a couple of possible ways of doing this.

1. Have prospective sponsors Apply for Role: Sponsors. Then use Signup Restrict by Role to allow only members of the Sponsors role to purchase sponsorship nodes. (Using Ubercart to restrict purchase by role turns out to be very hard.)

2. Integrate Node Published into the existing sponsor approval system. I believe this module will allow you to change the Ubercart order status based on the node published/unpublished status.

JSCSJSCS’s picture

I'm new to COD and looking at selling conference sponsorships online and I like Drew's suggestions in #6. I like the workflow that requires the prospective sponsor to request to be a sponsor and get approved before any other actions can be taken. (Jump to "So this is where I need some suggestions:" below if you don't want to read all this...)

To try this out:
1.) I created a "Platinum Sponsor" event (I probably should have used product content type and added Signup).

2.) I created the "sponsors" role.

3.) I added and enabled the simple "apply for role" module (http://drupal.org/project/apply_for_role). (I'd like this module to have a text field to enter some reasoning for applying, but alas.)

4.) In the administration settings (admin/settings/apply_for_role), I enabled the "sponsors" role.

5.) I added and enabled the Signup Restrict by Role (http://drupal.org/project/signup_restrict_by_role) and set Restrict access to certain Roles to "sponsors" in the node for the "Platinum Sponsor" Event.

6.) Since the Signup Restrict by Role module does not hide the actual node (Ubercart shows Add to Cart instead of Signup), I needed a way to hide this node from other users.

7.) so I added and enabled the Content Access Module (http://drupal.org/project/content_access), enabled "per node" access and set the "Platinum Sponsor" event to only the "sponsor" role.

So the workflow:
A.) the prospective sponsor registers on the site and clicks a "Become a Sponsor" link of some type and "applies" for the sponsor role.

B.) a privileged user approves (or disapproves) the application and an email is sent with directions on where to go to signup for (buy) the "Platinum Sponsor" event.

C.) the prospective sponsor logs in and signs up for (buys) the particular sponsor level.

D.) after successful check out, the user is directed to a node to fill out the sponsor details pending approval.

So this is where I need some suggestions:

They are already registered users, but I want the sponsors to create and fill out their own sponsor page, upload images, fill out description, and other fields, etc. and have that node unpublished pending approval.

Any suggestions on how to proceed? The default sponsor node has selections for "sponsor" levels (platinum, bronze, etc.) We can't let sponsors change their level. The more I think about it the more confused I get.

DrewMathers’s picture

I want the sponsors to create and fill out their own sponsor page, upload images, fill out description, and other fields, etc.

The Node Checkout module can do this.

and have that node unpublished pending approval.

The Node Published module will leave the sponsor's node unpublished until payment clears. Presumably the sponsor has already been approved before being allowed to purchase a sponsorship.

Note that my suggestion no 2 in comment no 6 is unfeasible. The Node published module uses the published/unpublished status, whereas the COD sponsor approval system uses a CCK field.

I did not consider that Signup Restrict by Role would block Signups but still allow an item to be added to the cart. As you are using Content Access to prevent the sponsorship item being displayed, Signup Restrict by Role isn't really getting you anything extra. Another option would be UC Members Only. Contrary to my previous statement about not being able to restrict Ubercart purchases, it allows you to display prices or not, or allow purchase or not based on roles.

JSCSJSCS’s picture

Thanks Drew for the reply. I think I read all the UC_Node_Checkout info I can find. It seems that COD is centered on UC_Signup and the Signup module. UC_Node_Checkout seems to be another means to an end...that being registering attendees. UC_Signup adds a signup for items added to the cart and checked out. UC_Node_Checkout automatically adds items to the cart when the node is filled out. I'm not sure if they will work together for this purpose.

The UC_Node_Checkout documentation says to not put a link to the cart item, but rather link to the UC_Node_Checkout node. Filling out the node and saving will put the item in the cart. If UC_Node_Checkout and UC_Signup are both used, I wonder if the signup will also be posted correctly.

I guess I will have to do some testing.

DrewMathers’s picture

I recommend keeping the attendee registration (UC Signup) completely separate from the sponsorship purchase (UC Node Checkout). Sponsors might not even be attendees at all. For the reasons you stated, these two modules should not be attached to the same content type. I am hoping that UC Node Checkout is flexible enough that the type of node it creates can be used for anything. You can think of selling sponsorship nodes through Node Checkout as like selling advertisements on your site, except that sponsors can edit their own "ads".

michellezeedru’s picture

Great thread - I'm working on setting this up myself using Node Checkout and Node Published. I've used this before for conference sponsorship and it works fine -- except for one icky step I can't get around:

I have one content type "Sponsor", connected to a product with 4 options/prices - Platinum, Gold, Silver and Bronze. This works fine except when it comes to creating the page that shows the sponsors. Using views, I'd like to group the page by sponsor level, showing the Platinum first, then Gold, etc. In views, I've tried every way I could think of, but can not get a hold of the product attribute to call it for grouping or any other purpose in views.

In the past, I just added a CCK field that duplicates the product options, but that looks dumb in the UI, and allows sponsors to call themselves platinum and pay for only bronze if they want.

I suppose I could get around this by creating 4 separate content types and 4 separate products. Not an optimal option, but I don't see any other way. Any ideas for this? I know this is probably a UC issue, but thought some COD people may have figured out this problem. Thanks!

JSCSJSCS’s picture

michellezeedru,

I am still working on my COD conference site and just resolved a similar issue. The default for the sponsor selections in Alpha 3 is:
Platinum
Gold
Silver
Bronze

I changed this to:
0|Platinum
1|Gold
2|Silver
3|Bronze

Then you can add a sort criteria on that sponsor level field (ascending) AND organizartion name (or random) and you will be able to show it correctly. I think this shuld be the default for COD.

Instead of node published, I added two fields (order_status and order_id) and used a PHP conditional action to set those (and sponsor level) if a successful checkout occured. (see http://drupaleasy.com/blogs/ultimike/2009/03/event-registration-ubercart...)

I am still working on trying to use the single sponsor content type and associate it with many products (platinum, silver, etc.). I found this:

"This was the whole reason Views support was added. With Views 2 installed, create a View that will list any product node you want to associate with a node type form in the View's default display. When any matching product is added to the cart, the customer will be redirected to the node add form." from http://drupal.org/node/497928, but do not quite understand what it is trying to explain. I guess I will in time.

ezra-g’s picture

Status: Needs work » Needs review
FileSize
22.06 KB

Here's an update on this feature, based somewhat on the work from the DrupalCon Chicago site with some other tweaks. I suspect this will need one more re-roll before it is RTBC.

Note, you may need to Update to the most recent Ubercart dev version.

Steps to test:
- Enable cod_sponsor_sales feature
- Create sponsorship product
- Be sure to set sponsorship level for the product

- As a non-admin browse to sponsorships/become-sponsor, purchase the sponsorship product, checkout and pay

- As an administrator (ideally a sponsor manager) verify that the created sponsor node has the correct sponsorship level (same as the sponsorship product purchased), and is unpublished.
- Publish the new sponsor node.

coltrane’s picture

Status: Needs review » Needs work

Once I updated to the latest dev release of UC Signup I was able to get through the cart page, however I was not prompted for any details for the sponsorship node, like title or body.

ezra-g’s picture

I think this might be a documentation issue. To be tackled at the next sprint!

ezra-g’s picture

Status: Needs work » Needs review
FileSize
22.89 KB

This patch saves some values to the {uc_node_checkout_types} table when the feature is enabled.

coltrane’s picture

Status: Needs review » Needs work

Couple issues:

* The permission "create sponsor content" was not granted in the Feature to any roles, so users would 403 when trying to purchase sponsorship
* Only the title and body were on the sponsor node I created, no other fields
* The sponsor node was published right after purchase, instead of being unpublished as mentioned it should be in #13

coltrane’s picture

Status: Needs work » Needs review
FileSize
28.17 KB

#16 with fixes for #17 done to cod_sponsors feature.

ezra-g’s picture

Re-rolled #18 to remove the image field from the sponsorship product, since this is part of the sponsor node. I think this is RTBC.

coltrane’s picture

Status: Needs review » Reviewed & tested by the community

Followed steps in #13 without issue. There's a small amount of custom code and it looks okay. RTBFC!

ezra-g’s picture

Status: Reviewed & tested by the community » Fixed

This is committed. COD sites now print money. Thanks!

http://drupalcode.org/project/cod_support.git/commit/4b3e043

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.