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: Limiting access to attributes
Topic Summary:
Created On: 5-Dec-2007 18:19
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.
 5-Dec-2007 18:19
User is offline View Users Profile Print this message


Kevin Tarling

Posts: 9
Joined: 8-Nov-2006

Does anyone have any ideas on a method of preventing a set of users from editing an attribute without locking out the access rights of other attributes in the object and other objects in the module. Would have liked to use a trigger but cannot find a way of getting the attribute about to be editted, without already editting it. Or can you roll back an edit?

Thought was to:

Check flag for object ( = limited attribute access)
Check user
check attribute ( is now limited access)
prevent change!!!! if user not allowed

A number of people are accessing the module with the data within the module at difference levels of maturity

Triggers have been a pain to get right. The open trigger not giving the attribute details and the attribute edit trigger not preventing change!

I might have got it all wrong

Any thoughts,

Thanks

Kevin Tarling
Report this to a Moderator Report this to a Moderator
 5-Dec-2007 20:49
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

You can restrict the access to the Attribute 'values' as you see fit; probably providing 'Everyone else' just 'R' access, and providing a particular group or two 'RMCD' access. Users's won't be able to change that value.

If you go the 'the way of the Trigger', then you would need a pre-save-attribute trigger, that does checks as you see fit and either [1] set(trigPreConPass) to allow the change, or [2] set(trigPreConFail) to disallow the save. Within the Trigger you will want some code like this:
Trigger tCurr = current
AttrDef ad = attrDef(trg)
Object oCurr = object(trg) // I THINK, this is the object about to be changed
string NameAttr = ad.name // Name of attribute being changed
string Value = value(trg) // oCurr.NameAttr is about to get this value
User usr = find()
string NameUser = usr.name // Name of the current user

// Debug: print name(tCurr) "\tChanging:\t" (identifier(oCurr)) "." NameAttr "\n"

If this NameUser make changes to this oCurr.NameAttr
then set(preConPass)
else set(preConFail)

- Louie
Report this to a Moderator Report this to a Moderator
 21-Dec-2007 09:39
User is offline View Users Profile Print this message


Marcel van der Laan

Posts: 15
Joined: 21-Sep-2007

Hi Kevin,Louie,

I can confirm the Trigger story - the object(trg) does indeed get the object you are about to change. I use this to allow my DXL to lock certain attributes of certain objects (e.g. linked objects are no longer allowed to be changed, or objects with a certain status). Stuff like that. Works so far, in my experience.

I am facing a challenge though. I have an Object level attribute that contains the attributes that are locked (since in my case this may differ per object). This attribute is set by DXL script. However, to make this more secure, I would like to restrict access to this attribute itself. For example, I could make the trigger code refuse changes to this attribute, but that would cause a catch-22 situation: I would never be allowed to change that attribute again - locking myself out permanently. Right?

I can see a couple of scenario's and would like your opinions:

1. Make the attribute hidden. That would stop manual change, while still allowing acces by DXL, right? But change by DXL would still call the trigger code, so I should not lock myself out of hidden attributes...

2. Make the trigger code 'see' that it's my DXL programme making the change and setting trigPreConPass. Users not allowed to change the attribute by hand (hacking) but can still modify it in a controlled environment by DXL.

3. Remove trigger, modify attribute, apply trigger. By code, or by hand if you know the trigger...

4. Rename attribute, edit, rename back? Would this work?

Anyone come across such a situation? (FYI: client is v8.1)


Thanks,
Marcel


PS: To all - happy holidays!
Report this to a Moderator Report this to a Moderator
 7-Jan-2008 20:31
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Some months ago I posted a clever 'TriggerState.dxl' or was it perhaps 'SetTriggerState.dxl' program that disabled triggers. You could use it to disable triggers, change the attr, then re-enable them. That's better than removing the trigger, change the attr, and re-deploy the trigger. You could also use the -T command line switch to disable triggers. Be advised that only DB admins may disable their triggers; triggers always run for Standard folks even when they try to disable them.

All recursive or circular code should be written to avoid any catch-22. In this case I'd be tempted to code the trigger such that it allows changes when the currrent user is the 'Administrator'; something like this:

if (doorsname == getAdministratorName())

Or perhaps let the Administrator or any DB admin make changes:

User uCurr = find(); if (uCurr.class == administrator or uCurr.class == databaseManager)

- Louie
Report this to a Moderator Report this to a Moderator
 8-Jan-2008 10:22
User is offline View Users Profile Print this message


Marcel van der Laan

Posts: 15
Joined: 21-Sep-2007

Hi Louie,

Thanks. It was indeed called TriggerState.dxl. I found the thread. As I see it, this method works only for priviliged users. this is not quite the case in my situation.

Basically it comes down to the fact that a user may not manually change the property in DOORS, but some of the scripts that are run by that same 'standard' user should be allowed to change that property.

Since the locking trigger code is of my own hand, so to speak, I could modify it to see whether some 'disable' variable has been set by the script before a modification is done. After the modification, this variable should be reset, obviously.

Can I do it this way? Can I share variables somehow between a standard script and a trigger-script?

Perhaps checking whether the user running the script is the same as the user trying to modify the property could make this solution even more secure...


Marcel
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 2 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 2 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.