I'm looking for a way to have separated but INDEPENDANT build_mgr on a same database to limit interaction between us. Each build_mgr will have a group of project to manage.
I want to avoid that the build manager of a project interact on a project which is not in its group....
any idea ?
You can define user groups and then assign one or several groups to your prep projects.
Once that is done, only a build manager who is a member of at least one of the project's user groups will be able to modify that project. You can find more information in the IBM Infocenter[/url]. Look at the "ccm groups" command.
Regards,
David.
OK for ccm groups command, but this command can only be applied on a specific version of an object.
Can I limit the access on all version of a project (even if a new version is created) and for all object in it ?
Can ccm groups command be applied on a release ? (or better on a component) to prevent people creating tasks or other object linked to a release ?
The user-group based restrictions are specific to each object version. However, once set on an object, any versions that are derived from get the same group-based restrictions copied to it from its predecessor. Once you have all versions of a project with group-based restrictions, any user that performs a "copy project" operation will always get group-based restrictions regardless of which version they are copying.
If you have a project with user group-based restrictions, any new files or directories created in that project will have the project's group-based restrictions copied to it by default. Thereafter, when developers check out from that first version, the new version will get a copy of the group-based restrictions from its predecessor.
While you can place group-based restrictions on a release or on a process rule, that only affects the access rights to that release or process rule. There is no object in a database that represents a component, as in the "component" part of a release namespace.
If you have a requirement that only developers that are members of a specified team can create or check out files in a project, you have to apply group-based restrictions to the project and all of its members. If you do not do that, a user could create a new project, add one of that team's files to it, and check it out. This is a different security model from those used on file systems. File systems can support an inheritance model based on parent directories since a file can only appear in one place in the file system. In Synergy, an object can appear in zero, one or many projects and under different directories. That is why access rights have to be defined on a per-object-version basis.
Regards,
David.
Thanks for all... I'm trying to
A last question :
- In the case of user group restriction is applied on a project and all its members, if a new element is created, does it inherit of group restriction of its project or folder ?
Yes (copied rather than inherited), as described in my earlier reply... "If you have a project with user group-based restrictions, any new files or directories created in that project will have the project's group-based restrictions copied to it by default. Thereafter, when developers check out from that first version, the new version will get a copy of the group-based restrictions from its predecessor."
David.
Thanks for all ...
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.