Trigger to Prevent view creation in ClearCase / ClearQuest

Share URL
 
craigalanleigh's picture

We are an interop shop currently upgraded to CC/CQ 7.1.1.1 Our vob/view server is unix (SOL). End users are all Windows XP Prof OS (some Linux later)

One of the uses for Rational is a 4 year old home grown DocMgmt app which uses CQ as the document request meta data piece and CC as the document repository for the documents.

One of our user groups (call them TEO for 'Their Eyes Only') wishes to use the system, but needs more security than what is provided currently. Clearcase is set up with only one Clearcase group which has access to all VOBS in an effort to reduce operational maintenance costs (I'm told). However, this means anyone who can create a view, in any region, on any stream on any VOB.

I would like to create a special TEO DEV stream off of the DocMgmt INT stream we now have with 10,000 tech docs in it and create a trigger to validate who is creating a view on the stream and prevent them from doing so if they are not one of a list of ten network IDs. If necessary, we could create a network group and place TEO users in it or just maintain the list with the trigger.

Can this be done and any special considerations?

Thanks,
--Craig

Tags: 
configuration management
clearquest

2 Answers

martina's picture
martina replied on April 13, 2011 - 11:23pm.

there is no trigger for mkview.
The first question is whether you want this hacker proof or just casual user proof.

If you want it casual user proof, you can probably doctor up something, but it will still be more effort than making a group, and it won't give you read protection, only write protection.

If you want this hacker proof, a hacker can always, always make a base CC view and look at things. Or hack even more and look into the VOB storage files.

So you will need a separate group for TEO and you will want to put their VOB(s) into a separate directory and don't give the regular group any read access.

You will have to look at the current data and figure out whether all these docs are in a separate VOB or mixed in with other stuff.
If it is mixed, you are really up a creek.

You will have to look past UCM terms into the underlying VOB structure.
At this time there is no per stream (or branch) protection. Its for the element and for all branches of it.

hth

craigalanleigh's picture

Martina,

Thx for your reply. I was surprised at "no trigger", but otherwise your response confirms my suspicion as to the options. And yes the data is mixed with other stuff and we are up the proverbial creek.

We could create a separate VOB in a separate directory accessible by TEO group only, but the effort to rewrite and test our DocMgmt code (written in CGI Perl) compared to the benefit to a very small user base makes the effort unjustifiable.

--Craig

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.