![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: 2 Different Databases, 2 Different Admins, Same Server Topic Summary: Created On: 29-Jan-2003 19:22 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Is it possible to have 2 separate database "roots", with different Administrators for each on the same clients/server?
|
|
![]() |
|
![]() |
|
There is no problem with Clients accessing different databases. You can override the default "-data" environment variable by putting the "-d <location>" statement in the DOORS icon; as per "Summary of command line switches" in the Help.
There is no problem with different users being Administrators of different databases. The problem would be having two DOORS databases on the same server. I'm a bit ignorant about all this, but I don't think it can be done. The server will have to have two DOORS "services" set up, each with a different ID (perhaps "36677" and "36678") and, of course, different folder paths. If you CAN do that, then you are home free. This should be a simple question for your server administrator. To access the 2nd, clients would have icons that say "doors.exe -d 36678@Server". You can certainly have different databases on different servers. A client's icon may say [1] "doors.exe -d 36677@server1" and another icon that says "doors.exe -d 36677@server2". If you succeed, I'd be tempted to rename each Database (from within DOORS) from "DOORS Database" to some meaningful title that includes the server's name, like "DOORS on Server1". - Louie |
|
![]() |
|
![]() |
|
Richard,
Depending on what you are trying to accomplish, you can set up one DOORS database, and create two Project folders (A and B) directly below the database root. You can then use access rights and groups to make it seem to group A that their project folder is the only folder in the Database, and to group B that their project folder is the only folder in the database. Then, assign a user (or two) from each group to be "Database Manager" for each folder, so the all-powerful "Administrator" (root) user does not have to administer Access rights below the highest level for each project. The only issues I recall that were not ideal with this situation are: (1) In previous versions of DOORS, a "Database Manager" could add and subtract members to ANY user group. I believe this can be fixed in DOORS 6.0 or DOORS 6.0 SR1 by applying access rights to the groups themselves, which could not be done in DOORS v5.x. (2) If the user is in "View->Project View", they will see the name of both projects, and any sub-projects in both project folders, although access rights will prevent the actual access of any data below the project folders. Using actual folders instead of the special project folder could solve this, although when I implemented this I used project folders at the highest level to allow an Archive of each project to be created independent of the other. ------------------------- Michael Sutherland michael@galactic-solutions.com http://galactic-solutions.com |
|
![]() |
|
![]() |
|
Michael's solution has the following features that, if I understand this correctly, conflict with the original desires:
[1] A single user could not get at both projects. Such a user would need to have two DOORS accounts, user-1 and user-2, each having access to a different project. [2] All "Database" administrators would have full access to Manage Users, and could, even without any Read access to the other Project, modify that project's users. Using "Project Managers" (instead of "Database Managers" would not allow such a special user to create/modify users, but he could manage his projects various user groups to grant/deny users access to his project. You would still need some trusted "Database" manager to oversee the entire database, its users, and both projects. [3] Whatever reason you have for wanting these databases separate CAN, relatively easily, be circumvented by just about ANY user in either project. Give Joe-Standard-User access to the project, and he can steal access (or worse) to anywhere in the database. - Louie |
|
![]() |
|
![]() |
|
[1] A single user could not get at both projects. Such a user would need to have two DOORS accounts, user-1 and user-2, each having access to a different project.
- Not correct. If a user needs access to both projects, they are added to the appropriate access rights group for both projects. [2] All "Database" administrators would have full access to Manage Users, and could, even without any Read access to the other Project, modify that project's users. Using "Project Managers" (instead of "Database Managers" would not allow such a special user to create/modify users, but he could manage his projects various user groups to grant/deny users access to his project. You would still need some trusted "Database" manager to oversee the entire database, its users, and both projects. - You are correct, there may be a problem if the DB administrator for group "A" can delete users from the database that are not in his group. I'm not sure if there is a way to prevent this, beyond not granting the "Manage Users" power to the group managers. [3] Whatever reason you have for wanting these databases separate CAN, relatively easily, be circumvented by just about ANY user in either project. Give Joe-Standard-User access to the project, and he can steal access (or worse) to anywhere in the database. Please clairify. I've been fairly satisfied by the ability of DOORS to apply access rights to prevent such scenarios, expecially with the changes in DOORS 6.0. Do you have a specific scenario in mind beyond the ones covered above? ------------------------- Michael Sutherland michael@galactic-solutions.com http://galactic-solutions.com |
|
![]() |
|
![]() |
|
(1) In previous versions of DOORS, a "Database Manager" could add and subtract members to ANY user group. I believe this can be fixed in DOORS 6.0 or DOORS 6.0 SR1 by applying access rights to the groups themselves, which could not be done in DOORS v5.x.
- I do this in version 5.2 currently where I have database managers for different projects. Each manager can admin different groups however this does not prevent them from creating new groups. The purpose of having them as a database manager is they can clear dead locks, create users, new projects, archive, manage the change proposals and permissions for their projects (2) If the user is in "View->Project View", they will see the name of both projects, and any sub-projects in both project folders, although access rights will prevent the actual access of any data below the project folders. Using actual folders instead of the special project folder could solve this, although when I implemented this I used project folders at the highest level to allow an Archive of each project to be created independent of the other. - Yes this creates yet another interesting workaround. I currently have two seperate databases installed. One for V 5.x and one for V 6.x. I could have this because they are different versions, since one uses a doors.ini file to point to the data and one uses the registry. In this case each could just run on a seperate port and they would be two seperate user databases. I do agree with everyone in this case. One one hand having one database makes admin of it more complex but is doable. Having two seperate databases makes managing users and admins more complex but resolves issues of an admin not deleting another admins users. I am going to try an experiment with two seperate V 6.x databases on one machine. I'll let you all know if it works. I could make sense if you want a production and development database and have only one server. Vince |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.