Selective over-riding of the parent process XML is not currently
supported. This been requested in work item 139992. This work item
depends on support for "process fragments", which is requested in work
item 29537. Please feel free to add a comment to either work item, to
indicate your interest/support.

Cheers,
Geoff

On 2/25/2011 4:08 PM, ianonymous wrote:

Hi Martha (and Everyone),

I am in a similar situation wherein we upgraded from RTC 2.0 to 3.0,
and would like to take advantage of the process sharing
functionality. I followed Claudia's steps and created an Unconfigured
process template, and managed to get the process sharing working.

However, I do not understand how to go about overriding the shared
process template selectively. For example, one of the projects wants
a minor override to the shared process template's permissions, so
that they can make changes to a custom attribute. What is the best
way to make this change?

If I go through the "Process Configuration" tab and edit
permissions for modifying that particular attribute, the other
permissions are lost because this one change is causing an override
of ALL permissions inherited from the shared project's process. In
other words, the XML source is now defining permissions very narrowly
in the<role> and<operation> hierarchy.

So what is the right "granularity" for editing the XML? Do I
need to copy the XML source under<permissions> from the shared
process, and then edit it? Or does this need to happen at the
team> level? What will happen to stuff defined under
project> if the "child project" modifies the
team> section? Will it still be inherited from the shared
parent?

I hope I have explained my problem clearly. Please let me know if you
need any clarifications.

Thanks.

Jared and Geoff,

Thank you very much. That was very helpful and informative.

Hello all,

Please, Could you confirm my understanding ?
If I have all my PA upgraded to RTC 3.0.1 from RTC 2.X, what is the best way to set a Master PA for these already existent PAs ?

I understood that I should follow these steps:
- Create a new project (as admin). Save the project first.
- Select "Allow other project areas to use this project area's process".
- Add roles and a new work item type to the new project that is acting as the "master" process for your repository.

Now, if it was a new PA, I should do the steps:
- Create a new project. Make sure Unconfigured Process is selected.
- On the Application Administration page of the web client, click Project Areas.
- In the Active Project Areas list, click the project area that you want to modify.
- On the Overview tab, scroll to the Process Sharing section.
- Select Use the process from another project area for this project area.
- Click Change and select the project area whose process you want to use. To select a project area from an application that is registered with a different server, select an entry in the Application field, then select the project area.

As it is an already existent PA, with a lot of connected information (work Items, templates, rules), I understood that I would loose a lot of data doing this, so I should manually modify the XML for each PA, and there isn't an easiest way for a while. Is that correct ?

Do you know about samples or more documentation that could guide me on how to modify the XML file to use the "Master PA" ?

Thank you,
Isabel Murakami

Hello,

Yes your understanding is correct; there is no automation to support removing unneeded configuration information from a process consumer. So, it must be done by hand.

The online help has information about Process Sharing hee:
https://jazz.net/help-dev/clm/index.jsp?topic=%2Fcom.ibm.jazz.platform.doc%2Ftopics%2Fc_sharing_project_area_process.html

This work item also has some good information:
https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/153393

Martha
Jazz Developer, Process team

Hello all,

Please, Could you confirm my understanding ?
If I have all my PA upgraded to RTC 3.0.1 from RTC 2.X, what is the best way to set a Master PA for these already existent PAs ?

I understood that I should follow these steps:
- Create a new project (as admin). Save the project first.
- Select "Allow other project areas to use this project area's process".
- Add roles and a new work item type to the new project that is acting as the "master" process for your repository.

Now, if it was a new PA, I should do the steps:
- Create a new project. Make sure Unconfigured Process is selected.
- On the Application Administration page of the web client, click Project Areas.
- In the Active Project Areas list, click the project area that you want to modify.
- On the Overview tab, scroll to the Process Sharing section.
- Select Use the process from another project area for this project area.
- Click Change and select the project area whose process you want to use. To select a project area from an application that is registered with a different server, select an entry in the Application field, then select the project area.

As it is an already existent PA, with a lot of connected information (work Items, templates, rules), I understood that I would loose a lot of data doing this, so I should manually modify the XML for each PA, and there isn't an easiest way for a while. Is that correct ?

Do you know about samples or more documentation that could guide me on how to modify the XML file to use the "Master PA" ?

Thank you,
Isabel Murakami

We use Process sharing, on 3.0.1.1 today..

but we have a new problem, and don't know how to solve it cleanly..

some parts of the customized defect workitem are project centric,
and some are enforced, globally across all projects..

so

1. we cannot use Final, cause we NEED to configure at the children projects
2. we don't have admin control over what attributes the children are allowed to configure, so will have to setup a central team to maintain these modified children
3. once A (any) change is made to a child project process areas, it becomes completely disconnected from the parent.. and future changes to the parent process config are no longer seen..

as an example,we had to add a 'feature' enum for each project, which separated team from technical content, cause category changes if the receiver ina drag drop has a different default team assigned.. (drop a compelted workitem in backlog onto a plan and watch what happens to category)..

but now this feature needs to be managed per project..
so the parent can't set the process config as final. (can't control at the enum level). and once the change is made in the child process config, the parent process config is no longer visible at the child. (ie it makes a copy and uses the copy forever)..


and we also need to make team configuration changes in the children.. for example team A wants fields x,y and Z as manatory, and team B wants field a,b,c and f mandatory.
so I cannot make the team config final either..

are there any suggestions on how to keep the children in synch with the master except for some specific exceptions..

help

Hello,

You are running up against a known problem that is being worked, but there is not a fix in 3.0.1.1. There will be a prototype of the fix in 4.0, but it will not be final.

The level of granularity for changing configuration data (such as work item information) with process sharing is too broad. This work item and its children track the discussion and work on this issue:
https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/169932

Martha
Jazz Developer

We use Process sharing, on 3.0.1.1 today..

but we have a new problem, and don't know how to solve it cleanly..

some parts of the customized defect workitem are project centric,
and some are enforced, globally across all projects..

so

1. we cannot use Final, cause we NEED to configure at the children projects
2. we don't have admin control over what attributes the children are allowed to configure, so will have to setup a central team to maintain these modified children
3. once A (any) change is made to a child project process areas, it becomes completely disconnected from the parent.. and future changes to the parent process config are no longer seen..

as an example,we had to add a 'feature' enum for each project, which separated team from technical content, cause category changes if the receiver ina drag drop has a different default team assigned.. (drop a compelted workitem in backlog onto a plan and watch what happens to category)..

but now this feature needs to be managed per project..
so the parent can't set the process config as final. (can't control at the enum level). and once the change is made in the child process config, the parent process config is no longer visible at the child. (ie it makes a copy and uses the copy forever)..


and we also need to make team configuration changes in the children.. for example team A wants fields x,y and Z as manatory, and team B wants field a,b,c and f mandatory.
so I cannot make the team config final either..

are there any suggestions on how to keep the children in synch with the master except for some specific exceptions..

help

thanks for the fast response..

so, please confirm the workaround til some future release

is:

1. someone has to manually re-apply all changes from the master to the affected children.

2. there is no current electronic method available which can tell us which projects are affected (disconnected from the master)
( i could write that code if someone could tell me how)

3. because there are no granular admin levels, we must create an admin group to maintain all the children for the project teams, to prevent them from changing the centrally managed elements.

just fyi, we expect to have 400 project across 10 ccm servers by end of year, and our users should not be inhibited by the system implementation (search for workitems across server), but we want to admin it as a single logical system with centrally admined processes, with local admin control of limited elements.