I questioned this while in the San Jose office pre 9.0 GA. There was laughter as soon as I asked. Turns out I had just tapped into a pretty heated topic in the office. From what I remember there are so many different use cases, requirements, biz rules, etc. that they had to pick something and Create Date was it. I gave my two cents. My memory is a little foggy but I think I also suggested Last Modified Date.
I have implemented archiving for several customers over the last 15 years. The qualification to archive a record was always "Last Modified Date", normally together with something like "Status".
I cannot see any reason to choose "Submit Date" as default.
Hi Jason Miller,
You are absolutely right, they had to pick one. But why the Submit Date?
A colleague of mine attended the same session in San Jose and he wasn't able to tell me a reason for the pick. He had got the impression that they just did it.
And your are also right, that there are different requirements. But I have never seen any use case, where Submit Date would have been the preferred choice.
So did BMC roll dices and depending on odd or even numbers made their decision? (Hopefully not.)
Or is there a meaningful reason behind it, which can also be understood by none BMC employees and real world customers?
Again: We now will have to create overlays for the form properties of all affected forms regardless whether there are other modifications or not.
I was very disappointed by this design as well! Usually I see archiving requirements being something like "archive tickets that have been in a closed status for X months". The best way I think would be using the dates like 'Last Resolved Date" on INC, "Completed Date" on change and 'Last completed date' on problem.
Is it possible to change the qualifier in an overlay?
did you read the last paragraphs in my postings? Please, read them again.
We don't want to create unnecessary overlays for something that could be there out of the box.
We want to reduce the numbers of overlays to get closer to the standard and reduce time and effort when upgrading to newer versions of BMC Remedy ITSM.
But this one forces us to add overlays even for those forms, that did not have one yet.
Number of overlays do not impact on upgrade rather creating overlays of the objects is a best practice. It protects our changes during upgrade.
If you really do not want to create overlays then you can change this qualification in base mode of dev studio. (It will make form copy as a BASE copy).
I know what overlays are good for.
But I have to disagree with some of your statements.
- Each and every time an upgrade is taking place, we will have to analyze the new BMC code and the overlay regarding compliance and compatibility. Even with the help of 3-way reconciliation this is a task we would like to avoid. And it can be avoided by providing the better choice qualification date field out of the box.
- Each and every time an upgrade is taking place, we will have to move customizations from dev to QA to prod. And why should we migrate something in an overlay that could simply be provided by the upgrade installer.
- And finally: If ever possible DO NOT develop in base mode except BMC is telling you explicitly to do so. You will loose all your modifications during an upgrade.
So it's not the question, whether we CAN create an overlay. What you can do is not necessarily the thing you should do and which will make sense.
Thomas Hammer - I think we're going to have to end up changing the archival qualification field as well, have you encountered any issues with doing this?
I'm looking to change this from submit date to closed date, but you only have to do this on the parent forms right (e.g. Incident, Change, Problem, etc), not the child forms (e.g. work logs)?
I can only agree with the other people. The Submit Date is the worst that could be chosen.
The only real one can only be the Last Modified Date. So the archive function cannot be used.
Can someone from BMC explain the design?
short answer is : this is as per design.
1 of 1 people found this helpful
In short: Not every implementation is design.
Design is a cognitive achievement. So someone here must have consciously decided on a solution that is not very practical. As Peter Adams always says: that's business, better fast and bad ...
True. We can expect changes in the 'design' in upcoming versions