Abuse service features added in this release

View abuse history in posts and delete abusive wiki post revisions

7.0 related feature: Abuse service

In release 7.1, the abuse management functionality has been extended to display abuse-related history on any kind of post page and to allow one or more revisions of an abusive wiki page to be deleted.

There are five specific features or changes (detailed in subsequent sections of this article) that contribute to this functionality:

Abuse queue wiki item "View post" link displays post content and link to revision history

7.0 related feature: Abuse social service

In release 7.1, there is a View Post link on an Appeal queue item that displays the reported post content. In the case of a wiki page, it also provides a link to the page's revision history where applicable.

Somewhat related to the new 7.1 capability of evaluating each revision of a wiki page separately for abuse, this particular feature makes it easier for you to view the reported-abusive post content and to view other revisions for evaluation.

The "View post" link is located in the bottom-left corner of the appeal queue item expanded view.

When you click this link, the reported content appears in a modal window. It displays the post title and the reported-abusive content. (Note that this option does not open the post page; it displays the content of the page.)

In the case that the abusive item is a wiki post with revisions, the "View revision history" link is displayed at the bottom of the Appeal Queue item expanded view.

When you click View revision history, you are taken to the wiki post's history (~/history.aspx) page. From here, you can click each revision and evaluate its content.

If you find that a prior revision is fine and you want to go back to that content, you can use the "Revert to this version option" in the Wikis - Revision widget.

If you find that a revision contains abusive content, you can elect to:

  • "Delete this version" (revision) in the updated Wikis - Revision list widget but retain (and evaluate separately) other revisions.
  • Delete the entire page and its revisions in the new Wiki - Resolve Appeal ("Fix wiki page" widget, shown below) using the "Confirm as abusive and delete page" option.



    The other two items in the Wiki - Resolve Appeal widget, "This page is fine - Restore" and "Review specific revisions," are treated in more detail in the Wiki - Resolve Appeal widget section.

Previously in release 7.0, it was necessary to click the page's "View history" link on the Wikis - Links widget ("Administration"/"Options") to view  revisions and you only had the options to revert to a revision or go to current view.

(See also: Review appeals, Abuse social service, Wiki - Resolve Appeal widget)

Delete Wiki revisions

Wiki revisions can now be deleted.

Like service feature changed in this release

Registered users can view the full list of likers on posts or comments

7.0 related feature: Like social service

In release 7.1, registered users can click the number of likers or "+ others" text on a post, comment, or status message to view a complete list of likers in a modal window.

Members of a community aren't as interested in anonymous opinions as they are in the opinions of identifiable community members. In release 7.1, Telligent Evolution has an improved Like service experience that displays all likers - not just the 10 most recent likers - on posts, comments, and status messages. The list is displayed in a modal window that you can click to open.

For example, in the comment on the following status message displays the number of likes.

In release 7.1, you click the Like symbol or text. A modal window then opens, displaying a full list of the likers (with links to their profiles) in two columns.

The modal window stays open until you close it.

Previously in release 7.0, likers were visible in a mouse hover-over on posts, status messages, and comments, and the viewable list was limited to the last 10 likers.

(See also: Like content, Activity Story Stream, Configure the Activity Story Stream widget)

Permission feature added in this release

Group permissions can be reverted to default

7.0 related feature: Group Permissions page

In release 7.1, you can now revert group role permissions back to the defaults, restoring permission inheritance from the site.

Release 7.1 gives you an important new capability: You can revert all of the permissions for one role (or all roles) in a group back to the default. Reverting the permissions serves to restore the cascade of permissions down from the site-level roles to the group-level roles.

You can tell whether or not a role's permissions have been customized by selecting the role in the group Permissions tab. If the Revert this role's permissions or Revert all roles' permissions buttons are available (that is, not greyed out), this means the role has been altered at some point.



Notes: You can't revert selected permissions; they are all reverted at the same time for either one role or all roles. The Revert all roles' permissions option is available even if only one role's permissions have been customized in the group.

Release 7.1's revert permissions feature provides two options:

Revert this role's permissions

As an example of using this option, suppose a previous administrator created or administered GroupA. You receive complaints from users in this group that they can't create blog posts, even though you have granted the Blog - Create Posts permission to the Registered Users role from the site level. If you look more closely at the Registered Users role in GroupA, you notice that the Revert this role's permissions button is available, indicating the role's permissions have been altered at some point and deviate from the Registered Users role that is defined at the site level. You would select the role and use the Revert this role's permissions option to restore it being affected by changes in membership administration, resulting in GroupA Registered Users being able to successfully create blog posts.

Revert all roles' permissions

As an example of using this option, suppose you want to move a group (Developers) from the Site Root parent to another parent group (GroupA). The Developers group has customized permissions for the custom Contractors and default Owners roles, which you know because you've observed they both have the Revert this role's permissions button available. After you move the Developers group from the Site Root to ProductA in the Group Options tab, you now want the Developers and Owners roles to behave the same way in this group that they do everywhere else on the site. You would use the Revert all roles' permissions option on the group Permissions page to achieve this affect. Thus Developers and Owners now have congruent permissions all over the site.

(See also: Permissions defined)

New and changed widgets in this release

New Abuse History widget

7.0 related feature: Abuse service

Release 7.1 introduces a widget that displays abuse-related information for a blog post, forum post, media gallery post, or wiki page that has at some point been been hidden due to abuse.

The Abuse History widget is designed to help you evaluate edge case content by giving you more historical data to use in your decision-making. For example, if you see that a flagged ("possibly abusive") item in the appeal queue has an abuse history, the pre-existence of the history itself might weigh upon your decision. Seeing that a page is flagged by an administrator (such as Ashley in the screen capture below) or by another high-status community member might also factor in. In the same vein, content having previously been hidden; having no appeal previously accepted, and/or never having been restored might also help you decide how to best handle this content.

The Abuse History widget contains the following information:

  • Status:
    • Active - The post was previously reported and found not abusive, thus was restored.
    • Possibly abusive - The post is currently reported as abusive.
  • History of being flagged for abuse - A list of the dates and usernames for previous abuse flaggers.
  • History of being hidden - The previous date, if any, on which the content was hidden.
  • History of appeals and current status - Number of total, open, and accepted appeals.
  • History of restoration - Whether or not this content has previously been restored.

This widget does not appear for a post in the flagged but viewable state because the content is not and has not been hidden. And the widget is only visible to those having the Group - Manage Abuse permission.

(See also: Configure the Abuse History widget, Review appeals, Override score decay rates for applications)

New Wiki - Resolve Appeal widget

7.0 related feature: Abuse service

In release 7.1, the new Wiki - Resolve Appeal widget (called "Fix wiki page" in the user interface) is specially designed to help you manage abusive wiki pages.

This widget only appears on wiki pages reported for abuse (current revision and previous revisions), and is only visible to users with the Group - Manage Abuse permission. If or when a wiki page is restored, the widget is hidden. (But you can still view the wiki page's prior history in the Abuse History widget.)

The options on this widget let you perform blanket actions for the page and all of its revisions (confirm as abusive or restore), or view and handle specific revisions by opening the wiki post history page (much like the "View post" link does in an appeal queue item) to let you access them.

The options available from this widget include:

  • Confirm as abusive and delete page - If you decide to remove the wiki page and its revisions in entirety from the community, this option will allow you to do so in one stroke. Clicking this option opens a small "Board Response" text field where you can supply the deletion reason, then click Submit and confirm the deletion. Note that "deleting" actually means to hide.



    Because the page is hidden, you can still access it and its revision history in the appeal queue by selecting the Archived (Confirmed Abusive) option in the "Show" drop-down list.

  • This page is fine. Restore - If a page was removed as abusive, you can still restore (or unhide) the page with this option. Clicking it will open a small "Board Response" text field for you to furnish the restoration reason. You then click Submit and confirm the restore.

  • Review specific revisions - This is another access route to view the wiki page revisions (in addition to the appeal queue item "View post" revision history link) and to evaluate and treat them individually using the Wikis - Revision widget "Delete this version" link.

(See also: Configure the Wiki - Resolve Appeal widget, Review appeals, Comparing versions of a wiki page)

Changed Wikis - History widget

7.0 related feature: Abuse service

In release 7.1, the Wikis - History widget has an added "Delete Versions" button which allows you to select multiple revisions of a wiki page to remove, whether due to abuse or editorial reasons.

You might use this new option after you view several revisions of a page - such as when reviewing revisions for an abuse report - to selectively remove undesired revisions.

In release 7.0, the Wikis - History widget only provided a "Compare versions" button and links to individual revisions.

(See also: Revert a wiki page to a previous version, Comparing versions of a wiki page, Configure the Wikis - History widget)

Changed Wikis - Revision widget

7.0 related feature: Abuse service

In release 7.1, the Wikis - Revision widget adds a new "Delete this version" link, enacting the new capability in this release to manage abusive wiki page revisions.

Wikis - Revision appears any time you access a previously saved revision of a wiki page.

You can access a revision containing this widget in three ways:

  • The Wiki - Links ("Administration"/"Options") widget "View history" link > select a revision
  • The appeal queue "View post" link to a wiki post's revision history > select a revision
  • The Wiki - Resolve Appeal widget "Review specific revisions" link > select a revision

As mentioned in previous sections, this widget allows you to evaluate and treat page revisions separately for abuse. On each revision page you can take one of three actions:

  • Click the previously existing "Go to current revision" link
  • Click the previously existing "Revert to this version" link
  • Click the new Delete this version" link

In release 7.0 and prior releases, only "Go to current version" and "Revert to this version" options were available in the Wikis - Revision widget.

(See also: Revert a wiki page to a previous version, Comparing versions of a wiki page, Configure the Wikis - Revision widget)