IP.Board makes my community feel unstable.

[Makoto]

I'm going to use IP.Blog as an example here, but the situation applies globally.

So, you can apparently prevent users from deleting a blog, but why?

They can still go through and delete every entry in that blog without any restrictions. When they do this, there's absolutely no way to recover it either, unless you've made a database backup recently.

The only thing it does is making it a little less difficult to accidentally screw up, or more difficult to cause destruction, especially in multi-administered blogs.

This is truly one of the things that bother me so strongly about IP.Board. There are so many ways your community members can cause destruction and there's almost nothing you can do to prevent it.

The only thing with a real safety net are posts. Posts that are deleted can be kept and recovered by a moderator if needed.

Gallery images? Nope.

Gallery albums? Nope.

Blogs? Nope.

Blog entries? Nope.

Files? Nope.

Attachments? Nope.

Recover posts destroyed by edits? Nope, though you can set a time restriction for posts, and there is a hook for storing edit history.

The only sane thing to do is not trust your community. Don't grant them deletion privileges anywhere. But what about for systems such as IP.Blog? What if someone's account is stolen and the thief decides to wreck havoc by deleting everything they've ever posted on your community? You can assign multiple editors in IP.Blog, right? Can these editors also delete entries? Even if not, they could simply go through and edit all the posts into insults if they get mad at their fellow blogger.

Now, for the gallery? If someone deletes all their uploaded images, or deletes an entire gallery, can you recover it later? If it was an accident, can you simply recover it? Or what if their account was compromised as exemplified above? Well, it's sad, but there's really almost nothing you can do here. A database backup will likely be useless. Why? Because these are images. Your images are likely not stored in the database. If you go without noticing and they get cleared out, what then? You're screwed.

I posted about a chaotic experience with post attachments not too long ago.

Am I a little overly paranoid and possible untrusting of my community? Maybe. But so what?

When you run a site that is heavily operated around user contributed content, you should want to have fail-safes in place. Not just for your members, but in case you one day have a staff member/moderator with a bloodlust for revenge on you. Wouldn't it be nice to be able to truly undo all the destructive actions a moderator made through your ACP?

There's a good reason I've administrated my IP.Board community alone the last two+ years.

Why can't we have a section for deleted gallery images in the removed content section? How about blogs and blog posts, instead of just topics and posts? These can be automatically pruned after a set time period, just like with posts and topics, of course. Why can't we prevent members from going through and nuking their post attachments as well?

What's even the point of giving your members the ability to delete attachments on communities where everything is centered around content? "Break one of your older threads and confuse everyone else who tries to access it so you can post something new."

Now, giving members the ability to delete attachments that aren't in use anywhere? Sure, assuming the admin doesn't do this himself routinely via the ACP, it could be useful. No complaints about that. But attachments that are in use all over the site in various threads? I've learned the hard way how chaotic it can be when you give a member that kind of power.

To sum this thread up simply, we need more control over our community. We need more safety nets, more ways to ensure the stability of our community. Not just in IP.Board, but in all IP applications.

[esquire]

I prefer the inability to edit after a certain period of time and not allowing users to modify or delete. It just has to be that way or I end up with clever spammers who invest time creating profiles just to change things surreptitiously later. When you start to have a site that ranks, it creates those problems. I'd prefer it if a time limit was set for every module and then only moderator intervention would allow for modification.

[Makoto]

I prefer the inability to edit after a certain period of time and not allowing users to modify or delete. It just has to be that way or I end up with clever spammers who invest time creating profiles just to change things surreptitiously later. When you start to have a site that ranks, it creates those problems. I'd prefer it if a time limit was set for every module and then only moderator intervention would allow for modification.

I support this, but I think we should be able restore deleted blogs/blog entires, gallery images, and so on in the same fashion that you can restore deleted topics and posts.

[Saiga]

Reading the OP really makes me wonder why IPS hasn't aggregated everything that gets deleted into a huge removed content area, regardless of what kind of content it is. It could prevent disasters from happening. If they content really needs to be deleted, it can, but if it needs to get restored it can.

[Wolfie]

This is truly one of the things that bother me so strongly about IP.Board. There are so many ways your community members can cause destruction and there's almost nothing you can do to prevent it.

I'm going to respond to this first then for your overall concerns.

If you have a community where the members are likely to 'cause destruction', then are they really the kind of members you want to have? If it's that bad then put on some rather heavy restrictions so that they are like inmates at a prison, where they are very limited in what they can do. I can assure you though, that if you do that to all members, including those that you know are mature enough to not act out like that, then you will lose many valuable members. Look at how popular this community is and there are blogs and posts and other content that are at risk of being vandalized but there are few restrictions and what restrictions are there appear to be rather lenient. So being completely serious, if it's that much of a problem or a concern, then there's a problem that stronger moderation control won't fix. Just food for thought.


On to your overall concerns. Yeah there are times when a rogue person may come along and attempt to cause some sort of destruction to your community. Sometimes it's a person that is holding a grudge of some sort, either against you or could be someone else and they think you're the same person. Sometimes it's a kid thinking that it's fun and doesn't realize the true trouble they're causing. There are some who get their jollies from doing that sort of thing (trolls) but that in person would NEVER do anything bad because in person, they could get their butt kicked, so they do horrid stuff online because they feel they can get away with it. It reminds me of a saying someone said to me one time, they misquoted a popular saying but still holds the main point. "Absolute power corrupts absolutely." There are other quotes and philosophies that come to mind too. It boils down to the fact that some people taste the 'power' of anonymity and abuse it. It's their true nature coming out and they would feel pure shame if people they knew/respect in person were to learn of it.

Anyways, the keeping of an edit history has been requested many times. I think the main concern comes down to space used for keeping the edits as well as performance and maintenance (purging old 'edits'). Imagine if someone created a guide of some sort and it's 10k in size and during the course of a week of doing tweaks to the guide, they perform 10 or more edits. That's 100k (or more) just for that post. If prior versions of the post are discarded automatically to limit the space usage, someone might figure it out or learn about it, make an offensive post and then edit it a few times a couple of minutes later and you'd never know it because they've already managed to get the original 'bumped' off. If it's purged after a period of time, you might find a need for it past that period of time. ie, always going to find problems with either the settings you're using or the number of copies kept, etc. Also, what about the admins responsibility of keeping backups to restore such vandalism and using the right settings to ensure that it either doesn't happen or if it does that it's minimal damage? It does reach a point where the software can't be expected to do all the work for you. Many things to keep in mind.

Don't get me wrong, I'm all for the ability to review what edits have been made and even having some sort of a way to 'undo' stuff done by members, where they may have done something by mistake (or deliberately). Just there are other things to consider.

[Rimi]

Reading the OP really makes me wonder why IPS hasn't aggregated everything that gets deleted into a huge removed content area, regardless of what kind of content it is. It could prevent disasters from happening. If they content really needs to be deleted, it can, but if it needs to get restored it can.

Basically soft delete support should be added across the suite. Someone should try to get Brandon to stick this into Gallery 5 before it gets released.

[Maxxius]

I definitely support this!

Keeping of an edit history of stuff would be amazing.

Sure some settings have to be made so old edits could be pruned, etc.

This is something that IPS should look into in the future.

[bfarber]

Basically soft delete support should be added across the suite. Someone should try to get Brandon to stick this into Gallery 5 before it gets released.

"Hide" is effectively the replacement for soft delete, and it is supported in Gallery 5.

[Makoto]

I'm going to respond to this first then for your overall concerns...

I'm not meaning saying I don't trust my community as a whole.

There is a reason I listed accounts being phished as a possible occurance. I've had members get mad at someone else in the community and react badly in this way before. They contacted me wanting me to restore their content.

Could I? No.

I'd like to give my members more control over what they post, but I don't like knowing that giving them this power warrants them to do irrevocable damage that can't be recovered, whether it was intentional or unintentional. Someone could have spent a year working on a blog, meant to delete a newer one that they wished to abandon at 4AM in the morning and accidentally realize that they had deleted the wrong blog, regardless of the bright red warning.

They loose a years work and there's nothing you can do about it. There's no safety net, and you can't say occurrences like this aren't to happen. Have you ever deleted the wrong file by accident before?

"Hide" being supported in Gallery 5 is good, but what about blogs, blog entries and attachments?

Lastly, this is IP.Boards support site. Most of the blogs are for selling items in the marketplace and testing. There's nothing to abuse here.

[Rheddy]

I haven't worked with IP.Blog or any of the addons in that I only use IP.Board and IP.Content but coonsidering that everything is ran through your forum's database, I'm pretty sure that you can restrict anyone from deleting anything unless you give them that permission. I believe this would be set up through the "usergroup" permissions and not through your application settings.

Personally, I give my members the ability to only manage their own content. I don;t allow them to edit or manage anyone else's content.

[Rimi]

On the topic of edit history...IP.content supports revision history doesn't it? I think edit history support with periodic pruning isn't unreasonable.

"Hide" is effectively the replacement for soft delete, and it is supported in Gallery 5.

Ah yes. I keep forgetting about those moderation changes...good news there.

[Makoto]

As far as I can see, you can't prevent members from deleting entire blogs. Only blog entries. I'm not sure why that is, but regardless, as I've said many times, I'd like to give my members the ability to remove or "hide" their own content, but I'd like to be able to recover it later if it was done by accident.

You shouldn't treat the ability to irrevocably delete a blog or album that's been worked on for a entire year like a joke of an issue. I can accept "hide" as a compromise for this, it may even be better since it lets users state why they wished to have the content deleted.

But this still leaves us with IP.Blog, IP.Downloads and attachments.

Blog entries can be deleted by any editor, permanently, irreversibly, and a user can go through and delete every attachment he's ever made to a years worth of posts.

This is generally one of the "bad apples" wolfie mentioned, but I honestly don't see the logic behind deleting attachments to begin with. If an attachment is in use somewhere, deleting it will break the post that's using it. Why would you want that?

[Rimi]

I'm sure they will add it to blog now, since they seem to be developing that and, frankly, there's no reason not to.

As for attachments, I still like Marcher's solution better.



Everything there still applies for me.

[esquire]

I support this, but I think we should be able restore deleted blogs/blog entires, gallery images, and so on in the same fashion that you can restore deleted topics and posts.

I love the idea but I get queasy just thinking about the overhead involved in a "trash" system.

[Makoto]

I love the idea but I get queasy just thinking about the overhead involved in a "trash" system.

It can be optional, of course. The intervals that trash is cleaned out in is customizable. You can have it clean out trash during your lowest traffic hour and the overhead would be negligible.

[Rimi]

I love the idea but I get queasy just thinking about the overhead involved in a "trash" system.

There is already a moderator task that deletes items in the "trash" which should address your concerns.

[Wolfie]

I'd like to give my members more control over what they post, but I don't like knowing that giving them this power warrants them to do irrevocable damage that can't be recovered, whether it was intentional or unintentional. Someone could have spent a year working on a blog, meant to delete a newer one that they wished to abandon at 4AM in the morning and accidentally realize that they had deleted the wrong blog, regardless of the bright red warning.

They loose a years work and there's nothing you can do about it. There's no safety net, and you can't say occurrences like this aren't to happen. Have you ever deleted the wrong file by accident before?

That example is where I'd say it should fall into the admin's lap because that content could be recovered from a database backup. It may not be the latest revision, but it would be fairly recent. How often a community should be backed up depends on how busy it is, but I'd say at minimum, once a week. So let's say you do weekly backups and they deleted it a day before the next backup. They're out one weeks worth of revisions, but it's recoverable. If you're not performing backups, then I'm gonna tell you right now, if your site ever encounters an issue (server crashes, community gets severely hacked, etc), your community will be gone and you'll have to start fresh.

Not speaking out against features to make it easier to undo damage, just saying that there are some things that do fall into an admins lap. One of those being to be prepared for accidents/emergencies/etc that the software either isn't prepared for (yet) or wasn't meant to protect against.

This is generally one of the "bad apples" wolfie mentioned, but I honestly don't see the logic behind deleting attachments to begin with. If an attachment is in use somewhere, deleting it will break the post that's using it. Why would you want that?

For that, I'd say, ask for an option to restrict how much time must pass before someone can delete an attachment that is in use. That way, only older posts (for example) might wind up with dead end attachments. Another option would be to have it go into 'limbo' where it's no longer held against their upload limit, but will instead be listed in the ACP for you to decide if you want to fully delete it or keep it. Could use both options. Yet another would be to set a time limit, where deletions before that time would require approval (and the member would be informed of it). Just have to decide the best method to ask for and then make the request for that idea.

[Makoto]

That example is where I'd say it should fall into the admin's lap because that content could be recovered from a database backup. It may not be the latest revision, but it would be fairly recent. How often a community should be backed up depends on how busy it is, but I'd say at minimum, once a week. So let's say you do weekly backups and they deleted it a day before the next backup. They're out one weeks worth of revisions, but it's recoverable. If you're not performing backups, then I'm gonna tell you right now, if your site ever encounters an issue (server crashes, community gets severely hacked, etc), your community will be gone and you'll have to start fresh.

Not speaking out against features to make it easier to undo damage, just saying that there are some things that do fall into an admins lap. One of those being to be prepared for accidents/emergencies/etc that the software either isn't prepared for (yet) or wasn't meant to protect against.

In a sense, I do agree with you. And I've had to do that once recently, but not due to an issue with a member of my community, due to a technical fault I want to blame on me frequently archiving and unarchiving posts. Mysteriously, all posts past the 13th post "vanished" in an old thread of mine with hundreds of posts. No logs of who deleted it or what happened, but I had to pull up an old database backup to restore the posts.

I had planned on setting up a script to make automatic database backups every week or so.

But I still think including blogs and blog entries in the "removed content" section is a much more viable option. Especially when you're granting members the ability to have multiple editors on a blog. People are jerks, plain and simple. Someone could go through and delete all entries in a blog they're working with others to maintain. It would be sad to have to tell the original author of that blog that they're "SOL" because you don't have a recent backup for them to use.

And this I think should be quite simple to integrate. It'd add two extra tabs to the Mod CP's removed content page. They can be displayed in a similar fashion to posts and topics and can be restored just as easily.

You do have some good ideas for the attachments issue.

[Wolfie]

In a sense, I do agree with you. And I've had to do that once recently, but not due to an issue with a member of my community, due to a technical fault I want to blame on me frequently archiving and unarchiving posts. Mysteriously, all posts past the 13th post "vanished" in an old thread of mine with hundreds of posts. No logs of who deleted it or what happened, but I had to pull up an old database backup to restore the posts.

I hope you submitted a support ticket on it, because you may have stumbled across a bug that could affect others and if you're able to duplicate the issue (in a test environment of course) then you could provide details on how to do it so that the developers can look into it.

But I still think including blogs and blog entries in the "removed content" section is a much more viable option. Especially when you're granting members the ability to have multiple editors on a blog. People are jerks, plain and simple. Someone could go through and delete all entries in a blog they're working with others to maintain. It would be sad to have to tell the original author of that blog that they're "SOL" because you don't have a recent backup for them to use.

And this I think should be quite simple to integrate. It'd add two extra tabs to the Mod CP's removed content page. They can be displayed in a similar fashion to posts and topics and can be restored just as easily.

Simple to 'integrate', perhaps. But from a development standpoint, it could be anywhere from a few minutes to make possible to being a nightmare to add in. Look at the log-in process. It's simple to us because we type in a username (or email) and a password, submit and moments later we're signed in and ready to go. That seems so simple. However, going based off of my limited knowledge of what goes on, the "behind the scenes" is huge. Verification of the session, cleaning up of values submitted to prevent hacking attempts, checking if the member is banned/suspended, if the IP address is banned (at which point they shouldn't be able to sign in to begin with), remembering where the member was so they can be taken back there, checking if they have any new messages/notifications.. Oh yeah, making sure the account ID and password match up.. Can't forget that minor detail. That's not all that goes on neither. That isn't getting into loading up settings, accessing the database, and many other things that go on. Such a simple process to us but a ton of things going on that we don't think about or aren't even aware of. All done to ensure that each community is safe, simple, efficient, flexible, feature-rich, etc.

Mind you, if the developers were to include such a feature, I'm sure it's something they could do with one eye tied behind their back and the other eye taking a nap. They are, after all, very capable and ingenious, as the software already demonstrates.

I think what you're wanting, to put it into simple words, is the equivalent of the "Previous Versions" option for Windows 7. In fact, that might be the best example to use. It allows you to specify how much space to use and for recovering a 'previous version' of a file, you can make a copy instead of doing a restore. Which is good because for a post, you might want to leave the current version alone, but have a copy for your records. Thinking on it, here's a bit of a 'detailed feature list' on it:
- Option for how much overall space should be used for 'previous versions' of posts and other content. Global setting as well as a setting within each app. (Could put a limit of 5mb of content, but might restrict each app to 2mb max, or different settings per app but combined total is over 5mb, but global would help balance it.) Global setting idea, of course, isn't necessary, just would be an extra option to make the system more dynamic.
- Time period for content and if that content should be protected from pruning when content is purged. Content flagged to not be deleted shouldn't count against the space quota.
- Ability to permanently delete items, one at a time as well as multi-select (same way topics can be multi-moderated from the topic list page).
- Ability to copy an item to a new (post/topic/blog entry/blog comment/etc) either using the original authors ID or as a quote. For the quote concept, think of the how reported content is handled.
- Option to restore an item (with the current version (if there) being saved in its place).
- Option to 'compare' versions. Think wikipedia, where you can select two versions to compare and see the differences.
- If current content matches previous content, have the previous content refer to the current. Saves space but shows the history of it as well. If another edit is made, update the reference to the saved 'previous version'.
- Per group settings for who can see previous edits, which edits they can see (self, others who aren't supermods/admins, all).
- Per group settings for who can copy (and/or restore) previous edits, along with which edits they can copy/restore (refer to previous example)
- Being able to permanently delete content I feel should be restricted to the ACP. Otherwise, the whole purpose behind the feature would become moot.
- Include option to see previous versions in both the ModCP as well as within topics/blog comments/etc. Seeing the option for "Previous Versions" would be an indicator that the content has been edited and the previous content is accessible.

I think that should cover it for the most part. Like I said, I'm actually in favor of something like this. Just keeping in mind that it might not be practical or feasible.

People are jerks, plain and simple.

You're too kind. I mean that seriously. I would have used slightly stronger wording, because people really can be.. um.. well, let's just say they can be what they sit on.

You do have some good ideas for the attachments issue.

Thank you. If you like any of them enough to ask for it, I suggest you do it in a separate topic (if you haven't already). When multiple ideas are presented in the same topic, they can, as IPS has said multiple times, end up getting overlooked. So ideas that are somewhat different should have it's own topic. So preserving attachments is a good idea but shouldn't be a concern as far as keeping 'previous versions'.

[Makoto]

I hope you submitted a support ticket on it, because you may have stumbled across a bug that could affect others and if you're able to duplicate the issue (in a test environment of course) then you could provide details on how to do it so that the developers can look into it.

As I hinted, the cause was unconfirmed. It's just a hunch. I planned to test the archiving system in a development environment to see if I could replicate the issue, but until then, there's not a point in filing such a report. I will try and test it soon, however.

Simple to 'integrate', perhaps. But from a development standpoint..

I meant from a development standpoint. I'm at least a little familiar with how the current system processes deleted topics and threads, I don't believe it would be that much harder to replicate the function for IP.Blog, especially since IP.Content already takes advantage of the function as well.

I think what you're wanting, to put it into simple words, is the equivalent of the "Previous Versions" option for Windows 7...

What I want is very little different from the current system in place for topics and posts.

As seen here,

[Rimi]

"Hide" is effectively the replacement for soft delete, and it is supported in Gallery 5.

That was a bit misleading...

Only moderators can hide images. The members are only allowed to permanently delete images. The permissions are not as fine tuned as they are in board.

[Aiwa]

Lots of words.....

A front end management system to hold onto deleted content until a second action can be performed doesn't do any good if a member knows that and remembers to delete it twice.

Front end deletion management is no where near as good as proper database backup management.

Edit history, I agree on that point. Much like IPC now has edit history, it would be nice to store at least the past couple revs of a post.

[Rimi]

Lots of words.....

A front end management system to hold onto deleted content until a second action can be performed doesn't do any good if a member knows that and remembers to delete it twice.

Front end deletion management is no where near as good as proper database backup management.

Edit history, I agree on that point. Much like IPC now has edit history, it would be nice to store at least the past couple revs of a post.

Well it's different if the second action has to be done by a moderator which is what soft deletion is.

[Aiwa]

Well it's different if the second action has to be done by a moderator which is what soft deletion is.

True, but what if it is your moderator that goes rouge? That is the OP's point...

[Rimi]

True, but what if it is your moderator that goes rouge? That is the OP's point...

I guess I missed that part in the OP.

Honestly I think that case is rarer and a backup solution is more reasonable to consider.

Of course lots of people have also asked for global moderator permissions.