One of the new features in IBM Connections 4.5 CR3: ‘community re-parenting’

As you may be aware by now, IBM Connections 4.5 Cumulative Refresh 3 (CR3) shipped yesterday.  

Amongst the detail of that fixpack, is a description of the new functions contained within it:

1. Reparenting communities

This function allows an administrator to modify a top-level community to become a subcommunity of another community or modify a subcommunity to become a top-level community.

2. Community activities view

This function provides a view that lists all activities that are part of all the communities that the user belongs to. The view is linked under My Activities left navigation bar. The listed activities do not include public activities, activities that the user tuned out, or activities that have been completed.

3. Badging

This function adds a badge next to the “@ Mentions” and “My Notification” links within the Activity Stream view.

4. Ideation blogs filter APIs

The new APIs provide extra parameters to filter the results by blog type (e.g. blog, ideationblog, and communityblog). There are also new VM methods for displaying most commented and most visited blogs/entries by blog type.

Whilst all all useful in some way to all the organisations I work with, the first is a key features that has been requested for a long time – in fact variations of this request have garnered over 500 votes in the Greenhouse ideation blog.

[line]The ‘Reparenting Communities’ feature allows a Connections administrator (not a user at this stage) to move a community to become a subcommunity of another community, or to move a subcommunity to become a top-level community.  

[box color=”gray”]

This is done using two new wsadmin commands:

• CommunitiesService.moveSubcommunityToCommunity(“subCommunityUuid”)
• CommunitiesService.moveCommunityToSubcommunity(“parentCommunityUuid”, “communityToMoveUuid”)

[/box] [line]In the first case, of [mark]moving a sub-community to become a top-level one[/mark], this is the impact.  The new top-level community retains the following characteristics of the original sub-community:

• Original access level (public, moderated, or restricted)
• Membership list
• Community logo (picture), tags, and description
• Community theme
• Original start page setting
• Any existing web addresses (Note: The URL to access this community changes slightly because the parent handle no longer exists.)

[line]In the second case, of [mark]moving a top-level community to become a sub-community of another[/mark], there is a bigger change… 

• First, the new sub-community with existing web address is cleared – Any “Invited” users on the sub-community that have not accepted or declined the invitation are removed.

The new sub-community retains the following characteristics of the original top-level community:

• Start page setting.
• Community logo (picture), tags, and description.
• Community theme.

Membership relationships between parent and subcommunity are as follows:

• Community owners in the parent are copied to the new subcommunity as owners.
• Sub-community members and owners are copied to the new parent as members.

There will be an error generated if the following reparenting actions are attempted:

• Reparenting a community that has sub-communities.
• Reparenting a community that is already a sub-community

[line]These restrictions make sense to me – I can’t see how else they could have been managed.  It is a shame that users cannot do this for themselves, but given the complexities of ownership and access, I can see why this is the case.  It is great that us admins now have this ability baked into the released product.

As an aside, it is also worth looking at Domain Patrol Social, a third-party solution that offers a UI for admins that allows reparenting communities and much more besides. I resell the product and would recommend it highly, even with this functionality now in the main product.