problem with "last access"?

This was intentionally added (well, I proposed that along with others) because there's an anti-spam measure, so that user profiles with access 'never' (i.e. not logged-in yet) are not visible. But there are scenarios, where administrators want to make such profiles active, for example when they create dummy profiles for persons not really going to log in technically - for example to show some VIP's in-line with really active members, or to simply submit nodes for them (contents received by site-maintainer via e-mail for example, intended to be later editable by the real author). If the person in question already registered, this needs to be done through editing an existing account, due to the duplicite e-mail check on newly added accounts.

Previously, these scenarios led to user profiles full of useful information and/or owning nodes, but showing ugly 404 page if clicked, and administrators had no chance to change that (unless taking over the account by forcing password change and logging in to these accounts themselves once, in fact denying access to the real owner due to the password change). The viewing restriction (i.e. a 404 for profiles with access 'never') may not be removed, as it's our safeguard against registration spam.

IMO, technically, admin's manual edit/creation of the account IS a sort of activity (although with 'forced' access to the account), so it's not so totally wrong. Note that this only occurs on first access ever (for orphan accounts, more or less); if the user already logged in and so started to use the account, admin interference no more counts.

See the original issue: http://drupal.org/node/171117

I understand that you've tried to fix a problem, but you've created a new one!

Being able to easily tell whether an invited user has actually logged in or not is a basic necessity, and you've killed the "Who's new" block. I'm surprised that you threw that out so easily...

In your own words: "Basically what this patch does, is that Drupal consider an admin-manually-edited/added account as already logged in once, so EVERYONE with the permission can access it."

Considering A as B when it's not B is a quirky hack that may work for your special situation, but this must not be default behavior. If you really need this quirky behavior then make it an option (turned off by default).

I've come across this problem in D55 and need it fixed there, but apparently you've managed to introduce it into D6, too, so I'm marking the issue for D6.

Salvis, if you need to know if users are logging in or not, you can use the triggers module to send notifications. The "Who's new" block is still there by the way.

No, this is basic functionality, a contrib module and a manual list won't do. A core listing has to show things how they are, and "Who's new" has to show who has actually arrived at the site, not who has been invited.

Without the patch, I was unable to delete inactive users - it'll remove also dummy profiles created by other admins, and owning nodes. That's why I never cleaned my site of bogus registrations, which is sad, too. We need a good solution for both cases, probably introducing some new "invited" status. Unfortunately that's a feature, and so impossible until 7.x

francoud - "inactive user" module works quite well setting a time limit on users who haven't logged in for a long time.

There could maybe be something in the admin/user/add form which says "mark this user as active" with a checkbox (checked by default). If it's unchecked, then the user never logged in as before. This wouldn't be a huge change I guess.

@catch: Yes, this is a good idea, but the checkbox needs to be OFF by default, because turning it on results in illegitimate behavior.

Actually, it should be accompanied by a warning, something like "Do not turn this on, unless the user has agreed to join the site."

Closing this thread, and encouraging all discussion to continue in http://drupal.org/node/171117. That thread predates this one, and that thread also has a patch that's been committed, yet some feel it shouldn't have been. Discuss amongst yourselves, but do it on node/171117.

I am going to go out on a limb here and reactivate this issue for D6 purposes only ( I know the duplicate issue ticket is mostly about D7 since this is seen as a feature addition ). What I am going to suggest is a simple trick that is a workaround to the issue and at the same time is not a feature add ...

Keep all of the functionality of this issue AS IS in D6, i.e.: if an admin is the one who edits the account and activates it change the last access date except instead of setting the last access date to now, set it to a date of 01/01/2000. This will allow the user list to be sorted by last access and easily identify those users that are admin activated yet never accessed for real.

Also add a small line of code to Who's New that says in effect "if last access = 01/01/2000 then do not list".

No new functionality has been added, yet it now becomes easy to spot and hide/manipulate the never-been-used accounts. An example of that would be the Inactive User contrib module which could be updated to ignore all users dated 01/01/2000 and still be effective in removing idled accounts of real users.

The chances for getting anything committed in this area are NULL.

The Fix Core module fixes this (and a few other bugs) in D6.

I agree, but see #13.