Bug Post Event Bug

[ichpen]

Fairly serious issue I believe.

Use case:
Post event, credit = 5, negation=5, word amt = 0.01, word negation amt = 0.01, min words=2, frequency = 1, max application = 5, limit period = 86400 (24 hours).

OK, here's what happens, everything until the max application limit is fine, once you hit that limit things go wonky. I created 7 posts, received 25 credits which is perfect BUT then I went back and edited previous posts and on each edit (I was adding words though that is irrelevant) 5 credits were deducted. Fairly serious issue for members who edit a lot, and I have a few.

 

[ichpen]

So in the ACP transaction log I see correct number of transactions (with the edit doing a subtract and add) but my total doesn't add up so more of a totals bug.

This was a test using max = 3, I did one edit and I'm showing 5 credits on the front end which doesn't match up the transaction log below at all.

See attached. Easy to recreate, basically put a low ceiling, go beyond it, edit any previous post and you'll see totals going down. Not sure if other event types that allow for a ceiling are affected.

 

[Fillip H.]

The transaction log in the AdminCP does not make any distinctions about whether a transaction was skipped, which is the issue you're seeing in the transaction log.

The problem is that the system has no way of knowing whether a successful transaction has been applied prior to negating it. That's one of the big design issues still left in this mod (you would have hated the vB version with a passion ).

I do have potential solutions in mind, but there's pitfalls.
First and foremost; performance. I need to ensure the database is properly indexed so when I query for matching transactions, it doesn't kill the site for large sites.
Secondly, I need a way to ensure I can still keep transaction logs for transactions that have been negated, so I need a way to tie the original and negation transactions together.

There's probably other concerns as well that I can't think of right off the top of my head.

Also, before I'm able to commit to a large rework like this, I need to create a rebuild feature. It's the number one concern for forums installing this mod for the first time, and needs to be addressed.

Before that can be added, I also need to finish the Shop conversion, as a lot of forums are blocked from upgrading to this version until this has finished.

Before I can start that, I need to ensure I'm on top of XF 2.1 compatibility issues and preparing versions of all mods that work on XF 2.1.

In other words: Reworking the transaction system so that I'm able to fix this issue is a high priority, but so are a lot of other things.

If I delay the Shop conversion, I'll potentially have to tell customers stuck on v5.0 "sorry, I can't help you with this problem you're facing because it's been fixed in v5.1, which you can't use.".

If I delay the Rebuild feature, I'm harming sales of this mod for people who are installing it on an established forum.

If I delay the XF 2.1 compatibility, I'm harming sales of all mods as people want to use the latest & greatest XF version.

It's not so much a catch-22 as a Triple Decker Mc-Catch-22, which I guarantee you tastes worse than anything else sold at McDonalds.

 

[ichpen]

Appreciate the triple honesty sandwich

I guess at this stage the workaround is basically to ditch setting ceilings (max amt) on any supported event types until you figure this out. It's a pain for me and other communities where we want to limit credit abuse but can live with it for a little while in the name of shiny new 2.1 things.