Title
Use newer technology in posting replies

Short, concise description of the idea
When posting (or editing, or deleting) replies, the page should not have to refresh.

Full description of the idea
Newer websites allow you to add, edit or delete comments without refreshing the page.

• More streamlined commenting.

• (Can't think of any)

Title
Always allow posters to access their own friends-only community posts

Short, concise description of the idea
Allow users with community posting access to view their own members-only posts to communities they're not members of and comment on those posts.

Full description of the idea
Currently, a LiveJournal user can have posting access to a community without being a member of it (usually for a closed/moderated membership community). When posting members-only to that community (either by choice or because the community was set to members-only default posting), the user will not be able to see or edit their own post, comment on it, reply to comments, etc. This makes less sense now than it may have made in the past, since the user can now be notified of comments by email, with the original post included in comment notifications. The suggested change would give posters full access to their own posts, thus letting them edit, delete, or tag them (if allowed to tag by community settings), comment on them, reply to comments, manage comment threads, etc...

This could be done either for the current "can post, can't join" access, or through a new "can post and manage own posts, can't join" access level.

• Would give authorized posters the same access to their members-only posts that they have to their public posts (assuming public posting is allowed).
• Would remove the irritation factor of not being able to correct typos, reword for clarity, or reply to comments that you're notified of.

• Giving posters full access to their own members-only posts could prevent or hinder current uses of that feature. That could be remedied by using the new access level mentioned in the detailed description above.

Title
Do not post replies to deleted comments

Short, concise description of the idea
Replies to deleted comments end up disorganizing threads. They should not go through if the comment was deleted before the reply was submitted.

Full description of the idea
Many users regularly edit comments that have not yet been responded to by deleting and reposting. The problem comes in when someone responds to one of those deleted comments. This occurs most easily via the email based forms, but can occur directly on the website if the comment page is opened right before the comment is deleted. This should result in a "deleted comment" message similar to the "deleted post" message and the comment should not go through.

• Cleaner, easier to read and understand threads.

• There may be valid reasons for responding to a deleted comment in-thread.

• Write the code.

Title
Link back to entry after deleting comment

Short, concise description of the idea
Add a link to return to the entry on the comment deleted confirmation page.

Full description of the idea
Add a link that will return you to the entry you were reading after deleting a comment. (Or just do it automatically.) Currently, you have to manually go back to the entry page and refresh it to make sure your comment was deleted.

• Easier navigation.
• Would take much less time.

• None, that I can think of.

• Someone would just need to add the link back to the entry to the "comment deleted" confirmation page. Perhaps something like "return to the entry you were reading".

Title
Comment/Post Deletion Notification

Short, concise description of the idea
Similar to the existing new comment/post subscription, this would send a notification upon a post or comment being deleted. This should only be available to community maintainers or moderators.

Full description of the idea
A community maintainer would subscribe to "notify me when anyone deletes a post from this community" or "notify me when anyone deletes a comment from this post". They would then receive a notification when someone deleted something that they were subscribed to. (If the suggestion for maintainer subscription to all comments in their community is implemented, this could be expanded to include a subscription to all deleted comments on all posts in the community, with the ability to stop tracking deletions on any given post without affecting the auto-subscribe to post/comment deletions on new posts.) Another refinement would be to subscribe to deletions of content by or deletions made by any given member of the community.


This is superficially similar to a rejected suggestion about notification for the user upon maintainer deletion, but this would work the other way around: notifying the maintainer when a user deleted content from a community that the maintainer manages.


Since the potential for stalking using this feature would be incredible if it were available to all users in all situations, the feature would only be available to community maintainers in their communities, thus restricting the feature to a narrower and legitimate application.


The notification would contain the name and IP address (if logging is enabled) of the user who posted the item, a link to the entry the comment was in (if applicable), the subject and text of the deleted comment or entry, the timestamp of the post or comment, and the username, IP address (if enabled) of the deleter, and the time of deletion. This level of detail would enable maintainers to quickly spot which deletions were merely people correcting their own typo, which deletions were done by other maintainers, and which deletions were by the owner of the post deleting someone else's comments.

• Parallels the subscription to the creation of posts and comments.
• Increase ease of maintaining high-traffic communities.
• A number of communities have rules against deleting posts, or deleting comments from other users simply because they expressed a differing opinion. This would make it easier for maintainers to see when this is happening. (suggestions could have used this feature in the recent past.)
• Fighting trolls and flamewars. Posting and deleting comments is a classic troll tactic.
• Maintainers would potentially have a copy of a comment that was deleted against the community's rules, and they could forward that copy to the user who posted it.
• Maintainers could see the content of a deleted comment or post in case it was something that required action on their part.
• Maintainers and people subscribed to posts and comments already do get to see comments and posts that have been deleted, after they have been deleted, through the e-mail notification system, if they have subscribed.

• People might not like it.
• People might want it for comments in their own personal journals or their comments that they have made in communities or other people's journals.
• Currently, comments and posts that are deleted are deleted right then and there; there is nothing stored. Implementing this might require changing that.
• Might not be available in the notifications inbox; might be an e-mail only feature, or might require significant change to support being used in the notifications inbox. (Since deleted items are not stored and not displayed in notifications mailbox.)
• There might be copyright issues with LiveJournal storing any post or comment content post-deletion.
• Post-and-delete as a method of passing private messages would be less secure than ever (though it was rendered completely insecure with the advent of comment subscriptions).
• Misuse of this could lead to drama.
• This could be used to spam a maintainer by repeatedly posting and deleting.

• Create an event upon deletion, if there isn't already one.
• Capture the necessary information. (Store if necessary.)
• Enable subscription to this event.
• Check for maintainership in the community before allowing subscription (or offering subscription).