With the arrival of ITSM7 it seems to me that the amount of customisation being demanded is very small it doesn't matter so much anymore whether pre or post fixes are used.
In my experience BMC upgrades do enable disabled objects so it's necessary to have a method of disabling them again later. Maybe ITSM patches no longer do this? Then there are the issues with customised workflow in guides which also get corrupted by upgrades. Upgrades continue to be a painful process and what I'm seeing on the list about how the P5 upgrade works isn't going to reduce the stress. > In the 'old days', we used "Prefixing" as you have mentioned. > > > > Now we have chosen to use "Postfixing" instead, this allows the > Work-flow-object (AL,Filter,guide..) to be listed "next to each other" > in the admin tool. > > > > When customizing, we might DISABLE the OTB object, then clone it (Save > as) and put a "_IFX" at the end, tweak it, and then enable it. > > > > We elected to use the _ because it can be used to parse the object name. > Note that we have discussed internally using 2 of the _ characters for > better parsing as some OTB objects have a single _ in them. > > > > Remember that an "upgrade" should not ENABLE a disabled object, but will > IMPORT it if it is deleted. > > > > However, you will quickly want to prevent your Administrators and > Incident/Problem Investigators from using the output of WECSOG on > themselves... having "it works this way for them, and that way for those > guys" is quite confusing say the least when trouble-shooting, and > training, and... > > Thanks-n-advance; > > HDT Platform Incident / Problem Manager & Architect > Robert Molenda > IT OS PA > Tel: +1 408 503 2701 > Fax: +1 408 503 2912 > Mobile: +1 408 472 8097 > [EMAIL PROTECTED] > > Quality begins with your actions. > > > > ________________________________ > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of William Rentfrow > Sent: Wednesday, August 29, 2007 8:21 AM > To: arslist@ARSLIST.ORG > Subject: Workflow naming for multi-tenancy > > > > Has anyone come up with a workflow naming convention that includes > multi-tenancy as part of the naming? > > > > For example, In previous version of application being customized for the > ACME corporation you might have named a new active link on the > HPD:HelpDesk form something like this: > > > > ACM:HPD:ThisIsMyNewActiveLink > > > > We are now doing minor customizations that are company specific - the > logical approach is to just add another layer in the mix. So the WECSOG > (Wile E. Coyote School of Gunsmithing) division of ACME might have an > active link named something like.... > > > > ACM:WECSOG:HPD:ThisIsMyNewActiveLink > > > > This seems solid enough - but I'd like to hear any other strategies > people might have come up with for doing company-specific customizations > while utilizing multi-tenancy. > > > > William Rentfrow, Principal Consultant > > [EMAIL PROTECTED] > > C 701-306-6157 > > O 952-432-0227 > > > > __20060125_______________________This posting was submitted with HTML in > it___ > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where > the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
