Legacy vBSuper PM's Link/Email Settings additional usergroup

[HiTeck Techkings]

Another problem I am having is.

When someone has made a donation to my forum there members account becomes an additional usergroup which is named Forum Supporter.

Their user title remains the same but go into an additional category whereby they can do what non forum supporters cannot e.g download without having to post first/more email quota/ bigger avatar/ signature etc etc and that always automatically is allowed after the donation is made without any problems.

So I have this modification set up like this for vBSuper PM's Link/Email Settings

I want members that have donated to the forum to be allowed to post links in private messages - email addresses in private messages and email addresses in titles.



BUT when a user that is a lets say going by the above image a "TK veteran" and has donated to the forum so is an additional user = "forum Supporter" the super pm system gives them the no permission error message.

This member is a TK veteran that has donated so is an additional usergroup "forum Supporter".

See error messages in both images;





Showing his additional group;



With downloads or anything else this additional usergroup gives them extra permissions but doesn't appear to work the same way with this modification?

 

[Fillip H.]

That's not how those permissions work. If you are a member of one of the groups ticked, it doesn't matter what your additional usergroups are

I'll change this to a Feature Request so we can take it into consideration for future versions. Please do be aware that Feature Requests aren't considered support tickets, so I will not be alerted to any further responses to this ticket. As a result, responses may be delayed.

 

[HiTeck Techkings]

You're wrong.

WIth all other modifications that I have installed that I have added as an additional group and even vb stock upgrades for "forum supporters" having larger avatars/sigs etc . The additional usergroup/ if better/ overrides the lesser.

Seriously how would the VB stock paid subscription work otherwise?

 

[HiTeck Techkings]

THis should have been left as a bug! it is a fault whereby the additional usergroups are not taken into consideration with this modification. This shows the case with the vbulletin stock paid subscription explanation here.



Can this be fixed please otherwise this modification is useless to me once again as it seems with every modification I buy here.

 

[HiTeck Techkings]

It also explains the exact same thing here on vbulletin.

Explanation - Using Secondary Groups - vBulletin Community Forum

 

[Fillip H.]

I'm not entirely sure how the way vBulletin's permissions work is related to the way vBSuperPMs' permissions work?

vBSuperPMs was not coded by Jelsoft/Internet Brands. The original coder of this modification used a different method of calculating usergroup permissions, and as a result the existing behaviour is not a bug.

For that reason, this support ticket was changed to a Feature Request because it seems logical that you would request to have vBSuperPMs' method of calculating permissions changed to match that of vBulletin / other DBTech mods. If this is not the case, please let me know and I will change this ticket back to a Bug report and close it as "Working as Intended".


To elaborate: If a modification works different from how you would like it to function, or expected it to function, that's not a bug. The modification was not coded in a way that makes it function the way you want/need it to function.

 

[HiTeck Techkings]

I would like it so that when a user pays via vbulletins own "Paid subscription" they get these extra features. How would I go about making this happen otherwise this is useless to me and a waste of my money.

I would really like to keep this feature and I paid for 3 months. If this is updated to work as it should with vbulletin after 3 months I will have to buy it again so do you have a time frame in mind if not I would prefer a refund please until this is included.

 

[Fillip H.]

The way you would do this is to avoid using "Additional Usergroups", instead making your paid subscriptions move their primary usergroup to the supporter group.

This means you will need to go through all usergroup & forum permissions for your supporter group, as well as any UG permissions from other modifications, to make sure they do not lose any additional functionality.

Unfortunately I can't give you an ETA for implementing this feature request, because of the fact that it would require a complete re-vamp of how the modification works. It would also involve resetting everyone's configured permissions, which is something we want to avoid wherever possible. For that reason, we would only do this if the update also carried a significant amount of other features and enhancements, otherwise it would simply not be worth the dozens of man-hours that would need to go into such an update.

As you are the only customer out of all the countless people using this modification to complain, the vast, vast majority of our customers would see an update that (to them) contains no benefits whatsoever, yet requires them to reconfigure their settings. I hope you can understand that it would not make business sense to release such an update.

 

[HiTeck Techkings]

Its very strange that you don't make this to work with how the vbulletin uses and considers additional usergroups.

Your explanation means say a "VIP member" who on my site only earns that stature from a good amount of informative posts if then say that VIP member donates to the forum his usergroup title will be downgraded to forum supporter instead of using the additional usergroup feature which allows him to retain his user-title and also benefit from the extras a "forum Supporter" has. Its backward! and I am very very surprised that no one else has brought this up.

 

[Fillip H.]

Its very strange that you don't make this to work with how the vbulletin uses and considers additional usergroups.

Let me clarify, it does consider additional usergroups, just not in the way you expect.

Currently, vBSuperPMs uses the vBulletin Options system for mass usergroup configuration. By necessity, this means that any usergroup permissions are inclusive - i.e. that you tick the usergroups you want to explicitly ban / explicitly grant access.

It's obviously not possible to set defaults for any and all usergroups that a customer has created.

This means that if one or more of a user's member group is explicitly banned or explicitly granted access, the user as a whole will be banned or will be granted access.

In this particular example, you are explicitly banning certain usergroups, meaning that as long as a user is a member of any of these usergroups, the user will be banned.

What you want is "if any of the member groups they are a part of are not explicitly banned, then they should not be banned", which is impossible. No part of vBulletin nor any other modification works in this way.

Alternatively, the setting's functionality could be flipped, so instead of it being a ban list it's an allow list. That means every new customer will have to spend the time configuring the modification, instead of only the ones wanting to avail themselves of this functionality needing to do so. This is a very poor solution for obvious reasons.

At some point during vBulletin's lifespan, they changed the "Is Banned Group" usergroup permission to "Is Not Banned Group" for this exact reason. Before, if you defined a user's group as a banned group, it did not matter what other groups they were a member of, they would still be banned due to that one group they were a member of.
They changed the permission so that the only way to ban someone (via usergroups) is if ALL their member groups had the "Is Not Banned Group" set to No (a Yes always overrides a No).

You might ask yourself why we don't simply do the same thing - the answer is that modifications cannot control usergroup defaults for non-standard usergroups. In other words, changing this functionality would break the modification for every existing customer (yes, including yourself), as well as all new customers, until they manually configure each and every one of their usergroups.


In short, I would like to ask you to please stop claiming that the way this modification works is somehow not in line with vBulletin's usergroup functionality, because it demonstrably is.

If you would like a custom version of vBSuperPMs with changes to the permissions schema to match your particular usergroup setup, our Custom Work form can be found here: http://www.dragonbyte-tech.com/info/customwork/

I am very very surprised that no one else has brought this up.

Perhaps nobody else uses the exact same usergroup structure and uses that exact feature of this mod in that exact manner - considering the amount of potential setups, it's not strange at all in my opinion

 

[HiTeck Techkings]

It doesn't consider additional usergroups the same way as vbulletin does otherwise I wouldn't be having these issues. I don't think your fully understand what is happening.

This copy from the vbulletin article I posted the link above explains that.

S

Secondary groups are extremely powerful, but their concept can be confusing. This post will attempt to clarify what they do and how they can be used.

With the introduction of secondary groups in vB3, users are now able to belong to multiple usergroups at once. A user will always have one primary group, but they can belong to any number of secondary groups. The permissions from a user's secondary groups merge together in determining their final permissions, such that one Yes permission overrides all other No permissions. For example, if a user is a member of one primary group (pgroup) and two secondary groups (sgroup1, sgroup2), and the Can Post Threads permission looks like this among all of the groups:

pgroup - No
sgroup1 - No
sgroup2 - Yes​

So as above.

TK Veteran - is set to not allow posting of links. so this is a NO
Forum supporter - is allowed to post links so this is a YES.

YES overrides NO with vbulletin and all its built in features so you are incorrect. This modification does not work as it should do with usergroups which is why I said I was supprised that nobody else has reported this or maybe they have and your not taking it in as you are doing with me.

---

Same with Downloads II

If a member joins they need to post once to use the download section.

If that member joins and pays for forum supporter usergroup they don't need to post they can go straight ahead and download due to the paid subscription adding that addtional usergroup.

Zero poster = NO
Forum Supporter = YES

So the outcome is YES as YES out of the two rules always overrides NO.

---

This next e.g is all vbulletin stock, no modifications used.

Forum Supporter = larger signature 10 lines /more pm quota 500 inbox messages/larger avatar 200x200/can manage own profile.
Zero poster = signature 5 lines / pm quota 10 inbox messages / avatar 90x90 /.

Then go ahead and look at that user permissions/quota. Out of the two groups when merged due to forum supporter being an additional usergroup that person will have the higher amounts of the two groups.

If this modification worked the same way as vbulletin considers additional usergroups I wouldn't be having problems whatsoever.

 

[Fillip H.]

TK Veteran - is set to not allow posting of links. so this is a NO
Forum supporter - is allowed to post links so this is a YES.

YES overrides NO with vbulletin and all its built in features so you are incorrect. This modification does not work as it should do with usergroups which is why I said I was supprised that nobody else has reported this or maybe they have and your not taking it in as you are doing with me.

Your understanding of this is fundamentally wrong.

Please try to understand this: Ignore the title of the setting, and instead focus on the actual checkboxes themselves.

When you tick a box in the "Excluded Usergroups PM Message" setting, this constitutes a YES.
All usergroups that are not ticked, are considered a NO.

Therefore, if you tick a box for TK Veteran, this means that TK Veteran has 1 YES, which overrides all NO.

Therefore, everyone who is a member of TK Veteran, as well as any other usergroup, will return YES for this check.

Are you with me thus far?

Now that we have established that any user who is a member of TK Veteran will return YES for this check - regardless of their other usergroups, let's apply the meaning of the setting. The setting is titled "Excluded Usergroups PM Message", which in this context means "Selected usergroups can NOT post links in the PM body".

Now we take that meaning and apply it to the conclusion we arrived at earlier: "Any user who is a member of TK Veteran, regardless of their other usergroups, can NOT post links in the PM body".


I hope this clarifies for you the way vBulletin's additional usergroups functions.

 

[HiTeck Techkings]

We are not going to agree on this are we. Everything else on Vbulletin all other mods and the stock itself works the same. I am shocked you don't already know this in fact I am going to start another thread over on VB.org asking this then direct you too it.

TK vet = not allowed
forum S = yes is allowed


Tk vet and forum supporter become merged when a tk vet pays a donation (additional usergroup) thus giving a yes no conflicting situation.

YES ALWAYS overrides no. Its in the vbulletin manual here for god sake https://www.vbulletin.com/docs/html/main/acp_permissions_overview_multiple_groups


Can you ask ozzy to look at this please as he made the modification and you clearly haven't a clue.

 

[Fillip H.]

No, I don't think we are going to agree if you continue to argue that you know more about programming vBulletin modifications than me.

Since everything I say is going to have to be repeated in the vB.org thread, I'll simply end my involvement in this thread by saying that while your words are not wrong (yes overrides no), your understanding of what constitutes a "yes" and what constitutes a "no" in terms of actual programming is wrong.

I'll close this feature request & this thread, as we're not going to get anywhere and we will not be making any changes to the product to suit your needs, as it would mean violating the fundamentals of vBulletin that you yourself argue for. Feel free to PM me the link to the thread and I'll re-post my explanation in that thread.