Jump to content

Invision Community Blog


Managing successful online communities

bfarber
Sign in to follow this  
 

4.0 - Simplification of deletion and approval process

A little history

For many years, IP.Board functioned under a relatively normal model of managing a content's status. A topic, for example, was either unapproved or approved. If a moderator did not like the topic, that moderator could delete the topic. This worked well for many years, but improvements in technology and processes necessitated changes. As IPS software evolved we recognized the need to handle all content throughout the entire suite in a uniform manner, so old concepts like the "trash can" forum were no longer relevant when considering how you work with Gallery images or Download Manager files. Additionally, many sites today employ moderators that they do not wish to entrust with the complete ability to irrevocably delete content, yet they still need the moderator to be able to clean up a mess should it occur.

A few years ago, we introduced the concept of "soft delete". In practice what this meant was that when a user soft deleted a topic, the topic would be removed from general view for most users, but the topic would not actually be deleted. Administrators could choose who can view soft deleted topics, and who could "un-delete" the soft deleted topic.

Some time after this, the way topics were deleted changed as well (which was now referred to as "hard delete" in contrast to "soft delete"). If a topic was truly deleted, it would not actually be immediately removed from the database. Instead, a flag was set and the topic would be deleted from the database at some future point in time by a task. The idea was that you may need to restore something that was deleted by a moderator...but then, the software already supports a soft-delete concept to account for this, right?

When clients proved to be confused with all of the terminology (we can't blame you!), "hard delete" was renamed back to "delete", and "soft delete" was renamed to hidden. Nevertheless, behind the scenes we still had all of the various statuses to account for

  • Content is awaiting approval (unapproved)
  • Content is approved and viewable (approved)
  • Content has been hidden or soft deleted (hidden)
  • Content has been deleted but not removed from the database yet by the task (pending deletion)
  • Content has been deleted and is gone permanently (deleted)


And how about 4.0?

In reviewing the needs of most admins and how the process of managing the content and your moderator roles works in the real world, we decided to simplify and improve this experience.


The 4.0 Suite now has just 4 of the above statuses, and they behave in a manner you would expect.
  • If you require moderator approval of new content, when something is submitted it will be in an unapproved status. If you do not require moderator approval of new content, that content will be approved automatically and immediately viewable.
  • If a moderator has permission to hide content, the moderator will be able to hide any content that has been submitted. The moderator may or may not be able to see content that is hidden, and may or may not be able to restore hidden content to viewable status. (All that depends on Admin settings.)
  • If a moderator has permission to delete content, the moderator will be able to delete content that has been submitted. Upon doing so, the content is immediately and permanently deleted.


You can configure your moderators such that they are able to hide content, delete content, or both.

As with 3.x, moderators who can see hidden content will be able to review all hidden content in the Moderator Control Panel, and those with permission to restore hidden content will be able to do so from here as well. You will not have to worry about the content you are viewing in the Moderator Control Panel is deleted or hidden, as there is only one status now.


This is an example of a very minor change that was made after careful consideration of how the software functions and should "flow" when being used in a real-world situation. It is often the case that the smallest changes can make the biggest impact in the eyes of the users.
Sign in to follow this  

Comments



Recommended Comments

We can come up with examples all day long of why (insert obscure feature here that 3 people "need") is necessary, but the reality is....if you click "delete" it should "delete".  It shouldn't set a flag in the database and then at some future point "really really delete".  You can "delete" without removing from the database now (hide) and you can delete from the database (delete).  I think the majority of our clients will find that sufficient.  It vastly simplifies the code behind the scenes, improves consistency between the apps (no other apps do what you are describing, only the forums did this) and reduces potential for bugs.

 

I think if you have such a setup where extra fail-safes and data retention policies (while giving moderators permission to actually delete) is necessary, you have needs outside the norm.  We aimed to simplify the process, and we feel the changes we've made have done just that.

Share this comment


Link to comment
Share on other sites

That's fine. I'm not trying to attack your decision, just providing general feedback.

 

I don't think the deletion queue was really obscure, its purpose was fairly obvious. I think it was a nice extra (optional) fail-safe to have.

 

But I also don't think it's a necessary function, I only questioned if it's really necessary to remove it. I'm neutral on it being removed. I don't care one way or the other. I think it has its uses, I think it's nice to have available, but I don't think it's essential, and I think removing it to keep things simple and efficient is an understandable choice.

Share this comment


Link to comment
Share on other sites

To be fair, I've seen on more than one occasion on this very support forum admins saying how something was accidentally deleted and then rejoicing at the fact that it's still been retained and can be restored.

 

My only thing is, can we search through hidden posts and topics?

Share this comment


Link to comment
Share on other sites

horrible. Totally unnecessary. If I or another moderator of my forum accidentally delete one post, I have to use a backup to restore lost content.

Then do not give your moderators the ability to delete. Just give them the ability to hide. This serves the same purpose; the moderators can remove content from public view but you still have the option to restore.

Share this comment


Link to comment
Share on other sites

Then do not give your moderators the ability to delete. Just give them the ability to hide. This serves the same purpose; the moderators can remove content from public view but you still have the option to restore.

This is perfect... From the IPB 3.2, i removed permission of moderators of suspend due to novelty of them also may change a user from group (something that should be done exclusively in AdminCP). Now, them lose another tool ...

IPB getting better...

Sorry my bad english

Share this comment


Link to comment
Share on other sites

Then do not give your moderators the ability to delete. Just give them the ability to hide. This serves the same purpose; the moderators can remove content from public view but you still have the option to restore.

 

To be fair, I've seen on more than one occasion on this very support forum admins saying how something was accidentally deleted and then rejoicing at the fact that it's still been retained and can be restored.

 

My only thing is, can we search through hidden posts and topics?

Share this comment


Link to comment
Share on other sites

Things that are deleted but have not *actually* been removed should be removed by the upgrader.  In 3.4 if you "delete" something it will be marked ready for deletion in the database and is not meant to be hidden, so that should be honored by the upgrader IMO.

Hi Brandon, I understand that these changes are to reduce the redundancy of current ways of deleting.

I usually do not delete anything from the database of my forum so I have disabled until the task that removes the contents of ModCp after "x" days.

Would not be possible to the upgrader convert current deleted posts (now in mod cp) in hidden posts?

Share this comment


Link to comment
Share on other sites

Hi Brandon, I understand that these changes are to reduce the redundancy of current ways of deleting.

I usually do not delete anything from the database of my forum so I have disabled until the task that removes the contents of ModCp after "x" days.

Would not be possible to the upgrader convert current deleted posts (now in mod cp) in hidden posts?

 

I sincerely don't think that is what most administrators would want or expect to happen.  Most administrators, I would venture to guess, don't even realize that "deleted" topics and posts are actually retained for a short period of time before being deleted, and would probably be confused after upgrading if those deleted items suddenly reappeared as hidden content.

 

 

Is there a possibility we can look just for hidden messages and topics, as was the small icon in IPB 2?

 

Hidden posts and topics are still shown inline when viewing a forum or topic.

Share this comment


Link to comment
Share on other sites

 

This isn't possible at present but isn't a bad idea for an addition in the future.  That said, the warn system already allows for the functionality you are describing, including requiring the user to acknowledge the warning before they can post again (suite-wide).

We've found users look at warnings as very serious and it makes them a little scared so we don't use them for smaller things which is why I'd prefer this functionality. It is something we did have on a vBulletin board I used to help run. Would love it in a future update if possible =)

Share this comment


Link to comment
Share on other sites

I sincerely don't think that is what most administrators would want or expect to happen.  Most administrators, I would venture to guess, don't even realize that "deleted" topics and posts are actually retained for a short period of time before being deleted, and would probably be confused after upgrading if those deleted items suddenly reappeared as hidden content.

 

Ok :(

Just making my feedback, the feature that will be removed is a differential of IP.Board in relation to other bulletins systems and still think very necessary as administrators also commit mistakes when deleting things, beside which is present several years (since the trash can ). This feature has prevented that good content was deleted by beginners moderators in my forum who mingled with the tools. Hide in-line is not the same thing.

Share this comment


Link to comment
Share on other sites

Then do not give your moderators the ability to delete. Just give them the ability to hide. This serves the same purpose; the moderators can remove content from public view but you still have the option to restore.

Is there an option to delete a post only if it's already been hidden? The main thing with 3.4 is that if a person accidentally clicks on delete there is still a way to bring the post back.

Share this comment


Link to comment
Share on other sites

Is there an option to delete a post only if it's already been hidden? The main thing with 3.4 is that if a person accidentally clicks on delete there is still a way to bring the post back.

 

I doubt such feature is included by default but I'm sure a mod for it can be made.

Share this comment


Link to comment
Share on other sites

 

I doubt such feature is included by default but I'm sure a mod for it can be made.

Well, a mod can be made for everything. :P But if someone accidentally deletes a post it doesn't matter if the mod exists or not unless they have it installed already.

Share this comment


Link to comment
Share on other sites

Actually I have a more developer oriented question. How do you handle "hidden" content in the database? Is there a column added for each content item/node type that acts as a flag? And I take it that the content items/nodes account for this flag when generating feeds of data. Is the column name universal for all content item/node types? I'd love a coding example of how easy it is to flag something as hidden. Mostly curious to see if you're got a fixed, one line method for it or if each individual app has to handle it separately with an sql update command.

Share this comment


Link to comment
Share on other sites

Hidden content is handled centrally.  If you support approved content, then you will inherently support hidden content.  We will blog about specifics later, but to support this in Calendar was effectively just implementing the interface IPSContentHideable and then defining the column that stores the approved/hidden flag.  You then determine where in the template to show the link, but the act of actually hiding the content is handled centrally.  Similarly, showing hidden content in the ModCP is handled centrally (you don't need to write per-app plugins for this purpose).  And yes, streams of data account for the hidden flag automatically.

Share this comment


Link to comment
Share on other sites

Hidden content is handled centrally.  If you support approved content, then you will inherently support hidden content.  We will blog about specifics later, but to support this in Calendar was effectively just implementing the interface IPSContentHideable and then defining the column that stores the approved/hidden flag.  You then determine where in the template to show the link, but the act of actually hiding the content is handled centrally.  Similarly, showing hidden content in the ModCP is handled centrally (you don't need to write per-app plugins for this purpose).  And yes, streams of data account for the hidden flag automatically.

 

Lovely *-*

Share this comment


Link to comment
Share on other sites

And....we already have dev documentation written on how it all works (although I'm sure it will be refined further before we release it - we're using it as a template while *we* write apps to see what parts are clear and what needs clarification.

Share this comment


Link to comment
Share on other sites

I guess I will disable the "delete" option for everybody, and just have the "hide" option and the multi-moderation action "move to trashcan" (Or I'll name it "delete", maybe :smile:) which will move topics to a trashcan forum, that only admins and mods can see. Like the good old days. Problem solved.

Share this comment


Link to comment
Share on other sites

It does not make sense to me , i read through the comments and i still don't get why you would opt to do this.

Giving mods hard delete does not work. Some of my forums have volunteer mods. They have soft delete function. Once every 2 weeks i check in and hard delete tens to hundreds of threads. Occasionally i get a request to restore a thread mostly due to human error. I have had encounters with volunteer mods where they deleted thousands of threads as a griefing attempt or because their accounts got "hacked". A simple select all and restore works wonders.

 

Giving my mods the hide option only, it will not make sense to them, they have this function allready and never use it. From their perspective they want something gone, not out of sight but still using recourses or either for admin only visible or themselfs aswell. It's just an annoyance to see it.

 

While this functionality may be nice when implementing and utilizing it accross all integrated apps into the ips suite for a forum i do not see this as a good change. Your stepping away from a functionality that has been these since 1998 or even earlier.

If you are an administrator and you do not understand the different rights and what these individual rights do that you can give to ranks... give up because running a board is so much harder then that. You can indeed simplify this process for people who do not understand it. but taking these extra configurations completely away is not justified nor necessary.

Please "advanced role/rights configuration" button?

Share this comment


Link to comment
Share on other sites

It does not make sense to me , i read through the comments and i still don't get why you would opt to do this.

Giving mods hard delete does not work. Some of my forums have volunteer mods. They have soft delete function. Once every 2 weeks i check in and hard delete tens to hundreds of threads. Occasionally i get a request to restore a thread mostly due to human error. I have had encounters with volunteer mods where they deleted thousands of threads as a griefing attempt or because their accounts got "hacked". A simple select all and restore works wonders.
 
Giving my mods the hide option only, it will not make sense to them, they have this function allready and never use it. From their perspective they want something gone, not out of sight but still using recourses or either for admin only visible or themselfs aswell. It's just an annoyance to see it.


I don't think you understand the changes. :smile:

Soft delete IS "hide". It is the same thing. So if you don't give mods hard delete but do give them soft delete....you already do exactly what we have recommended - do not give moderators delete ability, but give them "hide" ability.

You can control whether moderators see hidden content or not. So if moderators want it "gone", then simply don't let them see hidden content, and when they hide it - it's gone.

 

If you have to, you can rename "Hide" for your moderators to "Delete", and the end result is a moderator clicks "Delete", the item is gone from their view, and you as the administrator can later go restore or mass-delete these hidden items.  It's the exact same workflow.
 

While this functionality may be nice when implementing and utilizing it accross all integrated apps into the ips suite for a forum i do not see this as a good change. Your stepping away from a functionality that has been these since 1998 or even earlier.


1) Our software has not been available since 1998

2) Virtually none of our competitors retain deleted content for later "really really" deletion, so we are not stepping away from any common convention
3) We only began retaining "deleted" content in an extremely recent version (3.3 or 3.4). Before that, as almost everyone would expect, when you deleted a topic or post...it was deleted.




What you already do on your site is effectively accounted for, as with almost everyone else who has replied with concerns. :smile: I realize no one likes to read "we are removing x", but this is a situation where we have opted to go with a simpler route that behaves as most users would expect (except for a small handful who are intimately familiar with the internal workings of recent versions of IP.Board), and that does not materially change any existing capabilities.

Share this comment


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...