User permissions for ISM on 9.1

[wwilliamson]

I've recently finished building our new DataStage 9.1 environment and have been designing a deployment process that incorporates Subversion source control via ISM. The issue I've encountered is that the functionality relating to source control is disabled for all of the developer accounts.

The details: My intent was that each developer would have their own project where they have edit privileges but other users do not, and that there be a main project where the developers have no modify privileges and only a Builder account has privileges higher than Super Operator. To that end the Builder account has the DataStage Administrator component role, and the dev users have the DataStage User component role. Additionally, the dev users have the Prod Manager project role within their specific project and the Super Operator project role within all the other projects (including the main project).

Given this configuration I used the Builder account to open ISM, integrate version control, and perform the initial commit. All of those operations work fine for the Builder account but the developer accounts do not have access to any of the source-control operations (those items are grayed out on their context menus).

A. Does this sound like a permissions issue
B. Am I going too far trying to isolate everyone's work to this degree
C: Is this how ISM is intended to be used or am I missing the boat entirely
D: What kind of deployment process do you use

edit - corrected some spelling.

[roy]

IMHO,
Yes you went too far.
The whole concept is that everyone has access to it and it alerts you to objects being edited by others.

The only thing you want a final say about, is your production environmemnt,
otherwise you'll be doing nothing else except moving objects around all day.

Goog Luck,

[wwilliamson]

Thank you for taking the time to respond, Roy.

If the aforementioned method is overkill then what would be the better way? Our prior dev environment project arrangement consisted of a project for dev work and another project for 'unit testing'. I'd like to expand this to include a separate 'baseline' project that always contains what's deployed in prod.

I found a couple of threads that talk about this sort of thing but they both end up sounding like they're proposing the kind of complexity that your prior post is directing me away from.