Handling Comment Deletion

benloh commented 3 months ago

How should we handle comment deletion?

I think there are two basic approaches: A. Delete the comment and relink everything else B. Mark the comment "DELETED" but leave it in place to account for any missing references

The approach we take probably depends on where in the comment threads the deletion is happening.

1 root comment with thread

If the root comment is deleted, and the root comment has threaded replies, use approach B. mark it "DELETED". This way the thread remains visible.

1.1 reply to root

If a reply to a root is deleted, and the reply is part of a longer thread, use approach B. mark it "DELETED". This way the thread remains visible. (Alternatively, we can remove the reply root, but if there are replies to that root, the conversation may be confusing because there may be references to a now-not-visible reply.

1.2 last reply to root

If a comment is the last reply to a thread, use approach A. go ahead and delete the comment. (2.3 can also be deleted in the same way).

3 third root comment with no thread

If a comment is a root comment with no child threads attached to it, use approach A. go ahead and delete the comment. It should be OK to delete the comment since any other comments are not explicitly replying anything, and we don't need to worry about child threads that need to be relinked. e.g. we can remove comment 3, and comment 4 would be moved "up" to follow the end of the comment 2 thread. (4 is also treated like this).

Any thoughts? Other approaches? We could always just use approach B, marking comments deleted instead of actually removing them.

jdanish commented 3 months ago

Awesome. After discussing with @kalanicraig our pitch is:

If the comment is at end of chain just remove
If higher, use your b (mark deleted) with the following caveats: 1) if you go back and delete all the replies it then the deleted root goes away, and 2) if you have admin access you can delete the whole chain (ideally via a pop up dialogue that gives the choice to flag or delete all)
We likely will want to be able to export the comments table like the nodes and edges

Note that we imagine a few use cases including kids make mistake and want to delete, but also teachers or kids want to delete a chain that has been handled. In word / google terms this would be resolving v deleting but we assume deleting is more manageable for now than having both

benloh commented 3 months ago

Thanks for the feedback.

One other thought: Do you want a "Are you sure you want to delete this comment 'blah blah'" confirmation dialog to prevent accidental deletion? Or is that not necessary?

"Resolving" might be a little complicated because unlike Word/Google, we only have the ability to add a single comment to any anchor point, so if you add a comment and resolve it, what are you resolving? (in contrast with GDoc, where you can easily add another comment by targeting another word). So when you "resolve" a comment, are you resolving a root, or are you resolving the whole chain, including any other roots? And do they just all disappear like they do in GDocs? Or do you still want them visible in some way? And how do we convey that the thread grouping is what is getting resolved?

It's an interesting expansion of features, but I think we'd want to think through that design. It's potentially a signficant change to the data structure, and better to do that now than later.

jdanish commented 3 months ago

Yes, let's have a confirmation dialogue. Thanks!

And I think we will not need / want the "resolve." It makes sense in a test doc with hundreds of iterations but if we get 2-3 we count ourselves lucky. I'd rather put the design time into the other template features like checkboxes in comments and star ratings.

Joshua

benloh commented 3 months ago

@jdanish One more edge case/refinement I imagine if you're an admin, you are allowed to edit or delete ANY comment, whether it's a root with replies or a reply? (Currently the "Edit/Delete" menu is only shown if you're the author of the comment, so even as an admin, you cannot edit or delete a comment).

This actually gets a little tricky...

if an admin deletes a root that has replies (e.g. #1), any replies will also be deleted (#1.1, #1.2) -- this prunes the whole thread regardless of the fact that there might be valid replies in the thread.
if an admin wants to simply mark a comment root with replies as "[DELETED]" instead of actually pruning the whole thread (e.g. deleting #1), they actually need to exit admin mode and then delete the root.
if an admin deletes a reply that has replies (e.g. #2.1), the reply will be marked "[DELETED]", and any replies will NOT be deleted (#2.2 and #2.3 remain) -- so this is not quite the same as deleting a root comment, where any reply after the deleted reply will also be pruned.

Another way to handle this might be to add a prune menu item that is only selectable by admins. That way you can distinguish between deleting/marking individual comments vs removing everything after the comment.

jdanish commented 3 months ago

Random note - for some reason I see the question as from Ben on here, but Sri in my email. What's with that?

Yes, the admin should be able to delete things they are not authors of.
However, a) I am OK with them following the same rules we discussed (deleting top only works if they have removed the sub-nodes, or if they click the special "delete all" button / confirmation (Prune, but maybe a different term).
Ideally, this would all be specified in the settings for the current network, so if Kalani has a research team using a network, they can agree to allow deletion of each other's comments, whereas if it is a classroom we likely only want teachers or admins to have that right. Also, in the config we might determine that all users get access to Prune, etc.

benloh commented 3 months ago

Ideally, this would all be specified in the settings for the current network, so if Kalani has a research team using a network, they can agree to allow deletion of each other's comments, whereas if it is a classroom we likely only want teachers or admins to have that right. Also, in the config we might determine that all users get access to Prune, etc.

I wonder if we should just leave this as-is for now, and worry about the other cases once we get the full user authentication and permission set up. Otherwise things can get really hairy.

Random note - for some reason I see the question as from Ben on here, but Sri in my email. What's with that?

Dunno. That's a weird one. I've seen replies get hijacked, but not this.

jdanish commented 3 months ago

Yeah, waiting after this works for me.

Figured out the mail thing - Apple had assigned GitHub to Sri. Weird.

benloh commented 3 months ago

Addressed with #133

netcreateorg / netcreate-itest