[DBTech] DragonByte Credits [Paid] 7.3.2

[DragonByte Tech]

DragonByte Tech updated [DBTech] DragonByte Credits with a new update entry:

7.2.0b2

Update highlights​

This version brings the biggest update to addon integrations in Credits' history, alongside continued improvements to the Rebuild feature.

Continuing the work from Beta 1, the rebuild feature no longer offers the option to reset currency values to 0 (balances would always be recalculated anyway), and in its place it now offers an option to reset only rebuildable data.

A change from Beta 1; the Balance rebuild jobs now always run after rebuilds, to...

Read the rest of this update entry...

 

[DragonByte Tech]

DragonByte Tech updated [DBTech] DragonByte Credits with a new update entry:

7.2.0

Update highlights​

This version focuses mainly on bug fixes, but it does contain one new feature; You can now optionally allow credits expiry to take members into the negatives. This can help prevent users racking up expiring credits, spending them all, then not being able to have the credits deducted. You can turn this feature on or off by editing the "Expiry" event in the AdminCP, and it's off by default (to preserve current functionality).

The other notable change is...

Read the rest of this update entry...

 

[DragonByte Tech]

DragonByte Tech updated [DBTech] DragonByte Credits with a new update entry:

7.2.1

Update highlights​

This version adds full content type support to the "React" and "Reacted" events, so they can be used with all content types supported by Credits. It also allows for choosing "Any", which would trigger the events even for content types not yet supported by Credits.

Furthermore, a fix has been created for a recent compatibility issue with @Xon's...

Read the rest of this update entry...

 

[DragonByte Tech]

DragonByte Tech updated [DBTech] DragonByte Credits with a new update entry:

7.2.2

Update highlights​

This version fixes an issue with the new React/Reacted event content types added in v7.2.1, as well as further widening the negative balance changes to include all actions taken by a moderator.

Complete Change Log​

Change: Moderators can now delete, restore or approve content, including their own, regardless of the author's credit balance
Fix: Reaction events limited to specific XFRM, XFMG or XenAddons...

Read the rest of this update entry...

 

[javakhir]

new updates removed links to show, which Resource has been downloaded & trigerred. how to bring it back?
user not able to see, which resources they get paid for

 

[DragonByte Tech]

new updates removed links to show, which Resource has been downloaded & trigerred. how to bring it back?
user not able to see, which resources they get paid for

Sorry I don’t understand, the transaction history is still there. Can you clarify, please?

 

[javakhir]

missing XFRM link at the end

 

[DragonByte Tech]

missing XFRM link at the end

What version are you running?

 

[javakhir]

7.2.2

 

[DragonByte Tech]

DragonByte Tech updated [DBTech] DragonByte Credits with a new update entry:

7.3.0

Update highlights​

This version adds support for XenForo Resource Manager and DragonByte Manuals Library to the "Content Access" system that was previously occupied only by threads.

For the XFRM, the resource can be viewed, but downloading (or accessing the external URL) requires the content access payment.
As for DragonByte Manuals, only the description/custom fields can be viewed. Reading or downloading the manual requires the payment.

Furthermore, a few bugs have...

Read the rest of this update entry...

 

[javakhir]

Good evening to you! The same person downloads the same resource 3 times, event adds him 3 times. Where should we restrict it?
if user downloaded resource already, the second time must not be counted

 

[DragonByte Tech]

DragonByte Tech updated [DBTech] DragonByte Credits with a new update entry:

7.3.1

Update highlights​

This version fixes an issue with the currency donation feature, as well as resolving a couple currency privacy issues.

Complete Change Log​

Fix: Donations no longer fail with an "outside the range allowed for this action" error
Fix: Currencies are now considered unviewable if the user doesn't have the "View" permission
Fix: Currency displays like the postbit now correctly respects the "Self and designated user...

Read the rest of this update entry...

 

[rootksk]

Hello,
We are experiencing the following issue:

We run a thread-posting event in a specific forum category. All threads submitted to this category are automatically placed in the moderation queue. Our moderators review them and approve those that meet the requirements. Once a thread is approved, the user earns credits. We then move the thread to the appropriate category.

However, since the recent updates, the system has been taking back the awarded credits when these threads are moved to another category.

How can we restore the previous behavior so that users keep their earned credits even after their threads are moved?

 

[DragonByte Tech]

Hello,
We are experiencing the following issue:

We run a thread-posting event in a specific forum category. All threads submitted to this category are automatically placed in the moderation queue. Our moderators review them and approve those that meet the requirements. Once a thread is approved, the user earns credits. We then move the thread to the appropriate category.

However, since the recent updates, the system has been taking back the awarded credits when these threads are moved to another category.

How can we restore the previous behavior so that users keep their earned credits even after their threads are moved?

This is working as intended. You should enable the event for the new category as well, that way they won't lose any credits.

 

[rootksk]

This is working as intended. You should enable the event for the new category as well, that way they won't lose any credits.

This was not how it worked before. Which version introduced this change? If I can find that out, I will try downgrading, as we have been using this workflow for many years.

Our situation is as follows:

We created a dedicated event category where users post threads to participate. These threads are automatically placed in the moderation queue. Our moderation team reviews them, and users earn credits once their threads are approved as meeting the rules. We then move each thread to the appropriate forum category.

If we follow your suggestion, we would have to require moderation approval for threads in every category on our forum, which is simply not feasible

I wish this behavior had been made configurable in the settings for each event we create, rather than introduced as such a fundamental change.

 

[DragonByte Tech]

This was not how it worked before.

The way it worked before was a bug, it was always intended to negate currency on thread move. You can find the evidence in the code going back as far as the original XF2 versions pretty much.

I wish this behavior had been made configurable in the settings for each event we create, rather than introduced as such a fundamental change.

That is something I can implement, I hadn't actually thought of that as a solution I'll release that update as soon as I can!

 

[DragonByte Tech]

DragonByte Tech updated [DBTech] DragonByte Credits with a new update entry:

7.3.2

Update highlights​

This version adds a new "Keep credits when the thread is moved" setting for the Thread event, which stops credits from being taken back when a thread is moved to another forum. It can optionally still award credits when a thread is moved into one of the event's forums.

Complete Change Log​

Feature: New "Keep credits when the thread is moved" setting for the Thread event

Read the rest of this update entry...

 

[DragonByte Tech]

@rootksk That should now be implemented, let me know if you run into any problems

 

[javakhir]

as you can see, if the same user views the same thread 5 times, event triggers 5 times as well.
how can we prevent this?

 

[DragonByte Tech]

as you can see, if the same user views the same thread 5 times, event triggers 5 times as well.
how can we prevent this?

That depends, what are you trying to accomplish exactly? If it's 1 view per thread only, that's not currently possible because XF does not register thread views individually. There is nowhere in XenForo that stores "user ID 1 has viewed thread ID 2".

The reason why this doesn't exist is that it doesn't scale well. Imagine a site with 100,000 threads and 10,000 users. If all members viewed every thread, that would mean a database table with one billion records. If we assume 30 bytes per record (storing two integers would take roughly this amount), that one database table would take 30 GB worth of space.

I would recommend you look at the View event settings, under Advanced Options, and use those to limit the event application instead.