Plan assignation from backend bug.

14 years 11 months ago #96738 by beat
Replied by beat on topic Re:Plan assignation from backend bug.
guidoterhorst wrote:

In the front-end the joomla user group does get upgraded when the plan says so.

Whoever, in the backend, this is not the case.

The user field value update integration works fine in front end backend.


Ok, adding this issue to our list for checking.

#1010

Beat - Community Builder Team Member

Before posting on forums: Read FAQ thoroughly -- Help us spend more time coding by helping others in this forum, many thanks :)
CB links: Our membership - CBSubs - Templates - Hosting - Forge - Send me a Private Message (PM) only for private/confidential info

Please Log in to join the conversation.

14 years 11 months ago #96742 by beat
Replied by beat on topic Re:Plan assignation from backend bug.
guidoterhorst wrote:

Also, the upgrade function is unclear to me. When I have a plan, and upgrade to another plan. Please explain what happens with the old plan. Because the plan remains in the database?! If I unsucbscribe the upgrade, what happens with the original.


There is a quite complete and complex upgrade and upgrade reversal mechanism in CBSubs:

When you upgrade an Active subscription to another (exclusive too) plan, the Active subscription becomes unsubscribed, and has an Upgraded status, and the new subscription remembers from what it got upgraded.

This allows e.g. in case of cancellation (or payment reversal!) of the new subscription, to re-activate the previous, upgraded one, IF that plan would still be active if not having been upgraded.

Upgrades are done with exclusive/mandatory plan (radios) subscriptions only.

Non-exclusive/non-mandatory plans (checkboxes) do not upgrade, but add simultaneous subscriptions in parallel.

Hope that clarifies this quite automated mechanism.

Please see also Section 6.5.1 pages 105-107 (but specially page 106) of CBSubs manual 1.0.0.

Beat - Community Builder Team Member

Before posting on forums: Read FAQ thoroughly -- Help us spend more time coding by helping others in this forum, many thanks :)
CB links: Our membership - CBSubs - Templates - Hosting - Forge - Send me a Private Message (PM) only for private/confidential info

Please Log in to join the conversation.

14 years 11 months ago #96804 by guidoterhorst
Replied by guidoterhorst on topic Re:Plan assignation from backend bug.
OK, if understood correctly, upgrading to an exclusive plan replaces the ¨old¨ plan, and using an upgrade to a non-exclusive plan can be used to add rights/permissions/etc. to the existing exclusive plan.

Thanx a lot for the info!! The exact terminology can be quit confusing, because an upgrade normally means extra, which is not the case now, just a different plan (which cán be an upgrade off-course, but noyt neccesarily is). I suggest to change the buttons to "Switch plan" and "Upgrade existing". This makes more sense

It is therefore important in which order upgrades to non-exclusive plans are performed if for instance single select user groups (such as the Joomla Account Levels) are updated on subscriptions to secondary plans. (Ikes:sick: , that´s asking for proper implementation if you don´t want to get messed up:S )

What happens if the childplan is of longer validity as the parent plan?
Just checking some configuration problems I´m running into.

Post edited by: guidoterhorst, at: 2009/04/27 18:45

Please Log in to join the conversation.

14 years 11 months ago #96808 by beat
Replied by beat on topic Re:Plan assignation from backend bug.
guidoterhorst wrote:

OK, if understood correctly, upgrading to an exclusive plan replaces the ¨old¨ plan, and using an upgrade to a non-exclusive plan can be used to add rights/permissions/etc. to the existing exclusive plan.

Thanx a lot for the info!!


Correct :)

It is therefore important in which order upgrades to non-exclusive plans are performed if for instance single select user groups (such as the Joomla Account Levels) are updated on subscriptions to secondary plans. (Ikes:sick: , that´s asking for proper implementation if you don´t want to get messed up:S )

What happens if the childplan is of longer validity as the parent plan?
Just checking some configuration problems I´m running into.


Children plans should be same duration as parent plan or lifetime. It could work too for other situations as well, but was outside specs all the test-cases made. So if you do that you need to check that it works.

What happens is that:
- plan validity check of a child plan checks for the validity of its parent plan if any parent plan is there

- but expiration events will be triggered by the expiration of the child plan, if they differ.

- If validity differ, it causes complexity for the user, and auto-recurring payment subscriptions won't be offered, even if enabled (as the recurring can't re-occur automatically !) :)

That's why we recommend to sync validity of parent children plans, if not lifetime.

So in this kind of complex scenarios, testing for your particular case is required, as result will probably be correct according to design, but maybe different of what you want.

That are the consequences of a very very flexible system...

Beat - Community Builder Team Member

Before posting on forums: Read FAQ thoroughly -- Help us spend more time coding by helping others in this forum, many thanks :)
CB links: Our membership - CBSubs - Templates - Hosting - Forge - Send me a Private Message (PM) only for private/confidential info

Please Log in to join the conversation.

14 years 11 months ago #96811 by guidoterhorst
Replied by guidoterhorst on topic Re:Plan assignation from backend bug.
Thanx for the quick and explanatory replies.

Excellent!

For me, the only feasable option for child plans right now is lifetime, because there is no option to have syncing with parent plans (yet:)), so you will otherwise never know what happens. Customers will sign up and pay for secondary subscriptions they cannot finish because of the parent plan expiring, etc. is asking for problems:)

A "follow parent plan" option would be in place though.

Please Log in to join the conversation.

Moderators: beatnantkrileon
Time to create page: 0.220 seconds

Facebook Twitter LinkedIn