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: Attribute Access
Topic Summary: Restricting access to all attributes other than one
Created On: 2-May-2008 12:22
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.
 2-May-2008 12:22
User is offline View Users Profile Print this message


Gordon Woods

Posts: 35
Joined: 2-Mar-2007

I had a search through the forum but could not find an answer to the following problem.

We have a number of modules that we want to allow reviewers to add comments on objects but not modify anything else.
We have set up an attribute "Reviewer Comments". The reviewers (all belonging to a group) should only be able to add stuff to this attribute. We also want people to add comments in parallel, and not lock out the module for a long time. Not all of the modules are set up for shareable. I use a popup to get the comments, check that no-one else has exclusive, and then save downgrading back to Read only.

some possible solutions:
1. make the module Modify to the reviewers and then use a module level trigger to prevent a change to any attribute other than the "Reviewer Comments" by anyone in the reviewer group.
2. make the module Modify to the reviewers and then change all the other attributes to Read only. (but a pain to administrate)
3. make the module Modify to the reviewers and use a module level trigger on open to change to Read only mode for these reviewers.
4. disable opening in exclusive/shareable edit for the reviewers (but reviewers for one set of modules may be authors for another set)
5.temporarily give Modify access to a reviewer using dxl (but it seems that I can only do that if the person using the code has Admin - which is more than Modify -since to change the access rights for an attribute value, you must have Admin access to it ! )


Anyone know of a sneaky and easier way?

obviously the authors need to have full RMCD access as before. our default open mode is read only.


----------------

Gordon Woods
gordon.woods2@baesystems.com
Report this to a Moderator Report this to a Moderator
 6-May-2008 10:44
User is offline View Users Profile Print this message


Reik Schroeder

Posts: 361
Joined: 28-Jul-2003

Hi Gordon,

did you ever thought about linked review comments?
It would be much more comfortable to have the review comments within another module and link to requirements.
That could solve your problem easily because you are able to allow the reviewers to write to their comments module but not to module in review.

Greetings
Reik

-------------------------
Evosoft GmbH
for Siemens Industry Sector


Berlin, Germany
Report this to a Moderator Report this to a Moderator
 7-May-2008 18:39
User is offline View Users Profile Print this message


Gordon Woods

Posts: 35
Joined: 2-Mar-2007

Hi Reik

We had thought of that (and its a good solution) but we want the requirements and the comments in the same module since:
a) we need to send the module to our suppliers (we do not have eXchange yet) and b) we want to baseline and then clear the comments. We could use baseline sets of course and baseline the requirements and the comments together but it all becomes a bit more complicated.

incidentally your solution is roughly the way CPS works.



-------------
Gordon Woods
BAe Systems, Warton UK
Report this to a Moderator Report this to a Moderator
 8-May-2008 00:41
User is offline View Users Profile Print this message


Paul R Miller

Posts: 29
Joined: 16-Feb-2007

Hi Gordon,

Is your work environment such that you can't trust your reviewers not to modify the values of other attributes?

Rather than build a DXL like firewall around trying to capture the odd exception, is it a normal or exceptional case that your reviewers would mischievously alter attribute values that they have been instructed not to touch?

If it's vastly exceptional, then a combination of just Modify level access to the module and creating a specific view that displays the minimal set of columns required for them to see what they need to see and add their comments is possibly all you need.

Sometimes it's better to start from a position of trust before introducing potentially time consuming and over contraining DXL smarts to avoid exceptional events. Not withstanding the odd inadvertent user error (rare), if the work environment is such that users are unable to behave and cope with basic instructions, then I guess you have a business case to introduce the necessary protection mechanisms.

-------------------------
Paul Miller
Specification Practices Specialist
EuroCyber
Melbourne, Australia
Mobile: + 61 (0) 418 135 103
http://www.eurocyber.biz
Report this to a Moderator Report this to a Moderator
 14-May-2008 15:03
User is offline View Users Profile Print this message


Al Almoian

Posts: 30
Joined: 26-Oct-2007

Here is a different approach.
Create a new Level 1 section at the end of the module. (If module has paras 1 - 6 create Para 7 "Comments". Modify access rights for sections 1 - 6 to those allowed to make change. Give full access to section 7 to commenters. (This is probably less changes than modifying access rights to all attributes). Allow linking from section 7 comment to the subject object. Create a view which has the linked comment next to the subject object. Modify other views to filter out section 7.
Report this to a Moderator Report this to a Moderator
 16-May-2008 16:39
User is offline View Users Profile Print this message


Gordon Woods

Posts: 35
Joined: 2-Mar-2007

To reply to Pauls comments- we trust the users but unfortunately they do not trust themselves - the request came because we are moving them out of their comfort zone from using Word to using DOORS. Any change introduces some tension and they wanted some "padding" to ensure that they did not inadvertantly make a change.

Secondly, it is also too easy to make the odd "correction" and of course all our documents are under config control - currently not through DOORS but through an external configuration system. If someone makes an unconfigured change it can be impossible to spot and when the document is reproduced there may be all sorts of ramifications.

Thirdly we will be seeking comments from reviewers that should only be able to view specific objects or attributes - for security reasons. We had considered views but we would need to implement a full security model which has an overhead to administer.

No one would mischievously alter attributes - now would they?

Al Almoian's method would be entirely feasible but the approach we have now implemented is to use a dxl popup to capture the comments. This will be used for peer and stakeholder review comments. For post version 1 formal versions we will in the future be using Telelogic Change, which incidentally makes the module read only to all changes except via the approved change proposal system.

I can recommend this product for anyone considering implementing change control in DOORS.

----------------

Gordon Woods
gordon.woods2@baesystems.com
Report this to a Moderator Report this to a Moderator
 16-May-2008 22:44
User is offline View Users Profile Print this message


Uma Unnikrishnan

Posts: 5
Joined: 25-Feb-2008

Hi Gordon,

I didn't read all the posts, however the gist of what you want seems to be the same as the current set up in my project. We too have to send our comments and approval to our customer as module archives. I gave RM access to only the group that would be making these changes, then wrote a script that would change the access rights to all attributes other than the approval and comments attribute to read only.
Have attached the code.

Rgds,
Uma

Edited: 16-May-2008 at 22:48 by Uma Unnikrishnan
Report this to a Moderator Report this to a Moderator
 18-May-2008 08:52
User is offline View Users Profile Print this message


Paul R Miller

Posts: 29
Joined: 16-Feb-2007

Hi Gordon,

I understand your situation and have come across many users who are a bit nervous about using DOORS. Have the users you are talking about used Excel before? If these users are just doing basic data entry and don't need to create/delete/move objects, then a DOORS module really starts to look just like a glorified type of Excel workbook with many worksheets (aka Views to DOORS).

Sometimes describing DOORS modules as being a hybrid of a word processor and a spreadsheet can make new users feel a bit more at home - if this is possible then RM module level access combined with lock down of CM sensitive attributes and a dedicated View ought to do it. I'm not sure of the DXL approach can be made totally foolproof without a lot of smarts - although I'm sure Louie Landale (if he's watching this thread) might have something up his sleeve.

-------------------------
Paul Miller
Specification Practices Specialist
EuroCyber
Melbourne, Australia
Mobile: + 61 (0) 418 135 103
http://www.eurocyber.biz
Report this to a Moderator Report this to a Moderator
 9-Jun-2008 13:34
User is offline View Users Profile Print this message


Hazel Woodcock

Posts: 78
Joined: 6-May-2005

Gordon,

How about a separate review module as suggested by Reik, and then when you are ready to send this out do the following
create a traceablility column with the review comments
convert layout dxl to attribute dxl
copy values from attribute dxl column to a text attribute

... or any other scripted method to get that data into a text attribute.

Hazel
Report this to a Moderator Report this to a Moderator
 9-Jun-2008 18:37
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Perhaps provide the group RC access to the module, let objects and attributes inherit, but provide the group RMCD access to their attribute. It would be better to provide only R to the module but then they cannot open the module Edit. RC will let them create new objects and attributes, but won't let them modify the value of existing ones, such as Object Text.

- Louie
Report this to a Moderator Report this to a Moderator
 16-Jun-2008 13:05
User is offline View Users Profile Print this message


Hans-Edgar Koechling

Posts: 5
Joined: 20-Mar-2007

Gordon,

I have not t read all the posts...but, there exists a (quite complex) solution, where
a) same users are assigned to groups "Developer" and "Reviewer"
b) attributes to store review comments, review results (OK, NOK,...) and attributes(!) to be reviewed exists in one module
c) reviewers and developers are not able to change particular attributes during development, review phase, and release phase
d) the set of attributes (which store development contents, usually "Object Heading", "Object Text") can be changed dynamically,

To make it short:

The main design element for this solution is a trigger, which is raised every time one attributes of the set of attributes (development, review) is changed.
Second design element is, that a user, who has changed at least one of the developement attributes, is not allowed to change a review attribute, i.e., cannot perform a review on his/her "own" object.
Third design element are 2 attributes to store the development status (definition, review, release) and review result (null, open, OK, NOK)

Depending on the development status: development attributes may be changed (definition), or not (review, released); review attributes may be changed (review), or not (definition, released).

There are 2 main questions to be answered:
Q1) How does the trigger know, which attributes belong to the set of development and review attributes?

Answer: a) review attributes are well known, b) storage of development attributes is done using trigger names. The name of the trigger consists of 2 parts: a uniqe name and the name of the attribute he is assigned to. Now the trigger can check for all triggers, who have the same uniqe name and retreive the attributes from the complete name. Using this list, it can check, allow or deny changes to development and review attributes (incl. development status and review status).

Q2) How to handle recursive trigger calls to the same(!) trigger (setTriggerState_() does not work if you are not admin)?

Answer: Use of a (hidden) module attribute, which is always read and set, when the trigger starts or terminates. Only this attribute must have change access to developers and reviewers (which may compromis the trigger)

To be honest: The trigger code has more than 900 lines of code, i.e., a change of these attributes costs CPU resources.

Nevertheless: It supports
- check of ownership over a set of baselines
- concurrent development and review activities (not recommended)
- a finite developement-review state machine with 256 states and state transitions (19 allowed)
- serialisation of review comments into one attribute, so that only the last reviewer may change his last(!) comment
- users may be assigned simultaneously to reviewers and developers groups
- attributes can assigned to development attributes using one statement
- trigger code is completely stored in a string

HEK
Report this to a Moderator Report this to a Moderator
 23-Jul-2008 20:37
User is offline View Users Profile Print this message


Gordon Woods

Posts: 35
Joined: 2-Mar-2007

Thanks for all the responses - is there a rule that states -

Give 8 Requirement Engineers the same problem and you will get 8 different solutions.

If not, there should be...

incidentally we ended up with a dxl solution that now has them wanting version 2.


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