I'll look into it... not entirely sure what's going on. Also, not sure if this is related to what you're doing or not, but there is an inherent limitation in the way recurring fees work alongside of role promotions atm... there is no default way to match one up to the other so that the recurring payment "renews" that role.

Can you verify that you're on UC 1.4?

OP: I'm not sure about that particular issue - we tested on a D5 site and it worked fine, though maybe some issue exists on D6 that we haven't gotten to yet. The role promotion expiration shouldn't assume any sort of trial period.

Regarding subscriptions - you're correct. It doesn't mean it's impossible, because there is a hook getting called when a fee get's cancelled... it's just that right now it doesn't directly tie to other things like role promotions.

I think in general the features of subscriptions are obvious, but the trick is deciding what's already in place, what needs to be rewritten, what needs to be done, and how different pieces of core should work together. I think some of this could be answered without programming knowledge, but that certainly helps.

We've worked with other companies to give special attention to parts of core that were lagging for their use. We'd happily chat about sponsored development, or if you can find someone w/ good knowledge of Ubercart who can submit patches that'd be good, too.

One other comment ... we are also using the Subscriptions 2008-04-11 module (http://www.ubercart.org/contrib/2851) along with UC 1.4. Does this make any difference? I thought the purpose of this module was to tie together recurring payments and subscription services.

No response on this thread? Was hoping to receive some feedback to my comments ...

I have also been having problems with the subscription module. I have it set up and can purchase a subscription but it does not auto-renew even though the auto-renew item is checked. My understanding is it is supposed to renew and create a new order to be fulfilled (in our case this would work great as it is a monthly physical product we are selling). I would also be willing to contribute to a bounty to shore this up a bit although I am on tight timeline.

I was actually using just the test gateway. We were planning to use PayPal Pro for the actual gateway not Authorize.NET

I set up a subscription as a test that was supposed to expire after 5 minutes but automatically renew. I was running cron but the subscription just expired it did not renew and create a new order as I thought it was supposed to.

We are hoping to get this figured out this week if possible.

Josh

Well, there's some integration for recurring fees and Authorize.Net nowadays, but my understanding of this thread was that some contributed module wasn't functioning properly.

FYI, we also have figured out what was causing the initial date problem. The previous developer of the site, when creating products, had installed both uc_subscribe and uc_roles.

Under the product features sub-tab, it is possible to add multiple features on the product. The developer had added a Role assignment for 6 months, and *then* he also added a "Subscription: Generic subscription" option for 6 months.

This made the role expiration additive ... therefore someone who had wanted to purchase a 6 month subscription actually got a total of 12. The uc_subscribe "Product subscription" tab on a user's profile would show the correct 6 month duration, but the "Expiring roles" area on the user profile was showing 12 months duration (6 months from uc_subscribe + 6 months from uc_roles).

If both uc_subscribe and uc_roles are going to exist separately, there needs to be something in place to ensure users do not accidentally add another feature which can extend the length of a role.

You're welcome. I wanted to make one further caveat to what I said previously. I made the comment, "In 'Test Developer' mode, CIM (v0.90) works perfectly with uc_subscribe (2008-04-11)".

I wanted to add that it was necessary for me to create a couple of Workflow-ng business rules to really get it to work as I fully expected. The base rules come included with the uc_subscribe module. The two rules I created from these base rules are "Site subscription has begun" and "Site subscription has expired":

• Rule: Site subscription has begun
• Invoked on event: New subscription has been registered
• Conditions: User has role(s); User to test: Customer; Select role(s): Authenticated
• Actions: Add user role; User whose roles should be changed: Customer; Select role(s): Subscriber
• Rule: Site subscription has expired
• Invoked on event: Subscription has expired
• Conditions: User has role(s); User to test: Customer; Select role(s): Subscriber
• Actions: Remove user role; User whose roles should be changed: Customer; Select role(s): Subscriber
• Second Action: Execute Custom PHP Code -- we give subscribers access to several "paid only" Drupal Simplenews newsletters. When the subscription ends, we need to ensure the user no longer has access to the newsletters. We run through some PHP code to delete records in the database.

When using the uc_recurring/uc_roles modules in place of uc_subscribe, I was able to replicate the same type of rules by pointing to the "order" rather than the "customer" data.

Ok, while I'm looking at things, let me add one more comment that references back to the original post. In this scenario, I'm using uc_recurring and uc_roles, with standard Ubercart AIM gateway.

As a test, I just created a simple product called "One Month Extension". I gave it a title, a price, and saved it. Then edited the "Features" tab of the product, and added a "Role assignment" (uc_roles) as a feature. The role assignment has the following items:

• SKU: 8 (SKU of the product)
• Role: Subscriber (unique user role)
• Expiration: 1 month(s)
• Shippable: No
• Multiply by Quantity: Yes

No recurring fee, nothing else ... just a one month subscription. Fairly straightforward, eh? I then make a test purchase for one month, only have one of them in the shopping cart (so multiply by quantity is not an issue), complete the purchase, and the transaction adds TWO months to my role expiration.

Why? What is causing the role assignment to be doubled? If I purchase a three month subscription, it adds SIX months to my role expiration. Frustrating ...

Well since I'm not hearing anything about these issues, I'm starting to do some troubleshooting. I have placed some database inserts in the _get_expiration_date function in uc_roles.module, so I can see what's being written to the DB.

When I process a transaction, the function is called twice, when I'm sure it should only be called once. In the database, I get the following two writes for a one month subscription:

+1 month 1227385170 (Nov 22, 2008)
+1 month 1229977170 (Dec 22, 2008)

So the routine in uc_roles adds one month to today's date (Nov 22) as it should, *then* it returns and adds another month to Dec 22, getting us the end result of Jan 22 as the role expiration date.

Obviously something wrong here!

ron_s, any update on this project? I am creating a subscription based newsletter as well. Your input has been very helpful to me.

I don't have time to research this any more at the moment, but here is some more information.

The problem is associated with the uc_roles_order function in the uc_roles.module file. What happens with a new order is it first completes the "else" part of the "if (!is_null($existing_role->expiration))" conditional, to grant a user the role for a given amount of time.

Then shortly thereafter, the uc_roles_order function is run again, this time the "if (!is_null($existing_role->expiration))" part of the conditional. This renews the expiration time on the order, effectively doubling the role expiration length.

What doesn't make sense is it seems as though the uc_roles_order function is being called twice. I would have expected it is only being called once as the order is set to "Completed". However when I look at the Order Log, maybe this has something to do with it:

Sun, 11/23/2008 - 09:17 2923 Order status changed from In checkout to Completed.
Sun, 11/23/2008 - 09:17 2923 Order status changed from Completed to Completed.

Seems like maybe the hook_order is being fired twice, once for "In checkout to Completed", and a second for "Completed to Completed". If this is the case, then it might be that it runs through uc_roles_order a second time. Since the expiration date is already set, it automatically is going to treat it as a renewal and add the time to the end of the role expiration.

I think ron_s is getting at this... the gist of it is, you can't with core alone. This is an unfortunate side effect of the roles module being developed 6 months before the recurring module was actually put in core. So what we have are two systems that should work together but don't. I'll respond more to ron_s's posts directly here in a bit, but basically what you can do is either accommodate this in a custom recurring fee handler or work through an existing one. For example, I integrated Auth.Net's ARB service in the core Auth.Net module. I invoke a hook whenever an ARB payment is received, so a custom module could implement that hook and update a user's roles accordingly.

However, as is apparent in this thread, core really really needs to have a way to associate a role promotion with a recurring fee. It also needs to better understand what to do when a payment fails... when do you decide a payment is late and should reactivate a previous role w/ an extension or a payment should be considered as repurchasing an expired role? Perhaps ron_s's idea of creating a new order when a recurring payment comes in could solve this.

@ron_s - regarding your bug from uc_roles_order(), I fixed a similar bug in the files module but didn't think to check this module (they were written by the same developer). I'm going to go do that right now and will come back to this thread. I'm running behind on a project and need to devote a few hours to it atm.

fwiw, associating roles to recurring fees is something that is on my radar and will be possible in the 2.0 release.

I mean... I'm not sure it requires rethinking your entire project. Like I said, you can create your own recurring fee handler or work through Authorize.Net and make sure roles stay active. I'm not talking weeks of development work here... maybe just a couple hours to write the little bit o' code and do some testing. I'm working on a solution right now that uses the Auth.Net system, and as soon as it's solid I can provide more info... Don't wanna derail this thread too much.

I'm not sure how I missed this thread but I'll jump in now. I am now responsible for uc_subscriptions and I have updates for uc_subscriptions that need to be posted. I'd like to see uc_subscriptions work its way into core and I'm willing to do the code. uc_subscriptions works with workflow_ng. If you want a user to have a role when the subscription is created create a workflow_ng event for that. If you want the role removed when the subscription is canceled or expires create a workflow_ng event for that. uc_roles isn't required. If a subscription is renewed it will add the amount of time to the expiration, regardless of when it happens. I'm not sure why that wouldn't be working.

Ok all of this discussion about roles, recurring fees, and subscription functionality has brought to light another problem which I consider to be fairly serious.

Right now, no matter which approach is used, there is no good method for a user to upgrade to a longer subscription term. For example, someone is on a one month subscription, is a few days before expiration, and wishes to renew but this time with the three month product. Let's look at how this works in each scenario:

• uc_subscriptions: With this approach, a user has a "Renew" link on the "Product subscriptions" tab. If they click renew, it just adds the same term they already had. So if they had one month, they are adding another one month term. This really shoots us in the foot in regards to revenue generation, when we've got customers willing to spend more money more quickly, but have no method for capturing this.
• The only options available to users with the uc_subscriptions approach is as follows:
  1. Wait until the subscription expires, then purchase a longer-term subscription.
  2. Go through the renew process, but rather than "Checkout", click the "Shopping Cart" link at the top of the page. This allows a user to add multiples of any given product in their shopping cart. For example a user could modify the order to be three 1-month subscriptions. However without a discount module installed, there is no easy way to credit users for buying longer term subscriptions.
• A couple of nice features of uc_subscriptions are users can toggle autorenew on and off as they wish, and the subscription expiration date is not set in stone. If a subscription is renewed, the expiration date is automatically extended and updated. With uc_recurring / uc_roles, an invoice is immediately created for the next month, causing a lock in of the "expiration date". Also there is no notion of an autorenew on/off switch. Either a recurring fee is listed in the future, or it is canceled and no longer exists.
• uc_recurring / uc_roles: The options available to users with the uc_recurring / uc_roles approach is as follows:
  1. Out of the box, the uc_recurring / uc_roles method is rigid when it comes to extensions. Either a user can renew on the current product, or he/she can cancel the product and start over again by purchasing a longer term.
  2. One workaround might be to build a set of "subscription extension" products for users. These products would have a role assignment for a given length of time, but no recurring fee. It would be a one-time charge which adds to the current subscription timeline. The issue is the code should be smart enough to say, "if a user already has a subscription, and adds an extension, then automatically update the upcoming recurring fee due date".

I want to make sure it is very clear the problem this causes, so let me provide an example. Say a user purchases a recurring fee subscription which adds a $20 fee on the 27th of each month. On December 24, 2008, the user decides he wants to upgrade to a three month subscription. We can offer a "subscription extension" product for him to purchase, which immediately adds three months to his expiration date. His role expiration is now set to March 27, 2009. However, there is *no* update to the recurring fee. On the account page, it still says the next recurring fee due on December 27. If a user gets charged on 12/27 for another one month renewal, the immediate reaction will be, I just bought three months!

We need to have some reconciliation on all of this. I think two of the most common needs for any subscription site will be the ability of users to control their auto-renew status, and to upgrade/downgrade their accounts ... and in turn have the system understand what implications this has for role expiration dates.

There are actually a couple of funding possibilities to sponsor PayPal support in core that I need to follow up on. I should almost just make it a Chip In widget and then get to work once it's full.

I've been working on a module for sometime that uses Authorize ARB and deals with role promotion:

http://drupal.org/project/role_subscription

I decided to build it outside the scope of ubercart initially bc I thought recurring billing (not invoicing) wouldn't integrate well with ubercart which essentially deals with single payments (and recurring payments).

Anywho I suppose I'm wrong bc I see Authorize ARB integration and recurring billing in Ubercart, now I'm thinking I may need to rethink this bc if all I need to worry ab is role promotion then maybe that's the way I want to go as Ubercart is much more feature rich and better supported than my more barebones recurring billing module.

it seems to do what i set up my module to do which is grant roles with a certain type of subscription. i did some tests last week and sure enough it granted me a role based on a subscription, it will be difficult to test renewals/cancellations/etc to see if it removes expired/canceled roles correctly or if that's something I'll have to code. i also wonder ab updating the prices of subscriptions if it has any mechanism for updating existing subscriptions in authorize which is one of the things i did in my module. it's tricky bc it means you have to make potentially a bunch of API calls when you update a subscriptions terms/price and some terms you can't change in ARB once a subscription is created. that is something as well i suppose i could code. with any subscription you know there are going to be price changes from time to time, so that has to be handled well.