5 Replies Latest reply on Aug 19, 2019 5:19 PM by Jonathan Block

    How can you set custom access to a project?

    dazegar

      I (and we as an organisation) would like to make effective use of the projects element of JIVE but we have a major problem.  No matter what I try or where I create a project I have no way of setting access permissions.  Surely this cannot be correct and there must be some way to do this?

       

      Help please.

        • Re: How can you set custom access to a project?
          Stuart McIntyre

          Hi Gareth,

           

          Projects will always take on the security model, membership and permissions of the place that they are created within. So if a project resides within a space, it will use the permissions of the space as defined in the admin consoled. If added to a group, it will have the same access model (open, members only, private etc) and the same membership as the group.

           

          Hopefully that makes some sense?

           

          You can find more information in the Help documentation.

          2 people found this helpful
            • Re: How can you set custom access to a project?
              dazegar

              Thanks Stuart - that makes sense in the respect that I understand the process.  Unfortunately it doesn't make sense in terms of functionality.  With a sub-space you can sever the inheritance.  If I want to use JIVE for projects then I will have to create a new space/sub-space with the correct permissions and then the project within that space.  Potentially very messy.

               

                • Re: How can you set custom access to a project?
                  Stuart McIntyre

                  That could be necessary as you suggest, Gareth.

                   

                  However, the question would be whether you need to lock down the project beyond the permissions that you have set in the parent space or group? I know that's the traditional approach with file-shares and other types of systems, where each project or team would have it's own private area out of view of the rest of the department or organisation. As a Jive community manager I'd always encourage that these kinds of places get opened up to allow more colleagues to observe, learn and participate wherever possible. Therefore, for example, having one PMO space with many projects within that all have the same visibility is a way that you might encourage more participation/engagement, and thus increase the likelihood of serendipitous sharing and knowledge transfer, versus having a separate membership list for each project...

                   

                  There's definitely multiple approaches to this, and customers can use combinations of groups, spaces and projects to create the model that works best for them. But that's the rationale behind the model (at least in my understanding) - more openness and fewer restrictions leads to more collaboration.

                    • Re: How can you set custom access to a project?
                      dazegar

                      I agree entirely and as a community manager myself the openness and full possibility for sharing and collaboration is something my team and i push for every day.  There are times however where a more limited audience in specific areas is necessary to begin with.  As much as is possible I'm just trying to avoid multiple platforms for the same thing whilst taking advantage of everything that JIVE can give us.

                       

                      I guess this is one area where I'm going to need to apply some compromises.

                       

                      Thanks for the comments!

                    • Re: How can you set custom access to a project?
                      Jonathan Block

                      We ended up turning off Project places for this reason, among others.  Around the time of the Aurea acquisition, Jive (or maybe it was already Aurea) announced that their roadmap included collapsing the three different place types (Space, Group, Project) into one.  There was also a sense that the new unified place type could somehow use any of the features of the existing types, including their varied approaches to permissions.  In the time since then, Aurea's been sufficiently buried in bugfixes and damage control, plus whatever background work they're doing on the PeopleGraph concept, that I don't think this concept has moved forward very much.  It would be nice to see it happen, but I'm not holding my breath.

                      1 person found this helpful