Repository navigation
Remember users #35
Description
Activity
New Users table - one row per user
Desired fields:
Persistent data:
- key
- user/nick
- channel (in case we ever go multi-channel)
- login count (++, stops at some max count)
Session - ie (re)set on user leave channel
- is logged in (query nickserv [see below])
- is OP/Voiced/user
- last seen
For testing user's level get channel nicks test for ~/@/%/+ etc as first char in a user's nick.
However this alone should not be the only check performed when giving a user access to protected commands. The bot should also verify the account has been logged in (aka IDENTED with NICKSERV) so that people can't join and issue commands during the grace period that NICKSERV allows for entering a password.
To test whether user is logged in:
PRIVMSG NICKSERV ACC <nick>
Possible responses (need to verify accurate for freenode network)
0 - account or user does not exist
1 - account exists but user is not logged in
2 - user is not logged in but recognized (see ACCESS)
3 - user is logged in
The acc command works on freenode. I tested it before.
The one thing I don't get is why the bot would check for OP (and the whole access to protected commands thing). Doesn't the channel do that automatically for you?
I decided to work on this problem tonight, but I was wondering what you meant by key. Do mean an id for each user?
Yeah, the primary key for the table's rows.
The suggested format is _id serial primary key
Take note of users that join and perhaps the count of times they've joined (up to a certain max).
Can use to cap the number of times Users are greeted with "Are you new?" and perhaps customise the given greeting based on their 'experience' with Progether.
Can stop counting at a set max (like 10 or so).
Could be used by the Mail service too to only allow sending mail to Users that have previously joined the channel, rejecting failed attempts with an error and maybe the results of a fuzzy search for similar usernames.
Best implemented by using the database.