![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Partitions - objects are locked Topic Summary: Created On: 12-May-2004 14:39 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: I'm guessing but suspect your home objects have specific access rights that are NOT cleared when they get to the away DB. They can resolve this by logging on as the Administrator and clearing all the shared sections. - Louie | |
![]() |
|
Hi,
My problem is this. I partitioned a couple of modules with module access at RMCDA for administrators and RMDC for users. The away database is saying that some of these objects are locked and no one has write access. I only have read access and cannot find the problem in my modules at home database. Does anyone know what is making this happen? It is not happening to all the modules just to a couple. Mary ![]() |
|
![]() |
|
![]() |
|
I'm guessing but suspect your home objects have specific access rights that are NOT cleared when they get to the away DB. They can resolve this by logging on as the Administrator and clearing all the shared sections.
- Louie |
|
![]() |
|
![]() |
|
Louie,
Thanks for the input. I think these are locks but the access levels were set at home with the list of user names etc provided by the away database. The user do not seem to have the prvileges set by the home?? For now, we are working around with archives until we can figure out what is wrong with the modules that are partially locked. Mary |
|
![]() |
|
![]() |
|
Internally the AccessRecords do not remember the user/group name they remember the user/group internal ID. So if you give "Joe" sole access to something then really user "24F" has sole access. When it gets to the away database then user "24F" in THAT db is the one who has sole access, whoever that is if it exists, and "Joe" in the away database has no special privaledge. If user 24F doesn't exist then NOBODY can get at it (accept the Administrator). I hate it when that happens.
Module and Object specific rights are cleared to Inherited when a module is archived-restored, but the Attr Def/Val/Type and views are NOT. Don't know how accepting a partition works. - Louie |
|
![]() |
|
![]() |
|
Louie,
Are you saying that the names that we assign these privleges to are just masked for an internal code? Also when you refer to the Administrator, are you say "Administrator" and not just someone with the Administrator privleges? Thanks Mary |
|
![]() |
|
![]() |
|
When you say give "Joe" RMCD specific access to something then DOORS stores an Access Record featuring Joe's unique user ID , say 24F, along with "RMCD". It does Not store "Joe". If you rename user "Joe" to "Joey" then "Joey" has RMCD access. If you delete user "Joey" then these access records are automatically deleted the next time the thing is opened: the system knows that there is no longer any user 24F.
When you archive such a thing and restore it in some other DB, then user 24F has RMCD access. Attibute Type/Def/Value and View Access records exhibit this "feature". Module and Object rights are set to Inherited when archived. When I say "Administrator" I mean that single can-do-anything user; not just a normal user who is a DB Administrator. That's required since that user is the only one guranteed to actually SEE and EDIT everything and has the ability to set Inherited all those corrupted Access Rights. - Louie |
|
![]() |
Telelogic DOORS
» Administration
»
Partitions - objects are locked
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.