There is still one tab on the Settings page of the Administration menu that we have not discussed yet. It's the Projects tab. So let's check it out now:

A project in Redmine can be either public or private. A public project is visible to everyone, even to unregistered users (unless you have restricted access to the whole of Redmine by enabling the Authorization required option under the Authentication tab). Of course, access to some pages of the project can still be restricted, but even if every page is restricted, the public project will still be visible! It will just appear to be empty. A private project is the opposite—it cannot be seen by non-members, whatever you do! Thus, you can let unregistered users and non-members see everything, but still such projects won't be visible to them.

So, the New projects are public by default setting should be enabled only if all of your projects are to be public. Otherwise, it is possible that a project that was meant to be private is accidentally left public. However, even if you want all of your projects to be public, you may still want to disable this setting to avoid the appearance of empty projects in the project list, as users may need some time to put data into them (later, when their projects are ready, they can change this). You should consider this especially if you are positioning your Redmine installation as a list of active and up-to-date applications so that your users won't get frustrated when they see no data in a project.

The next setting is the reason we started this chapter with a review of project modules. Now, I believe that you can easily determine which modules you need. Remember, however, that on this page you select modules that are going to be enabled by default for all new projects. Also note that users will still be able to enable modules that are not selected here and disable the ones that you selected.

Like the previous setting, Default trackers for new projects can be used to select which trackers should be enabled for new projects by default. Here, you should enable only those trackers that are going to be common for all your projects.

Each project in Redmine has a unique identifier—a short string with letters, digits, dashes, and underscores. The main goal of this identifier is to replace the numerical project ID, which is used internally, by something more readable and memorizable.

For this reason, I'm not sure why one may need to enable the next setting. Perhaps, it was added for cases when users do not care about the readability of project identifiers. In other words, if you just don't want users to think up project identifiers and do not care about their ease of remembrance, you can enable the Generate sequential project identifiers setting. When it's enabled, Redmine generates sequential identifiers for new projects. Thus, if the identifier of the previous project was redmine, the next suggested identifier will be redminf (not very smart, is it?), and if the previous identifier was chapter-1, the next one will be chapter-2.

For the Role given to a non-admin user who creates a project setting, you should select a role that will be assigned automatically to the user who creates the project. Certainly, this should be a role with project management permissions. If you don't do this, such users will get the first role from the role list (which can be checked in Roles and permissions under Administration). So, using this setting you can avoid confusion when users discover that some things are not available for them in their just-created projects (because their automatically assigned role does not have the appropriate permission).