Gemini User Permissions / Project Visibility 3.1.1
I have to start off by saying that I have enjoyed Gemini for many years. Especially it's elegant simplicity. I realize, however, that projects must evolve and stay competitive with other tools on the market. When I first installed 3.1.1 I was really excited with the great integration, new features and flexibility. However, when it comes to user permissions and security, I must have become a total idiot overnight ;) I have watched the web casts, read the manuals and I still don't get it completely.
I want to be able to have my user groups (just like I used to) and they should have default permissions (which they don't seem to). Then I simply want to say whether or not that user has access to a project or not. Then his default security will apply based on the group he is in.
Overrides to this would be nice, but unnecessary for most I would assume.
At this moment, I am pleading for someone to try to explain what is really going on here and why it is so labot intensive to get this thing configured and users able to work in their projects again. All the extra features in the world cannot make up for the complexity that I have found in this small section of the application.
Thank you in advance for anyone that may be able to show me the way. And I apologize for my rant, but I am completely frustrated right now.
Tim
tdemeza
· 1 |
|
Tuesday, January 27, 2009, 3:14:03 PM |
0
|
Hello, |
||||
|
0
|
Is there any documentation that descirbes how Project Groups and Global Groups relate to each other? I have created a security scheme that I was planning to apply to all of our IT projects. And I also created Global Groups that I assumed would work in some sort of hierarchy with the Project Groups (e.g. if you are a Developer in the Global group you are also a Develoer in the Project Group). I thought if a Developer was not in the Project Group, he/she would therefore not be able to create an issue for the project. But this does not seem to be the case. Do I have to choose between using Global Groups or Project Groups? I'm somewhat new to Gemini so maybe I'm missing something. - Barb |
||||
|
0
|
You can view the documentation here: http://countersoft.com/downloads/csfiles/CounterSoftGeminiv311_Documentation.zip But I suggest watching the webcasts: http://countersoft.com/webcasts/ Basicalliy users can be in both groups but project group is controlled per project. |
||||
|
0
|
Could you confirm that if I want to manage access by Project, on each project I have to replace my Global Security Scheme with a project-specific Security scheme? It also seems like if I have different users with different roles on different projects, I have to create different user groups by project. Am I missing something? |
||||
|
0
|
This is up to you. You can create one scheme per project or one scheme and use project groups to control access to that scheme. |
||||
|
0
|
Harvey, I have to say I appreciate you taking time to post a much more concise permissions structure. But, I guess I would like to ask if I can pay one of your staff to fix my mess. I can't seem to get anyone with the permissions that I expect. I wish there was a script or something that would have applied all permissions from 2.X to the new 3.1 structure. And maybe this did happen, but so far no one but myself (system admin) has been able to log in and see what I think they should see by default. This could be since I have a complete misunderstanding of the new permissions structure, or due to it's complexity (ie. flexibility). Anyway, I feel like I am stuck now, I have spent the last week solely working on permissions and trying to understand what is going on there and unfortunately I am still at a loss. So if it is possible to pay support to fix my mess it would be appreciated. I am afraid that I am going to have to scrap the system and start from scratch soon.
|
||||
|
0
|
We will be able to do this. Please send us the database and a spec for each user, what group they should be in and what can they do on each project. Send it to support at countersoft dot com |
||||
|
0
|
So, in other words, if I want to use a global scheme and use project groups to control access per project, then I have to create the following project groups for each project: DevelopersProjectA TestersProjectA Project managersProjectA DevelopersProjectB TestersProjectB Project managersProjectB ..and so on. Is this what you mean?
|
||||
|
0
|
No, you create one project group per user type: DevelopersProjectGroup TestersProjectGroup etc... Then give these groups the relevant permissions in the scheme. Now in each project you can assign users to these group (per project). Go to the project admin page (Project home -> admin) then click on Project Groups. Note that you have to assign the correct scheme to the project. |
||||
|
0
|
Mark, I really appreciate your response to do the setup for me, but I don't even know where to begin because I don't know if I need to start out by defining the permissons of the groups (which used to be predefined and maybe I messed this up). This is a daunting task for me. For a small installation this may be a reasonable security scheme. But I think you have totally lost me. The power of Gemini was in it's elegant simplicity. I absolutely love some of the new features in your software which is why I was so excited to upgrade. But the security model, although tremendously flexible, makes this completely unmanageble for me. I am soooooooo confused still. And my users are ready to kill me. Thank you for trying to dig me out of this hole, but I fear I am too far frustrated to continue messing with this. For now I will make all users administrators and see how that goes. In the mean time, I am looking for options and hopefully before I jump ship you will have some refinements in place that will clarify the process for folks like me. Thanks again, Tim
|
||||
|
0
|
ok, I did this, but when I logged in as a user that was not in my project group, and should therefore have no rights, I was able to create an issue. Theoretically, I should have not been able to do this since I was not in the Project Group for that project. I was using the Global scheme for which I had defined global groups as well as project groups. |
||||
|
0
|
Please log in as admin and check (via the users page) the groups and permissions that user has. It might be that the user belongs to another group that does have the create issue permission. |
||||
|
0
|
Here are my findings: The test user is Dev1 He is in the Global Group "Developers" which has access to Create Issues with a global Security Scheme "CompanyName IT Projects". The Security Scheme "CompanyName IT Projects" is assigned to "Gemini Upgrade Project" The Project Group for Gemini does not include him. So I was thinking he should therefore not be able to create an issue for that project. However, under User Permissions, all of the projects (including "Gemini Upgrade Project") which use the "CompanyName IT Projects" security scheme and its related global groups, and the defined permissions for "Developers" are listed. He is not listed as a member of "Gemini Upgrade Project" here. But he can still create an issue for that project. So does this mean his Global Group privileges override his Project Membership? I am using the same e-mail address for the Dev1 user as I am for my own Administrator user. Would this have an impact?
|
||||
|
0
|
email address will not have an impact. Basically, it's because he is in the developers global group, which has the create issue permission. We always give preference to what you are allowed to do as in your case. If you want to post here some high level details of what you are after, we can make this a sample for all to see how to configure security. |
||||
|
0
|
Here is what I am trying to accomplish - hope this helps: 1. Establish general permissions by user role. To do this I defined the following Global Groups and different permissions for each group in an overarching Security Scheme.
2. Restrict permissions/access to certain users by project while retaining the permissions defined in the Security Scheme for their Global Group. For example:
|
||||
|
0
|
Ok, the best way of doing this is by using project group instead of global groups. Create the project groups:
Create a security scheme and assign the relevant permissions to each project group. Then in project A (home page for the project) go to the admin section (top right) and click on Project Groups (left hand side). Now for each project group asssign the relevant users. eg. For Developers assign Joe Smith and Susie Swanson, for testers add John Doe. etc... Do the same for project B, but assign the other users. I hope this makes sense. |
||||
|
0
|
So what you're saying is I need to choose between using Global Groups and Project groups. The system really is not desigend to use both for the same user set. Right? |
||||
|
0
|
No, you can use both. But in your case projcet groups is the way to go.
|
||||
|