Mastering Redmine

5 (1 reviews total)
By Andriy Lesyuk
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Getting Familiar with Redmine

About this book

Redmine is well-known as one of the best open source project management applications. But, it's also one of the best project hosting and issue tracking solutions. In addition it incorporates Wiki, repository management, forums, time tracking, and more. This book reveals the power of Redmine and manifests its exceptional flexibility and customizability.

Mastering Redmine is a comprehensive guide which covers a wide variety of topics: from configuration to writing simple plugins, from issue reporting to managing issue lifecycles, from writing simple Wiki pages to designing rich web content using the Wiki syntax, from quick installation to  deep customization, and more.

This book resembles a learning tutorial. It imitates the self-learning process so that you first understand the basics before we dig deeper into the advanced concepts.

You will first read about possible setups. Then, you will choose an appropriate setup to install and configure. The book runs through the main features of Redmine and shows how it can be effectively used as project management, issue and time tracking solution. Once you are familiar with all the essential features of Redmine, you will start exploring advanced concepts such as integration with other applications, customizing Redmine, and using various Redmine plugins.

This book will help you master Redmine by unleashing it's core functionality .

Publication date:
January 2013


Chapter 1. Getting Familiar with Redmine

When we are about to try a new web application we ask experts, who are familiar with it, what would they recommend us to use, for example, which database backend, which platform, and many more. That's what this chapter will try to do, it will help you learn what options are available and which one fits your needs better.

In this chapter you will also find a very short description of the Redmine interface. It's described in short because I believe it is easy to learn. You will be able to play with it more in the next chapters where we'll discuss how to install and use Redmine. So why this chapter should be of interest to you? The power of Redmine is in its components; some components influence performance, others influence functionality. I'm quite sure that even experienced users will discover new options in this chapter and may decide to switch to or utilize them.

In this chapter, we will cover the following topics:

  • What is Redmine?

  • Walking through the Redmine interface

  • MySQL, PostgreSQL, or SQLite

  • Textile or Markdown

  • Selecting a Source Control Management (SCM)

  • Selecting a web server and an application server

  • Redmine or ChiliProject?

  • Recent versions of Redmine and ChiliProject

  • Helping Redmine


What is Redmine?

If you search for a free project management tool most likely you will end up with Redmine. This is an open source Ruby on Rails web application, which can be considered to be the de facto flagship of project management solutions in the open source world. It supports all you need for effective project management: member roles, permissions management based on roles, Gantt charts, scheduling, calendar, roadmap, versions management, documents management, news delivery, files directory, activity view, and more. With third-party extensions, you may also get invoice management, Scrum backlogs, Kanban board, burndown charts, and more. But it's not only a matter of project management.

No one can tell whether Redmine is more a project management tool or an issue tracker. Ideally, a good issue tracker must have some project management features. In Redmine these two components are combined flawlessly. But what makes it a perfect issue tracking application is the fully-configurable workflow, which lets defining issue status change permissions for each role and tracker (issue type). As an issue tracker, Redmine also supports such essential features as priorities, sub issues, watching, comments, custom fields, listing filters, and more. Anyone who has ever worked in a team understands the importance of project documentation. For this purpose, many teams establish Wiki sites. Redmine ships with its own per-project Wiki system supporting the Textile markup syntax and source code syntax highlighting. The staggering thing is that this Wiki syntax is supported all over the Redmine that is in issue descriptions, comments, news, and so on. The syntax also allows you to have cross links to other issues and projects.

For public projects support, Redmine comes with a simple bulletin board module, which allows you to have as many forums as you need. Each forum can have an arbitrary number of threads. Forums and threads can be also watched.

Having read the above paragraphs one may think that the only missing feature for making Redmine host one's projects is some support for version control systems. But such support is also available. Redmine can be used as a repository source code browser. The repository component also integrates flawlessly into other Redmine components such as issue tracker and Wiki. For example, an issue can have list of revisions related to it, a Wiki page can link to a revision, a commit, a source file, and more. With some additional extensions, Redmine also can be turned into a repository manager or even play like Github. The list of supported version control systems is also impressive. They are Subversion (SVN), Git, CVS, Mercurial, Bazaar, and Darcs.

All the things mentioned above make Redmine a perfect application for project hosting. Many individuals and organizations use it for this purpose. But it's not limited to a single project – it is multiproject and each project can have subprojects to any nesting level. Many companies utilize Redmine's collaborative capabilities for forge or labs sites. However, it is not even limited to software development. Other companies use Redmine for customer support, order fulfillment, task management, document management, and more.

I cannot describe Redmine without mentioning the people who created this fabulous software. As soon as you open Redmine, you see the name of its primary author at the bottom of each page (near the copyright section), Jean-Philippe Lang. A huge contribution to Redmine was also made by Eric Davis who then forked Redmine into ChiliProject.

Why does Redmine succeed

The previous topic makes Redmine sound like some all-in-one software. To some extent it is. It was the evolution of Redmine that made it look like this. It is extremely popular these days and that's why it constantly gets new features. But what makes it so popular?

Having first seen Redmine I got the impression that it was a very easy-to-use and friendly application. It is not overloaded with design and UI elements and everything seems to be in its place. This makes users get used to Redmine and like it on first sight. The very first time I saw Redmine I also thought that perhaps it was too limited for my needs mainly because it looked too simple. Both impressions were wrong; it's not an easy-to-use software and it's not limited. The easiness of the look and feel however does its job. If you need only basic features you are ready to use Redmine right after you have seen it for the first time. When you need more advanced features you need to spend some time learning them. That's the main thing that makes Redmine so popular I believe.

The right tools are built with the right technologies. What make Redmine so "right" are Ruby and Rails. Ruby is known to be perhaps the most modern metaprogramming truly object-oriented language. This programming language is very flexible and is considered to allow building powerful applications fast and easily. All this can be said about Redmine. This all can be said about Ruby-on-Rails as well. Rails is a web framework similar to Symfony and Zend Framework but unlike the others it is the de facto standard for Ruby. Treat Rails as a construction set for building web services like Redmine. The names are so closely associated that many people believe they are about the same language. Ruby-on-Rails also became the source of inspiration for many frameworks and libraries such as CakePHP and Grails. Redmine is built on these technologies and this is the thing that makes it so good.

Of course, you can wonder what exactly is in Ruby-on-Rails that makes it good? The first thing is that Ruby (and therefore Ruby-on-Rails) supports metaprogramming. It's the technique which allows an application to modify its code (that is itself) at runtime. This means that there is almost nothing in Redmine that cannot be altered programmatically. Usually API of an application is limited to some functionality but there are no limitations in Ruby thanks to metaprogramming. What a good feature for plugin API, isn't it? The second thing is that Ruby-on-Rails establishes plugin API, which is used to develop Rails plugins called engines. So as you see Redmine does not actually need to provide plugin API to be extendable but it does. Redmine plugin API is built on top of the Rails engine API.

Thereby we come to the next thing, which makes Redmine so popular—its plugins. If you are familiar with Ruby and Ruby-on-Rails, you need to learn a little to start developing Redmine plugins. Taking into account that Ruby-on-Rails is very popular nowadays, Redmine has a huge amount of potential developers. Therefore it has a large variety of plugins. With its plugins you can even turn Redmine into a CRM or help desk. Some of the plugins will be reviewed in Chapter 10, Plugins and Themes.


The known issue is (at least partial) Redmine versions incompatibility. Redmine plugin API used to be changed from version to version without good backwards compatibility. It's even more critical as many plugins use metaprogramming for altering non-API (core) functionality. But in fact it's impossible to preserve full backwards compatibility in such cases. The same compatibility issue affects the Rails API that is especially seen in Redmine 2.0, which switches from Rails 2 to Rails 3. Hence, when selecting a plugin you should always check if it is compatible with the Redmine version you are using.

And last but not the least important benefits are that Redmine is cross-platform open source and freely available. Open source code and GPL license makes any modification possible. Nothing limits you in making Redmine better fit your needs.


Walk through the Redmine interface

It's always better to meet than to only hear about. I cannot imagine a reader who is familiar with Redmine but has never seen it. So let's start with checking the Redmine interface.

As mentioned earlier, Redmine has an easy-to-use and simple interface. The following screenshot shows its Home page:

On the top-left of the page, we have the global menu (Home, My page, and so on). To the right-hand side of the page, we have the account menu (Logged in as). The blue area below these menus contains the site title. And finally the content area contains site introduction, recent news for all projects and recent projects.

Actually any page in Redmine can be either a global page (the previous screenshot) or a project page:

This is the start page for a project or the project home page. Most of the time when working with Redmine, you will be interacting with project pages. The blue top area on a project page contains the project title. The project menu is displayed below the title. The project home page contains a description of the project, issues summary, members summary, and the latest news about the project. Most project pages also have the sidebar with contextual information, such as links and forms.

As one of the primary features of Redmine is issue tracking, let's check the issue list:

As you see the layout is quite simple and friendly. Collapsible boxes such as Filters and Options are used all over Redmine to hide rarely used elements. The order of issues in the issues-listing table can be changed by clicking on a header.

The following screenshot shows how an issue page looks:

In the top-right corner of the content area we see the contextual menu, which is duplicated at the bottom of the page. A similar type of menu is used for other Redmine objects such as projects, Wiki pages, and more. The big yellowish box contains issue details. Below this box, there is the changes' history.

Another UI element, which is intensively used in Redmine is the tabular menu. Such a menu can be found, for example, in the project settings:

Here we also see another UI element, which is widely used in Redmine - the Wiki syntax enabled text area.

The following screenshot shows how administration settings are implemented in a similar way:

This is another global page (similar to Home). Administration sections are available on the sidebar. Currently, we are in the Settings section, which also utilizes a tabular menu. On the General tab of the Settings section, we see Wiki-enabled Welcome text field.

This was a short walk through the Redmine interface to let you get used to it and understand its basic concepts. I hope you see that it is easy to use. We will review the interface in detail in subsequent chapters.


MySQL, PostgreSQL, or SQLite

Redmine can be used with MySQL, PostgreSQL, or SQLite database backends (actually the same backends that are natively supported by Ruby-on-Rails). But which of those should you use? It's perhaps too important a question to be ignored in this book. No, I'm not going to praise one of the databases or criticize another (it's out of scope here) but I'll cover things you should consider when choosing a database backend.

In its Installation Guide in the Database section ( at the time of writing this book, authors of Redmine added (recommended) to the right of MySQL. Let's try to understand why they recommended this backend.

Having worked with Redmine for a long time I noticed that most users use it with MySQL. It does not matter why they choose it but this means that Redmine has been tested better with this database backend. As long as plugins may use SQL directly (that is without using Rails SQL query builder) this argument becomes even more important. Also I'm sure there are plugins which have been never tested with other database backends.

If you are seeking a reliable source on what database is faster with Redmine, you can check Redmine build logs at These logs contain results of tests for different versions of Ruby and different databases. Thus at the moment of writing this topic the latest revision r9739 in the latest stable branch 2.0-stable contained the following timings (showing only ruby-1.9.3-p194):





Tests run 1




Tests run 2




Tests run 3








According to these data, SQLite is fastest and PostgreSQL is slowest. You can check new data or take several revisions into account to make sure.

You can ask: Why not SQLite then, if it's the fastest? SQLite has scalability issues (you can't put it on a separate server) and can potentially have problems with concurrent access. So, MySQL looks to be the optimal backend.


Textile or Markdown?

Good readability helps achieving perception. Rich formatting is very important for issue tracking software as it allows you to distinguish and highlight more important things thus drawing special attention to them. In Redmine, rich formatting is done using Textile syntaxes, which is supported almost in every text area. In addition, Redmine provides formatter API, which means that the default Textile formatter can be replaced.

There were attempts to add different syntaxes to Redmine Wiki but the only successful and still active non-native Wiki syntax plugin is the Markdown Redcarpet plugin ( This plugin replaced the default Redmine formatter with the Markdown formatter, which uses the Redcarpet library. This is the same library that is used by Github. Therefore the syntax provided with the Redcarpet plugin is compatible with Github's Markdown syntax.

If you asked what formatter I recommend, I would answer Textile. The Textile formatter is native, well supported, and well tested. However, when choosing a formatter you should consider your audience; if your audience is mostly Github users you should perhaps try Markdown but still remember that the majority of Redmine installations use Textile and users may expect your Redmine to use Textile as well.

But let's not be too verbose and compare basic rules of these syntaxes:




Bold text



Italic text



Underline text



Inline code

@inline [email protected]

`inline code`

Preformatted text




Text which starts with spaces

Syntax highlighting








Bullet List

* Item 1

* Item 1


* Item 2

* Item 2

Numbered list

# Item 1

1. Item 1


# Item 2

2. Item 2


h1. Heading 1

# Heading 1


h2. Heading 2

## Heading 2





h6. Heading 6

###### Heading 6











|Cell |Cell |



|Cell |Cell |


Selecting a Source Control Management (SCM)

Source Control Management (SCM) is better known as Revision Control Management. Revision control systems currently supported by Redmine include Subversion (SVN), Git, Mercurial, Bazaar, Darcs and CVS.

As mentioned, Redmine integrates SCMs nicely using them not just as source code readers but making more use of them. In Redmine, we can do the following: Associate a revision with issues (having revisions listed on issue pages). Automatically close an issue and/or change its done ratio when an appropriate commit has been made. Use Wiki syntax in commit messages. Refer a revision, a commit, or a file from a Wiki syntax powered content, which can be a Wiki page, an issue description, a project description, or a forum message and much more

But all this makes Redmine a source code browser not a SCM manager (that can be done with plugins however). So why is choosing the right SCM so important?

Unless you are fine with having SCM and Redmine integrated visually most likely you will want a deeper integration when you know the options. Three levels of Redmine and SCM integration can be distinguished as follows:

  • Redmine as a source code browser

  • Redmine as a SCM authenticator

  • Redmine as a SCM manager

The basic browser level requires SCM clients to be installed on the same server Redmine is running on so you may want to use only some of the supported SCMs. Also the basic support of SCMs is not equal: revision graph (similar to one on Github) is supported only for Git and Mercurial, however, these two SCMs can be only local (repositories should be on the same server, where the Redmine is).

Redmine comes with—a Perl module for Apache web server—which can be used to authenticate Subversion and Git users against Redmine. If the tool has been integrated, you can control who has access to project Subversion/Git repository and what kind of access (read and/or write) they have by simply managing project members (and roles). Something similar (with additional changes made to Redmine and/or system) can be done for Mercurial and Bazaar. Nevertheless Subversion and Git SCMs are best supported by and their support is out of the box. Most likely you will have problems configuring other SCMs to authenticate against Redmine.

The only missing functionality for Redmine to become a full-featured SCM manager is the ability to create repositories. And such functionality also comes with Redmine and is provided by the reposman.rb command-line tool. This tool supports Subversion, Darcs, Mercurial, Bazaar, and Git (all except CVS). The problem is that in order for it to work you need to create a cron job executing it periodically. Luckily alternative solutions exist and are provided by third-party plugins such as SCM Creator, Redmine Git Hosting, and Redmine Gitosis.

When choosing SCM, you should also consider your requirements, your experience, preferences of your team or audience, easiness or complexity of use and so on. However, the best integratable SCMs seem to be Subversion and Git.


Selecting a web server and an application server

Redmine as a Ruby-on-Rails web application should be run under a web server. This can be an independent web server such as Apache, Nginx, or Lighttpd running Ruby-on-Rails using either Passenger, FastCGI, or a dedicated Ruby web server such as Unicorn or Thin.

A big options list, isn't it? Actually these are not all the possible options. Redmine can also be used with JRuby under a Java virtual machine, can be run under standalone Passenger, under Mongrel, under WEBrick, and more. But the above options were chosen by practical use and, therefore, are most commonly used. So we review only them here. They can be divided into three categories:

  • Dedicated Ruby web server

  • Dedicated Ruby web server plus for example, Nginx as a load balancer

  • Separate web server with for example, Passenger module

Ruby often gets compared to PHP but actually these technologies are very different. For a PHP guy, which I am as well, using a web server written in Ruby for running a Ruby application can be weird. But in fact Ruby, like Java, also runs under a virtual machine. Therefore, for example, Apache in order to run a Ruby application needs to run a Ruby virtual machine as well so in total these are at least three processes: a web server, an application server, and an application itself. For this reason running a Ruby application under a Ruby server seems to be reasonable because in this case we get only two processes namely an application server and an application.

The lack of good multithreading support is a known problem of all Ruby virtual machines. This is the main reason why when running Ruby applications on production they usually use a Ruby application server in conjunction with another web server. As Ruby does not play well with multiple connections they run many instances of Ruby application server and use for example, Apache as a load balancer for forwarding requests to those instances and as a web server for giving static content (images, css files, and so on). The most documented option for this category is Apache plus Mongrel, the combination which, for example, was used by Twitter before the company moved first to Unicorn and then to Java. But the best combination, according to many benchmark results, is Nginx plus Thin or Unicorn.

But in fact this configuration uses not only a web server and an application server but also a load balancer. A web server needs to support the reverse proxy mode to be able to act as a load balancer. For Apache, this mode can be provided by mod_proxy, Nginx, and Lighttpd have built-in proxies. In addition, a good idea is to use some software for monitoring Unicorn/Thin instances, for example, onit.

You perhaps got the feeling that the just discussed category is for advanced usage and for high loaded services? Yes, it is in a way. The most commonly used, easy-to-install and best documented is the third category: a web server running a Ruby application using the Passenger module (also known as mod_rails) or the FastCGI module. The Passenger module is in fact another Ruby application server. The difference between it and Unicorn/Thin is that it usually runs as a module of a web server and not as a standalone server (while the last is possible). The problem with the Passenger is that it does not work with Windows. Also, the Passenger module is not available for Lighttpd. Thus, Lighttpd uses FastCGI for running Redmine instead. FastCGI, which is actually a protocol name, can be also used under Apache and Nginx.

However, the Passenger is more popular. It is used, for example, by BitNami Redmine stack and TurnKey Redmine appliances (systems for easy deployment of Redmine). In addition it is suitable not only for small and middle-sized websites but can be used for high-loaded web services as well. Thus, for example, Ruby-on-Rails framework recommends using Passenger in flavor of other options (

When run under a web server the Passenger creates at least two processes—itself and an application. This can be a problem if it is used on cheap OpenVZ powered VPS hosting where memory amount used by an application is very critical. This is where FastCGI helps: when run with FastCGI Redmine occupies at least one process (application).

In case you still don't feel sure about which option to choose, let's summarize:

  • If you plan to use Redmine for a heavy-loaded forge site you should think about using Nginx with Unicorn/Thin and possibly HAProxy.

  • For all other cases or if you are just unsure go with Apache or Nginx and the Passenger module.

While choosing you should also consider your other requirements and services you plan to run on the same server. For example, you will definitely need Apache if you plan to use for authenticating Subversion/Git users against Redmine.


Redmine or ChiliProject?

In the open source world, a good project can't just die or become worse because such projects always have a community ready to support it or take it over. If something goes wrong with a project its community can always make a fork. But the reason for making a fork can be just a wish to make the project better. Usually the appearance of a fork also divides the community, however, this does not make the fork or the project worse. In fact with the fork the original project gets a solid competitor—itself. And competition is what makes project developers strive for the best.

The history of open source knows many examples of forking and rewriting software what ends with the appearance of a new, better, or just different project. We do not need to search for such examples: Joomla was forked from Mambo, Gforge from SourceForge, X.Org from XFree86, Apache from NCSA, LibreOffice from, and many more.

You perhaps noticed that every page of Redmine contains a line Powered by Redmine © 2006-2012 Jean-Philippe Lang at the bottom. Jean-Philippe is the author of Redmine and its project manager but there were more people involved in this great project and one of them was Eric Davis. In 2011, due to project management concerns and community patches inclusion policy Eric Davis with some other Redmine core developers (most of whom are finnlabs ( employees) forked Redmine into the ChiliProject. This is how forking is explained on the ChiliProject site (

However, in the view of some of Redmine's leading developers, the maintenance and evolution of Redmine has not been as predictable and responsive as its developer community is capable of. Integration of community-created patches were too sporadic, lacked a clear methodology, and was interfering with the effectiveness of the Redmine project for its users. Over the past two years, several members of Redmine's community worked to resolve management bottlenecks through clear suggestions and contributions. They also attempted to broaden and open up the development process to more contributors. But efforts via public and private forums to discuss the goals and future direction with the project manager of Redmine failed, as the current project manager did not share these priorities.

A group of developers from the Redmine community has therefore concluded that the only way to ensure continued, sustained and stable development of our favorite project management solution is to fork it. We, long-standing community members and contributors, pledge to uphold the ideals of Free and Open Source Software ethics, governance and development practices in order to produce a reliable project management system released under the name of ChiliProject in February 2011.

Luckily at the moment Redmine and ChiliProject do not differ much so almost everything written in this book applies to ChiliProject as well.

So which one to choose? Let's discuss the difference now:

  • Of course, Redmine is older. It has been proven to live, to survive and be successful, its developers were active over five years and continue to be (besides Jean-Philippe there are Toshi Maruyama, Etienne Massip and others), it's stable.

  • Redmine has a bigger community than ChiliProject. But this does not mean that ChiliProject is worse though, most users have not moved to ChiliProject because they see no reason. Such a big community is mainly due to age. However, this means that most likely you will get support for Redmine faster.

  • Redmine comes in Bitnami, Turnkey, it is available in official repositories of Debian and Ubuntu, it is available for hosting at, HostedRedmine and more. But again it's mainly due to its age.

  • Redmine does not get changed much, it feels like a well supported software with major changes coming rarely (except 2.0.x which moved to Rails 3 but it was a developers' headache, not a users'). By changes, here I meant functionality and UI changes, which required users to update their third-party tools or get used to.

  • ChiliProject, on the contrary, introduces major changes with each major release. It feels like ChiliProject developers finally have a possibility to implement things they've wanted for a long time. However, these changes add much work for developers of third-party tools and many things should be learned by users.

  • ChiliProject promotes openness of development process and readiness for contribution. If you or your organization plan to modify the core or you just feel you or your organization can do this and you are ready to share your modifications, you should consider using ChiliProject. To some extent ChiliProject is for enthusiasts and advanced users.

  • ChiliProject lacks a good plugins registry which is available for Redmine, it has only a plugins compatibility list. However, Redmine plugins registry is far from being perfect (for example, it's incomplete and lacks some search capabilities).

  • The situation with themes is even worse: Redmine has many themes but they are not compatible with ChiliProject anymore since Version 3.x of the latter. ChiliProject 3.x does not seem to have any third-party themes available (ChiliProject prior to 3.0 worked fine with Redmine themes).

Having mentioned theme changes in ChiliProject 3, let's see what its new default theme looks like:

Some up-to-date information about differences in Redmine and ChiliProject is also available on the website of the latter:

You might expect features comparison in this topic. But theoretically features of Redmine and ChiliProject can be merged relatively easily into each other. So any features comparison here can become outdated when this book comes into your hands. So instead I decided to review different approaches these projects are taking. I hope this information is enough for you to decide.

Overall, ChiliProject seems to be in "transitional" period when its features, look and feel, design, and so on are changed and at the end of this period ChiliProject will turn into a completely different project management solution. Maybe it worth waiting for this period to finish but maybe it's worth helping the ChiliProject guys to move.

On the other hand, Redmine is a proven, stable solution, well-known, and well-documented.


Recent versions of Redmine and ChiliProject

In most cases everyone uses the most recent version of an application, which is 2.2.x in the case of Redmine. But there can be a choice. Thus, some stable Linux distributions come with older Redmine versions. Should you stick to that version or should you install the recent one which is more complex and assumes further manual checks for updates and doing multiple manual migrations? Besides, what if your organization uses a hardly modified copy of Redmine and therefore sticks to a particular version? Should you allocate resources for a hard migration? To answer such questions you should know a few things about those versions such as what do you lose, what will you get and so on. In this topic, we will review primary features introduced by some recent versions of Redmine and ChiliProject.

Redmine versions

At the time of writing this topic the recent version was 2.2.x. We will review all major versions down to 1.4.x.

  • 2.2.x

    This version comes with the following noticeable features:

    • Support for private comments in issues

    • Working days configuration

  • 2.1.x

    This version upgrades Redmine to Rails 3.2.x, which switches from Prototype to jQuery. This also requires developers to update their third-party tools. Besides, the version comes with the following features:

    • Ability to require issue fields or make issue fields read-only per status, tracker, and role

    • Support for subforums

    • Ability to close (freeze) projects

  • 2.0.x

    The Version 2.0.x is the upgrade of Redmine to Rails 3.1.x. It was released along with Version 1.4.x that is we got two stable versions at the same time (nothing like this ever happened before)! This version was released mainly for developers so they could upgrade their third-party tools.

  • 1.4.x

    This version includes the following new noticeable features:

    • Support for multiple repositories per project

    • Support for multiple values for "List", "User", and "Version" custom field types

    • Ability to add non members to the watcher list of an issue

Basically, due to migration to Rails 3 and, therefore, huge changes in API at the time of writing this book, not all Redmine plugins have been ported to Redmine 2.x.x yet.

ChiliProject versions

The most recent version of ChiliProject at the time of writing this topic is 3.x.x. Unlike previous versions, this version ships with some new interesting features. Earlier there were versions 1.x.x and 2.x.x but only the latter was bringing a really new project.

  • 3.x.x

    ChiliProject 3.x.x was released with the following noticeable changes:

    • Comes with new design (not compatible with Redmine themes any more)

    • Introduces Liquid template language (conditions, loops, and more in Wiki)

    • Support for issue tags

    • Comes with jQuery

  • 2.x.x

    ChiliProject 2.x.x is compatible with Redmine 1.1.x and comes with many internal changes.


Helping Redmine

What would be Redmine without many people contributing to it? Most likely it would not exist at all. Any contribution is very important for a free open source project, an active and passionate community is what makes such projects good.

Hearing about contributing to a free open source project most people assume some development but there are manu more areas where you can help. For example, this book helps Redmine by spreading information about it, teaching how to use it and demonstrating its abilities. You help Redmine by purchasing this book not only because you become a potential fan of this project but also because Packt Publishing, the company which publishes this book, will pay a royalty to Redmine.

Let's discuss how else can you can help Redmine:

  • As it has been already mentioned let's start with development: If you are a developer you can help by contributing code or patches to Redmine. To do this you should know Ruby and Ruby-on-Rails but if you know Perl you can still help by improving You can help even more if you know HTML and/or JavaScript because these technologies are intensively used by Redmine and may need improving. If you know neither of the above technologies you can still help by for example, developing a REST API client library for Redmine using technologies you know.

    Some links regarding development for Redmine:

  • If you are a designer you can make new themes for Redmine. This is an extremely important area as a good theme attracts more users.

  • You can write articles, blog posts, tutorials, improve source code documentation (which uses RDoc), and more. You can do this in English or any other language.

  • Regarding other languages: You can also translate Redmine, its official or unofficial tutorials and so on, into other languages.

  • If you are just a user or are going to become a user, do not neglect to report bugs or to suggest new features. If you are not sure that something is a bug still open a discussion on the Redmine forum and ask the community. Many bugs are hard to find and not many people report them.

  • And last: You can show your support for Redmine by making a donation.

In a similar way you can help not only Redmine but also its fork ChiliProject and many free open source plugins for Redmine.



The goal of this chapter was to familiarize you with Redmine and get you ready to dig deeper into this web application. Therefore we have reviewed not only advantages and the interface of Redmine but also have checked its installation components. We have also discussed ChiliProject as it's a community fork of Redmine and it's important to know about it if you become (or have become) a member of the Redmine community.

I tried to share as much knowledge about Redmine, its fork and its installation components as possible so you could understand them better, learn what options you have and would be able to choose the right option. Still remember that usually the best option is the one which is used by most users so if you choose an uncommon option you should be sure about the reasons for doing this.

The knowledge you have gained reading this chapter will help you in the next chapter as you will need to decide what components you will use for installation. However, the next chapter covers only common options. Anyway if you chose other options it's still worth reading the next chapter to see how the installation is done.

About the Author

  • Andriy Lesyuk

    Andriy Lesyuk is an open source evangelist. He is an enthusiastic and passionate developer with more than 14 years of experience. He is skilled in Ruby, PHP, Perl, C, and more. His primary areas of interest are web development and Linux system development. Andriy is also the author of more than 20 open source plugins for Redmine. He lives and works in Ivano-Frankivsk, Ukraine. His website is He started his career as an engineer at the Ivano-Frankivsk National Technical University of Oil and Gas, where he later became the head of the Software and Networking Laboratory. For some time, he worked as a freelancer, developing custom Redmine plugins for companies worldwide, the most famous of which is oDesk. Later, Andriy joined the Kayako team, which develops the world's leading helpdesk solutions.

    Browse publications by this author

Latest Reviews

(1 reviews total)
Book Title
Access this book, plus 7,500 other titles for FREE
Access now