Question on Review Process
On RAM7.2.0.1, setting up to work with CQ Review Process
Here is the scenario:
1. Submit Asset01 thru RAM with file0.1
2. Put the Asset01 into CQ Review Process (this will create a CQ record), then it is rejected during review
3. The Asset01 is reverted back to Draft state, Submitter updates the version to and upload a new revised file0.2, then put the Asset01 in to CQ Review again (another CQ record), this time it is approved.
4. In the Asset01 record will have both with draft status and with approved status (triggered from CQ).
Not sure whether it is correct way for review process or not
my question are
1. why after CQ rejection it go back to draft state? Since it is in draft state, it can continue on workflow.
2. Is there a better way to upversion from -->
(During review, found some errors on 0.1 after CQ rejection Submitter revised 0.1 and upversion to 0.2, then re-submit to RAM)
3. Is it possible to customize the "Draft" state name to "Reject" and have its state end there.?
Here is the scenario:
1. Submit Asset01 thru RAM with file0.1
2. Put the Asset01 into CQ Review Process (this will create a CQ record), then it is rejected during review
3. The Asset01 is reverted back to Draft state, Submitter updates the version to and upload a new revised file0.2, then put the Asset01 in to CQ Review again (another CQ record), this time it is approved.
4. In the Asset01 record will have both with draft status and with approved status (triggered from CQ).
Not sure whether it is correct way for review process or not
my question are
1. why after CQ rejection it go back to draft state? Since it is in draft state, it can continue on workflow.
2. Is there a better way to upversion from -->
(During review, found some errors on 0.1 after CQ rejection Submitter revised 0.1 and upversion to 0.2, then re-submit to RAM)
3. Is it possible to customize the "Draft" state name to "Reject" and have its state end there.?
2 answers
How did you do:
Did you take the Draft 0.1 and just change the version, or did you
create a brand new asset with the same name but version 0.2? If you had
just changed the version to 0.2 on the draft 0.1 then it would of gone
as 0.2 and 0.1 would be gone. But if you created a brand new asset and
gave it 0.2, then that is just a completely different asset that you
just happened to give the same name.
Rich
I update the
version to and upload a new revised file0.2, then put the
Asset01 in to CQ Review again, this time it is approved.
Did you take the Draft 0.1 and just change the version, or did you
create a brand new asset with the same name but version 0.2? If you had
just changed the version to 0.2 on the draft 0.1 then it would of gone
as 0.2 and 0.1 would be gone. But if you created a brand new asset and
gave it 0.2, then that is just a completely different asset that you
just happened to give the same name.
Rich
On RAM7.2.0.1, setting up to work with CQ Review Process
Here is the scenario:
1. Submit Asset01 thru RAM with file0.1
2. Put the Asset01 into CQ Review Process (this will create a CQ record), then it is rejected during review
3. The Asset01 is reverted back to Draft state, Submitter updates the version to and upload a new revised file0.2, then put the Asset01 in to CQ Review again (another CQ record), this time it is approved.
4. In the Asset01 record will have both with draft status and with approved status (triggered from CQ).
Not sure whether it is correct way for review process or not
my question are
1. why after CQ rejection it go back to draft state? Since it is in draft state, it can continue on workflow.
2. Is there a better way to upversion from -->
(During review, found some errors on 0.1 after CQ rejection Submitter revised 0.1 and upversion to 0.2, then re-submit to RAM)
3. Is it possible to customize the "Draft" state name to "Reject" and have its state end there.?
While a CQ driven review process state transitions are made by changing the state of the associated change request in CQ. Only the review states (states between draft and approved) are covered by the CQ workflow. Once a change request has moved to a approval state the asset moves to the Approved state in RAM. If the change request moves to a rejected state the Asset moves to the state Draft until resubmitted for approval. This is not changeable and Draft is not re-namable.
In 7.2 we have added control to customize the every state and transition in an Asset's lifecycle based on workflows modeled by an internal RTC server. We have also add the UI to drive the state transitions from with in RAM (you do not have to go to RTC to transition).