Bug DONATE event not working unless all usergroups are selected

[Sbenny]

What's the point in having a "Usegroups" field in the DONATE "Event Settings" panel if it's broken?

If you select just a few groups, no matter which ones, you can't use the donate feature at all, making it impossible for admins to decide who can or can't donate to other users.

I reported this bug on the xenforo page of your add-on and you replied to me that it's not a bug. Then, if this isn't really a bug, how do you call it?


Steps to replicate the bug:

1) Select the usergroup "Adminstrative" from the Event Settings's groups.
2) Save
3) Try to donate to any users, being an Admin.
4) You get the following error:
"Sorry, this action is unavailable because a matching Event record was not found. "

Assuming I did the opposite, do the following then:

1) Try to donate as USER to an Admin (which is the opposite)
2) You'll get the following error:
"Sorry, this action is unavailable because a matching Event record was not found. "


I did some template edits to hide the Donate tab on non-staff members to temporarily fix this issue, but the "exploit" I was talking about on Xenforo forum was the possibility for malicious users to still be able to access the Donate functions simply by doing a local html injection, because hiding a tab from a template doesn't mean blocking a php script from being executed.

 

[Fillip H.]

The "user group" select box controls who can receive the event, in most cases. In particular for the donation event, it actually works both ways; both the sending and receiving user groups need to be selected.

This is because the Donate event works in two stages:
Stage 1 is taking money away from User A (negation)
Stage 2 is giving money to User B (award)

If User A or user B is not a member of any groups listed in the user group select box, then the donation event will fail with the error message you state.

This is working as intended, and there's no plans to change it at this time.

the "exploit" I was talking about on Xenforo forum was the possibility for malicious users to still be able to access the Donate functions simply by doing a local html injection, because hiding a tab from a template doesn't mean blocking a php script from being executed.

Being able to trigger an print-friendly message isn't much of an exploit

 

[Sbenny]

So if I want to allow just an usergroup to SEND money but all usergroups to RECEIVE money (which, to me, sounds more fair), shall I start another Feature Request?

I was thinking this would have been the default behaviour of the event to be honest, as I can't find a reason for having to select both sending and receiving groups, while just the sender would have sufficed, in order to actually prevent users from SENDING credits which is the main concern, and not preventing people from receiving credits.

But if you don't plan to change it, I'll opt to post another feature request, when I'll see previous ones will start to get replied at, to avoid adding even more load to you which would result in an even longer wait list.

 

[Fillip H.]

But if you don't plan to change it, I'll opt to post another feature request, when I'll see previous ones will start to get replied at, to avoid adding even more load to you which would result in an even longer wait list.

There is no such thing as a wait list. Feature requests are not implemented based on the time at which it was posted, they are implemented based on the Return on Investment - the value they add to the product for the time it would take to create it.

For instance, if someone posted a feature request saying "Please add integration with <some website that automatically generates pretty invoices from PayPal purchases", the ROI would be close to zero, as very few people would use this (comparatively speaking).

Feature requests that improve usability (such as this), would have a much higher ROI and therefore would have a much higher priority.

 

[Sbenny]

Thanks, it's the reply I wanted to hear from you

 

[DragonByte Technologies]

Hello @Sbenny,

We hope your ticket regarding DragonByte Credits has been addressed to your satisfaction. This ticket has now been closed.

If your ticket has not been resolved, you can reply to this thread at any point in the next 7 days in order to reopen the ticket, afterwards this thread will be closed.

Please do not reply to this thread if your ticket has been resolved.

Thank you.


- DragonByte Technologies, Ltd.