Legacy Purchasable/Giftable Usergroup change Item

[nte]

Hello,

Here's a bug I've noticed in our community. We offer various (VIP) groups in a shop. Problem is following: If item is giftable it can be abused. Example:

User buys a usergroup change through shop and then gifts the same item to another user. In this scenario it will then happen that group is not removed from first user so both users will end up having/getting that group. And if item is furthermore giftable it can in essence be shared around and only purchased once. It's not really a big deal since I simply disabled giftable option but has potential if not spotted to create issues since it can easily be abused.

Another bug that is directly tied to this is "expirable groups"; Where if set Usergroup Change item expires in a certain time it will remove the item/mark it expired but group is not removed so it kinda destroys the possibility of "limited time only" scenario when it comes to "Usergroup change".

I think I covered all the angles, if more explanation is required let me know and I will gladly provide it.

Kind regards,
Nate

 

[Fillip H.]

Hi Nate,

The functionality you describe is by design

Certain items, such as Usergroup Change and User Name Change, cannot be reversed either when discarding the item, the item expires or transferring it to another user. The reason for this is that it would be very difficult to maintain data integrity were we to try to restore the previous data.

Two quick examples:
Usergroup Change - Let's say members start as Usergroup A and can buy Usergroup B, which can be promoted to Usergroup C via post count. Once user reaches C, they discard the item that changed their group to B. Do we undo the promotion? Or only revert the usergroup if it's still B? Different forums would have different preferences, and supporting all of them would make the item very complex to use.

Username Change - User changes from Test to Test2, then someone else registers with Test (or changes their name). What now? Does the revert do nothing? Again, different forums would have different preferences, some forums would want a feature where the member that "stole" the original username would be forced to change it, some would want the revert to do nothing, etc. Again, the item would become very complex.

For this reason we recommend admins do not set up these items with the parameters that allow for a single item to be transferred to multiple users. We have multiple configuration options intended to limit the ability for these items to "spread" in the way you describe.

Furthermore, this is the first time (as far as I can remember) anyone has ever brought up this issue, as far as I can tell it's not a widespread problem that many forum admins struggle with.

 

[nte]

Here's a simple way how complexity can be tackled.

A simple check field is added into UserGroup Change options where it asks if group should be removed if user discards the item. That solves the complexity issue since it's on per need basis.

On tech side of things additional Table is created containing item ID - Group ID - user ID fields. Since it's a table and not fields it's scalable. So multiple entries can easily coexist. And if field for removing groups is checked then group is simply removed when item is discarded/expires.

To solve any additional/potential bugs one only has to keep in mind that on any purchase an item with that option has to be added into a table regardless if field for "reverting" is checked by the time of purchase or not since if admin creates an item and at first doesn't check it but later on decides to modify it so it's lost on discard entry resides in table and thus group is removed if desired..if not, it's just removed from "tracking" table and no further action is needed.

EDIT - scratch above:
In fact a simple hook with "remove group on discarding/expiration" could be added and if checked, it removes it when item is discarded/expired, so complexity is non-existent and just falls down to one handling the shop. That's in essence it.

It's a simple solution as it's easily achievable (hook/db/optional action) and solves the complexity issue since it's on per choice basis so it's not 1 size fits all approach.

In either case, if it makes it or not is up to you and however you decide it's fine but if you ever decide to go into it, approach written above could be a possible solution.

 

[Fillip H.]

Hi Nate,

Sorry, but I don't see how anything you just put solves the issues I brought up in my examples. As far as I can tell, all your post describes is a method of storing the old value to be removed, but it does not address any of the issues should the original value be changed.

What I have to bear in mind when choosing whether to add this functionality is whether people will want it to work differently. If one forum wants to make the changes revert when the UG is the same but not if the UG has changed, another forum wants to put the old UG back as a secondary UG but only in the event the primary UG has changed, [...]

There are several different combinations that this could work, and it would be a monumental task to implement all possible variations.

Of course, there's nothing stopping yourself or indeed anyone else to open a Feature Request thread, and possibly design an update around this I don't mean to sound like I'm totally opposed to changing this!

 

[nte]

Sorry for late reply.

If you want to extend it and make it more suitable for wider audience than on a (optional) rollback you simply introduce two options:
- Should group be removed when item is discarded/expires?
- (If so) If group is primary to what group user reverts to after it is removed / If secondary, should user get a different group (solves from C -> D dillema).

Brilliance of this design resides in a fact that:
a) It's optional, so it can or cannot be used
b) Complexity solely resides on a Admin/Manager introducing an item and not a script itself so it's breakable by one doing it and not script itself.

In essence it's just a optional reverse (rollback) action so it does not break any existing installs nor does it meddle with anything, rather just extends possibilities and can be completely ignored if not needed.

Just one thing I would like to address - In your initial reply I failed to address the following; This is requested only for Usergroup Change item as in a Namechange item such an option makes no sense for reasons you already stated.

In either case, I just wanted to clarify it and polish the concept a little better since in essence it's just a hook and not a feature that would require serious work or modifying the core of the script. I understand there's various- some less, some more justifiable reasons why it should or shouldn't be done. However you decide is fine by me, I just wanted to lay it out.

And sorry for (again) opening a closed ticket. There's nothing more to be said from my end so I'll accept any resolution accepted. Truth to be told, it fell more into Request than Bug realm at this point.

Nate

 

[Fillip H.]

Don't worry about opening a closed ticket, they are completely open for replies I set the status so that if people stop replying, the ticket doesn't clutter my "needs looking at" display (which doesn't include Feature Requests), and so that they get the option of re-opening it later

I agree about this being a feature request, and I've changed it to reflect that