Gemini Community Support Site

This Gemini community support site can be used to find solutions to product issues. You can log in using Open Id, Google Profile and even Facebook. Feel free to ask a question or browse FAQs and documentation. Product tour videos are also available along with how-to videos demonstrating key Gemini capabilities.




Restriciting Visibility

web-app

Is there any way to restrict visibility at the PROJECT level so only certain projects appear to certain users?  I thought the Project Groups would resolve this, but it didn't and I can't locate it in the user guide.

Thanks!

englea
· 1
englea
Replies (6)
helpful
0
not helpful

You need to give user "view project" permissions only for the projects they can "see".

Make sure you set the "View All Projects" setting to "NO" under Security -> General


Saar Cohen
· 5000
Saar Cohen
helpful
0
not helpful

[quote user="SaarCohen"]

You need to give user "view project" permissions only for the projects they can "see".

[/quote]

 

And....where do I do that?  It's not under the user permissions, or project administration (that I can see).

Thanks!


englea
· 1
englea
helpful
0
not helpful

it is under the security scheme


Mark Wing
· 9108
Mark Wing
helpful
0
not helpful

so, let me get this straight, see if I understand.  I have to develop a new security scheme for EACH project, just so I can turn off visibility to a handful of developers?

Shouldn't this be handled at the PROJECT level?  Get a list of users attached to project based on the development security scheme (in our case, the 4 original global groups + 2 more), and then just turn off visibility to NON-ASSIGNED users.

Not ALL application developers in the application developers group work on ALL the projects.  See?

So, by the current theory, if I understand correctly, I have to create an Application Developers Project B group, Application Developers Project A group, etc, and then assign them to the security scheme so the developers on Project B don't see Project A's projects and vice versa.

That's a load of you know what...  Unless I'm not understanding 100%.  And let's face facts, I've had to deduce a lot from the minimal answers I'm receiving on this "support" forum.

Thanks.  Not sure if our enterprise is going to consider Gemini now.


englea
· 1
englea
helpful
0
not helpful

Not quite correct (assuming I understand your scenario).

1. Create Project Groups that reflect how you work/organise (Project Leads, Developers, Testers, etc.)
2. Create ONE Security Scheme.
3. Allocate appropriate permissions/roles within the SINGLE Security Scheme to your Project Groups.
4. Go to each Project and define the members for the Project Groups (e.g. Bob is part of "Developer " Project Group for this project).

Two points:

1. Use Gemini 3.0.4.
2. Gemini 3.1 (ships next week) simplifies step 4 by centralising this administration task for all Projects.

I hope I have understood your requirement and indeed provided a satisfactory, actionable response!






Harvey Kandola
· 212
Harvey Kandola
helpful
0
not helpful

Thanks Harvey!  I'll follow that, see what happens.  Finally, a response that's more than three words, and some text that actually explains the use of Project Groups.  Sorry if I seem a little dry/harsh.  I seem to be getting short answer one word responses on just about every forum I post to and it's getting pretty annoying.

Am using Gemini 3.0.4.  Looking forward to the new features of 3.1.

Thanks again for your input!


englea
· 1
englea