Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Yes, merchandise plans can fire some integrations, but you should not be using a merchandise plan in this scenario.Does buying merchandise plan trigger 'activation'? Can I do SQL Action so when someone buy the upgrade, an SQL statement to change his current subscription ID is executed. Doesn't sound safe to me but this is the last resort
They should be able to see the plan, but not buy the plan.For total number of occurrences, yes, I set it to 1 but user can still see the plan after buying. I will do some tests again for this to make sure.
Please Log in or Create an account to join the conversation.
May I know why? The reason I didn't set it as lifetime subscription plan is so member won't see it displayed in their profile after the upgrade since it's a one-off upgrade.krileon wrote: Yes, merchandise plans can fire some integrations, but you should not be using a merchandise plan in this scenario.
I recommend the below setup.
Associate Member (Parent) - $25, Subscription, exclusive, no upgrade
-Upgrade to Full (Child) - $10, Subscription, non exclusive
Full Member (Parent) - $30, Subscription, exclusive, no upgrade
The prices are just examples, but the idea is to have the Full plan simply extend the associate plan. Adjust the associate plan as necessary to account for the $10 recurring subscription of the full upgrade.
Alternatively you could make the full upgrade a single purchase with a duration of lifetime. Users would receive a $5 discount for obtaining the full subscription directly.
Please Log in or Create an account to join the conversation.
The plan will remain displaying regardless of plan type, which is a good thing so the user knows what they've bought.May I know why? The reason I didn't set it as lifetime subscription plan is so member won't see it displayed in their profile after the upgrade since it's a one-off upgrade.
From backend would be a matter of checking both plans; shouldn't be an issue, review users from 1 full membership plan then users from another afterwards. Of course they'd have 2 plans, but am not sure what else to suggest to you. CBSubs is quite powerful, but it certainly will not fill every single imaginable role.With the above setup, user will end up in situation like I mentioned in another thread: they will have 2 plans (associate + upgrade) forever instead of being a truly 'full' member. Plus, filtering by plan at backend will be confusing as there are real Full members and those who upgrade (how to filter these users?)
That would be something to discuss with your client ensuring they understand the limitations of the software. Sometimes what a client wants isn't always doable/available, avoid empty promises as well (ones you couldn't possibly fulfill).In addition, I can't change the price since it means changing my client's business model.
Bottom line is exactly what you're wanting can not be done. I've afforded several alternatives to come close to what you're wanting, but exactly what you're wanting is not available. I recommend reviewing many of the suggested approaches, testing them, then presenting them to your client; explain a limitation of software is being imposed and it shouldn't be an issue assuming you did not make a obligatory promise that it could be done all is well!Honestly I don't know how to solve this problem
Please Log in or Create an account to join the conversation.