3 Replies Latest reply on Nov 12, 2015 5:07 PM by Billy Volpone

    Setting Up Client Users with limited views


      Currently undergoing an upgrade to cloud and have found many of the discussions very helpful, so thank you!


      Recently, one of our product management teams approached me to see if we could set up a process whereby a client user would have limited view to only certain spaces (we do not leverage groups much at this point).  We have a group of clients that only leverage one or two of our products and we do not want to open up the full site.


      Curious, if one of my peers have experience setting up a users to only have access to a certain number of spaces/groups.

        • Re: Setting Up Client Users with limited views
          Kara Francis

          We have something similar, but we do have areas that are open to everyone as well, so not exactly the same.


          But if you truly want to restrict them from generally public areas, you would need to institute a permissions-based approach for all spaces in order to exclude them from the ones you don't want them to see. But if you use sub spaces, maybe it wouldn't be too cumbersome to set up. But it could become pretty manual as you would need to maintain permissions groups every time someone joins your community (in order to give others access to the more public areas). (I can be more specific if I understood your full picture, but hopefully this help)


          Is it that you don't want them to see the other stuff or is it to avoid cluttering their view?

          1 person found this helpful
            • Re: Setting Up Client Users with limited views

              We do this quite a bit in two ways. One is as Kara describes and it is very manual if the group changes much. IOW, you create a User Group in the admin console, then allow that group access to a space/sub-space as you see fit. Couple drawbacks: if this group morphs frequently, you or whoever who assign to have limited admin rights to Manage Groups needs to go in and add them when they join the comms (in our case, they have to log in once to be able to be found in the Jive member tables), or you remove them when they are no longer part of the group. Tedious and not a very efficient process. The other way we set ours up is we have SSO with our ldap. Way back when we first started using Jive, one of my colleagues was smart enough to set it so at log in one of the parameters in our ldap is ‘supportype.’ So when they log in for first time, if they are on current support, they are automatically added to the permission group of active support customers. If declined, automatically added to that group, and so on. So when I set a comm up, I just need to allow access to the active support customers group. Make sense?


              BTW – our primary use of social groups is internal. There are limitations with Jive in this respect if one uses an outside authentication like we do. You can’t, for example, invite anyone to join a social group without changing a setting in the console that basically makes toe comms unfindable by search.

              1 person found this helpful
            • Re: Setting Up Client Users with limited views
              Billy Volpone

              Agree with Kara's comment but would encourage you to also consider leveraging social groups on the front end specific to non-product related use cases (like user groups or events, etc). There are other great uses for groups, separate from the far more controllable spaces, and our strategy teams would be more than happy to chime in around best practices.