![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Sharing levels removed Topic Summary: Created On: 28-Nov-2006 17:01 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I'm curious if this has happened to anyone else. We had two different DOORS v7.1 databases running with different projects. The second database was necessary because it was a joint venture with another company and we only wanted them to have access to the project that we were joint ventured with. Well now the other company has backed out and it was decided to move the project from this stand alone database to the main database. So I did an archive/restore to move it. I used this method becaue I do not have access to the server level files to move it from the backside.
Anyway, we have discovered that after the restore, all sharing settings have been removed. Most of the modules had share levels set at 3 or 4, but now all of them are gone. So I am now going through and resetting the share levels in all the modules of that project. Has anyone else experienced this or know how to keep this from happening in the future? Thanks. ------------------------- Matt Herald Systems Engineering Tools Administrator ITT Corporation - Communications Systems Fort Wayne, IN |
|
![]() |
|
![]() |
|
When you define an object as a shared section you are really just removing its 'inherited' rights and giving it 'specific' rights. The initial specific rights will be identical to the inherited rights so you will see no access differences. (I digress: if you change the module rights such as take away someone's access, then that someone still has access to the object...).
Anyway, specific rights mean a user or group has some sort of access. Storing the access rights is easy, some form of "RMCDA". Storing the 'user or group' part does not involve storing the name, it means storing the user or group internally assigned ID. (I digress: if the name was stored and then you changed the name of a user, that user would lose access. Worse yet if you deleted the user and then recreated the user with the same name, the new user would have access). Now if you archive such a module and restore it in some other database, the user IDs won't match up. If user "DBAdmin" ID 00123 has access in the source database then user "00123", whoever that is, has that access in the target database. Typically there is no such user. Often such a restore would result in nobody having access to the object. See the problem? DOORS decided, rightfully, that archives will have their Module and Object specific rights removed and replaced with Inherited rights. When its restored then the module 'inherits' whatever rights exist for the folder, and that usually works fine. The real mistake was associating 'shared sections' with 'specific rights'. DOORS should have an additional flag for an object that says whether or not it heads a shared section. (I digress: In a gross oversight, DOORS failed to reset the accesses for Views, Attr Defs, Attr Values, and AttrTypes in archives. When restored, those with specific rights are all hosed up. I wrote a script to fix all that when archiving. I don't know if this oversight has been fixed in DOORS v8.1 or not; it still fails in DOORS v7.1). - Louie |
|
![]() |
Telelogic DOORS
» General Discussion
»
Sharing levels removed
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.