How Do I Get the "Before" State of the Project Area in an Operation Behavior Triggering on ProjectAreaSave?
I am writing a precondition that triggers off the operation id "com.ibm.team.process.server.saveProjectArea". I am trying to create a precondition that will disallow changes to a project area's configuration if they qualify as a certain type of change. Basically, it's an attempt to get more granular control over a project's configuration than simply relying on the "final" checkbox. I've written a prototype for the precondition and it looks like the pieces are there to make this work. However, I've run into a problem. In order to verify that the user hasn't changed something that they shouldn't, I need to be able to see what has changed with the save operation. I am able to see the current Process Configuration Source XML of the project area, but can't seem to figure out how to see what the user is trying to change. When the operation fires, I cast the operation as a "ProjectAreaSaveOperation" object. This object has a function called "getItems" that has the following explanatory text: "Returns the items that this operation will save. These are the new item states." This sounded promising, particularly "these are the new item states". I started iterating over these saveItems and looking at each of them to see if one of them would give me a view into the "new" state of the ProjectArea XML. Unfortunately this appears to be a dead end (or I'm just looking at the wrong thing). Can anyone advise me on how to do this? |
One answer
|
I think I found the solution. I cast the saveItem.getWorkingCopy() object to an IProcessArea object. I then used the getProcessData function of the IProcessArea object. This map was the NEW process configuration source XML. So it looks like I now have a before-and-after shot of the process configuration XML. Comments I am confused.. I thought you had all the NEW values.. and needed the OLD values.
When I said I could see the "current" configuration of the project area, I meant that I could see the configuration prior to any change had taken effect. I was resolving the project area, but the repository was giving me the data prior to any change had been committed. Perhaps it was a poor choice of words. In any case, I can see both states now. cool.. thanks for the update
No problem. Let me know if you are interested in any more of the details. I work with David Evans and he told me that you two had had some dialog on this subject in another thread. He thought you might actually be interested in our solution based on your comments there. We intend to use it to allow our projects to employ process data deltas in their areas without changing the core configuration specified in the parent process. ooooo.. very interested!
For us, the biggest hurdle was just figuring out how to trigger an operation behavior when the project area was saved. The key was provided in another forum posting here:
Sorry to resurrect an old thread but I'm grappling with this right now. Specifically I'm interested in the awarding of roles, trying to add a measure of control over who's giving what roles to whom so I need the 'before' state as well as the 'about to be saved' state.
As Nate did, I also use the getItems() call against the "ProjectAreaSaveOperation" object but the item most definitely gives me the NEW, pre-committed values. I need the OLD values to determine what's actually changed, and this is what I'm struggling with. And it's the same for the TeamAreaSaveOperation too.
I can't see how Nate's approach provides anything but the new values, based on the testing I've done so far, but maybe I've missed a point somewhere.
Can anyone offer some help with this?
showing 5 of 7
show 2 more comments
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.