On Mon, 5 May 2008 16:46:14 -0500 Larry Garfield <larry@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