![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Access Rights at project, module and attribute levels Topic Summary: DXL program does not correctly display access rights Created On: 19-Jan-2005 21:56 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: Your second "for ar in ad do" needs to be changed to "for ar in values(ad) do". See page 336 v71 DXL manual, chapter "Access Controls". - Louie | |
![]() |
|
Hello,
I am writing a DXL that examines all of our projects' access rights at the project, module and attribute levels. The reason I am writing this is because we have large projects that control access down to the individual attribute. Rather than having to look at every single attribute in every module of the project when they need to change access rights, I wrote this DXL to examine the access rights and indicate whether they are inherited or not; if they are not, the program attempts to display what the access rights are. It works except for two problems. 1)It does not display the project-level access rights if they are inherited; it displays them fine if they are not inherited. 2) At the attribute level, if an attribute's definition access rights are inherited and the value access rights are not inherited, it does not display the access rights for value. Be careful if you run this DXL on your system. It will examine every project your user account has access to which could take some time. You will notice at the beginning of the DXL, there is code that generates a "USER_TYPES.txt" file that lists all users' types and a "GROUP_MEMBERSHIPS.TXT" file that lists all group memberships. Any advice or solutions would be greatly appreciated. Thanks, Tim |
|
![]() |
|
![]() |
|
try...
for ar in all p do { instead of... for ar in p do { otherwise inherited aren't returned. |
|
![]() |
|
![]() |
|
Ross,
Thank you for your posting. Implementing your fix resulted in the DXL not having the two problems listed above. However, my DXL is still having two issues. 1) If an attribute's Definition access rights are inherited but its Value access rights are not, it correcty indicates that the Value access rights are not inherited, but instead of displaying what the value access rights are, it displays the inherited access rights. (e.g. If the value access rights are set to RMCD, it displays RMCDA which is what the access rights would be in they were inherited.) 2) If both Definition and Value access rights are not inherited, it correctly indicates that both access rights are not inherited, but it displays the access rights for Definition for both Definition and Value. (I think these problems are actually the same problem.) Any help you could provide would be greatly appreciated! Thanks, Tim |
|
![]() |
|
![]() |
|
Your second "for ar in ad do" needs to be changed to "for ar in values(ad) do". See page 336 v71 DXL manual, chapter "Access Controls".
- Louie |
|
![]() |
|
![]() |
|
Louie,
Thanks for your posting. Implementing your solution, my DXL works perfectly. -Tim |
|
![]() |
|
![]() |
|
Timothy Perry, thanks for sharing your DXL.
Can anyone tell me, What is the difference between:
Definition and Value access rights
Setting one does not change the other. They are indepedent settings.
I may have need to set access rights at the attribute level, so I am trying to learn more about them.
Regards,
Richard
|
|
![]() |
|
![]() |
|
Every attribute has a definition in a module, and applying access rights to it is usually done so that users do not delete or change the definition.
Assigning access rights to the the value portion of an attribute is usually done to control who can read or modify the data values assigned to that attribute for each object. ------------------------- Michael Sutherland michael@galactic-solutions.com http://galactic-solutions.com |
|
![]() |
|
![]() |
|
Yes. Some with "D" rights to a user created attr DEF can "D"elete that attribute completely from the module. Someone with "M" rights to an attr VALUE can "M"odify the values of that attribute for some object. Not sure what "C" or "D" rights means to VALUEs.
Someone with "A" rights to a DEF can change other's rights to the DEF; specifically who is allowed to delete it. Someone with "A" rights to the VALUES can change other's rights to modify the values. The attr TYPE rights are similar to attr DEF rights: with "D" you can delete an attr type (so long as its not being used by some DEF). 3 sorts of attr access rights. Pretty confusing. There is also object, view, and module rights for a total of 6 different access rights associated with a module. - Louie |
|
![]() |
|
![]() |
|
Did "Ross" make a non-fourm response? I don't see anything posted by a "Ross". I would like to see the two corrections.
|
|
![]() |
|
![]() |
|
Can someone please post the updated code?
|
|
![]() |
|
![]() |
|
I am in the same boat as Kirk and Al, I don't see any posting that includes the corrected script for this. I could spend a few hours trying to fix the original, but it would be appreciated if the fixed version could be made available here, since it represents the ultimate solution to the problem. It looks exactly like what I presently need for a similar task I'm confronted with.
thanks,
Chris
|
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.