Did someone knows where is located the process of projects issues or risks ?
I want to know what process loads when i click "save"
Other question: can we load a customized process when clicking "save" button?
Can you explain in greater detail? OOTB generally does not have a process that runs when you save an Issue or Risk. While there is the Assign Risks process, and the Issue Review and Escalation, they are not set to run by default. I would recommend that you check with your administrators,
Thanks for your reply,
What i want to do is to retrieve the date when i change the issue status to "Closed".
is there a possibility to associate a customized process running with the "save" button click ?
Or can we register the "closed date" when changing the status ?
Just create a process that if the status changes to "Closed" then auto populate the "Date Closed" field.
There is no out of the box "Date Closed" field, at least not in our 14.2 on premise solution.
If your setup is the same as ours, then you'll also need to create a custom "Date Closed" field. Make the "Date Closed" field read-only and then populate it using the process suggested by Michael Thibault. Sorry if you already understand this - I think, from what I read, that there is an assumption that custom fields must be created - just wanted to make sure and not assume. An alternate solution might consider renaming "Date Resolved" to "Date Closed" - this I don't recommend (see below).
As risks and issues reside in separate objects, you'll need a "Date Closed" field added to each object, and processes for each object.
Of course, as soon as you close a risk or issue and set the "Date Closed," someone will want to reopen the risk or issue - they may have closed it by mistake or someone higher up will disagree with its closure. So, please consider adding a process that will delete the date from "Date Closed" if/when the risk or issue is re-opened. You may also want to put "Date Closed" on the Audit Trail, if you find that resources are closing and re-opening risks or issues often. If they are not doing this often, then perhaps remove "Date Closed" from the Audit Trail when its no longer helpful to track.
If you are thinking about renaming the out of the box "Date Resolved" attribute to "Date Closed," I do not recommend this:
I took awhile for our users to fully grasp why we had to distinct end states, Resolved vs. Closed. But today, its pretty much common knowledge, a given.
I made the assumption that Date Closed was a field to be added, as resolved does not equate to closed. An issue may be resolved, but not closed as they may want to leave it open for a while to ensure it is truly resolved, or to make sure any and all documentation is updated, etc.
The 'resolved but not closed because...' thought process was ours as well. Until I discovered that marking an issue closed deleted the Date Resolved content. The only way to keep Date Resolved content, therefore, was to keep Status = Resolved and not change it to Closed.
So, I 'invented' the two-end state paradigm - maybe it wasn't new to CA, PMI or others, but it was a new paradigm for us. Using "it will help us search for lessons learned" helped get the paradigm sold, here.
The alternative was asking CA to change the app to suit our needs - and wait.... In the end, I still believe the 'two end state paradigm' is better - it better represents our reality. We resolve things and we close things without resolution.
If the app didn't delete the resolved date, if we could search for lessons learned by searching WHERE Status = Closed AND Resolved_Date isnot Null, I could probably be persuaded to change my mind. Of course, we could have hidden the out of the box Date Resolved field, created our own custom version and populated it with a process. Many ways to do this, though portlet searching on Null/Is not Null is still a problem. Maybe have a Resolved check box in addition to custom Date Resolved - can then filter on Resolve = 1/0 (yes/no). In the end, elected to stay with 'out of the box' and updated our procedures to match.
Hello Dale,Michael, thanks for helping me. It's totaly clear
But what i don't understand is : how can i run this process just by changing the status to closed?
Can you please tell me more about how to do this (technically speaking).
You create a "process" - the process is related to the RISK object, you define the process as "auto-start" (not "on-demand") and set the start condition to be status previous value != closed, status new value = closed.
( this is fairly normal PPM "process" setup, I'd suggest if you are struggling with this concept you should at least read the "Configure Process" section of the "Administration" documents in some detail before you start playing around! ) https://docops.ca.com/ca-ppm/14-3/administrating/configure-processes
Retrieving data ...