Unmoderated column contains comments of deleted users that cannot be removed

[ideallical]

Currently the new coral talk contains a moderation column named "unmoderated"
This column contains all comments that either have status NONE or PRE-MOD.

However, some users deleted their account and now some comments are forever in unmoderated, as the comment can no longer be declined or approved.
The same applies for the review column.

Expected behavior:
Either: being able to accept or decline comments that no longer have an author
or: do not show comments that have no author in the unmoderated and review column

Actual behavior:
comments without authorId are forever in the unmoderated and review column, making it hard for the editors to review new comments if they sort by oldest first

Related Issues:

Versions:

• talk: 7.1.3
• NodeJS: ^14.18
• NPM: ^8.0.0
• MongoDB: 5.0.13
• Redis: 3.2
• Browser: Brave/Chrome/Firefox
• OS: OSX

[ideallical]

This comment can not be approved or declined, because it has not authorId.

[tessalt]

Hi there! can you let us know how the users were deleted?

[ideallical]

These are users from over 4 years ago. I recon these users were deleted using this graphQL mutation:

mutation DeleteUser {{ delUser(id: "$userId") {{ errors {{translation_key}} }} }}

https://github.com/coralproject/talk/blob/v4.8.3/graph/mutators/user.js#L101-L187

I think this delUser mutation from coral talk v4 doesn't replace the status from PRE-MOD or NONE to REJECTED, as the new coral talk version do seems to do using the new deleteUserAccount mutation:

deleteUserAccount(input: $input) {
            user {
                id
            }
            clientMutationId
        }

talk/src/core/server/services/users/delete.ts

Lines 170 to 234 in 45eb755

	async function deleteUserComments(
	mongo: MongoContext,
	redis: AugmentedRedis,
	authorID: string,
	tenantID: string,
	now: Date,
	isArchived?: boolean
	) {
	// Approve any comments that have children.
	// This allows the children to be visible after
	// the comment is deleted.
	await moderateComments(
	mongo,
	redis,
	tenantID,
	{
	tenantID,
	authorID,
	status: GQLCOMMENT_STATUS.NONE,
	childCount: { $gt: 0 },
	},
	GQLCOMMENT_STATUS.APPROVED,
	now,
	isArchived
	);
	// reject any comments that don't have children
	// This gets rid of any empty/childless deleted comments.
	await moderateComments(
	mongo,
	redis,
	tenantID,
	{
	tenantID,
	authorID,
	status: {
	$in: [
	GQLCOMMENT_STATUS.PREMOD,
	GQLCOMMENT_STATUS.SYSTEM_WITHHELD,
	GQLCOMMENT_STATUS.NONE,
	GQLCOMMENT_STATUS.APPROVED,
	],
	},
	childCount: 0,
	},
	GQLCOMMENT_STATUS.REJECTED,
	now,
	isArchived
	);
	const collection =
	isArchived && mongo.archive ? mongo.archivedComments() : mongo.comments();
	await collection.updateMany(
	{ tenantID, authorID },
	{
	$set: {
	authorID: null,
	revisions: [],
	tags: [],
	deletedAt: now,
	},
	}
	);
	}

Is there a way to easily get rid of the comments?
My first guess would be to:

1. locate all comments that have status in PRE-MOD, NONE and deletedAt not null
2. mark these comments as rejected

However:

• I can not reject these type of comment in the UI
• I can not reject these type of comments using the rejectComment mutation (as the comment no longer has a commentRevisionID, which is needed as input for the mutation

The only thing I can think of, is to manually set the status to REJECTED. However, I'm afraid this would mess up the total counts of each column. If I do that, is there a command that resets the counts?

... or I should set the status correct during the import.

[ideallical]

For now I changed the TranslateCommentStatus part in the migration script:
https://github.com/coralproject/coral-importer/blob/e49e576511b3fdb60e6dee3b80515169820615fa/strategies/legacy/models.go#L119-L125

to return status REJECTED for status PREMOD, SYSTEM_WITHHELD or NONE.
This was enough in our use-case as we only had less than 100 out of millions of comments with those status.

[ideallical]

This is still an issue. Occurs when while a user's comment is in pre-mod, he deletes his account.
This is clogging up the pre-moderation column with comments that can not be removed.

[tessalt]

we've added this to our backlog, thanks