IP.Nexus Feature Petition

25 posts in this topic

Posted

For paying customers, this is unacceptable. Many shop owners need the ability to have combined subscription. It's a nuisance to have to constantly tell members not to buy new subscription in order to renew an expiring one. Please, for the love of [insert some deity here, e.g., Matt Mecham], add this feature to the core of Nexus.


(Another case in point: Support ticket# #730886)
aramlg, Dennis_87 and Circo like this

Share this post


Link to post
Share on other sites

Posted

Arguing the status of bug reports is not something I usually entertain, but since you asked so politely, allow me to explain :)


Let's say you have a user in group A, he purchases an item which moves him to group B.
He then purchases a third item which moves him to group C.
When B expires, he is moved back to A, this is what you disagree with, but think ahead...
Let's say rather than Nexus moving him back into A, it leaves him in C. That's all fine and dandy until C expires, at which point he is moved into B, where he stays forever. Not intended, he should be in A.

A way this could be counteracted would be if when B expires, the record for C is updated to say that they should be moved back to A rather than B. However that still leaves us with problems. Let's take a user in group A again:
He purchases an item moving him to group B.
He then purchases another item moving him to group C.
He then purchases another item moving him back into group B.
The 3rd item expires and he is returned to group C. The return group for the third item is group C, so the second purchase (which moved him to group C) has the return group set to group C (previously it would have been B).
The 1st item expires. Nothing happens since the 2nd item is still active. Since the return group for this item is B, the 2nd purchase is not updated, it's return group is still C.
The 2nd item expires. The user is "returned" to group C where he stays forever. Not intended, he should be in A.


I don't just blindly mark bugs working as intended, here is the test code I wrote for that bug:

<?php // BUG REPORT 27776 TEST UNIT /* If we've done this 100 times and it works, let's assume we're good */ $tries = isset( $_GET['tries'] ) ? $_GET['tries'] : 0; if ( $tries >= 100 ) { echo "Seems to work"; exit; } /* Test class */ class testUnit { public $userGroup = 1; public $purchases = array(); public $debugmsg = ''; public function purchase( $newGroup ) { $k = ( count( $this->purchases ) + 1 ); $this->purchases[ $k ] = array( 'group' => $newGroup, 'return' => $this->userGroup ); $this->debugmsg .= "Adding purchase {$k} for {$newGroup} (Return {$this->userGroup})<br />"; $this->userGroup = $newGroup; } public function expire( $id ) { $this->debugmsg .= "Expiring {$id} - "; // Move back into correct group if ( $this->userGroup == $this->purchases[ $id ]['group'] ) // We have to do this check in case their been group has been manually changed since purchasing { $this->debugmsg .= "Moving back to {$this->purchases[ $id ]['return']}<br />"; $this->userGroup = $this->purchases[ $id ]['return']; } else { $this->debugmsg .= "Not in correct group; in {$this->userGroup}<br />"; } // Update return groups foreach ( $this->purchases as $k => $v ) { if ( $k == $id ) { continue; } if ( $v['return'] == $this->purchases[ $id ]['group'] ) { $this->purchases[ $k ]['return'] = $this->purchases[ $id ]['return']; } } // Remove purchase unset( $this->purchases[ $id ] ); } } /* Run test */ $test = new testUnit(); // Purchase some items foreach ( range( 0, rand( 0, 10 ) ) as $i ) { $test->purchase( rand( 2, 5 ) ); } // Expire a few foreach ( range( 0, rand( 0, count( $test->purchases ) ) ) as $i ) { $id = array_rand( $test->purchases ); $test->expire( $id ); } // Purchase some more foreach ( range( 0, rand( 0, 10 ) ) as $i ) { $test->purchase( rand( 2, 5 ) ); } // Expire them all foreach ( $test->purchases as $id => $data ) { $test->expire( $id ); } // If we're not back in group 1, it doesn't work if ( $test->userGroup != 1 ) { echo $test->userGroup . '<br />'; echo $test->debugmsg; exit; } // If we are back in group 1 , try again $tries++; echo "<script type='text/javascript'>window.location = '{$_SERVER['PHP_SELF']}?tries={$tries}';</script>";






















































By all means, if you have an idea how to make it work, lay it on me - please just remember that I don't mark bugs WAI just to annoy you, and no petition or rant in a massive font size is going to make a concept work which isn't possible ;)


As an aside, I would recommend if you have a complex group structure to use the secondary group promotion feature, as secondary groups can be added and removed without complication.

Michael, AlexJ and Volvospeed like this

Share this post


Link to post
Share on other sites

Posted

Let me know what you think of these:

Possible Solutions:

  1. Have a mechanism that checks and disables purchases of a subscription that is already active. The add to cart text button would instead say, "Renew." For this to work, the "renewal X days before expiration" needs to be unlimited to allow unlimited renewals OR the add to cart text button still says "Renew" but in a grayed out box. Below it would be a message, 'Renewal for this subscription will be enabled [insert MM/DD/YYYY]'
    1. logic: (Is subscription active? If yes, display Renew AND date when renewal is allowed)*.
    2. User purchases Subscription A (30 day duration)
    3. User the following day purchases Subscription B (30 day duration)
    4. User the following day purchases Subscription A again ((30 days - 2 days) + 30 days)

As an aside, I would recommend if you have a complex group structure to use the secondary group promotion feature, as secondary groups can be added and removed without complication.





[*]Allow combined subscription only for subscriptions that promote secondary groups. That way, the primary group is never changed. Yes I do this on another site. However, it still won't solve the problem of a customer being removed from the secondary group if the same subscription is purchased again instead of renewed during or before the renewal period. *The way the problem is solved is that quantities greater than 1 of the same active subscription are never allowed. Only renewals of active subscription are allowed. Essentially, the user will have 2 places to renew subscription, in their client center (this is not obvious or intuitive) or in the nexus store front (more intuitive) **After further contemplation I realized the primary group should never be changed for communities that use more then 1 subscription package. Perhaps it's best to eliminate the feature to change primary groups entirely and only allow secondary groups to be added/removed? That way multiple subscriptions can be supported. For instance, 3 private forum categories that require 3 separate subscriptions would need to be based on secondary group privileges. I now see little need in using the feature to change the primary group.

Share this post


Link to post
Share on other sites

Posted

Some of these issues can be solved by the addition of the setting:

"Always return users to this group upon expiry"
[ dropdown menu with groups ]

Instead of always wondering where a user will end up after multiple subscriptions, etc., you know exactly where they will go. You decide.

IP.Subscriptions has this, and I also run a vBulletin where I do this by running a daily task that resets all previous usergroups to the designated one.

If a user upgrades from A to B by purchasing B while A is active, when A expires, nothing happens because B is active (vB does a check), but when B expires, they are returned to the designated usergroup (due to the task I run), instead of the previous (which would have ended up giving them a free lifetime subscription to A by putting them there without a subscription).

Multiple subscriptions and upgrades can get messy and users can end up with lifetime subscriptions when they are not meant to. I found this setting solved all the issues I had.

You could set it to Members. I actually have a group called Expired.

I would really like this in Nexus, and per-package would be the best way. This way we could have expired groups for each subscription.

If this would not solve what you have above, I would still like to see this added. It is very beneficial to be able to designate expired usergroups.

Thanks

Share this post


Link to post
Share on other sites

Posted

This is definitely a highly annoying problem. And I do use secondary groups. I had some fool subscribe 12 times to a 1 month subscription in one order. So he had 12 simultaneous 1 month subscriptions.

There needs to be settings to Allow Subscriptions!!!! If it is not a physical item, I need to be able to say, you can only have 1 of these OR a way that it just adds up all the days. It should never allow you to subscribe 12 times to the same 30 days...

Anf if I missed a setting somewhere, then it needs to be made easier because I've tried just about everything...

Nick² likes this

Share this post


Link to post
Share on other sites

Posted


I would really like this in Nexus, and per-package would be the best way. This way we could have expired groups for each subscription.



If this would not solve what you have above, I would still like to see this added. It is very beneficial to be able to designate expired usergroups.



Thanks




I like this idea but it's not possible per-package, you've got the same problem I described above.

Share this post


Link to post
Share on other sites

Posted


I like this idea but it's not possible per-package, you've got the same problem I described above.



I don't know why not, but I'd like to see it as a global setting then. That's the way IP.Subscriptions does it, and the way I use it in vB. I have one group called Expired, and return all expired members to this group. I do not have to worry about members not being properly removed from any subscriptions.

Another benefit is you have one group that is expired, and you can show them messages on the forum so they upgrade again. "Your membership has expired, you may upgrade here" and just put code around it so only that group sees it. I can easily email the group. I can assign an expired group image. Etc., etc. Many reasons to have this setting, like IP.S does.

I'm glad you like the idea. Do you have plans to add it Mark? In essence, this is just another setting missing from Nexus, that IP.S has.

Share this post


Link to post
Share on other sites

Posted

Please let me know what you think of the suggestions I've made. Otherwise I'll assume you think it's not feasible.

Thanks

chilihead likes this

Share this post


Link to post
Share on other sites

Posted


Please let me know what you think of the suggestions I've made. Otherwise I'll assume you think it's not feasible.



Thanks




I don't really have a strong opinion. I would like to add a "Is subscription package?" setting which would cause the item to behave as your first suggestion.

Neither idea actually addresses what we're discussing though :)

Share this post


Link to post
Share on other sites

Posted

What about blocking other "Is subscription package?" if another one is active? Would fix some problems, and they can always "update/downgrade" their package alone. Otherwise there is the support system for that?

chilihead likes this

Share this post


Link to post
Share on other sites

Posted


I don't really have a strong opinion. I would like to add a "Is subscription package?" setting which would cause the item to behave as your first suggestion.



Neither idea actually addresses what we're discussing though :)




Mark, I don't understand. Wouldn't the use of secondary groups and combined subscriptions solve this issue? If not, what is to be done? Surely this needs to be resolved some way, some how?
chilihead likes this

Share this post


Link to post
Share on other sites

Posted

Using secondary groups it works fine, yes.

Share this post


Link to post
Share on other sites

Posted

Mark, secondary groups alone does not solve the problem. Subscriptions need to be combined for multiple purchases. Even if all subscriptions change secondary groups, if I were to purchase 30 days today and 30 days tomorrow, I still end up with 30 days of subscription, not 60. Huge problem :(

chilihead likes this

Share this post


Link to post
Share on other sites

Posted

I don't disagree, but that has nothing to do with the bug report we were talking about :)

Share this post


Link to post
Share on other sites

Posted

You mean this? http://community.invisionpower.com/tracker/issue-27776-duplicate-package-purchases/

The problem I see is that the person is demoted even when an active subscription exists (duplicate). The solution to this (I think) would be to not allow duplicate subscriptions - instead, duplicate subscriptions should be combined, so 30 days + 30 days = 60 days of subscription. If I'm missing something, please let me know.

Thanks

Share this post


Link to post
Share on other sites

Posted

Why not add a "should this usergroup change override other packages usergroup changes" and then have a list of the packages so we can choose which packages this package should override on purchase?

Package A
Usergroup A

Package B
Usergroup B
Overrides Package A

Package C
Usergroup C
Overrides Package A and B

Package D
Usergroup D
No Overrrides.

---

  1. Client purchase Package A and is promoted to Usergroup (UG) A.
  2. Client purchase Package B and is promoted to UG B.
  3. Client puchase Package C and is promoted to UG C
  4. Package A expires. System check if client have overriding packages. Client have 2 overriding packages and no UG change is made.
  5. Package C expires. System check if client have overriding packages. Package C is top level override so UG C is removed and next UG below is added. UG changes to UG B.
  6. Client purchase Package D and is promoted tp UG D.
  7. Package D expires. System check if client have overriding packages. No overriding packages are found. System check for other packages that effect UG changes and find Package B. UG D is removed and UG B is added.


So when a package or subscription expires the system first check if the client have another package whith UG changes. If yes it look at which package have the highest ranking. If a package have "highest ranking" the system will change to that UG. If no highest ranking package exist I suggest a email goes out to the admin with a link to where s/he can manually choose which package should take over as active. Until that change is made by admin the current UG should remain to prevent angry clients...

Would something like that work?

Share this post


Link to post
Share on other sites

Posted

I also think that adding secondary groups would be the easier way rather than regular group changes?

Share this post


Link to post
Share on other sites

Posted

This can't go on... and I agree with Jimi's second post. Secondary groups seems to be the solution AND having subscriptions combined. Look below. 5 multiple subscriptions. Nexus needs to automatically combine them. This is frustrating for both admins and customers.
%7Boption%7D

photoadmin likes this

Share this post


Link to post
Share on other sites

Posted

As a temporary solution - why not just make the group they're moved in to not able to purchase that package in the store front, and instruct your members how to use the "Renew Now" button?

Share this post


Link to post
Share on other sites

Posted

That doesn't work with secondary groups. I use those since I have a lot of different groups but a common premium content option. (premium content is a secondary group). When it was a primary group, I was fixing user accounts way too often.

Share this post


Link to post
Share on other sites

Posted


As a temporary solution - why not just make the group they're moved in to not able to purchase that package in the store front, and instruct your members how to use the "Renew Now" button?




Mark, if programming Nexus to combine subscriptions is not doable, can't you disable purchasing the same subscription if one has an active one? Please at least add a setting per package that says "Allow duplicate purchases?" and a setting that denies purchase if another subscription from a list is chosen.

E.g., 4 subscriptions: 1 month, 3 month, 6 month, 12 month.

If you purchase 3 month subscription, not only can't you purchase a duplicate of the 3 months, you can't also purchase 1 month, 6 month, or 12 month. That way the user would have to wait until the 3 month subscription expires and decide whether to renew it manually, allow it to renew automatically, or let it expire in order to purchase a new subscription package such as 12 month.

I understand coding combined subscriptions may be hard so please let me know if the above solution works. You have told me repeatability that I'm not mentioning solutions to the issue at hand. If this is the case, please let me know what issue you are referring to because this topic was specifically made to resolve the issue I have been mentioning.

Share this post


Link to post
Share on other sites

Posted

Mark, if programming Nexus to combine subscriptions is not doable, can't you disable purchasing the same subscription if one has an active one? Please at least add a setting per package that says "Allow duplicate purchases?" and a setting that denies purchase if another subscription from a list is chosen.



To add on to this, a per-item setting with a maximum quantity that a user can purchase each order and another for how many they can purchase every X amount of days/months/years/lifetime would be ideal and have a slightly broader use.
-Mary- likes this

Share this post


Link to post
Share on other sites

Posted

I recently submitted a ticket for this issue as it was becoming quite frustrating. We get a lot of package renewals on our site, and this comes up at least every 1 in 3 renewals. After a user pays, in a week they get demoted to the base member user group with fewer privileges, then they contact us quite upset about not getting what they paid for.

I understand the complications that are involved with implementing this fix that Mark outlined earlier, but could a setting be used? Which may not work for everyone depending upon how their packages are set up, but at least it would be there for those of us who would like it to work this way? At the very least it should be a setting to not demote a user when a package expires if they already have an active copy of that package. Or, you could also take the route to only allow renewals of an existing package and not new purchases but direct the customer appropriately if they try to purchase it new, which would also solve the issue in certain cases.

I really hope a solution can be implemented (using secondary groups doesn't work for us). This really takes away from the automated renewal process we liked so much about Nexus, as we now have to manually change a user's group quite frequently post-renewal.

Thanks.

Share this post


Link to post
Share on other sites

Posted


I recently submitted a ticket for this issue as it was becoming quite frustrating. We get a lot of package renewals on our site, and this comes up at least every 1 in 3 renewals. After a user pays, in a week they get demoted to the base member user group with fewer privileges, then they contact us quite upset about not getting what they paid for.



I understand the complications that are involved with implementing this fix that Mark outlined earlier, but could a setting be used? Which may not work for everyone depending upon how their packages are set up, but at least it would be there for those of us who would like it to work this way? At the very least it should be a setting to not demote a user when a package expires if they already have an active copy of that package. Or, you could also take the route to only allow renewals of an existing package and not new purchases but direct the customer appropriately if they try to purchase it new, which would also solve the issue in certain cases.



I really hope a solution can be implemented (using secondary groups doesn't work for us). This really takes away from the automated renewal process we liked so much about Nexus, as we now have to manually change a user's group quite frequently post-renewal.



Thanks.




This* was reported in February. We're now in April. No solution as of yet.

P.S
You're not supposed to use primary groups if you have multiple subscriptions. The reason is because a person who is moved from VIP A to VIP B may lose features they already had in VIP A, and it gets complex if there are 5 VIP packages and people have different combinations. This is why I suggested for Nexus to have an accommodating setting or warning for the shop owner to only use secondary groups for multiple subscription packages. Changing primary groups only makes sense if you have just 1 subscription package. Since IP.Subscriptions didn't support multiple subscriptions, this was not a problem. But the developer(s) of Nexus did not take into account this problem (I assume) and is why Nexus delivers headaches to those shop owners selling multiple subscriptions.

*Problem = no combined shipping. See 1st page, bug report.

Share this post


Link to post
Share on other sites

Posted


To add on to this, a per-item setting with a maximum quantity that a user can purchase each order and another for how many they can purchase every X amount of days/months/years/lifetime would be ideal and have a slightly broader use.




I would also like to see a maximum quantity that can be purchased option with each product.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.