Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
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
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
Answer This question was answered by Louie Landale, on Monday, January 24, 2005 1:04 PM

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
 19-Jan-2005 21:56
User is offline View Users Profile Print this message


Tim Perry

Posts: 17
Joined: 31-Dec-2002

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
Report this to a Moderator Report this to a Moderator
 20-Jan-2005 10:42
User is offline View Users Profile Print this message


Ross Morgan

Posts: 74
Joined: 15-Apr-2004

try...
for ar in all p do {
instead of...
for ar in p do {

otherwise inherited aren't returned.
Report this to a Moderator Report this to a Moderator
 20-Jan-2005 13:59
User is offline View Users Profile Print this message


Tim Perry

Posts: 17
Joined: 31-Dec-2002

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
Report this to a Moderator Report this to a Moderator
 20-Jan-2005 22:45
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Answer 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
Report this to a Moderator Report this to a Moderator
 24-Jan-2005 13:03
User is offline View Users Profile Print this message


Tim Perry

Posts: 17
Joined: 31-Dec-2002

Louie,

Thanks for your posting. Implementing your solution, my DXL works perfectly.

-Tim
Report this to a Moderator Report this to a Moderator
 3-Feb-2005 14:12
User is offline View Users Profile Print this message


Richard Robledo

Posts: 1
Joined: 3-Feb-2005

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
Report this to a Moderator Report this to a Moderator
 3-Feb-2005 17:28
User is offline View Users Profile Print this message


Michael Sutherland

Posts: 248
Joined: 13-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 3-Feb-2005 18:21
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 23-Jun-2005 15:24
User is offline View Users Profile Print this message


Kirk Walker

Posts: 32
Joined: 18-Sep-2004

Did "Ross" make a non-fourm response? I don't see anything posted by a "Ross". I would like to see the two corrections.
Report this to a Moderator Report this to a Moderator
 30-Jul-2007 15:10
User is offline View Users Profile Print this message


Al Lione

Posts: 59
Joined: 13-Jul-2004

Can someone please post the updated code?
Report this to a Moderator Report this to a Moderator
 13-Sep-2007 16:17
User is offline View Users Profile Print this message


Chris Annal

Posts: 36
Joined: 14-Dec-2005

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
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.