It is often useful to allow customer access to an internal ClearQuest database, with the intent of allowing them to view records associated with their issues, submit new issues, and possibly see other public information that is not specific to any particular customer.
A key aspect of this ability is that one customer cannot be allowed to see, or discover, the existence of any other customer information. They also cannot be allowed to see, or discover, the existence of any internal users or internal information.
It is important to note that workspace folder permissions are only part of the solution to achieving the above goal. Many ClearQuest schemas include records containing data that it might not be advisable for a customer to see.
The Security Context feature of Rational ClearQuest must be used to restrict visibility of which records are returned by a query. Workspace folder permissions do not restrict in any way what data is returned by a query. And workspace folder permissions do not in any way restrict the users ability to make private queries. Only the Security Context feature of Rational ClearQuest has the ability to restrict which records are returned from a query.
The schema developer would have to modify the record types provided by the schema, by adding references to Security Context records and possibly separating logical record types into multiple records where the logical content of each record can be controlled separately, in order to truly enable customer access to an internal user database. (For example, if a product record has the product description, price, and cost to produce in the logical record, the security context feature can only restrict access to the entire record, not pieces of the record. So if a customer is not to know the cost to produce the product, then that information must be on a separate record. Such separation of records can be quite complex and lead to other problems and is not recommended
The Security Administrator performs the following steps.
The customer users would only be able to see their own Personal Queries folder and the CustFolder along with anything inside either folder. If Read-Only permission is granted to the CustFolder, then the customer users cannot create or modify any content and the folder would have to be managed by some other group that did have Read-Write permission on the folder.
If they also had Read-Write permission on CustFolder, they could create or modify things in that folder, including creation of subfolders, thereby doing their own management withing the folder.
A variation of the previous scenario is to separate the customer users into two groups: one for normal users and another that would be able to administer the content of the customer folder. This would allow using CustFolder in a way that is similar to the default for Public Queries, i.e. where most users have read-only access and selected users have read-write access.
To achieve this, the Security Administrator performs the following steps in addition to what is outlined above.
In this case, members of CustAdmin could modify the content of CustFolder, but users that are members only of CustUsers could not.
A large customer may have different internal groups that need access to an internal ClearQuest database. In this situation, there are two cases: the customer groups are either independent or cooperating.
In the first case, the two customer groups are independent and should not necessarily know about each other. This would be handled the same as two completely independent customers. The only real issue is what names to use for the ClearQuest groups and customer folders such that there is no suspicion that there are multiple groups. This may or may not be critical to the required security policy. For example, using “Acme1” and “Acme2” would suggest to a user of only one or the other that there are any number of other “AcmeN” groups. Appropriate naming for this situation is left as an exercise for the reader.
In the second case, the groups are cooperating and are aware that each is using the same database. In this situation the group and folder names are less important. There are several variations that could be used for this case, depending on how much sharing between the groups is desired. The typical case would be where each group, or each group’s administrator, controls its own customer folder, but allows the other group to have Read-Only access. This would require either 2 or 4 groups, depending on whether each group had a separate group for administration (as outlined in the previous section: Alternate scenario 3a: Customer management of their own folder. Another variation would be for the groups to share the administration role. This only makes sense if the previous alternate flow is used; it would allow using only 3 ClearQuest groups instead of 4: 2 for the customer groups and one for a common administrator.
This is a situation where more than one customer is involved with a single project and they both need to see the same data in the internal ClearQuest database. This can be addressed it two ways.