Posted By levirosol on 1/07/2007 8:28 PM

The existing registration control does not provide the redirectURL, however, you could just make your own copy of the control and include in the Sub Tools package. Then you would have the freedom of making changes as you see fit. 

Posted By proeder on 1/07/2007 4:06 AM

How's it going...?

Posted By emaynard on 1/09/2007 4:16 AM
Mariette,

I'm especially interested in your experiences with converting Subscription Tools to VS 2005.

-eric

Posted By smcculloch on 1/07/2007 4:57 AM
I really just need help on defining what needs to be done, I can do the grunt work.

When I mean "what", I mean structure it like this, use this fields from here, etc.

What I would really like in subscription tools, is to make it more of a workflow for the signup.. with the option to register the user at the same time.

So at the top of the subscribe/renew, a workflow would appear something like:-

[Select Plan/Processor] -> [Register (if not logged in)] -> [Fill in required fields] -> [Payment Processor] -> [Complete]

So the question is, how to mark which additional attributes should be collected? What is the process for filling it out? Should they just see the additional fields, or the whole account registration profile?

Posted By jhoelz on 1/12/2007 12:23 PM
I agree with as little duplication as possible, but for forms like this I would not want al of this information tagged with the user profiles. A form like this might be created 3 or 4 times per year per organization.

Posted By emaynard on 1/12/2007 1:38 PM
I think I have to agree with proeder and SPulley.

There may be some generic scenerios that Sub Tools can manage, but ultimately it should serve as a processor /  transaction validator and leave the heavy lifting to a 3rd party app or module that can be customized to the exact business logic requirements.

I think the flow SPulley has outlined is dead on except that I would take it one step further and suggest that an additional feature allowing for the ability to specify non-Time based payment type as well.  The most common example of this would be a classified ad type listing or even a one-off event.

So here's my list of desired additions to Sub tools.


1) Single action registration and subscription (per Scott's example work flow)
2) Required fields validation (per SPulley 'swork flow)
3) Host specified return URL by plan (per proeder)
4) Host specified plan type - time based or transaction based.
5) Host specified subscription action - Update security Role or Update a host specified profile field.

I may not have that last one quite right, but the idea is that you will have the ability to check this field value as a basis for authorizing some capability in your specific business logic.

UPDATE:  I'll try to add these to the feedback center or vote on similar existing entries.



-eric

Posted By proeder on 1/07/2007 11:18 AM

Ok, as my initial post may have sounded like a quick shot, I ordered my thoughts in the bath tub. Here's what I need exactly.

1. Set required profile properties per plan

This will render a list of all available properties to the admin, but only those properties that are not required per portal setting. Admins can make these proeprties required for the current plan. If one subscribes to the plan he will be presented the core ProfilePropertiesEditor (note that you can override the required attribute before ou render the editor). This screen will look like the core profile page to get the same look and feel throughout the page. As soon as all properties are set the user gets redirected to the payment processor.

2. Allow anonymous visitors to subscribe

This will present the visitor with a registration screen that looks like the core registration screen, In addition to the portal required fields the plan reuquired fields are marked as required. Again, the UserpropertiesEditor and the ProfilePropertiesEditor from the Core should be used for the reasons above.

Unfortunately the Core does not provide a ReturnURL attribute to be used in the registration pages, this would make things much easier

I  too don't believe storing required properties in the receipt table is a good idea. I would like to get to a point where all profile data is stored in the core. Storing thins like this in the module would lead to the opposite.

3. I need to set the end of the current year as the expire date of a role subscription, also I need to set a date where the role memebership effectively expires. Use case for this a club membership where memebrship usually expires at the end of the year while users have time until March 1st to pay for the next year. Until March 1st they need to sty  in the membership role. can this be done?

4. I need a way to allow users to subscribe to multiple subscriptions while they are already subscribed to one plan. Right now you see the current subscription on the landing page but not other subscriptions that are available. A better display would be

--------------------------------------

My current subscriptions

--------------------------------------

Additional available plans

--------------------------------------

5. I need an additional payment processor. A quite simple one actually: Bank Transfer. When selected the subscriptions becomes pending but the user needs to able to select hsi receipt (which would really be an invoice then) to see bank details for making the payment. This invoice would need to be templateable. Once paid the admin needs to be able to mark the subscription as paid.

I hope that was it for now. #2 is not immeditely important, while all others are. I'm prepared to fund $150 if you could start working on this soon, hopefully others are prepared to donate as well

Regarding the VAT, I still believe this is a valuable extension for the property types in the profile properties. I've seen others implementing user photos into the user profile - it's not that tricky. I could maybe do this for you Mariette