Usergroups and additional usergroup in vBSuperPMs - lite + Pro

[DragonByte Tech]

Originally Posted by synseal

Yes but WHY do they work different?

They work different because we wanted to avoid forcing administrators from having to go through multiple vBOptions, ticking potentially hundreds of boxes, in order for their forum to continue to operate as it did prior to installing the modification.

Imagine you are running a forum with 100 usergroups, because you're running a gaming clan forum that spans multiple different games, so you need fine-tuned permission control. You want to ban new clan members from posting links in PMs. There are a total of 10 usergroups that belong to "new clan members" for the various clans.

Scenario 1: You have to tick 10 boxes in 5 different settings in order to ban "new clan members" from posting links.
Scenario 2: You have to tick 90 boxes in 5 different settings in order to allow "full clan members", as well as all your staff, to post links.

I don't think you'll find anyone who would claim that Scenario 2 is the most user-friendly scenario.
Scenario 1 provides the most user-friendly experience for new installs.

This is why the setting was created in a backwards way.


PS: It's funny you should bring up our Thanks mod, considering the most frequently asked question from new customers is "I installed this mod and nobody can click any thanks button, where is the button to click thanks?" because we employ Scenario 2 in that mod.

There has literally not been a single week in recent memory where we have not received that question. It costs us, as well as our customers, time and money as a result.
The customer is frustrated because the modification appears not to work, so they feel like they have wasted their money.
We are frustrated because we have to answer the same question eleventy bajillion times.

I'm sure there's a way to solve this that works both ways, but thus far I haven't been able to think of it.


Fillip

[synseal]

Thanks for the explanation.

I did say this runs backwards on your site and you told me I was looking at the additional usergroup fundamentally wrong when I wasn't, which is why I said you haven't a clue. I wasn't wrong about this and how VB operates but I apologies for saying that to you.

With what you say above will your future Modification releases work the way this Modification does with additional usergroups or is this just a one off cause Ozzy wrote it. I seriously want to know as you offered me store credit and refused a refund and I wouldn't want to buy anything else further from your site that works this way round.

No offence its a serious question thanks.

[DragonByte Tech]

That would depend on the nature of the functionality in question. If we ever were to add functionality that has the potential to negatively impact the stock functionality until such a time as the administrator has configured the mod, yes we would absolutely add a "backwards" setting like that again.

In a similar vein to the Thanks mod, we would have also gone with a "backwards" setting if we were writing the modification for the first time today, but with the knowledge of what the current permissions scheme has caused in terms of the support load.

In short, we can offer absolutely no guarantee that any of our existing, nor future mods will not contain such a permissions scheme.

As for the refund policy, this is clearly laid out in the Terms of Service which you gave us express notice you had read in full & agreed to, before you submitted your payment to us. The nature of digital software means that offering refunds for products that have been downloaded (and especially installed) would open us up to getting scammed. I'm not saying you are a scammer, I'm saying that this is unfortunately one of those cases of malicious individuals ruining it for the rest of you.

The fact that, on a case-by-case basis, we offer store credit is a middle ground where even if we are getting scammed, we lose less money than if we were scammed by a full refund.

Full refunds are only available if our system shows no record of the product being accessed/downloaded prior to requesting the refund.

All of that being said, this isn't the correct forum to discuss DragonByte Technologies' policies.


Fillip

[John Lester]

Originally Posted by ozzy47

Those mods you mentioned work a bit different when checking permissions. They use something like:

PHP Code:

if (!($forumperms & $vbulletin->bf_ugp_forumpermissions['canview'])) 


While the mod in the first post uses something like this:

PHP Code:

if (is_member_of($vbulletin->userinfo, explode(',', $vbulletin->options['default_online_groups']))) 


Two totally different ways of checking, and both are legit, it just depends on how the coder who wrote the mod decided to do it.

Is it possible to code an option in the ACP to select between the two types of permission checks? Or would that cause a conflict in the code somewhere?

I realize it would almost double the code as you would have to do an "if such and such in the acp is checked use permissions a (or b)" for each option, which could be more of a hassle than it's worth.

[kh99]

The question's been answered, please take any additional support discussion to the dbtech forum or PM.

[Paul M]

Kevin has cleaned this up of silly arguments. please act like grown ups.

JFYI, working "backwards" as you call it is unusual, but also fine, there are no "rules" about it.

[John Lester]

Just so I don't get a warning or whatever, can we discuss my questions posted above? Or should I start a new thread or drop it altogether?

[synseal]

Originally Posted by John Lester

Just so I don't get a warning or whatever, can we discuss my questions posted above? Or should I start a new thread or drop it altogether?

As the thread starter I don't mind it being discussed as it still conforms to the thread subject at hand and I would also like this to work as all D-bytes other modifications do.

As said it is "unusual" for Modifications to work this way round so it may be beneficial for others that want it to work the "normal" way round way.

Unless DB are considering this already, I don't know?

(edit) please consider this the lite version as that works the same way.

So is there is no reason this cannot be discussed here according to the rules?

[TheLastSuperman]

Originally Posted by John Lester

Is it possible to code an option in the ACP to select between the two types of permission checks? Or would that cause a conflict in the code somewhere?

I realize it would almost double the code as you would have to do an "if such and such in the acp is checked use permissions a (or b)" for each option, which could be more of a hassle than it's worth.

If the author checks using two differnet bits of code then it can be done, usually its not "double" the code either i.e. if the .xml file was 2mb it doesn't go to 4mb just by adding in a small amount of code to "check" something. Basically the author could add in a new setting in the setting group of the mods xml, then in the primary plugin that handles or initiates the parsing simply add the check to that plugin and have it check the new setting, if it does or does not match or equals this THEN do what you want done or not done etc. Edit: You could also have it check and set a variable, later in the plugin or in a plugin that works in conjunction with another - you then say IF the variable = this, do this etc.

[synseal]

DragonByte Tech.

Is there any plans on making this modification work with the additional usergroups anytime soon so Admins can configure it the usual way or is this never going to be an option?

Just saying - I would pay allot more for this mod if it had that ability...........