I noticed that old posts from users that are no longer active in the forum / deleted, are assigned to user 1.

I suppose that currently orphaned posts are listed as created by the admin for lack of a better candidate. This however can create confusion about who wrote these posts. The same appears to be happening for private messages: some people that had exchanges with former users will now see conversations with the admin... Worse even, the admin sees messages for all kinds of different threads he wasn't involved in.

Perhaps some kind of logic would be useful here to allow the original user ID to be used as the author:

  • Create a blocked user with the author ID that cannot be matched to an existing user
  • To distinguish from active users, migrate the users as active, not blocked (don't know if the migrate module allows this).

Comments

JeremyFrench’s picture

Status: Active » Postponed (maintainer needs more info)

You should have inactive users on your system already? However deleted users is a different case.

I am thinking that we could create a 'deleted user' account and set all of these cases to that account. Would this solve your problem?

marktheshark’s picture

Status: Postponed (maintainer needs more info) » Active

The forum in question is 10 years old, so yes, there are topics, posts and private messages in there from users that no longer exist.

A 'deleted user' account would partially address the problem I guess. Unfortunately it would show all orphaned content as belonging to the same old user.

Is is possible to use the original author ID, import the data, then set the user to blocked or delete them while preserving their content (I suppose this also has to do with the Drupal user account settings.

JeremyFrench’s picture

Status: Active » Postponed

Migrate tries to map ids in the source table in this case phpbb_users with drupal user ids. In these cases there will be no source record to map from.

It is an interesting problem. However I am not sure if I can fix at the moment.

marktheshark’s picture

So this is appears to be a restriction in migrate itself?

Is the logic of assigning orphaned entries to User 1 also in there, or can you catch an exception for a nonexistent user and try to create a mock one?

marktheshark’s picture

Status: Postponed » Active

I have opened a similar issue for support in the migrate module issue queue.

Perhaps the current module can be adapted to do one of these things (possibly configurable):

For both posts/topics and private messages of old users:

  • Either provide a mock user ID
  • Create mock user(s), then block them, keeping their data
  • Or assign to the Anonymous user

I guess the Anonymous user is the simplest way to go, but the id of who posted is lost forever, even if the user doesn't exist anymore.

Let me know what you think, thanks!

marktheshark’s picture

@Jeremy: By the way, I am a developer (albeit Java, but can handle PHP), so with a little bit of guidance I would probably be able to try this on my local installation.

Thank you in advance

marktheshark’s picture

Since I've update my local test installation, to 7.x-3.x-dev, updating issue accordingly.

marktheshark’s picture

Version: 7.x-2.x-dev » 7.x-3.x-dev
marktheshark’s picture

Quick SQL workaround for assigning all orphaned topics and comments to the Anonymous user instead of User 1:

UPDATE `yourtableprefix_node` SET uid = '0' WHERE TYPE = 'forum' AND uid = '1';
UPDATE `yourtableprefix_comment` SET uid = '0' WHERE uid = '1';

... where yourtableprefix is the configured Drupal table prefix, if any.

JeremyFrench’s picture

Status: Active » Fixed

I have just committed a fix for this where disabled stub users are created in cases where the user dosn't exsist. Should be in a 7.x-3 build tomorrow.

marktheshark’s picture

Thanks! Do the stub users inherit their old user names?

JeremyFrench’s picture

No, as far as I could see the old user names are not in the DB so there is no source to generate them. If you know of somewhere that they could be accessed let me know and we can do something about it.

marktheshark’s picture

From what I see in the source phpBB installation, the usernames exist, so they must be in the DB somewhere. I'll check.

Will this address also the privatemsg migration issue?

JeremyFrench’s picture

Will this address also the privatemsg migration issue?

I thought it would, but there still seems to be something up with that. It has improved it.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Additional info