Product Idea

Hi  Kristina,
I think I've posted this request in to old forum but can't be 100% sure.

In our company we have dedicated test teams that look after all aspects of testing our products.

In order for our team teams to create a Test Plan, they need Manage Project permissions, which gives them more permissions than needed (desired). These teams are in various sites around the world (so I can't walk over and politely correct any hiccups!).

We need something like "Manage Tests" permission at the project level (as Test Plans do not appear in the project tree).

Is there anything in the pipeline or on the horizon that looks at improvements to Jama's permissions model?

Hi George,

are you using JAMA 2014.2 or older? It is changed in 2015.1. Check the release notes for 2015.1:

"Changes to Permissions
Permissions for creating test plans have been changed from requiring "Manage Project" rights to requiring Create/Edit permissions to the entire project. This will free up the ability to give users access to creating test plans without also giving them access to project configuration capabilities. This was a top request from customers who do a lot of testing within Jama."

D'OH!

Hi Sebastian,
Yes, our production version is 2014.2. We have a development server running 2015.1.
I didn't spot the change (the help link to the permission table is broken as mentioned in another thread).

There's nothing as silly as asking for a feature that's already there!

Thanks for putting me straight.

Hi George,

At the company where I'm working as part of the post-migration to on-premises 2015.1 version we are identifying all the project admins who need to be "demoted" to authors since they only need to manage test plans.

On the other hand, some people are not happy that now any author can edit test plans. Oh well. Your idea of "manage test plan" permission is actually a good one that Jama should have listened to if time travel is allowed :-)

swoo

If only time travel were allowed...

Someone had to post this...

Hahaha!

I'm with swoo that it would be nice if more permissions relating to test object management were added, but this change is a nice short term mitigation to help folks out and is much appreciated.

I do have 2015.1 installed locally, but all is not well... :( (Specifically, build version 2015/04/03 10:36 on our test instance of Jama)

I have test automation code that logs in via an Active Directory service account.

My test automation service account belongs to two projects (that are worth discussing): A and B.

In project B (which is the Jama project the unit tests for the automated code uses) the service account has manage project access and all of the createNewTestCycle SOAP API calls succeed. 

The reason for this permission setup in project B is historical in nature, and the service account really should have create/edit permissions only. The service user only cares about testing related artifacts at present.

In project A however, (which is where the unit test results need to get published) the service account has only create/edit permissions.

When the service user calls the createNewTestCycle SOAP API against project A it fails with a permission error.

However, when I login into the Jama web UI as the service account user and try and create a test cycle for project A (using as close to the same parameters as possible with the web UI) the test cycle is successfully created. 

Fyi,
Bill

Hi Bill,

As regard to your "all is not well" comment, Jama is observing a US holiday (one day before July 4th Independence Day) today. I'm sure Kristina will get back to you next Monday. Good luck.

swoo

I'm not worried, I'm in the US and my admin and I have today off as well. I'm sure we will just grant the service user manage project rights. It's certainly not the end of the universe for project A, but it would be nice not to need it for our other projects.

Bill

In 2015.1, the service user should be able to execute tests with create/edit permissions, provided those permissions exist on the project-level (rather than a set-by-set basis)—unless there is some limitation with SOAP and these permissions that we haven't stumbled upon. If you'd like, I can create a support ticket for this.

I'll go ahead and do that tomorrow, I'll grab SOAP traffic with Fiddler that shows the permission denied exception to assist with the ticket. I would have done it today, but today I was discovering how the 2015.1 WSDL bindings aren't backward compatible with older WSDL output from Jama for wsItem. (The 'lastActivityDate' element was added in the middle instead of the end of the XML Schema sequence, and so everything after 'isStructureOnly' wouldn't get correct deserialized with a XML Schema conformant WSDL binding like .Net uses.) 

Happily, regenerating WSDL bindings isn't hard, but annoying.
I already created a ticket for the wsItem issue.

Fyi,
Bill