![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Migrated modules (5.0 - 7.1) can't accept changes Topic Summary: Legacy migrated database - some modules can't be edited Created On: 24-May-2005 18:46 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I have a DOORS project that started out back in version 5.x, was ported to 6 and now to 7.1. It used the CP system extensively.
To be able to use the CP system in 7.1 one of our admins had to remove the CP system and then install the one for 7.1. Two of the modules in the new CP system will not let the Change Manager edit it. Only person who can edit it is someone from the old system. Everyone can edit the modules migrated to 7.1 that are not under CP control EXCEPT for one of the modules under the old CP system. Users show as having full control and the objects are "inheriting from parent". Any ideas? |
|
![]() |
|
![]() |
|
You'll have to explain what "cannot edit" means. Does it mean you don't see the "open exclusive" command? Once open exclusive you cannot edit object values? Cannot modify Attr Defs?
If you cannot see the "open exclusive" command, try these [1] from the explorer, select the module and hit cntrl-E [2] When the module is open Read, edit DXL and run "setExclusive()". If these let you edit the module .... ... There was a DOORS bug that failed to display the exclusive commands in the menus. It has something to do with the order in which the Group accesses were displayed. Even though the user had RMCD rights, the algorithm that displayed the menus was incorrect. If you rearrange the groups such that the group with the most rights is last, IIRC this cleared up the menus. Some additional wild guesses: [] you've got some sort of "propagate additional rights with Create access" issues. [] the project or CPS folder has odd Specific access rights. [] You've got disabled groups The more I think about it ... when you "ported" you din't migrate the date, your archived your v6 project and restored it in a v7 database or Somewhere along the way you restored a User Archive; either of these would destroying all your access rights and will cause the Change Proposal Users module to reflect rediculous data, since its "sections" don't match up with their intended users. (TechnoBabble: CPS keeps track of stuff using the Unique IDs of users. When you restore a project into a different DB or when you Reload Users from another DB, the Unique IDs no longer match up. User "03ca" may have been "MyCPSAdmin" when you configured CPS, but after the restore user "03ca" may now be "MyComptetorsSpy", and user "MyCPSAdmin" may not be configured for CPS at all). Did you migrate the database, or did you restore the project? Try this: Start to reconfigure CPS and see which users IT thinks are configured. Be sure to cancel the reconfiguration. - Louie |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.