List usernames in enumeration attribute

Mathias Mamsch - Fri Apr 09 08:08:03 EDT 2010
While it is not a big deal to put all users to an enumerated attribute type, it is not always a good idea, since you would need to update that type all the time.

What exactly do you want to accomplish? If you want to put the name of the user to an attribute I suggest you create an attribute of type "User name" (built in type) and fill it automatically be a trigger or use a trigger to present a GUI to the user, which lets him choose a username.

Regards, Mathias

liamc - Mon Apr 12 10:11:38 EDT 2010
I want to assign a user to an object. The list of users should be chosen from all users within the database. Is there an easy way to do this using some sort of drop down menu?

liamc - Fri Apr 16 12:16:39 EDT 2010
I did wonder if it was going to be possible using dxl coupled with ennumeration, as it doesnt seem possible.

I will need the attribute to accept multiple usernames (as in the multi ennumeration). But i wanted to use DXL so i dont have to update the ennumeration everytime we add or remove a user from the system.

The idea of triggers sound interesting, i've not used them before. Is it possible to throw up a gui when you try to edit an attribute (with the basetype username). Then have the gui create a drop down menu of usernames? The problem i can see with this scheme is picking multiple users?

liamc - Fri Apr 16 12:16:39 EDT 2010
I did wonder if it was going to be possible using dxl coupled with ennumeration, as it doesnt seem possible.

I will need the attribute to accept multiple usernames (as in the multi ennumeration). But i wanted to use DXL so i dont have to update the ennumeration everytime we add or remove a user from the system.

The idea of triggers sound interesting, i've not used them before. Is it possible to throw up a gui when you try to edit an attribute (with the basetype username). Then have the gui create a drop down menu of usernames? The problem i can see with this scheme is picking multiple users?

GordonWoods - Tue Apr 20 05:40:01 EDT 2010
Liam

your concept is flawed. If you have leavers/starters you will need to update each enumeration in each module where it is used on a continuous basis. Admin nightmare.

We have over 800 users on our database - somewhat of a long list - and only a handful may be relevant.

You need to consider the information as a relationship between objects.
So create a stakeholder/organisation module. Structure it according to your organisation with departments etc so that you can easily find users. Make it read only except for the Admin staff. It is the responsibility of the Admin staff to maintain this list for new starters/leavers - not the requirement writers. You now have only one place to modify the list of users. And if required this can be automatically updated overnight from the DOORS user list by a DXL script. Note: For a leaver strikethrough their name - do not delete.

Then link from your requirement to the relevant person in the stakeholder module (note direction of link is to the stakeholder module).If more than one user then use more than one link.

Use a DXL attibute to display the user name(s) obtained from the target object(s).

As an added bonus you can see who "owns" what requirement - even when these are spread over many modules. You can also trace down the links from the stakeholder module to see what requirements are affected by changing owner etc etc.

You can provide a DXL script to provide a "user editor" but it is really very simple. All you have to do is create a link and the user name appears. Remove a link and the user name disappears. The magic of DOORS!

This principle should be applied to all enumerations that are subject to change or are in more than one module.

liamc - Tue Apr 20 07:32:08 EDT 2010
Gordon, thanks for the tip, it's a good one!

It's overkill for my sittuation though, and i think you've misunderstood what im trying to do.

Right now we have several attributes which are ennumerations (project members, project admins etc). In the current scenario we do indeed have to update each ennumeration, and it really is a nightmare.

My suggestion is to fix this by using a simple basetype user attribute, when you try to edit the attribute it triggers a dialog box to show, which has list of all the users in the database, which i can simply select and press ok.

Now all i have to do is add/remove users to the database, and all the choice of users for each attributes will be automatically updated. Simple and (unless you can help me realise otherwise?) i don't think it's flawed.

GordonWoods - Tue Apr 20 05:40:01 EDT 2010
Liam

your concept is flawed. If you have leavers/starters you will need to update each enumeration in each module where it is used on a continuous basis. Admin nightmare.

We have over 800 users on our database - somewhat of a long list - and only a handful may be relevant.

You need to consider the information as a relationship between objects.
So create a stakeholder/organisation module. Structure it according to your organisation with departments etc so that you can easily find users. Make it read only except for the Admin staff. It is the responsibility of the Admin staff to maintain this list for new starters/leavers - not the requirement writers. You now have only one place to modify the list of users. And if required this can be automatically updated overnight from the DOORS user list by a DXL script. Note: For a leaver strikethrough their name - do not delete.

Then link from your requirement to the relevant person in the stakeholder module (note direction of link is to the stakeholder module).If more than one user then use more than one link.

Use a DXL attibute to display the user name(s) obtained from the target object(s).

As an added bonus you can see who "owns" what requirement - even when these are spread over many modules. You can also trace down the links from the stakeholder module to see what requirements are affected by changing owner etc etc.

You can provide a DXL script to provide a "user editor" but it is really very simple. All you have to do is create a link and the user name appears. Remove a link and the user name disappears. The magic of DOORS!

This principle should be applied to all enumerations that are subject to change or are in more than one module.

Mathias Mamsch - Tue Apr 20 08:30:40 EDT 2010
Gordon, I like your concept. I really like the benefit of seeing for each user the requirements he owns over all modules. DOORS magic indeed :-)

Imagine I have an "requirement module A" which shall have links only to another specific "requirement module B". In addition for every object in that requirement modules you have an "Editor Name", a "Verifier Name" and a "Quality Assurance Name" for documenting your object life cycle. Using the link solution I would need three link modules for the three different relationships OR I would need three user lists (which would be awkward again).

Having three link modules for a link to the same module gives the problem, that I cannot enable the "Only allow outgoing links as specified in the above list" mandatory link module for the requirement module, thereby allowing the users to draw links anywhere they like.

Do you have a solution for this?

Regards, Mathias

GordonWoods - Tue Apr 20 09:10:02 EDT 2010
Mathias
You are correct you can only have one source /target pair defined in a module irrespective of the linkmodule

source -> linkmodule ->target

One solution is to use a link attribute.

add the attribute "role" to the linkmodule with, for example, enumeration type Verifier .

in both "requirement module A" and "requirement module B" add linkset pairing via linkmodule to target.

Add a column to a view in "requirement module A" using a dxl attribute to get the target name. name the column "Editor". Add extra line in the DXL attribute to only display if the link attribute matches the column title. repeat for the other 2 roles.

To use it then add a link from source to a target name. Change the link attribute type and now only the matched item is displayed in the relevant column.

You will be able to have more than one person in any one role.

liamc - Tue Apr 20 08:24:39 EDT 2010

Two queries regarding listview.

1/ how do i get it to be multiselect AND checkboxes? (the DXL ref has the syntax the following, which doesn't seem to work

listViewOptionCheckboxes|
listViewOptionMultiselect   provides check boxes and multi-select capability

2/ how do i insert a string into the listview? (i've tried it using the code below but it doesn't work)

//inserts the attribute history collumn
 
/*

*/
 
Module m = current
Baseline b
 
string users
string     dummy[]      ={}
User user
int     userCount       =0
int     i                       =0
 
//throw up a dialog box to get variables        
DB selectusersDB = create ("Compare Attribute History", styleStandard)
DBE userchoiceDBE = choice (selectusersDB, "Select Users: ", dummy, 0, 30, false)
DBE userchoice2DBE = listView (selectusersDB, listViewOptionMultiselect, 20, 10, dummy)
 
//put the db variables into dxl variable
void getvariables (DB selectusersDB)  {
        users = get (userchoiceDBE)
}
 
ok (selectusersDB, "&OK", getvariables)
realize(selectusersDB)
 
//list attributes and insert into choice element
for user in userList do 
{
        string uname = user.name
        insert(userchoiceDBE, userCount, uname) 
        insert(userchoice2DBE, userCount, uname) 
        userCount++
}
 
//show
show (selectusersDB)

Mathias Mamsch - Tue Apr 20 09:22:52 EDT 2010
I like this solution. You cannot have one person have more than one role for the same object (same source, same linkmodule, same target = only one link). In the example this would be an additional benefit, since you don't want editor, verifier and QA to be the same person. I will keep this solution in mind. Regards, Mathias

liamc - Tue Apr 20 08:24:39 EDT 2010

Two queries regarding listview.

1/ how do i get it to be multiselect AND checkboxes? (the DXL ref has the syntax the following, which doesn't seem to work

listViewOptionCheckboxes|
listViewOptionMultiselect   provides check boxes and multi-select capability

2/ how do i insert a string into the listview? (i've tried it using the code below but it doesn't work)

//inserts the attribute history collumn
 
/*

*/
 
Module m = current
Baseline b
 
string users
string     dummy[]      ={}
User user
int     userCount       =0
int     i                       =0
 
//throw up a dialog box to get variables        
DB selectusersDB = create ("Compare Attribute History", styleStandard)
DBE userchoiceDBE = choice (selectusersDB, "Select Users: ", dummy, 0, 30, false)
DBE userchoice2DBE = listView (selectusersDB, listViewOptionMultiselect, 20, 10, dummy)
 
//put the db variables into dxl variable
void getvariables (DB selectusersDB)  {
        users = get (userchoiceDBE)
}
 
ok (selectusersDB, "&OK", getvariables)
realize(selectusersDB)
 
//list attributes and insert into choice element
for user in userList do 
{
        string uname = user.name
        insert(userchoiceDBE, userCount, uname) 
        insert(userchoice2DBE, userCount, uname) 
        userCount++
}
 
//show
show (selectusersDB)