![]() |
Telelogic SYNERGY (steve huntington) | ![]() |
Topic Title: How to use User-Privileges in scripts for ChangeSynergy Topic Summary: API calles to get User-Privileges of a user Created On: 24-Nov-2004 10:47 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Hi all,
Problem description We've implemented a life-cycle of CR's in which users with certain privileges can skip certain CR states: We've defined 3 CR types: CR (change request), PR (problem report) and WP (work package = plannings item from integration with our project planning tool). For CR and PR the normal CR life-cycle is followed (i.e. [Start] -> CCB -> Assigned -> Accepted -> Resolved -> Verified -> Concluded -> [End]) and everyone is allowed to enter a CR or PR. A WP may only be entered by a user with the privileges 'project_manager' and the CCB state is skipped (i.e. [Start] -> Assigned, etc). We've also implemented two Submit screens to do so, but this causes problems with the integration with DOORS, so we'd like to get back to 1 Submit screen. I'm therefor implementing a perl script as a trigger, which checks the CR type (CR, PR or WP) and if the type is 'WP', it should check the user has the User Privileges 'project_manager'. If so, the WP is allowed to enter and set through to the status 'Assigned'. We're using CS4.3-SP3 and CM Synergy 6.3-SP3, incl. patches 036, -037, -038, -039 and -041. Question I already managed to check on the CR type. I already managed to get the CR to skip a state. What I don't manage is to get the user's privileges out of Change Synergy. I can't seem to find the right API calls. The calls at my disposal are: getUserRole() and getUserRoleList(). This only get's me the role in which a user logs in into Change Synergy (i.e. Admin, ReportBuilder or User) and not the privilege 'project_manager'. Can you help me?! ------------------------- Regards, Danny |
|
![]() |
|
![]() |
|
That's nice. My own question appears to be my answer, which is not the case...
I've found a way around it, with help of the Telelogic consultant, Jaap Mulder, who was at our disposal. It works like a charm, but is still a solution in terms of '3x right-turn makes 1x turn left...'. I've took the liberty to attach the Code. ------------------------- Regards, Danny |
|
![]() |
|
![]() |
|
Hum... I think there is no real need to check if a user has some privileges or not... as SYNERGY/Change already deals with this kind of security issues. I mean that Change PERL API would allow you to transition a change request only if you are allowed to do it, according to your current roles.
Have a look in the transitionParent.pl sample trigger file (in wsconfig/triggers) directory, and especially from line 68. my $theproblem = $csapi->AttributeModifyCRData($user, $problem, "crstatus"); This line does some kind of a "Show" on CR number $problem. Ok ? Then, there is a loop on all allowed transitions from current CR state: #For each allowed transition. for(my $i = 0; $i < $theproblem->getTransitionLinkSize(); $i++) { #Get the transition object my $transLink = $theproblem->getTransitionLink($i); #See if the transition is the one we want. my $value = $transLink->getToState() cmp "\L$stateName"; ... I think you only need to check if the transition you would like to do is (or not) allowed. If it is allowed for you, then it should appear in transitions lists brought to you by getTransitionLink() API call. PERL API will always list you the transitions you are allowed to do. So you do not have to deal with security. Therefore you do not need to check if your user has (or not) role(s). Am I clear ? :-) not easy to explain such things... HTH Regards Vincent |
|
![]() |
|
![]() |
|
Hi Vincent,
Yes, you would think so, but... We don't want our users to log in, in any other role than 'User' for the following reasons: 1. We have an integrated process, which is supported by the implemented tools (yes: Telelogic Suite, with DOORS, Change- and CM Synergy with all integrations; in combination with TestDirector). From DOORS a user can submit Requests to CS. If this Request is of type WP (Work Package) and that user has the privilege in CS of either project_manager or lead_engineer, that user is allowed to create a Request of type WP, otherwise the user is only allowed to create a Request of types CR (Change Request) or PR (Problem Report). Unfortunately user privileges aren't shared between DOORS and Synergy, DOORS submits the Requests into CS with the login-role 'User'. If we could have had DOORS react upon CS privileges, e.g. by not allowing to submit WPs into CS when the user doesn't have the proper privileges in CS, we wouldn't have to implement our current solution. 2. We had two seperate Submit screens: one for CRs/PRs and one for WPs. But when submitting CR/PR/WP from DOORS we were faced with the fact that you had to choose in DOORS if you wanted to submit a CR/PR or WP and then in CS again! A normal user would select a WP to submit to CS, DOORS automatically logs in with login-role 'User' in CS, only to found out that (s)he was only allowed to submit CRs/PRs with that login-role. We've now simplified the implementation: within DOORS you only indicate you want to submit a Request. In CS the user's options are available, without having to re-start CS, thus losing all automatically filled in data from DOORS, in login-role 'Project_Leader'. 3. Although we have an integrated process, we don't want to burden our users with the details of implementation within the tooling. Our users are mostly PLC-programmers and this is the first time they're subjected to a more strict way of version-, change, requirement and test control. Coping with the new processes is more important and any too 'complex'/'deviating' tool usages is undesired, because it takes the attention off the processes. Our implementation: 1. User accounts already have privileges, so once a privilege is enabled CS should react upon it, unfortunately it only reacts on the login-role. As a work-around we've coupled specific login-roles with specific privileges (i.e. login-role: Project_Leader = privilege: project_manager) and check if a user was also allowed to log in with another login-role. 2. The Perl-API call UserRole and UserRoleList are exactly the same in output, although you would expect the later to have a list with allowed login-roles in stead of the role the user currently used to log in. We, in cooperation with some Telelgic Consultants here in the Netherlands, have tried to address the UserRoleList function, didn't get the expected output and implemented the code I've posted above. I hope you see our challenges and understand why we've implemented the code above. If you have any suggestions on better approach, please let me know. Kind regards, Danny ------------------------- Regards, Danny |
|
![]() |
|
![]() |
|
I've maybe not been clear enough: I was not talking about SYNERGY/Change roles (User, Admin Report Builder, etc...), but about security roles (developer, build_mgr, verifier, pt_admin, etc...), a.k.a. privileges in your message.
The PERL API UserRoleList function will always returns you a SYNERGY/Change roles list. That's not what you want to have. What I explained in my answer yesterday is that PERL API reacts to users privileges by returning you only what user can do ("what he is allowed to do"). The code sample I quoted in my answer showed that. Anyway, there is a second solution, based on listboxes. You need to create a new listbox (in your CRProcess or in a .cfg configuration file). For example: [CCM_LISTBOX][NAME]USERS_ROLES[/NAME][TYPE]STANDARD[/TYPE][FILE][/FILE][FROM_DATABASE]users_roles[/FROM_DATABASE][VALUES][/VALUES][DATABASE_SPECIFIC]NOT_DATABASE_SPECIFIC[/DATABASE_SPECIFIC][/CCM_LISTBOX] In your script, you can then query for this listbox: my $users_roles = $csapi->GetListBox($aUser, "USERS_ROLES"); Of course, you'll have to do some parsing to extract the appropriate data. But this should not be too difficult: #checking is user $username has $a_role privilege. for (my $i = 1;$i < $users_roles->getListboxSize(); $i++) { my @t = split(' ',$users_roles->getLabel($i)); chomp(@t); if ("$t[1]" eq "$username") { for (my $j = 3;$j < @t; $j++) { $this_role = $t[$j]; if ("$this_role" eq "$a_role") { exit 0; } } } } die "<FONT COLOR=red><B>Insuffisent privileges</B></FONT>"; exit -1; Vincent Edited: 7-Apr-2005 at 11:16 by Vincent Gaudeul |
|
![]() |
|
![]() |
|
Danny,
At this point I do not believe Telelogic provides a solution to the problem you describe. I have called tech support with this very issue and they did not have a solution. Perhaps in a future release? But that does not help you to solve your problem! I had to solve precisely the same problem at Sprint. We have an Oracle database in which we store ChangeSynergy related metadata e.g., listbox data, userid roles, etc. From this separate database we generated a perl module containing a hashtable so that, given a userid, we could use it to look up privilege information. Alternatively you could create a perl script to generate the above hashtable module from the ccm_users attribute. This hashtable module looks something like the following: ================= $user_role_db{'abc1234'} = {'privilege1'=>'', 'privilege2'=>'', 'privilege3'=>'', 'privilege4'=>'', privilege5'=>'', 'privilege6'=>'', 'privilege7'=>'', }; 1; ================= Then use code like the following in your trigger script: ================= if (exists $user_role_db{$userid}{$role_required}) { exit(0) } else { # The die statement causes the script to exit with an error code that CS sees # and then prevents the transition from proceeding. die("WARNING! You do not have the role required to proceed.\n"); } ================= That should give you some ideas. Hope it helps. Jim Heimbach Change & Configuration Management Sprint |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.