![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Limiting access to attributes Topic Summary: Created On: 5-Dec-2007 18:19 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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! |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Limiting access to attributes
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.