Project Open 3.5.x

Delegating ITSM Release Item Management

Project Open includes some really powerful and easy to use ITSM Release Management tools. Well, powerful and kinda easy to use. Once you know the secret.

Now, this might be stunningly obvious to many of you, and if it is, please do feel free to ignore this article. But if you have ever wondered why your non-PO Admin users can’t see the list of Release Items on your project Releases, this article might help sort things out.

Consider the simple project hierarchy shown in Figure 1.

Figure 1: This is a simple project hierarchy.

This project has a single Software Development project called “Upgrade Many Things 2011.” This project has a single Release called “Software Releases for 2011_0051”, which uses a naming convention I implemented to prevent Release names from duplicating across multiple projects*. Finally, it includes three Release Items called “File Processor 1.2.0”, “File Mover 1.1.0”, and “File Encrypter 1.1.0”. If I click on the Release and scroll down to the bottom of the page using an ID in the PO Admin group, I can see the ITSM Release Items, as shown in Figure 2.

Figure 2: The Release lists each Release Item, and each has its own status.

I can set a separate status for each Release Item. My Project Manager can watch as each piece of software marches through its life cycle. Life is good! Good, that is, until I ask my Design Leader to conduct his testing and update the status for select Release Items. When he clicks on the Release and scrolls to the bottom of the page, he sees what’s in Figure 3.

Figure 3: By default, the Design Leader won’t see Release Items.

He sees nothing! My Design Leader immediately lost faith and confidence in me for asking him to do something that wasn’t possible. Morale plummeted!

I felt foolish, but you can learn from my pain! It turns out to be fairly easy to give individuals the ability to both see and manage Release Items.

First, while logged in as a PO Admin, navigate to the Admin tab and click on the Portlet Components URL.

Scroll down until you find the Release Items Component. It looks like the one in Figure 4.

Figure 4: You can control who can see the Release Item portlet here.

Notice that all of the “r” characters beside it are lower case and not bold. If you go back to the top of the screen, you’ll see a bunch of little icons indicating the groups you’ve defined. Hover your mouse over all of them until you find the group that contains the IDs you’d like to be able to see the Release Items. Follow that column down to where it intersects the Release Item Component’s line and click on the “r”. It should change to look like the one in Figure 5.

Figure 5: This is what the “r” looks like when selected.

After I made that change, my Design Leader could see the Release Items, but he could not change them. What was the big blank white nothing from Figure 3 now looks like Figure 6.

Figure 6: At least this is progress!

I found the clue to the last step I needed to do in the source code in this file:


It contained this comment:

# -------------------------------------------------------------
# Permissions
# The project admin (=> Release Manager) can do everything.
# The managers of the individual Release Items can change
# _their_ release stati.

When I had added the Design Leader to the Release, I had added him as a Full Member. However, if I delete him and re-add him not as a Full Member but as a Project Manager (for the Release only), the next time he logs in, he sees the screen in Figure 7.

Figure 7: After changing the Design Leader from a Full Member to a Project Manager, he can edit the Release Item statuses.

In other words, I made Design Leader a Release Manager for that Release. I didn’t change his permissions for the Project or for the Release Items; he was still a Full Member there. However, on the Release itself, I made him a Project Manager.

It’s easy in retrospect, and I’m sure it’s documented somewhere besides the source code. I just couldn’t find where. But now, I can delegate some steps in our Software Development Life Cycle to responsible team members so everyone can help move the project forward.

I hope this helps you avoid the embarrassing situation that engulfed me!

* This implements my philosophy of better living through standards.

Terrance A. Crow is the Senior Security Engineer at a global library services company. He holds a CISSP and has been writing applications since the days of dBASE III and Lotus 1-2-3 2.01.