6 Replies Latest reply on Jan 21, 2010 3:05 PM by CarlosCaballero



      Is there a difference between the SharePoint plugin and the SharePoint Module?


      Also, has anyone any success in getting it to work in a hosted environment?

        • Re: SharePoint

          Is there anyone at Jive available to do a demo of Sharepoint module?  I am not sure who at Jive to speak with.  

          • Re: SharePoint

            There is no difference: they are all the same. There is only one SharePoint-related product in the Jive SBS product family; it's formally known as "Jive SBS Connects for Microsoft SharePoint". It used to have a much simpler and direct name, but then again, there are too many bored lawyers looking at "protecting brands" almost as much as to creating billable hours...    That said, the product referred above is a connector (it makes content and activity from SharePoint available to Jive SBS users by connecting to it), and it's packaged as a module (which is, in itself, a packaging concept).


            As for running on the cloud, I don't know of customers that have it running in Production on the cloud, but we know that the product does run in such deployment scenario.


            PS: "All product names in this post are the trademark of their respective vendor companies, etc. etc." 

              • Re: SharePoint

                Hi everyone,


                     I think the question is about if the Sharepoint plugin ( http://www.jivesoftware.com/jivespace/docs/DOC-3026 )  and the Sharepoint Module ( http://www.jivesoftware.com/products/technology/modules/sharepoint ) do have the same functionality ? Well, it is known that the first one is compatible with v2.5.X,3.x, and the second one only with v4.X, but moreover, on what do they differ exactly once installed ? ( new/unique features, both the code-based approach and the user-interface-based approach would be helpful to understand their differences).


                On the Sharepoint Module, does the following has been improved ? :




                Make sure to inform the SharePoint Administrator of the lowest security permissions level among your Clearspace user base, so that the SharePoint Admin can set the permissions for the ClearspaceSearchUser Role appropriately. Sub-sites by default inherit the permission levels of the parent site, and should be adjusted separately as needed.


                However, there is no user role in SharePoint that can prevent a user from viewing a file's indexed content. Sensitive files, while they can be set not to be opened, will still be indexed, and as a result sensitive information could be viewable by people not cleared to view it. The only way to guarantee that a file is not viewed is to avoid linking that SharePoint site to Clearspace! " (Extracted from the Sharepoint Plugin Readme file )



                Thanks so much,



                  • Re: SharePoint

                    If that is the case, let me (a) apologize for shooting from the hip, and (b) try to answer those specific questions.


                    1. The old version of the connector was mostly a proof of concept for loose integration, whereas the new product is much more functional and production quality all around: content navigation from both SBS and SP, unified search from both SP and SBS (which is, as the rest of the product, fully security trimmed), single sign on (with Kerberos support), web parts that bring the most popular Jive widgets to SP, widgets that facilitate integration of SP lists and calendars, integration of SP file-related activities into Jive SBS Activity streams, socialization management by container, user, type of files, etc., mapping to socialization containers that are fully and finely controlled by the content owners, and much more. Comparing them is effectively comparing apples and oranges
                    2. No, the security constraints you refer to are not true about the new product. On the contrary, the complete implementation is security trimmed.


                    I hope this helps

                      • Re: SharePoint

                        Hello Carlos,


                              Thanks very much for the insight. Would you say that in the Sharepoint Module for Jive SBS 4.0 , there is a way to manage the permissions that Jive Users have for locating indexed documents on the Sharepoint side i.e. when browsing-performing a search ? ( thus, preventing that all Jive Users see all documents existing within the Sharepoint Instance ) ... how is this achieved ?   What are the means to accomplish this ? Is the Admin Console involved in some degree, or some kind of table populated by hand or Admin console that maps Jive Users with documents which are viewable ?


                        Note: We are worried about common Jive Users seeing certain confidential documents on the Sharepoint Side. Only Admin-Moderator Jive Users ( or as an alternative, several Jive Users which have received such permission by the Jive Admin) must be allowed to see firstly that they exist, and secondly to read their content. Perhaps the allowance-permission for locating these confidential documents, when browsing from Jive towards the Sharepoint Instance, is managed by invitations, in a similar way such as inviting a new Jive User to join a community ?


                        Any comment or information is greatly appreciated,


                        Best regards,



                          • Re: SharePoint

                            Except for the streaming of activities from SharePoint to Jive, credentials of the current Jive user are used to obtain access to content in SharePoint.  This means that SharePoint site administrators can rely on the same security permissions which they use ordinarily to restrict/grant access to content.  As for activity streams, the credentials of the user who chose to stream the activities of a SharePoint site to a place in Jive are used for security trimming.


                            Let me be more specific.


                            Credentials delegation (think forwarding) is used for:

                            • SharePoint widgets in Jive which display SharePoint content directly in a Jive place
                            • Display of SharePoint data within Jive documents
                            • Publishing of Jive documents to SharePoint sites
                            • Retrieving, and thus viewing, of SharePoint documents  in Jive
                            • Search of SharePoint content from Jive


                            As for activity streams, the credentials of the user who chose to stream activities in a SharePoint site to Jive are used for access to those activities, but not necessarily the content.  Though the activity, “Bob created proposal A in SharePoint site B on Friday”, is streamed to Jive, this does not necessarily mean that the user in Jive will be able to view the content, “proposal A”.  Access to the content is again configured by the site administrator who chose to socialize the SharePoint site with Jive.  The site administrator can specify that access to the content will use the same credentials as is used for the streaming of activities or use the credentials of the current user in Jive.


                            The two options for streaming of activities allow for the following:

                            • “I want to share activities and content from SharePoint site A with any user who has access to the Jive place which I have selected regardless of what access they may have to the content in SharePoint”
                            • “I want to share activities from SharePoint site A, but I want to be sure that only users who have access to the content in SharePoint will have access when they attempt to view the document from within Jive”


                            So, how does it work?  Credentials delegation is achieved ideally by having both Jive and SharePoint connecting to the same Active Directory.  In this case, Kerberos can be used to provide for the proper forwarding of credentials.  If by chance it is not feasible for Jive and SharePoint to share the same active directory, then a “service account” will be used for primary access to SharePoint, and then within that call, impersonation is used to ensure that content returned from SharePoint to Jive is security trimmed for the current user in Jive which is aligned, by user name, with users in SharePoint.


                            The streaming of activities goes further by allowing SharePoint Farm Administrators to define farm wide policies for the streaming of activities.  For example, the administrator can choose to allow streaming only to private groups, include/exclude documents by file extension or content type, include/exclude specific SharePoint sites, or block content created by specific users.


                            (Thanks to Erid Bowden for providing technical content for this answer)