Tuleap 10.2 June 2018

It’s time to grab a nice cup of coffee, 10.2 is here and the list of changes is long. New features for those who organize things, for those who are doing them, for those who are testing things (and if you are doing all that yourself, you are going to be happy). Even if your thing is to write complex math formulae we have something for you !

Colors on cards in kanban


Scrum and Kanban

Scrum and kanban pushes one step further the visual management.

You can now associate a color to a concept (importance, type of issue, etc). This color can be used as cards’ background in Scrum cardwall & planning views (see below), in Kanban (release outline) and in tracker cardwall renderer.

Colors on cards in scrum cardwall

Colors on cards in scrum planning

The feature is automatically activated in new Kanban with field “Importance” (default to None) that can be set to “High”, associated to Red color, to outline urgent elements (use it sparsely otherwise it defeats the whole purpose of the feature).

For Scrum or tracker cardwall renderer there are no default configurations provided, it’s up to you to adapt to your usage. To configure you will need to set a background color in tracker semantics and the colors are associate to field values using a brand new and beautiful color picker. The color picker replaces the legacy one in all places (including in scrum cardwall columns). The legacy color picker is still available for backward compatibility.

New color picker

Accessibility is also taken into account. Colorblind people can activate it in their preferences (account settings), then, in addition to colors they will have distinct marks to identify various backgrounds. You can see it in action on tracker cardwall renderer.

Cards made accessible to colorblind

Git pull requests

Much of this story is an internal refactoring so you won’t see much on the user interface. However it’s a major leap forward in pull request support in Tuleap: pull requests get a real object in git repository.

Until now, pull requests were managed from the source branch of the request: diff was computed based on that, the continuous integration was configured on the source branch, etc. It was working quite well but at some limitations (see hereafter what’s possible now).

Starting Tuleap 10.2, when one create a pull request on repository a new git reference is created internally (in the form refs/tlpr/XXX/HEAD for those that are in the git things, and yes we are quite proud of the namespace :D). This branch is accessible in read-only to all people who are granted read access to the repository but only Tuleap can write in it. As a developer you won’t see the branch by default as git UI displays only refs/heads and refs/tags during listing of branches and tags. However if you run a git ls-remote the new objects will show-up.

What does it change you should be aware of ?

At 10.2 upgrade there will be a conversion phase


In continuation of the epic of moving artifacts between trackers the move REST route now moves comments (content, authors, dates and changes on moved fields).

The first part of the story got its way into the release. Tracker admins can reduce the amount of notifications sent by their trackers with a new notification option.

New notification options for tracker

When “Status change notification” is selected, instead of getting an email every time someone changes something in an artifact you are involved, you will receive notification only when status (as per semantic) changes.

Note: if you are in a “Global notification” for this tracker, this default will not apply to you.

Test management (Tuleap Enterprise only)

Steps in TTM are getting real and usable. It’s not yet completed but it already brings a net advantage over using test’s description for long tests.

Example of steps in test management

After having added “Step definition” field in “Test definition” tracker and “Step execution” in “Test execution” trackers, you can add Test Definitions artifacts (only in tracker view for the moment, the feature is not yet accessible in TTM modal window for test edition or creation). You can add as many steps as you need. You can also delete steps.

At execution, default action is to mark test as passed but one can select any other value from the select box (see screenshot). The rules are

Early adopters can start experimenting, those who ain’t time for that should wait a bit. Keep in mind that tests you are modifying to leverage steps now will probably need an update when we introduce the distinction between ‘Actions’ and ‘Expected results’ (due in 10.3).

Another nice addition of 10.2 is that tests that get updated by robots (automated tests) are now visible in real time while you are running your manual tests.


The Math extension provides support for rendering mathematical formulae. An overview of what can currently be done with this extension is found at the English Wikipedia’s documentation.

Checkout administration guide to install the needed packages

RHEL7 support

Site administration

It’s now possible to better control how projects are requested. As site admin you have 2 new options:

Both options aim to ease site admin work regarding project moderation. During this work a couples of things where modified to make project moderation a little bit easier:

Site admin project configuration


Framework and internals improvements

On the road to PHP7

Releases stats

Validation scores

Tuleap 10.2 results

Bug fix





Document manager

Time tracking (Tuleap Enterprise)

Test management (Tuleap Enterprise)

Dynamic credentials (Tuleap Enterprise)

Pull requests

Project admin

Legacy trackers

Site administrator & system administration

Websites located at tuleap.org and other tuleap.org subdomains need to store and access cookies on your device. We need your acceptance. Get more information. Yes, I agree No, I disagree