![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: List Groups and Remove Groups from Module Level Topic Summary: Created On: 7-May-2008 19:09 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I know how to list access to objects , attributes, etc from within a module. However, how can I do this from the module level?
For example, here is some sample code I have. However, it doesn't remove remove all the access from the module at the module level. ------------------------- pete.kowalski(at)motorola.com |
|
![]() |
|
![]() |
|
I think you are looking for the 'inherited' perm, in this case setting the module's access to Inherited (from its parent folder).
Module mCurr = current string ErrMess = inherited(mCurr) - Louie |
|
![]() |
|
![]() |
|
Thanks Louie.
I had code before that did what I wanted to do, but I can't find it, and I vaguely remmeber how I did this before. Basically, what I want to do is this. 1) From database level look at a module 2) Turn off inheritance of that module from the module level 3) Read all the Groups and Users assigned to that module from assigned at the module level 4) Remove certain Groups and Users from the module at the module level I looked through the DXL manual again and here is some new code I managed to hack together. Code currently tells me if the module has inheritance turn on or off from the module level. EDIT: Just updated my attached code sample to remove the user "pete" from the module at the module level. ------------------------- pete.kowalski(at)motorola.com Edited: 8-May-2008 at 17:53 by Pete Kowalski |
|
![]() |
|
![]() |
|
So 'set' creates an AR and 'unset' removes an AR.
Odd that 'unset' works on a 'Read' module, but the 'set' commands require module to be open 'Edit'. - Louie |
|
![]() |
|
![]() |
|
Yes, Louie this is indeed odd.
Attached is my alomst finalized script. However, when I run it in DOORS 7.1 and DOORS 8.3 it crashes DOORS. Well, it results in an DXL error message and the lovely, but arcanic DOORS Diagnost Log Window to appear. In DOORS 8.3, the DXL error message given is this -I- DXL: execution halted Line 60 is this line: for a in m do The Diagnostic Log is DOORS: **** Translating a structured exception **** DOORS: Version 8.3.0.1, build number 83124, built on Dec 11 2007 12:38:44. DOORS: Server Service Pack 1 (Build 3790) DOORS: DOORS: 47 percent of memory is in use. DOORS: There are 4194303 total Kbytes of physical memory. DOORS: There are 3318788 free Kbytes of physical memory. DOORS: There are 4194303 total Kbytes of paging file. DOORS: There are 4194303 free Kbytes of paging file. DOORS: There are 1fff80 total Kbytes of virtual memory. DOORS: There are 1d7dfc free Kbytes of virtual memory. DOORS: argv[0]: D:\Program Files\Telelogic\DOORS_8.3\bin\doors.exe DOORS: argv[1]: -d DOORS: doors.exe caused an EXCEPTION_ACCESS_VIOLATION in module doors.exe at 0023:005A6F13 DOORS: 0023:005A6F13 (0x002DF6CC 0x053003E0 0x075DB3D0 0x002DF758) doors.exe DOORS: 0023:007BF9EC (0x00000000 0x00000000 0x00000000 0x00000000) doors.exe DOORS: **** end of event **** DOORS: **** Translating a structured exception **** DOORS: Version 8.3.0.1, build number 83124, built on Dec 11 2007 12:38:44. DOORS: Server Service Pack 1 (Build 3790) DOORS: DOORS: 42 percent of memory is in use. DOORS: There are 4194303 total Kbytes of physical memory. DOORS: There are 3629160 free Kbytes of physical memory. DOORS: There are 4194303 total Kbytes of paging file. DOORS: There are 4194303 free Kbytes of paging file. DOORS: There are 1fff80 total Kbytes of virtual memory. DOORS: There are 1d82fc free Kbytes of virtual memory. DOORS: argv[0]: D:\Program Files\Telelogic\DOORS_8.3\bin\doors.exe DOORS: argv[1]: -d DOORS: doors.exe caused an EXCEPTION_ACCESS_VIOLATION in module doors.exe at 0023:005A6F13 DOORS: 0023:005A6F13 (0x002DF6CC 0x053238B0 0x075E1408 0x002DF758) doors.exe DOORS: 0023:007BF9EC (0x00000000 0x00000000 0x00000000 0x00000000) doors.exe DOORS: **** end of event **** ------------------------- pete.kowalski(at)motorola.com Edited: 8-May-2008 at 21:27 by Pete Kowalski |
|
![]() |
|
![]() |
|
The unset removes an AR. You are doing that within the loop for ARs for the module. That messes up the loop for the same reasons deleting a link inside a link loop will mess up.
Stage the ARs in a skip list, then plow through the list: Skip skpARs = create // KEY: 'int' sequencer; DATA: 'AccessRec' int Sequencer = 0 for a in m do { put(skpARs, Sequencer++, a) } for a in skpARs do // This is your line 60 { ... } Notice the Sequencer insures that the ARs are retrieved in the same order as the original loop, for whatever that's worth. - Louie |
|
![]() |
|
![]() |
|
Thanks Louie. That was it. I can post my final code for those who are interested. I thought I did this... sorry.
------------------------- pete.kowalski(at)motorola.com |
|
![]() |
|
![]() |
|
Louie,
the code -----------cut from here --------------------- Skip sk = create int iSk = 0 AccessRec ar string sUser for ar in current Module do { put(sk, iSk, ar) iSk++ sUser = username(ar) print ">>" iSk ", " sUser "\n" } for ar in sk do { sUser = username(ar) iSk = (int key sk) print "<<" iSk ", " sUser "\n" } -----------cut until here --------------------- results in -----------cut from here --------------------- >>1, >>2, HEK >>3, Admins >>4, testproject_PL >>5, testproject_DEVEL >>6, testproject_RVWR >>0, >>1, >>2, >>3, >>4, >>5, -----------cut until here --------------------- so your solution seems not to work. Any suggenstions? HEK |
|
![]() |
|
![]() |
|
Your iSK++ should go below the print statement, but that's not the problem.
Wow, am getting the same thing. Perhaps an AccessRec is like a History where assigning it makes an alias, doesn't assign the value. You can embed the 'for ar in mod' loop inside a 'while' loop, where the while loop keeps looping as long as an AR was deleted inside the inner loop, and the inner loop, when it deletes an AR, sets the flag and aborts the loop. Looks like attached. - Louie |
|
![]() |
|
![]() |
|
Louie,
this does not really help: I also want to change access rights to a module using the code for ar in current Module { string sUser = username(ar) set(current Module, sUser, read) } The storage or retrieval of ar's to/from the skiplist seems to change the ar's. So we have the situation: - usernames of ar's stored in skiplists cannot be retrieved - the do-loop statement causes a null pointer reference, after(!) 1st loop Also the statement for ar in all current seems not to make any difference Any suggestions? Edited: 17-Jun-2008 at 09:53 by Hans-Edgar Koechling |
|
![]() |
|
![]() |
|
With Louie's assistance before he is the final version of the code that does what you want Hans. Reply back to this post or send me an email if you have further problems.
------------------------- pete.kowalski(at)motorola.com |
|
![]() |
|
![]() |
|
Hi, Pete.
What I want is, on a module to - set access rights 'read' for all users, who have any access right - set access rights 'read|modify|create|access' to one user group - set access rights 'read|modify|create|delete' to another user group. Last two items are simple, but first item does not work using AccessRec ar for ar in current Module { string sUser = username(ar) set(current Module, sUser, read) } --> leads to null-pointer reference or Skip sk = create int iSk = 0 AccessRec ar string sUser for ar in current Module do { put(sk, iSk, ar) } for ar in sk do { sUser = username(ar) set current Module, sUser, read } --> sUser is always empty HEK |
|
![]() |
|
![]() |
|
HEK,
You still having issues with this? If so feel free to send me an email. ------------------------- pete.kowalski(at)motorola.com |
|
![]() |
|
![]() |
|
Hi, Pete.
Thanks for reply. I've raised two bug reports. Results: My workaround: - storage and retrieval of username(ar) into a skip list - check for null-pointer reference HEK |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.