D7 Port

I'm not really using D7 yet, so I haven't looked at porting it. If the schema hasn't changed, I imagine it's mostly a matter of rewriting the queries to use the new database API layer.

It would be interesting to port this module to D7.

Thanks a lot

I can port it, but since my last comment I discover that the functionality of this module are implemented in userpoints so I think porting this module is not necessary.

Maybe I'm wrong.

A 7.x-1.x-dev release of the module should be available shortly. Please test :-)

Points do not evaporate.
After an hour I ran cron, logged in my user (after an hour and 10 minutes) and the points were the same as before.

Can you check what the watchlog log says for userpoints_evaporate? I checked that the queries ran locally, and my installation does log that it has evaporated some points, but I didn't actually check that the points had gone, now that you mention it :-P
Will do so shortly :-)

In the meantime, if you could help with the above code that I posted, we have a temp fix.

I've not used Rules on D7, mainly because it's always given me errors and WSODs, so I can't help with that one...

I see the problem, the named placeholder in the query that updates point totals is parsed as a string, so the query fails silently.

The DB API is not cooperative and refuses to interpret the number of points to be deducted as an integer, so I've had to include the value in-line in the query, without using a placeholder.

That updates the totals for me when cron runs. A new 7.x-1.x-dev release will be built when d.o next does its cron builds.

If you need to test sooner, you can apply the attached patch to your 7.x userpoints_evaporate module.

Okay, I've set up a site in aegir to be able to test this thing properly. There were two problems I've found and (hopefully) fixed in regard to this issue:

1. The transaction log query was not limiting its run to the specific category, but inserting transaction for ALL categories on each run through the loop. That would be *bad* :-)
2. There's a new table, userpoints_total, which keeps a running total of the combined number of points, which wasn't be updated.

I've fixed the transaction insert query to only affect the specific points category on each run and added a query to update the total points per user in the userpoints_total table. Should be in the next available 7.x-1.x-dev release.

Also, I've moved the configuration to a tab on the userpoints module configuration.

Yup, it's been running on my system overnight and it *looks* to be working as intended. I have a category that expires 5 points for inactive users each hour and a category that expires 1 point for all users each hours.

Both have worked correctly for the past 13 hours. All users have lost an equal amount of the points that always evaporate, the admin user has lost less of the points that only expire for inactive users because I've been using it to check results.

That is the codebase I checked in over 12 hours ago, so the current 7.x-1.x-dev should include those fixes.

I note that userpoints_no_negative was not ported to D7, so I'll add functionality to evaporate to set 'No negative' as option for each category... my users now have -6 points :-) ( #1372452: 'No Negative' function in D7 port)

The module works like "b" indeed.

It doesn't work on an event basis at all, the design is instead to minimise database load and bulk evaporate points for *all* affected users simultaneously. So the module rather than patching in to Rules, uses hook-cron and runs its code on every cron run.

If a user hasn't logged in for 3 days, the module starts evaporating 10 points per day for that user.

That means it runs two SQL queries for each of the configured categories in order to set points for *all* users. After that, it now runs one additional query to update the grand totals. It's designed that way to be able to quite quickly evaporate points on a site with tens of thousands of users without looping through a Rule (calling a userpoints API function) tens of thousands of times each cron run.

That seems to be working, as the test users have 0 points in one category and -72 in the other :-)

I'll mark this issue as RTBC and add a patch to the nonegative issue (as well as commit to -dev).

in admin/config/people/userpoints/settings you will see this tab:
"Expiration",
there are the userpoints expiration feature.

Still thinking porting this module is not necesary.

HIH

Expiring a points transaction after a set period is not the same as expiring a fixed number of points repeatedly after a given time interval. Userpoints does the former, this module does the latter.

Sorry, you're right.
I had not understood.

Thanks for your info.

Pushed 7.x-1.0-beta1, which includes these fixes as well as the no-negative functionality.

Marking this issue as 'Fixed'.