Hello, my name is Norm and I have a messy repository.
All: Hello, Norm.
Okay, now I’ve taken the first step and admitted I have a problem.
I inherited this repository when I began serving as BO administrator here. Since then I’ve read all the posts on BOB about how to organize users and groups for efficient administration. I attended the “Let Me Speak to Your Supervisor” session at the 2002 User Conference. Then on the trip home Cindy preached the gospel of repository management and I took copious notes. I understand the concepts and want to change. So why haven’t I? No time.
Recently, for various reasons, the need to clean things up has become more urgent. But I have one basic question:
All the advice seems to address setting up a new repository. But how do I change my current repository where users have command restrictions and resource links defined in multiple groups to a repository where command restrictions are defined in one area and resource links defined elsewhere? Is it better to do it gradually or all at once? Are there gotchas I need to watch out for?
If you’ve been through this process, I’d appreciate any advice.
It will take some time to do the work. But people need to be using BO all along.
Basically, you need an entirely new set of folders for everything. You can configure the folders they way you want and then start dragging users from the old folders to the new ones. By doing this, you don’t have to deploy a new .key file or do any of the ugly things associated with having a new repository. Users stay in the old structure until you move them. When you move them, do it 1 folder at a time. Then you can just delete the old folders 1 by 1.
I agree with Steve. No shocker there. I usually do.
You may be able to get away with just setting up a new Config tree where you establish the various types of users you have (power, web only, designers/developers, etc) and gradually add people to those groups. Then you could change the buttons to green for all the old groups and begin to use them as ‘Resource’ groups.
I am in the same boat. I took over as administrator last year and the users setup is aweful! After I took the excellent Supervisor class by Scott , I really want to redo the whole tree.
I might try Steve’s suggestion. But I have a couple questions:
If I create separate instances of users in the new folders, will I run into the potential problem of permission conflict?
As Scott taught us in the class, we should by default disable everything at the root level. But that will create problem on our “old” folders. Is it possible to create more than one root? I don’t think I can, but it won’t hurt to ask.
Now, make sure I understand you correctly. When you said “new config tree”, you meant a new “root”. Correct? So is my question #2 is do-able then, right?
If true, how can I create a new root? I thought the root level is created during the initial set up of Supervisor. Please explain.
Then I’d get the permission traffic lights set in the Config branch and begin adding users one and only one of those. That determines their permissions. Then when you’re all done and everyone is in one and only one config group, change all the traffic lights to green in all the other branches. Use those branches to grant universes and documents. Make sense?
Steve and Cindy,
Thanks for your input. I was planning on doing something along the lines of your suggestions. You’ve given me the confidence that I’m going in the right direction.
Hmm, you are separating the permission to access documents and universes from the permission to “do” things after accessing documents and universes. That makes sense only if each user is allowed to do exactly the same thing on all accessible documents or universes.
What about the following scenerio…
User A is allowed to use List of Values for project X documents, but is not allowed to use List of Values for project Y documents?
How do you handle that in your structure? One thing I can think of is to set up two different login accounts for user A, one for project X and one for project Y. But that could become very messy.
Which is exactly the framework that BusinessObjects provides us at this time.
Can’t do it. Access rights and Permission rights are handled differently. Access rights are more open, meaning if you have access to a universe somewhere you have it everywhere. Permission rights are most restrictive, so if you have lost the ability to refresh LOV queries you have lost it everywhere.
And that’s the only way currently that it can be done.
I just sent another I’ve been meaning to send for a long time. It is the same info only a little more visual. It takes you through a repository setup for a company called Sally’s Seashell Sales.
Dave, Forgive me. It is basically a rip off something you emailed me about 4 years ago
(BOB member since 2002-07-10)
, I really want to redo the whole tree.