Bug Two Paycheck event bugs in ACP Transaction Log

[fearmywrench]

Two separate issues with the Paycheck events in ACP Transaction Log:

1. Event reoccurs for every user on the Paycheck interval when maximum applications is set to 1 and limit period is set to 0
   
2. For some users, a similar incorrect Paycheck event bug occurs, but not consistently every 7 days and with dates into the future too. (they always appear at the top of the log due to this) On our test site, I'm seeing this with the users 'Justin Test' and 'User Test 1:54am' if that will help with re-producing.
   

Here are the details of the event this is occurring on:

Event Title: Member for One Week
Event Trigger: Paycheck
Event Amount: 10
Frequency: 1
Maximum applications: 1
Limit period: 0

In Credits settings, Paycheck interval is set to 7 days.

As far as I can tell, these bugs are only effecting display in the ACP Transaction Log. The front-end log is unaffected and the incorrect events don't seem to actually be occurring / making real credit adjustments, although I haven't done enough research to be 100% confident of that.

 

[Fillip H.]

This is working as intended, sort of. What you are seeing is skipped events, but I recognise that they are not properly highlighted as such.

 

[fearmywrench]

Skipped event meaning the maximum applications setting in the limit period has been reached? I would really suggest filtering these out unless specifically enabled in a filter for debugging purposes as these can easily add up on a busy forum and get confusing fast.

After posting this, I discovered a similar issue with a Daily Activity event I modified to weekly by changing the limit period, displays the event every day. I'm assuming this is from the same cause then and would display an extra skipped event for every user that visits each day almost.

Also, isn't the dates in the future a separate issue then? Or have I misunderstood something?

 

[Fillip H.]

Skipped event meaning the maximum applications setting in the limit period has been reached?

That's correct. If records were not inserted when skipped, transactions would fail to work correctly if the event configuration were to change.

Also, isn't the dates in the future a separate issue then? Or have I misunderstood something?

I will need reliable step-by-step instructions for how to replicate such an issue.

 

[Fillip H.]

I've just uploaded a new Credits build to the test site.

Feature: Event transaction moderation*
Feature: AdminCP transaction list / transaction view now displays the transaction state
Change: AdminCP transaction list now hides "Skipped" and "Skipped (maximum applications)" by default
Change: Renamed the Credits alert content types for consistency
Change: Rework the way Interest, Paycheck and Taxation events are applied in an attempt to reduce race conditions where events would apply into the future

* Individual events can now optionally place any transactions made by any user into moderation, which will place those transactions in the Approval Queue. There is a new permission controlling who can moderate these transactions. Approving a transaction will apply the credits, whereas rejecting a transaction will delete it from the system.


Undocumented change #1: Internally, transactions have changed from using a numerical status column to a text-based transaction_state, which is consistent with the rest of XenForo.
Undocumented change #2: It's now also possible to filter transactions by transaction state in the AdminCP "Search logs" form for transactions

 

[fearmywrench]

Haven't had a deep dive yet but took a quick look and these are some great changes. Thank you for taking the time to make them, it will definitely be a lot cleaner with the skipped transactions hidden by default but accessible if needed for any de-bugging. And the approval feature could be very useful too for certain events!

 

[Fillip H.]

I'm hijacking this thread since it's tangentially related; I can't find your previous post on the matter (or maybe it was Jeremy himself) but I've pushed a change to the test forum that changes spending transactions in Shop to no longer insert DB Credits transactions as "negated".

In other words, going forward, future transactions will no longer be "strikethrough".

You can update this for historical transactions by running a query like UPDATE xf_dbtech_credits_transaction SET negate = 0 WHERE event_trigger_id LIKE 'shop_%'

 

[DragonByte Technologies]

Hello @fearmywrench,

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.