We are rebuilding our whole system and at the same time reducing our communities from about 30 down to 2. However we thought we might keep the exisiting communities in a dormant state (ie nobody in those communities) and all existing users (40) in case it is decided at some later date to farm editing back out to communitiets. However it seems that if we created content in the 2 new communities we would not be able to transfer this back to the older list of communities because a central part of the concept of RHythmyx is that a content item is tied to the community in which it is created - so it may be pointless keeping the old communities.
Does anybody know if it is actually possible, using the backend (workbench) to move items between communities?
rljohnson is correct. However, items “can” be moved to another community but require modifying entries in a few tables in the database. This is not recomended as it is not supported by Percussion and not for the faint at heart.
As stated, manually modifying the database is NOT supported, however this project is something that either our Field Services team or one of our partners could assist you with. If you are interested, please contact either TS or your Percussion sales representative and we’ll be happy to get the ball rolling.
We are trying to design communities for a new implementation. We understand that you cannot move content between communities. What happens if you delete a community? Will the content created by users in this community stay or be deleted?
Also, if you have multiple communities for admins, power users and contributers, and there is content created in the contributor community that is also used by the users in the admin and power user communities, what is the relevance of the community in which a given content item exists since the content can apparently be used from any of those communities? Why would you need to move content between communities in this type of community arrangement?
CM System does not allow you to delete a Community that has content. You must purge all Content Items and delete all Folders associated with the Community before you can delete it.
A user must be logged in to a Community to have edit rights to its Content Items. Content is usually segregated in this way specifically to control edit access. For example, in the FastForward implementation, only admins have edit rights on Navigation Content Items; the model does not allow members in general to edit Navigation. In the model you propose, it sounds like there is content you want general contributers to edit, other content you only want power users to edit, and some content you want only admins to be able to edit.
Admins are a special case. In CM System, as in many other products, admins have broader rights so they can resolve problems, such as unlocking content locked by a user that is unavailable.
While only members of a Community can edit its Content Items, members of other Communities generally have read access so they can create links to the Content Items.
One final point: a user can be a member of more than one Community. So a power user, for example, can be a member of the contributor Community, too. But the user would have to log out of the power user Community and in to the contributor Community before they could edit content in the contributor Community.
Your last sentence especially was very informative and it clues us in that creating communities based on role (contributor, power user) rather than content group (marketing, finance, etc) would likely result in very poor usability for authors with them switching between communities all day long. Seems like a best practice would be to organize communities in a way in which there is minimal content sharing between communities or else have one single community for everyone to use, with a heavy realiance on folder permissions.