Hi Thomas,

Currently when a rule is checked in with PMF task, the pmf task id will be shown in the history memo.

See the below screen shot.

As the view full history window is final, you may not be able to customize it.

There is another option to see the list of rules checked in with the PMF task/bug id.

From designer studio home--> Click View PMF worklist in new window --> On this, click on View Changes link on the top.

You will be able to see the list of rules checked in with PMF id.

Thanks

Anil

Hi Anil,

thank you for your reply. Your screenshot is very small but I get what you meant. The problem is in our system the Task ID is not shown in the memo or anywhere else. The only place where I saw it was when we were merging a branch and checked for the conflicts. Thats why I was asking for the extra column.

The view changes option is good but only for recent changes. I am more interested in long term traceability. So when you see rule where changes were made half a year ago and you wonder why it would be helpful to look at the task in PMF which you can't if you don't see the ID.

Kind regards,

Thomas

Hi Thomas,

I am just trying to understand what you would like to achieve with this functionality.

In my opinion a user story has a certain lifecycle. When its taken on in a sprint you will add the tasks and you can actually start delivering the functionality delivering what has been described in the story. When the user story is done and accepted in the sprint, its basically resolved. In next sprints you could have other tasks in user stories that also make changes to that specific rule. But what is the value of the taskid in a rule after the sprint? And what is the value of that after a year? And what is the value of a taskid in a reusable asset that is going to be reused by another team for another application that has no notion of the user stories it was originally created from?

I believe the feature of attaching the rule at check-in to a task or bug is handy for an overview of the touched rules. This can help to decide what to deploy, it can give you insight in what ruletypes are typically being changed/created or how many, etc. But as said; after the implementation (and acceptance) i dont see added value of knowing from what task, bug or user story it has been changed/created.

tx

Dion

Hi Anil,

we are using 7.2

Hi Dion,

I know that to some people my suggestion makes no sense but we have a very big application that grew over time and sometimes you want to know the reason for a change that was made. And the best way to check is to look at the task / story where the reason / all the discussions are documented.

Kind regards,

Thomas