Renewing plan in backend doesn't restablish group

12 years 9 months ago #165927 by MarkRS
On my installation if a subscriber's plan lapses the account falls back to a lower access group and to the standard J! "registered" group.

If I renew the plan through the backend the user doesn't get replaced in the appropriate group automatically, it needs to be done manually.

CBSubs 1.1.2, CB 1.4

Please Log in to join the conversation.

12 years 9 months ago #166110 by krileon
If I am understanding correctly you've a child plan and a parent plan both of which change the users usergroup. Upon expiration from the child plan they're returned to previous usergroup, but upon renewal it does not place them in that usergroup? Backend functions differently in that the usergroup you're able to set directly from profile will have precedence over whatever CBSubs would set them to. In other words in backend you should set their usergroup manually while also granting them the subscription.


Kyle (Krileon)
Community Builder Team Member
Before posting on forums: Read FAQ thoroughly + Read our Documentation + Search the forums
CB links: Documentation - Localization - CB Quickstart - CB Paid Subscriptions - Add-Ons - Forge
--
If you are a Professional, Developer, or CB Paid Subscriptions subscriber and have a support issue please always post in your respective support forums for best results!
--
If I've missed your support post with a delay of 3 days or greater and are a Professional, Developer, or CBSubs subscriber please send me a private message with your thread and will reply when possible!
--
Please note I am available Monday - Friday from 8:00 AM CST to 4:00 PM CST. I am away on weekends (Saturday and Sunday) and if I've missed your post on or before a weekend after business hours please wait for the next following business day (Monday) and will get to your issue as soon as possible, thank you.
--
My role here is to provide guidance and assistance. I cannot provide custom code for each custom requirement. Please do not inquire me about custom development.

Please Log in to join the conversation.

12 years 9 months ago #166177 by djsdjs
Seriously?

I was just researching using CB Subs as a unified ACL solution which I would manipulate ONLY through the backend.

Sounds like it is not good idea because there are dependencies on user-driven subscription events that are not replicated by the backend?

D.

Please Log in to join the conversation.

12 years 9 months ago #166367 by MarkRS

krileon wrote: Backend functions differently in that the usergroup you're able to set directly from profile will have precedence over whatever CBSubs would set them to. In other words in backend you should set their usergroup manually while also granting them the subscription.


Hmm, is that the whole story?
When I create a new user from the backend and allocate them to a particular plan it does put them in the correct group... :dry:

Please Log in to join the conversation.

12 years 9 months ago #166409 by krileon

Seriously?

I was just researching using CB Subs as a unified ACL solution which I would manipulate ONLY through the backend.

Sounds like it is not good idea because there are dependencies on user-driven subscription events that are not replicated by the backend?

What are you saying exactly? CBSubs for the most part works exactly the same in backend as it does on frontend aside from no payment processing.

When I create a new user from the backend and allocate them to a particular plan it does put them in the correct group...

This should be the case assuming you didn't manually give the user a usergroup. Am trying to understand your EXACT steps so I can attempt to duplicate your issue. Is this working fine on frontend?


Kyle (Krileon)
Community Builder Team Member
Before posting on forums: Read FAQ thoroughly + Read our Documentation + Search the forums
CB links: Documentation - Localization - CB Quickstart - CB Paid Subscriptions - Add-Ons - Forge
--
If you are a Professional, Developer, or CB Paid Subscriptions subscriber and have a support issue please always post in your respective support forums for best results!
--
If I've missed your support post with a delay of 3 days or greater and are a Professional, Developer, or CBSubs subscriber please send me a private message with your thread and will reply when possible!
--
Please note I am available Monday - Friday from 8:00 AM CST to 4:00 PM CST. I am away on weekends (Saturday and Sunday) and if I've missed your post on or before a weekend after business hours please wait for the next following business day (Monday) and will get to your issue as soon as possible, thank you.
--
My role here is to provide guidance and assistance. I cannot provide custom code for each custom requirement. Please do not inquire me about custom development.

Please Log in to join the conversation.

12 years 9 months ago - 12 years 9 months ago #166493 by MarkRS

krileon wrote: This should be the case assuming you didn't manually give the user a usergroup. Am trying to understand your EXACT steps so I can attempt to duplicate your issue. Is this working fine on frontend?


Ok, you're right I have a parent plan with a child plan, four in fact. The parent plan causes no change of group. All the child plans of this parent do alllocate a user to a group. When subscriptions expire they should (& do) revert to another group. I can't find where I set that :(

In the first case I mentioned, when I reinstate a user into the plan whose subscription has expired from the back end, the user's group doesn't come back to the one specified by the subscription plan.

In the second case, when I create a user in the CBSubs back end and set them up in a plan, they are entered into the group specified by the plan.
This group is not a default group, nor even the first one in the list.

Hence my suggestion that CBSubs operates differently in these two cases.

(Later) Ooops, missed the last question. As far as I know it is working fine on the frontend.

Regards
Mark

Please Log in to join the conversation.

Moderators: beatnantkrileon
Time to create page: 0.231 seconds

Facebook Twitter LinkedIn