Profiles in ODI

Question

Hello there, I am new to ODI and I had a couple of questions about the profiles.
I would like to know what profile(s) i need to assign in order to allow a developer to work in a given repository/project without being able to change a data model.
I need them to be able to view, edit, delete interfaces, packages, variables, Copy and modify....not modify the original.
Any help you be great.
Thank you,
IT Intern

Answer 1

Ok, but I do not completely understand what every
method does. Basically I want the Devs to not be able
to change any metadata and just to be able to work on
their own projects, or projects which I allow them
too.As far I as have been able to determine there is no documentation of what each method does. Generally they correspond to the right-click options, but there are often other methods required to perform a specific action.
The best way I have determined to build a custom security profile is to go through the tedious work of granting a profile a few methods at a time, then logging into the Designer application to test the privilege. You will then inevitably get an some obscure error and need to guess at what method the profile is missing.
We are in the process of setting up our ODI environment and I recently spent a few weeks(!) of time developing custom security profiles. We had a similar goal of creating a role that gave developers read-only access to models and non-generic project access (= access only to projects they created or had been granted). We also had another major requirement to restrict users from making changes to the production work repository.
We did successfully create profiles to meet the goals of that role -- as well as several other roles we required -- but discovered a significant security issue. Any user could log into Security Manager and drag-n-drop any instance (project, model, work repository, etc.) that they could see from Designer onto any other user that had a non-generic type profile and grant that user access to the instance. This was true, even though we hadn't granted them the appropriate Security Manager methods that control this "drag-n-drop" functionality. The consequence is that we couldn't really create a secure environment that utilized any non-generic privileges. (Our assessment is that ODI security is still pretty buggy; Oracle should invest some time in unit testing their ODI security model.)
We decided to change direction: We have an open development environment where every developer has full (generic) access to all projects in the development work repository (still have read-only access to models). To meet our secure production requirement, we also ended up creating the production environment as a separate master repository with separate authorized users.