EdB wrote:

... and what happens when expiration is both about to happen and actually happens.

1. Email notification: "Login within 5 days to confirm that you are still alive"
2. Email notification: "You were kicked off the system. All your posts and comments now belong to user X. Your account has been deleted. Thank you :)"

I don't see any benefits from doing that, do you?

How about moving the user to a different group (with less or no posting permissions) instead of deleting their account?

Yes, I see benefit else I wouldn't have mentioned it ;)

EdB wrote:

How about moving the user to a different group (with less or no posting permissions) instead of deleting their account?

And then charge them something in order to restore the rights... This might be useful, I think.

Exactly!

My thought on it is for hobby club membership tracking. The peeps don't actually post anything - I use the database to keep track of details normally associated with hobby club stuff. Name, address, email, phone, emergency contact, ... and club-specific info of course. Notification prior to bumping to a 'former member' group, then bumping (expiration) would also trigger another email to the system admin and maybe a few others so that other details can be taken care of as need be. In my case it would be restriction from private forums in a phpbb2 installation.

Another thought is that the trigger need not be time. 0 for days being "infinity" is only one bit. One might also say, in a multiblogger situation, that if you don't post for 30 days you get notified then bumped.

One could easily envision this as a method to keep registered commenters coming back to comment more often if registration expiration reset was based on posting a comment. In this case the 'warning' email would be "hey where did you go hope you're all right" and actual expiration wouldn't change anything.

So one must consider what factors cause the expiration clock to reset. The admin saying "they paid" is one, posting a post is another, posting a comment would be a third. I'm sure there are more. Then the 'warning' email must have a time window associated prior to actual expiration, then expiration needs an action and at least one email. Maybe one to the expiree and another to the system admin (or group of email addys), with the second being more important in my mind.

hmmm... "0 is infinity" is silly. Either use or don't use the feature. Not using it is infinity eh? So a checkbox instead of a text field defaulting to 0 makes more sense.

Checkbox to use or not

Text field for expiration in days

Text field for warning notice in days (prior to expiration date), where 0 is no warning notice.

Another text field for what the email says - obviously.
- Sent to the expiree by design.
- Sent optionally (checkbox) to an identified user ID (text field), or to the system's ID #1? ID#1 requires no other fields so that's nice.

A complicated bunch of crap for actual expiration :(
- Downgrade to a different group? Probably the best in terms of overall installation management.
- Deleting the profile? Rather aggressive move and will surely piss of the person if they ever intended on returning.
- Email to the expiree? If so what it says needs another field.
- Notification email to user #1?
- Notification email to a list of users, or a list of email addys?

Be quite the groove eh? Mostly it would be nice for paid registrations assuming there are any. But like I said for me it is about maintaining hobby club membership info in a reasonably easy format. Our Treasury guy uses something on his PC, which exports in the most crapped up .csv format you could imagine. I think if I could give something groovy online to use that'd be an improvement eh? Truth be told I've looked and looked and looked and don't see anything free open source out there for club membership records. Awwww. Sad Face :(

Isn't it easier to create a plugin for it?

? Might be. Dunno if there is hookage enough to handle it by default though.

?? Can you point to an example of a plugin that reads and alters 'by design' tables? That would be required eh? Like, changing the group if nothing else. OH DUH! Widget Manager does that :roll:

??? I guess the only real question then would be how to trigger it. Is there a hook associated with the bit that clears out the older hits when a new day happens? Last time I stumbled into that area I don't recall seeing hooks one could take advantage of. Obviously the plugin would need something reliable and repeatable to trigger it to check if anyone is about to get expired.

Hey it would be a fun plugin! I haven't done anything with plugins in way too long. Might have to fake up a hook or two, or come up with some really creative method to figure out how to tell it to purge the undesirables. Or just use a hook :) If there is one :)

Ideally there should be a cron job configured to run every day and check for expired users. But I guess cron jobs are configured on less than 10% of b2evo blogs.

So you will have to use the following events and do some BASIC checks every time somebody accesses the blog. This will definitely decrease the performance.

function AfterLoginAnonymousUser()
{
    return $this->AfterLoginRegisteredUser();
}

function AfterLoginRegisteredUser()
{
    // Basic check. Ideally one tiny query :)
}

You don't really need any other events unless you want to add a cron job option for those who uses it.

User Blog plugin has a good user notification example

Yeah I'll check on the userblog plugin for some helpful hints.

There is a hook called AppendHitLog but that'll fire every hit so even a tiny "check it" function would be a big resource hit. I think. AfterLoginRegisteredUser will be way less frequent than AppendHitLog.

The quick check is fairly easy: just copy the bit that pruning the hitlog does: if the day is different than the last time you did your thing then do your thing. Once that decides "oh wow it's tomorrow already" then go ahead and weed out the weaklings.

This will indeed be fun. A lot more fun than working through the installer to undo the bits I don't like :D

EdB wrote:

This will indeed be fun. A lot more fun than working through the installer to undo the bits I don't like :D

Yeah, and you will probably finish the plugin much faster ;)

This would be great for a software/online course purchase type thing. When you have the requirement that after someone has paid they get put into a group that has access to the product but only for a period of time - like a week to download the software or for the duration of the course.

Very cool :D

EdB, This is ideally what I wanted. I don't know if you responded to some of my posts, but I've been thinking and looking into ways to make this happen. I'm running b2evo 3.3.2 and have over 9,000 users. Kinda would be nice to have something so useful for dealing with those users. Also would be nice to have an option to configure how these users get deleted, or bumped from the system. Once again you have captured my thought and brought it to light in a more elegant way that I could have expressed.

Interesting ideas. Feel free to add to CVS.

If you make a plugin, feel free to add missing hooks to CVS.