2 Replies Latest reply on Feb 18, 2017 12:01 AM by huong_ho888

    Fine grained group member


      Is it possible to organize the members of a group into sub-groups?

      • Group_X: common to all
        • X_IT
        • X_HR
        • X_MK
        • X_RD


      Kind regards,


        • Re: Fine grained group member

          Hi Huong Ho,


          Reviewing through your description, the concept of sub user permission groups is not currently in the Jive Platform. While multiple user permission groups could be created (Managing User Groups ) these would not be nested within each other.


          That being said, if this is a feature you are interested in seeing available in a future release, I would recommend submitting an idea to the Ideas for Jive space, as our Product team reviews through top rated ideas when evaluating features for future releases.



          1 person found this helpful
            • Re: Fine grained group member

              Hi Jesse Fuller,


              I am a Jive/VA-Pulse advocate and believe that having a fine-grained access would enable Jive to match with other collaboration tools such as SharePoint in terms of access control.  You can get by with coarse-grained access in a small and flat organization where there are no or few overlaps of shared functionality.  But the scheme won't be sufficient for a large and hierarchical organization.  The current Jive permission model won't be able to handle Role-based access control (RBAC).  For example, group of SMEs perform multiple site visits and report check list requirements (met, not met, and partially met) to the national team.  They need to collaborate with the local facility but can't share sensitive finding information.  Within SMEs, certain members would only be allowed to upload a report, others would have access to read, and a very few will allow to add comments to the reports.


              The benefits of having fine-grained access control will greatly improve the security of web applications.

              1. Support Principle of Least Privilege.
                • Grant component access to only the resources they truly need.
                • Reduce privilege means reduce trust in components.
                • Less-trusted components would be subjected to less security review than more-trusted components.
              2. Improve isolation and component encapsulation.
              3. Increase security and protection.
                • Increase user confidence.
                • Increase application component robustness.
              4. Enable the facilitation of security audit.


              I strongly urge you (copying Micah Markman, my VA Pulse guru ) to make this request as a priority with the Product team.


              Thank you so much and have a wonderful President's Holiday.


              Kind regards,


              1 person found this helpful