Simple Subscriptions UI

The following are some mockups by kristyb2008 for one idea of what this simple_subscription_ui could look like.

This module would not provide any new functionality at all, it would just be a UI. All the functionality would still exist only in uc_recurring or uc_role or what every module provides the actual functionality/features.

If you look at views, it actually consists of 2 modules, the "views api" and the "views_ui", another separate module called "simpleviews" exists which allows you to replace the "views_ui", or you can have them both running at the same time.

uc_recurring provides some UI stuff to add a recurring feature to a product, but unless you understand what features are in ubercart, this can be confusing to a new user. So the idea is that you can still go to the product in ubercart and then select the features tab and manage the recurring fee and roles from those various pages or if you have the 'subscription_ui' modules you have a simple UI for managing just your subscription products which in the backend would just call the function in the uc_recurring api to add/update products. But even when you are using this module, you could also alter these same variable (or at least the most common element) from the standard product pages.

The idea is this should provide the types of simple interfaces that various other membership scripts you can install provide.

I am interested in feedback though on what the UI should look like though? What are peoples normal workflows when adding/managing a group of subscription products.

I am keen to see this get built as it would open up uc_recurring to anyone needing a simple subscription management tool, but remember this isn't going to add any functionally that isn't already in ubercart/uc_recurring/uc_roles - its goal is just to make things easier, there are a couple of features in uc_recurring that I feel are higher priority and would prefer to have them for my own needs over this feature, I have posted my list here: #498828: How Close to 2.0 Release? What is needed?

Thats not to say this feature can get started now.

There are a couple of things I would personally change from the initial mock ups:
* In step 1, rather then a drop down box lets just have a title and body fields so we can create/manage the product completely from here.
* This module needs to know which products it should manage, I think this can be done by creating its own product class's in ubercart.
* In ubercart roles have their own expiry date, I think at least in the first version of this module it would be simpler to just have one role that gets added on subscribing and then expires when the subscription expires.

Other lower priority features:
* Provide an attribute to handle multiple price/subscription terms for the same product (e.g. monthly/yearly prices)
* provide an import function to import an existing product into the "subscription product class"

This is more of a pain then I was hoping for. I have made a start but I really can only do the recurring stuff as ubercart doesn't expose any api functions to manage things like roles or attributes which I want to use to provide potentially multiple payment options for a subscription (e.g. monthly/yearly).

I have uploaded what I have so far.

Thanks for the review, you have raised a couple of useful points.

I probably should make the point that the idea of this module is its is very much an end user tool, rather then a webmaster/developer tool.

So things like enter the PHP time may not be the most user friendly way of entering time? on the other hand I probably wouldn't be against using PHP time in the uc_recurring product feature forms. But the other issue is that payment gateways that have their own recurring interfaces and often use intervals measured in units like days or months rather then a time and having an interval like 2 weeks 1 day is not always possible.

The idea I had was to separate products managed by this module from other products using a product class which is what is setup on install. I would also like to have an attribute to allow multiple payment intervals for a subscription (e.g. monthly/yearly).

The features in this issue are become more of a requirement for me as I am finding limitations specifically working with uc_roles.

I have taken another stab at building this module, the main issue really holding me back is not having a good way to extend the ubercart attribute system, there is a great patch here: #488422: Cleanup uc_attribute's product/class API, and add test coverage for the new API, as well as the UI. which is what I really need for this.

I have also written some code to provide conditional action support to roles that really should be in uc_roles.

If you are a git user you can grab a copy of the module off github (need to checkout the uc_recurring_subscription branch):
http://github.com/univate/uc_recurring/tree/uc_recurring_subscription

Here is a patch of the current state of this module development.

If you want to test it out you should read the INSTALL.txt file under modules/uc_recurring_subscription as you need to patch ubercart.

Updating to current revision.

I have committed this module to this project - to make use of this you need to patch ubercart (read the README.txt) - hopefully this might help push along the issue: #488422: Cleanup uc_attribute's product/class API, and add test coverage for the new API, as well as the UI.

Good news the main issue thats been stopping this features has been committed to ubercart:
#488422: Cleanup uc_attribute's product/class API, and add test coverage for the new API, as well as the UI.

There is one other issue that is also required:
#750664: Product Feature API

This module allow roles to be assigned and revoked on subscription purchase and expiry (through CA so there is flexibility to tweak how it works).

Extending a subscription will automatically mean the role does not get revoked until the subscription actually expires. This is useful when you want to manually extend when the next payment is due for a user or you don't want the role to end on a failed payment but allow uc_recurring to re-attempt the payment again in a couple of days. But if you are using a payment gateway with limited functionality that does not allow payments to be triggered when you want you may not be able to use this functionality (these features work well with payment gateways like Authorize.net CIM in the US or the uc_securepayau gateway in Australia)

This module does not mean you can't also use uc_roles, the only problem you may face is if two roles renewal/expiry methods collide. It would be great to see uc_role module also include functionality to allow roles to be assign/revoked on CA, so we could use that module for all role management in ubercart.

I just had another idea if you wanted to use both this module and uc_roles with the same roles. Setup two identical roles, one for this module to automatically renew and another you can manually assign through uc_roles extend. That way as long as the user has the role from one of these features they would always have the permissions set by that role.

@eojthebrave - that requires a payment gateway that allows you to charge what you want when you want. ie: the payment gateway just stores credit card details for you and your application triggers payments when you want them - as I said these features work well with payment gateways like Authorize.net CIM in the US or the uc_securepayau gateway in Australia. I am using these feature everyday on sites that I have setup with the uc_securepayau module.

Does WPP allow you to set it up to charge what you want when you want? so you can skip a payment.

With the current implementation that was given to me to commit to this module I believe the way WPP works is it take not only the credit card details but all the information about the recurring payment and it charges things when its wants to charge them, so changing the next_charge field in uc_recurring is not going to help you you need to change it in the gateway as well.

Using any gateway that is setup like that is always going to limit what you can do as you are handing control over to the gateway - which is why I will always recommend using a gateway like Authorize.net CIM (in US) or securepay.com.au (in Australia) - there are others out there for other countries as well.

So please by all means please take a stab at implementing this functionality for WPP, at the very least all you need is a method that that talks to the gateway and allows you to edit when the next payment occurs. The better solution is to take control back from the gateway (if the gateway allows it) and just store credit cards at the gateway and let uc_recurring handle the renewals (that way all you need to is change the next_charge field in uc_recurring and it just works)

Still wait on this patch:
#750664: Product Feature API

Please review and help convince ubercart maintainers to commit.

Closing this issue now that the patches are in. You will need to use the current -dev of Ubercart until 2.5 is released.