I setup a central repository and multiple local repositories. Now, I am trying to add the central repo in my designer and activate it, but when I try to add the central repositories through tools – centraal repositories – add, I get the error that “no repository is configured for the user”. My user id has view & schedule permissions on the central repository. If I change my permissions to full control, I can add the central repository !!
does this mean that any user who wants to connect the local repo to the central repo needs to have full control rights to central repo ? view/schedule rights are not enough ?
no, I am not talking about the database rights. I am talking about the user permissions on the central repository itself. This is DS 4.0. If you go to CMC, open data services, right click on central repository, choose user security, then assign security, you can assign which users will have what kind of permissions/rights on this repository. There are 5 levels of permissions i can give: Full Control, full control owner, schedule, view and view on demand. Now until I do not assign full owner permission to a user (developer) for the central repository, the user cannot connect their local repository to the central repository !!! In other words, for the developer to connect their local repo to the central repo in designer, they have to have full control permissions in the backend (CMC) ?
Were you ever able to figure this one out. I know it is a old post and I am in the exact same situation here and would like to know if you ever got to the bottom of this. My issue is granting the FULL CONTROL also gives a user to delete a Job/WF/DF/Project from teh Cntrl Repo which I am trying to take away.
Collection Type Right Name
Application DS Repo Allow user to retrive the Repo Pwd
General General Edit Objects
General General View Objects
This is what I have given for the user under the “CNTRL_REPO” name
Inspite of taking away the FULl CONTROL rights and giving just the above rights, the user is still able to delete the WF/Jobs/DF/
Surprisingly, when the Central Object Library is opened up, under the Permissions columns ( for the said WF/DF) it shows FULL. I am assuming this means FULL CONTROL. I am not sure where this access right is being inherrited from.
@Tim : Yes, I have added the users in the Mgmt Console under CNTRL_REPO
You are right about setting up the connection to the Central Repo in Desginer as a one time…but my Q is not about that. It goes beyond, after setting it up.
As a Eg: User A logs in and checks in a WF into the Cntrl Object Library.
User B can log in using his/her own credential and activate the CNTRL_REPO and open the Cenral Object Library and delete the WF that User A has put into the Central Object Library.
What I am trying to achieve is that UserB should not be able to Delete the WF’s.
I hope you got my point.
Yes…
That is the goal. But that is the next on my list.
For Now, it is just trying to kepe it simple by not allowing any user ( except the Admin) to be able to go in and delte the Job/WF/DF.
Have noticed one thing though…
If a USER adds a new object to the central library, the current/Default user group gets FULL permissions and all other groups get READ permission. The default Groups can be maintained in the Admin Console of DS. I believe there are only 2 privilages right now… READ and FULL. Would be nice to be able to add a Custom Privilages too. Also, I do not think we can get these grps to show up on CMC to be able to administer the security.
As you are learning the Secure Central Repository is somewhat limited. If the person that applies the permissions to an object assigns it to the wrong group then it may turn out that nobody can modify the object until it is changed. It seems to me that rights should be set at the group level, not the object level. If you have two groups, ReadOnly and FullAccess you could assign both groups the “Full” right which is probably not what has intended. There is the potential for a lot of mistakes.
I would audit the security settings frequently by querying directly against the repository tables.
Don’t think of it as an enterprise version control system. What it lacks in security features it makes up for it with the ability to coordinate the various parent/child objects. Checking in a parent object without the child object already checked in (or getting checked in) raises an error. With a single operation you can check out , or get, all the objects for a job. With an independent version control system like Subversion you would have to track down every object yourself. That would be quite painful.
(BOB member since 2008-07-17)