Hi there.
We have a series of Documents that we need to make a minor change to - edit the "Assigned Creator" or "Designated User". We wanted to use the Manual Change lifecycle state to achieve this, but after promoting an item into Manual Change, editing, and attempting to promote back to Released, we get a InvalidEffectiveDateValueException "The value of the effective_date property specified for the Document is invalid. A value is required and it must be greater than or equal to the today date.". But we would like to keep the original prior effective date.
When saving the edit while in Manual Change, we can see that the Release Date gets cleared. So perhaps attempting to promote back to Released when there is no release date set is causing the effective date to get checked?
So: 1) Is using Manual Change the correct approach to making a minor edit, such as changing Designated User? 2) How can we get Manual Change to work without causing the released and effective dates to get updated to today?
Using v11 SP 12. Thanks!
Jared -
Okay, if it was a one-time thing, we were thinking that an SQL Script could solve the issue.
Since it is an ongoing thing, there will need to be a configuration change to how the property Effective Date behaves for your implementation. There are default rules in the Product Engineering (PE) Application related to CMII behavior that is not going to allow you to use an Effective Date earlier than the Manual Change that you are doing. I tried many ways and could not get around it.
Your are correct that the Manual Change is allowing you to make a minor change and not up the Revision. It is still considered a "change" to the Item, however, so it is not allowing you to keep the original Effective Date. It wants the Effective Date to change to the new version of the Item, even if the Revision didn't change.
Effective Date and its behavior is part of the core PE capability. I've spoken with a colleague and he recommends that the best approach would be to create your own custom property for Effective Date, hide and stop using the OOTB Effective Date, and create the custom behavior and logic that you need for your Effective Date custom property. The OOTB Effective Date drives and is driven by many of the PE OOTB processes and behaviors, it would not be a simple matter to change its logic as part of PE, there are too many dependencies.
Hope this explanation helps.
Thanks,
Lisa
Jared -
Okay, if it was a one-time thing, we were thinking that an SQL Script could solve the issue.
Since it is an ongoing thing, there will need to be a configuration change to how the property Effective Date behaves for your implementation. There are default rules in the Product Engineering (PE) Application related to CMII behavior that is not going to allow you to use an Effective Date earlier than the Manual Change that you are doing. I tried many ways and could not get around it.
Your are correct that the Manual Change is allowing you to make a minor change and not up the Revision. It is still considered a "change" to the Item, however, so it is not allowing you to keep the original Effective Date. It wants the Effective Date to change to the new version of the Item, even if the Revision didn't change.
Effective Date and its behavior is part of the core PE capability. I've spoken with a colleague and he recommends that the best approach would be to create your own custom property for Effective Date, hide and stop using the OOTB Effective Date, and create the custom behavior and logic that you need for your Effective Date custom property. The OOTB Effective Date drives and is driven by many of the PE OOTB processes and behaviors, it would not be a simple matter to change its logic as part of PE, there are too many dependencies.
Hope this explanation helps.
Thanks,
Lisa
