Redmine: Estimated Time as mandatory field

At work, we are using Redmine for all our project management needs. It is a flexible and powerful system that allows flexible configuration for the processes of most companies.

Recently, we have decided to make the Estimated Time field mandatory for all the tickets. Configuring this turned out to be trickier than I thought initially. I couldn’t find the option to do so on the first go.

Some Googling around suggested that Redmine’s source code needs to be modified for that. Not something that I wanted to do. And the tip is also from 8 years ago, so it’s probably quite outdated.

After digging deeper, I found a way, that doesn’t require source code changes. This can be accomplished via editing the Field Permissions in the Workflow. Here’s the process (for Redmine 3.3.0 stable, that we run currently):

  1. Login to Redmine as administrator.
  2. Navigate to the Administration screen (a link in the top bar or so, depending on the skin you are using).
  3. Navigate to Workflow.
  4. Switch to Field Permissions tab.
  5. Select desired roles and trackers.
  6. Press Edit button.
  7. Scroll down to the Estimated Time field.
  8. Select Required from the dropdown for each status, as needed.
  9. Press Save button.

You are all done. Now all tickets of the above selected trackers will require the input of the Estimated Time for all above selected statuses and roles.

Similarly, you can make other fields required or read-only, as per your company or team needs.

Deploy and Maintain Redmine, the Right Way


Jens Krämer wrote this nice guide to deploying and maintaining Redmine the right way.  This is basically a combination of the official Redmine documentation with a variety of guides on deploying and running a generic Ruby on Rails application.  The solution is rightfully focusing on git, combining the upstream patches with your own changes.  And given that this is “the right way”, you don’t even have to have any of your own changes.  Just being prepared for some is good.

Once you’ve setup the proper environment, you can further automate the deployment of Redmine with Capistrano.  If you don’t use Capistrano for whatever reason – no worries, the process is easily adoptable to whatever build/deploy tool you are using.




Using tables with Markdown in Redmine


We use Redmine for our project management needs in the office.  It works pretty well, but there are, as with anything, a few rough corners.  One thing in particular that I was trying to figure out is how to use tables in Wiki pages, issues, etc.

The official documentation says that tables are not supported and you need to use HTML.  Yuck.  I do, of course, know how to mark up tables in HTML, but that’s definitely not the most pleasant of experiences.  Especially if you need to modify them later.  So I dug deeper.

It turns out that the documentation is outdated.  Modern Redmine versions (we are on 3.3.0) use the redcarpet library for parsing Markdown, which supports tables just fine.  Here is an example of the Markdown that you can use in pretty much any textarea field:

| Header 1     | Header 2     |
| ---          | ---          |
| Row 1 Cell 1 | Row 1 Cell 2 |
| Row 2 Cell 1 | Row 2 Cell 2 |

And it’ll render as a table just fine. The dashed line separating headers should have at least 3 dashes for the parser to understand it correctly. But you can extend the dashes for the whole width of the column.




Infrastructure update : GitHub, BitBucket, HipChat, TeamworkPM and Redmine


It’s been a while since I posted an update on our infrastructure tools, so here goes one.  (I know, ideally, it should be on our company’s blog, but we haven’t finished that part of the site yet).

Continue reading Infrastructure update : GitHub, BitBucket, HipChat, TeamworkPM and Redmine