[development] User last access

[Earnie Boyd]

Quoting Neil Drumm <drumm at delocalizedham.com>:

> On Fri, May 2, 2008 at 1:41 PM, Earnie Boyd
> <earnie at users.sourceforge.net> wrote:
>>
>>  You mean
>>  <?php
>>    // Consider users edited by an administrator as logged in, if they
>> haven't
>>    // already, so anonymous users can view the profile (if allowed).
>>    if (empty($array['access']) && empty($account->access) &&
>> user_access('administer users')) {
>>      $array['access'] = time();
>>    }
>>  ?>
>>
>>  I don't understand the logic of the comment.  The same logic exists for the
>> create.  I'll do some more research.  My awe with the comment is; why do I
>> want to destroy the statistical data when I do an administrative update just
>> so someone I don't know can view the profile if they even have permission to
>> do so?  And the same doesn't happen if the user registers himself.  My
>> inclination is to just remove this since I consider it silly but I'll do
>> some more research.
>
> Users who register themselves and never log in should not have public
> user pages created since they are empty, useless, and possibly
> contains spam. Admins can view those user pages.
>
> This would be confusing for admins creating users. When admins do
> things, stuff should happen, those users need to show up.
>

This isn't nearly as confusing as the access time being updated because 
I create or edit a user.  Precious data is lost and using a column that 
was meant to mean last access for is active isn't a good thing.

> The way we store this is by overriding the access time. Users creating
> their account get a time of 0, which means the account registration is
> not finished and the user page does not go live. Admins creating
> accounts get a timestamp.
>

Well, not before the patch.  The admin creating and editing left the 
access NULL or 0 before the patch sometime last November.

> A couple options:
> * Make admin-created users get a access time bump, but not admin-edited
> * Remove the column overriding and make an is_active column or
> somesuch. Bonus points for merging with the status column.
>

Why isn't the user module looking at the status column for its data 
that created the patch at node/171117 that we're discussing?  The wrong 
fix was applied to a problem that caused issues with statistical data 
and upset a number of people.  Why does the fact that the user has 
accessed the system matter to the functioning of anonymous users being 
able to "access user profiles"?  Destroying the statistical data was a 
workaround and as a workaround should never have been a patch.  We need 
to revert this behavior in D5 and D6 and then find a real solution to 
apply that doesn't destroy data used for statistics.  I might be happy 
with only removing the on edit part of the patch but it still isn't 
giving correct data if I create a user and the access is given as the 
time of creation because the user hasn't accessed the system.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/