It's all about the answers!

Ask a question

In RTC, why does modifying the iteration structure require 'modify the process specification' permission?

Jaygee Santos (272811) | asked Jul 29 '14, 6:57 p.m.

We are on CLM v4.0.2 and we have unchecked the 'modify process specification' permissions for all roles in RTC project areas.  The intent is to only have the RTC Administrators modify any of the templates due to standardization of process within the company.  There are integrations being set between RTC and other tools that require standard templates for everyone which is driving this.

Now i am seeing unexpected behavior with respect to modifying the iteration structure within a timeline.  Here is an example:

Main Development

-  Release 1.0

  --    Iteration 1

  --    Iteration 2

-  Release 2.0

  --    Iteration 3

  --    Iteration 4

A project member with "Team Lead' role wants to move either Iteration 3 or 4, from Release 2.0 to Release 1.0, or

he wants to move Iteration 2 from Release 1.0 to Release 2.0

Once he tries to save the changes, he gets the error:

CRJAZ6053E The 'Save Project Area' operation cannot be completed. Permission is required to complete the operation. For more details, open the help system and search for CRJAZ6053E.

In order to carry out this operation, you would need permission to perform the following additional actions:
Modify the process specification
The Team Lead role has been provided permissions to modify the iteration structure, which includes modifying the collection of timelines and modifying the structure of iterations.  In fact, the role has all permissions under Modifying a project area checked, except for process specification.
Is this a bug and has it been fixed for a subsequent release?  We need a fix for this as we have to provide the project/team access to modify their timelines, but not the process specification/templates.
We are planning to upgrade to CLM 4.0.7.

Accepted answer

permanent link
Ralph Schoon (62.3k33643) | answered Jul 30 '14, 3:37 a.m.
I tried and this is the same for me in 5.0. since there are separate selections, I would expect you to be able to do this. I would consider this a defect and suggest to open a defect here: or PMR with support.
Jaygee Santos selected this answer as the correct answer

One other answer

permanent link
Jaygee Santos (272811) | answered Jul 30 '14, 9:22 a.m.
Thanks Ralph.  We're going to open a defect for this as we now have to consider workarounds for the project teams since we can't give the process specification permissions. 
1) Request a JazzAdmin to do move the iterations if they need to (can cause delays/bottlenecks)
2) Project team does not move iteration - creates new one where it should move and archive the old one (inconvenient and tedious as they would also need to re-slot all Work Items from the iteration).

Ralph Schoon commented Jul 30 '14, 9:36 a.m.


with respect to move iterations. In general I would consider.

  • Iterations don't move. Even dates only rarely move - at least if you are agile.
  • Make sure to have a good naming schema e.g.

Main Development

-  Release 1.0

  --    Iteration 1[R1]

  --    Iteration 2 [R1]

-  Release 2.0

  --    Iteration 1 [R2]

  --    Iteration 1 [R2]

Or for example

-  Release 1.0

  -- Milestone 1

    --    Iteration 1 [M1, R1]

    --    Iteration 2 [M1, R1]

  • Have unique ID's and show the iteration hierarchy in the display name - the ID can be very similar, based on that hierarchy.

Just some thoughts.

Jaygee Santos commented Jul 31 '14, 1:36 p.m.

Thanks Ralph, I agree iterations normally shouldn't move and also good naming conventions.

We have opened a Defect

Your answer

Register or to post your answer.