Bug Event triggering error, and fired when it shouldn't.

[Sbenny]

Here's how it happened:

• The user in the screenshot posted a thread which has the event "Thread" which is set to award 200 credits when a thread is posted in that node and 200 credits deducted when it's deleted.
• He posted it and gained 200 credits normally.
• I went to edit his thread and BAM that error appeared.

I know why this happens, altough you might not see it as a bug, I personally see it as bug indeed. I'll explain what I think it happened:

• Editing his thread, altough I'm not the author of it (being a staff), the thread was considered as "deleted" (firing the negation event) and then "posted as new thread".
• This usually generates 2 events (and 2 notifications sent to the user). The first event will try to deduct is trying 200 credits from his account and, if succeed, another event will add again those 200 credits.
• He doesn't have enough (from the screenshot you can see 99 credits), and here's why this weird error appears. I'd better expect:

a) A notification saying he doesn't have enough credits (I don't like this solution, but at least it's an improvement from a weird error message to something humanily redeable, which, at the same time, doesn't give users precious informations about our files location and database structure)
b) His credits being reset to 0 as set in the Currency Settings (I don't like this solution, he'll end up losing just 99 credits and then gaining 200 credits)
c) His credits not being deducted at all, because I'm not deleting and starting a new thread, but I'm just editing a thread (ideal solution)
d) His credits being temporarily deducted by 200 (going to -101), ignoring the Currency Settings, and then added 200 credits (alternative but still ideal solution)


Hope it helps better understanding this issue. For any questions, I'm here.

 

[Fillip H.]

The issue here is that prior to a certain date, there was a bug in the installer where the default credits column that came with the mod was actually created as an "unsigned integer", which means that going into the negatives is impossible.

What is actually normally going to happen is, based what I can surmise from your settings, option B.

The way you would fix this is to run the following query:

ALTER TABLE xf_user MODIFY dbtech_credits_credits DOUBLE NOT NULL DEFAULT '0'

The reason why this installation problem hasn't been corrected in an update is that it is not guaranteed that this column still exists, and if I tried to modify the column when it doesn't exist, it would trigger an error message. I will investigate whether it is possible to run that query in an update step without triggering an error.

 

[Fillip H.]

Regarding the two events being fired (negation then application), I think what I will do in v6.1.0 is add a new option, named something like "Always apply negation event" which will control whether an edit operation applies a negation before re-applying the event.

The reason why negation events are always applied now is the fact that a fair number of event triggers have a "character amount" or "word amount" input, e.g. you could award 0.1 credits per word in a post or similar. When a post is edited, the word count will change, and therefore the amount of credits being awarded should change.

In that situation, it is appropriate to negate the previous event (using the previous post text), then apply the event again (using the edited post text).

This applies to more events than just Post events, I just used it as an example as it is the most obvious example.

Circling back to that option; the tentative plan for that option is to make it disable those "Amount" options for all events, so that there is no need to negate them on edit. Given that the current functionality is the source for a lot of confusion, as well as race conditions, I am inclined to make the option default to off.

 

[Sbenny]

Thank you for the fast reply. Does this mean the user is going to earn more than he'll be charged for with the negation even then? (losing 99 and gaining 200)?

 

[Fillip H.]

That depends on your currency settings. If you review them, you will see there are 3 options. Off the top of my head, they are named something like "Reset to 0", "Display 0, but allow negative" or "Allow negative".

If you have "Reset to 0" selected then yes, they will lose the remainder and then earn the full event amount.
If you have either of the other two selected then no, they will lose 200 (putting them at -101) then gaining 200 (putting them at 99).

 

[Sbenny]

Thanks, I selected the second one for now, as the Reset to 0 seems to be problematic under these circumnstances.

 

[Fillip H.]

I would recommend that you test how Charge events function when selecting either of those options, as I am not sure whether it will still tell users "you need x credits to perform this action" if they do not have enough credits.

It will (probably) be a few weeks before I am prepared to undertake any design changes to the way charge events are handled, but it would be useful to know how they behave.

 

[Sbenny]

I just tested a charge event for posting a thread in a node, and it showed I don't have enough credits for that action. I was scared it would have let the user post it without having enough credits, but it looks like it's working, for now.

Also tested the charge bbcode, and I still got a message saying I don't have enough so it didn't let me spend them.

 

[Fillip H.]

Great, that's exactly how I was expecting the "Display 0" option to function. Thanks!

 

[Sbenny]

You're welcome. Whenever you need a tester, you can count on me.

 

[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.