[development] User Status

[Ivan Sergio Borgonovo]

On Mon, 5 May 2008 16:46:14 -0500
Larry Garfield <larry at garfieldtech.com> wrote:

> The more important question is what metadata fields do we want on
> the user object/user table?  Off the cuff I can think of:
> 
> - created time
> - last access time (0 means never logged in)

What about null? If D7 is going to support prepared statement through
PDO we could make good use of nulls.

If the hooks are going to stay the same they should suggest what to
log:
* view (I don't think is useful to log view time of a user profile,
maybe the number of times a profile has been seen, but that would
imply some "anti-spam" mechanism)
* insert
* login
* logout (interesting) even if it's interpretation and uses may be
tricky, it could still find a better place in a module that actually
know what to do with this data unless there is no more uid once the
execution reaches the logout hook.
* update

BTW it would be nice if sid could be accessed for anonymous users too
so to have a uniform access to sid for anonymous and registered users.
I patched my D5 to have ->sid for anonymous users... I could give a
look to D6 see if the patch can be applied and submit it for review.

> - last edit time (by anyone)
> - is_blocked (boolean, sadly this is the inverse of the current
> status column)
> - What else?

The countdown is nice... but what about another date? that will be
safer/easier to manage if you skip some cron run.
Anyway I see this feature more suited to contrib since it may have a
lot of variations.
eg. the is_blocked itself could be a date. If null it is not blocked,
if a date in the future it is blocked, if a date in the past,
unblocked... and it could also serve as a short term log.

But still I see so many way that users could be blocked/unblocked
that I'd leave it to contrib/other table.
eg. I may decide to block users after a certain period they have been
registered in spite of un-blocking them after a certain period, block
them if they don't log in in a certain period, if they don't add
content etc...

While the info about when they logged in, edited their profile etc...
fits in the users table other things may be more suited to external
tables/modules.

If there will be some refactoring in the users management/creation
etc... it should become easier to hook other tables to the main users
table.

OT: I'd like the creation/editing of users to become atomic, so that
if you use the insert/update hooks you don't risk to end up in half
created users. Deletion can be easily achieved if you can use
references and rules.

-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it