To control who can access your project, consider the purpose of your project and the
appropriate type of user.
Control access by user role
Project administrators use existing global project roles or create and assign roles to project members to define what those project members can do in the project.
Control access by user class
To avoid having to create and assign a lot of similar roles for individual users, give access to applications to whole classes of users whenever possible.
Control access by project type
Projects can be open only to project members, open to everyone in the world, or something in between.
Lock or unlock a project
To ensure that no changes occur in a project while you are collating or migrating project data, lock the project. You must have project administration permissions or be a site administrator to lock or unlock a project.
Control access to source code
It's a good idea to make sure your source code can only be used by people who have business with it.
Control HTML headers in hand-coded project pages
When a HTML page that you created in Microsoft Word or Frontpage looks strange, you may be able to fix it by suppressing the HTML head content.
Allow anonymous Subversion checkouts
To grant anonymous checkout access while restricting write access to a Subversion repository, set the project's default access permissions to public, provide Source Code View permission to all users, and limit other permissions to specific user classes.
Show or hide an application
To help users focus on the relevant parts of your project, choose which applications they can jump to from the navigation bar at the top of any project page.
Who can post to discussions by email?
To help reduce the risk of spam or other mischief, you may need to limit the users who can post to your project's discussion forums by email.
