Hi Zhang,
this thread has been sitting unanswered for a while and the question keeps coming up, so here is the mechanism, for you and for whoever lands here from a search.
The short answer: what you are looking for exists and it is called group security, driven by the ccm groups command. The way to think about it is two layers. Database roles (developer, build_mgr and so on) define WHAT a user is allowed to do, and they stay at database level. Groups define WHICH objects the user can actually read and write. Combining the two gives you exactly the project scoped permissions you are asking about, without touching anybody's role.
The reference for the role layer, with the full matrix of what each role can do per object state, is here:
https://www.ibm.com/support/pages/node/363793
And the project scoped part is documented in this IBM support page, including the exact commands to apply a group to everything inside a given project in one shot:
https://www.ibm.com/support/pages/how-set-group-security-multiple-objects-same-time-rational-synergy
The pattern is: first query all the members of the project recursively,
ccm query "recursive_is_member_of('<4 part name of the project>', '')"
then assign the group to the whole result set,
ccm groups /assign /value <group_name> @
From that moment the members of that group have read/write access to those objects, and users outside it do not. Removal goes through the same ccm groups command family, check the usage output at your exact version for the unassign syntax rather than trusting my memory on the flag.
Three practical notes from the trenches:
1. Groups have to exist first, with the right users in them. That is CM admin territory: the groups are defined in the database and the ccm groups command has the full set of subcommands (its help output is the honest reference for your level, and the Security section of the product docs covers the setup).
2. Group security is applied per object version. Objects that get created in the project AFTER your assignment do not inherit it magically, so either re-run the assignment periodically, script it, or bake it into your release process. The support page above exists precisely because people need to reapply this at scale.
3. The role layer still applies on top. A user without the developer role will not write anywhere no matter what groups say, and a build_mgr keeps their prep powers. Groups narrow the scope, they do not replace the roles.
If you share your Synergy version and what granularity you actually need (read only for some teams, write for others, per project or per folder), happy to get more specific.
Cheers
Roberto