Managing Project Permissions

Developers are the cornerstone of any successful Open Source Software project. We recommend that each project try to maintain a sufficiently large developer base to maintain development momentum, especially in the absence of some of the developers.

However, adding a user to a project is a major action with potentially serious consequences. The user will have access to project resource and content. There is a potential risk that the user could cause harm to the project. Before adding a user, weigh all the potential risks against the benefits.

You can categorize your contributors in different groups and assign permissions to various portions of your project by group. The default set of groups includes Admin, Developers, and Members. You can add as many groups as you would like, to manage various functions of your projects. Project permissions are managed by assigning the same permissions to everyone in that group.

Note, only a SourceForge.net project administrator can give a user membership in the project.

Adding another User to your project

Login to your project and click on the Admin icon. Then click on User Permissions

To add a user to a group, select "+ Add" under the appropriate group and enter their SourceForge username. Note that this is the unique username, not the display name.

To remove a user, select the "-" next to their username and confirm removal.

Assigning Permissions

Permissions are assigned to groups (not individual users). They can be set at the project level, and for individual tools.

Whole Project Permissions

On the Admin page, click on User Permissions. On this page, you can toggle high-level project permissions by clicking "read", etc. in the rightmost column.

Tool Permissions

Click on the menu unlock icon , then the next to the tool you wish to modify, then click Permissions. On that page, click Add to assign a group a particular permission, such as the ability to create or delete wiki pages or post comments.

Click on Save to save your additions.

Default Groups

• Admin: Project administrators have full control over the projects, and can add/remove other members
• Developer: This group also contains all Admins, most tools will allow Developers to perform most non-admin functions by default, though these can be customized using Individual Tool Permissions.
• Members: This group contains all developers, members generally have fewer permissions by default, but like Developers, this can be customized via Individual Tool Permissions.
• *Authenticated: Any user signed into the SourceForge site.
• *Anonymous: Everyone, logged in or out.

Keep in mind that the "Member" group contains the "Developer" group, and the "Developer" group also contains the "Admin" group. In other words, an Admin is also, by inheritance, in the Developer and Member groups.

Likewise, "*anonymous" (all users, both logged in and logged out) is a supergroup of "*authenticated" (ie., logged in users only).

Custom Groups

Use the "Add a new group" link at the bottom of the page to add a new group. This can be used to define specific teams (eg., "documentation", or "support") that have their own customized permissions set under the Individual Tool permissions.

Permission meanings

Please note that these are generic permission settings for the project and will be superceeded by permissions set specifically for each tool. It is recommended to use the default settings and manage the permissions through the individual tools themselves.

Admin: All permissions
Create: Allows creation of tools/content (some of these may still require admin permissions)
Update: Allows updates to the project such as new files/commits/pages (some of these may still require admin permissions)
Read: Read permissions, these should generically always be on for everyone. Turning this off for any user can cause issues for non admins of the project.

Common permissions

Several permissions are used for a number of different tools.

• ADMIN: Controls permissions for administrator settings
• READ: Controls who can view the contents of the tool.
• POST/UNMODERATED_POST: Controls who can use the discussion features (eg., commenting on tickets, wiki pages, or merge requests). If a user is in POST, but not the UNMODERATED_POST, their comments will first enter a moderation queue before it's publicly viewable.
• MODERATE: Controls who can approve posts that have been moderated, as well as who can edit and delete comments.

Specific tool permissions

Each tool has additional permissions specific to the functionality of that tool. The meaning of those are explained on each one.