38 replies to this topic

[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.

[Aiwa]

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.

I don't disagree... IPS has added rev control to many of their products... They should make it uniform across the suite...

At some point, you have to draw the line in the sand... At some point proper DB backups are going to be the solution to the extreme problems brought up... IPS can't design around the one off person that doesn't want to keep up with DB backups and wants everything to be quadruple redundant and handled by the front end. That's just not something that's even practical..

[AndyMillne]

Adding support for "hide" is on the agenda but not for 2.6 which is already in pre-release testing. It was decided to delay this for a major release due to the very different workflows between blog and forums. Currently there is draft/published status in blog which you can move back and forth between. If we were to make this the same workflow as topics then removing the option to go back to draft would be the outcome in favour of adding hide/unhide. It was decided this was too big of a workflow change for the 2.x series and if the option to revert back to draft was retained then there is little point in a hide/unhide mode.

In summary, we will be bringing this inline but not for this release.

[Rimi]

I don't disagree... IPS has added rev control to many of their products... They should make it uniform across the suite...

At some point, you have to draw the line in the sand... At some point proper DB backups are going to be the solution to the extreme problems brought up... IPS can't design around the one off person that doesn't want to keep up with DB backups and wants everything to be quadruple redundant and handled by the front end. That's just not something that's even practical..

But if they added it to IP.Content then I wouldn't say that it's not practical. Databases and articles can be just as open and edit heavy as posts, if not, moreso. I'm a trial and error type coder when I do my templates and I ended up with a ton of revisions when I remembered to check if that was building up.

Speaking of which...

Would also like to have pruning options for those revisions since I personally have no use for them since in my setup I am the only one who has access to content.

My suggestions are just based on what I think would benefit the most.

[⚔ Kirito]

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

I actually more so meant what if a blog editor (regular member added as an editor) goes rogue and destroys another members blog.

Adding support for "hide" is on the agenda but not for 2.6 which is already in pre-release testing. It was decided to delay this for a major release due to the very different workflows between blog and forums. Currently there is draft/published status in blog which you can move back and forth between. If we were to make this the same workflow as topics then removing the option to go back to draft would be the outcome in favour of adding hide/unhide. It was decided this was too big of a workflow change for the 2.x series and if the option to revert back to draft was retained then there is little point in a hide/unhide mode.

In summary, we will be bringing this inline but not for this release.

Will "hide" replace delete blog? As in, members will only be able to hide their blogs/entries and not delete them entirely?

I'm honestly fine with deletion as long as it can be restored if needed. Deletion queue actually sounds more efficient, as it's all stored in one easy to access area and is automatically purged at your set interval. Hide just hides the post. That's it.

As far as having blog editors goes, I think I like the idea of allowing editors to edit existing blogs, but the changes going into "draft" mode. As in, they're not live. The actual blog author would then have to review the changes and decide whether or not to push them live or keep the entry as-is.

[RObiN-HoOD]

I totally agree with the idea of this topic. I have been saying that for ages. HIDE everywhere and even then Permanent deletion ONLY by root admin or any specifically designated person.

Sometimes I am dealing with Copyrighted material. There is no "oops sorry". There may be legal implications. I need to be able to restore/recover/prove every single post/comment/edit and/or deleted content (post/image/etc).

Especially these days due to Facebook, everyone is starting to deal with their privacy and copyright issues and they make comparisons. One thing that I can already say is that expect people to start asking for profile restrictions based on friendship (I've already seen a third party module for friendship relationships around here). That may extent even to Profile feeds (status update). I had this kind of conversation just yesterday with a member. In 3.1.4 I had removed from the front page the "Recent status updates" hook because I could not restricted only to members and now upgraded to 3.3.4 I use a third-party hook to ditch guests from seeing "Last 10 status updates" from homepage.

I've bought IP.Downloads for about 2 years but not using it because there is no HIDE, at least properly implemented, so I can be sure that even if someone do something bad I can be sure that I'll have no lost content.

I understand that IP improves and is trying to extend this kind of framework functionality in all of its Suite, board and modules, but still I have to agree that it takes too long.

Editing and deleting of content should be fully managed in every aspect of it.

[Feld0]

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.

That problem can be alleviated by the addition of proper permissions management for super moderators, and even admins. Just like you're able to restrict exactly what each admin and admin group can do in the ACP, we should be able to control exactly what a super moderator is able to do and not do. In other words, someone should not automatically gain the ability to wipe all of the site's content from the database just because they are in a group with "super moderator" privileges.

Database backups, assuming you have them (you should, but that's for another topic), are very useful in case a significant amount of your site's content is deleted for whatever reason, but they are extremely cumbersome to restore little bits of "hard-deleted" data from. I had to use a few custom queries to restore all of a member's status updates from a database backup after someone figured out their password and deleted all of them from their account (that prompted me to start this feedback topic to make status updates "hideable").

Digging out a 2+ GB .sql file from my backup server, importing it into MySQL so I can work with it, locating the vandalized data, writing custom SQL queries to fetch it, then restoring the data to my live site's database should not be necessary to restore some accidentally (or maliciously) deleted data. It's extremely time-consuming, clumsy, and sufficiently challenging that many forum owners would not even be able to do it.

It's even worse if you're trying to restore attachments, gallery images, or anything else that involves a physical file in addition to a database entry - then you have a database backup and a filesystem backup to fish data out of.

All of this trouble can be resolved by extending the "Hide" feature to absolutely everything, and making super moderators honour all the "Can permanently delete content?" usergroup permissions. I think that's what we're all asking for here.

[nrep]

All of this trouble can be resolved by extending the "Hide" feature to absolutely everything, and making super moderators honour all the "Can permanently delete content?" usergroup permissions. I think that's what we're all asking for here.

This is a real must for me - I've had things permanently deleted by someone else and then to try and restore it has been a real pain, involving manual SQL inserts. I dread allowing permanent delete options to anyone other than the admin.

[stepy]

Hope IPB team will add it as soon as possible 

[RObiN-HoOD]

I concur!

[Neil2]

The Trash Can like the older software is the best and safest thing for the communities period, you can restrict access to it and it everything deleted went to the Trash Can since it was set up private.

If an accidental deleteion is performed root admin can restore it no problems, if a staff members screws up they can hide all evidnece with this half wit deletion on the new software.

[Aiwa]

Not if you don't give hard delete permissions to your mods.

If you have a staff member deleting things and trying to hide it, you have staff issues. Just saying.

[Wolfie]

The Trash Can like the older software is the best and safest thing for the communities period, you can restrict access to it and it everything deleted went to the Trash Can since it was set up private.

If an accidental deleteion is performed root admin can restore it no problems, if a staff members screws up they can hide all evidnece with this half wit deletion on the new software.

The new way is better.  With the old concept, using a forum as a trashcan, aside from the obvious (that Aiwa pointed out), if you have a bunch of posts or topics to restore, then you have a major chore ahead of you.  For topics, put them back in the proper forums and also edit/remove the topic description so that people won't be asking why it's there.  For posts, figure out where the topics are so you can move the posts back to the right forum and then merge those posts (as separate topics) into the original topic.  That's a hell of a lot of work.

 

Current way, you can just click a button to restore a post/topic and it's done.  Only thing I don't like about the current way is that to prevent anything from getting purged, you have to set the retention time to a really high number.  I'd prefer to just disable that part altogether.  Simple enough.

 

[⚔ Kirito]

How about extending the "hide" function to other apps then? IP.Downloads for example.

 

It would be useful in general. Right now I just move files to a "hidden" category when I need to remove them temporarily. (Eg. DMCA complaints and giving members the chance to file a counter-DMCA).

[bfarber]

Hide will be extended universally in time.  I think you'll see a lot more consistency with things like this as we approach the 4.0 Suite.