Guidelines for Project Managers

Who may host a project on this server?

Only members or collaborators of MPI-Met may host projects on this server, we cannot offer any service to external organizations.

How to create a project?

To request a new project, please contact the Redmine admins via the IT services of MPIM. We will create an empty project for you and permit management. After logging in, you'll see a link "Settings" on the right end of the projects navigation bar. Choose this for further configuration: Setting the description, select modules that should be available within your project, create a wiki or forums and connect the project to a source code repository and manage project members. Issue categories may ease working bug and feature requests, and versioning can help in organizing your code. Subprojects (depth restricted to one level by technical limits) can be created by the manager of the parent project.

The redmine developers offer an online demo of their work: Feel free to register for an account and play around with redmine.

Public or Private?

Code from the repositories of public projects is readable for all registered redmine users (that includes external users!).
Documentation (wiki pages, documents) is currently viewable even for anonymous visitors to ease getting help and information, and also to ease
project administration, as administrators only need to manage users that do need extended access to more advanced roles (bug-reporting or even managing for example).

If your code or project information needs to be hidden from all people but members of your project, you need to declare the project to be private during project-creation (or later reconfiguration via settings → information). Users won't be able to even notice the existence of a private project until they have been added as that projects member by the project manager. You probably want to use private projects for example to manage a groups or departments internal strategic discussions.

Unfortunately there's now way to use fine-grained permissions on a per-project level at the moment. The MPIM decided, that all MPIM projects should have the group "mpi-intern" with at least the role "MPIM Viewer" assigned to every project (exceptions need to be accepted by one of the directors), so MPIM staff can view, what's going on at the institute.

Some clarifications about Redmines access-management and how it may fit that need are developed here.

Roles and Permissions

Check the menu point Information from the upper left menu and check the Permissions report and the Workflows to understand, what a user with a specific role is allowed to do and grant your project members the roles they need to do their work with the project. "Manager", "Developer" and "Reporter" are Redmine standard roles which probably fit best for most of the projects, especially software development projects.

Please note, that you cannot add users to your project that have never logged in to Redmine - Redmine is linked with the central LDAP accounts, but these are only visible after a first login - please ask colleagues you'd like to add to your projects to login to Redmine if they never have before. Internal Users should always use the LDAP coupled accounts, not register a Redmine internal account!

Repository Access

The general guideline for configuring access to your projects repository within Redmine is:

  1. Don't use your personal account for fetching data from the repository. Please create a generic user with read-access to the related repository. For code hosted on, the username should have the form: "redmine-<projectname>". If you don't know who can create such a generic svn-account for your project, the IT services of MPIM may be able to guide you.
  2. use encrypted repository access (e.g. HTTPS instead of HTTP) wherever possible

Independently from the generic users access rights, Redmine doesn't change the code. It's possible to annotate code with Redmine, but you cannot edit the code here.

Repository access has a "one repository per project" technical limit. To access several Repositories, you'll need to create subprojects within a master project.

Access to git repositories

To access a git repository, the repository needs to be cloned on our Redmine server. This will be set up by one of the Redmine admins on request.

  1. The owner of git repository is authorized to update the cloned repository via git push. For this, he must provide the public ssh key by which access will be authenticated, and the name of the server on which the repository resides.
  2. On the Redmine server, an empty repository is created to hold the cloned git data, owned by the user git-data.
  3. The owner of the original git repository as well as the Redmine project manager will receive the path to this clone repository, eg. /srv/repos/git/clone.git. It's the path to be entered as the 'path to git directory' in the Redmine repository settings.
  4. The owner may then provide the clone with data, using
    git push --all ssh://
  5. To keep the clone up-to-date, the git repository's post-receive hook script should be activated. With this you may initiate an automatic push to the clone repository after each push to the git repository. eg. like
    cd /path/to/git/repository
    git push --all ssh://

    If the git repository may be used directly with git commit, these lines must also be put into the post-commit hook script.

This setup only works within the MPI-Met and DKRZ network domains. The Redmine server does not allow direct access to a remote git repository.

What's "Repository Mapping"?

If your repositories usernames or mail-addresses match with the Redmine-usernames, Redmine can match them automatically. If this is not the case, project managers can create manual mappings between them. To do that, the project manager can find the related settings at <Project> → "Settings" → "Repository"-Tab → "Users". There's a list with usernames from the code repository which you can match to redmine-users that are members of your project through a dropdown menu.