Everyone, I thought I would share a few thoughts....
We do listen to requests and feedback and often react to it. However, sometimes things are not as simple as they seem... Let's take this case as an example. You can have three types of things that you are looking at when in Best Practice mode: 1) An unaltered definition that is just being read through from the base - no delete is possible here 2) An overlaid definition that is present in base - delete of the overlay is possible but not of the base definition 3) A custom object that does not exist in base - delete here deletes the object All of the focus of the thread has been on the wording of the Delete operation and should it be called Delete Overlay. I actually think that the concept is a good one. However, be aware that there really needs to be three states for the menu choice: 1) It is disabled as it is not possible 2) Delete Overlay to emphasize you are only deleting the overlay and not the object 3) Delete to emphasize it is a custom object and you are REALLY deleting the object not an overly Then, let's look at the next topic - I believe you can multi-select items and then pick Delete.... What should the menu choice be if you select three items, one of each of the above categories, and then select Delete? Should it be disabled because one is just a read through? Should it say Delete Overlay because one is an overlay? Should it say Delete because one is a custom object? More complexity... Does it say Delete and Delete Overlay? Do we remove the multi-select (of if it is not there, never add it)? I am not objecting to the request and in fact think there is value in the request, but just be aware that there is sometimes more to the issue than it may at first seem. Now, there are icons that indicate if something is an overlay, a custom object, or a base object bleeding through so you can tell which is which - but does it need to be more? And, about the not being in base mode discussion.... I would agree and argue that you should not be in base mode. In fact, I would go so far as to suggest that you should have most - all the day to day Admin logins and any special access Admin user - LOCKED to the overlay layer. Check the documentation, it allows you to lock an Admin into a specific layer. They can go into the other layer (well, this depends on version, current versions let you in read only to other layers, but older versions blocked them entirely) but no change is possible. Doing this guarantees that there are no mistakes and that no one is accidentally in the wrong mode and making changes. (and yes, BMC should lock our Admins to base to prevent accidentally creating custom objects in the overlay layer) You always have some super Admin who is not locked to Base in case you do need to go into that layer. They could also change the rights of an Admin to remove the restriction locking them to Best Practice - there is logic that doesn't allow an Admin locked to a layer to change the permissions to override that lock. Note that you can use this same ability to also lock an Admin to an undefined layer so that they can make no structure changes at all but can access data. This is good for a data access but read only definition Admin or for Admins used for integrations that only do data so that they cannot be used to change structures regardless of what calls are made. So, we have deviated from the original topic a bit. I just wanted to note that not having action taken is not always a sign of disagreement or of ignoring. Sometimes the problem is simply more complex than it seems nad more work needs to be done to make a decision. Then, there is the entire balancing of requests to pick the ones that make the most difference. Please keep the ideas and requests coming as without them being shared, there is almost 0 chance of them being done as we don't know about them. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Monday, April 27, 2015 6:02 PM To: arslist@ARSLIST.ORG Subject: Re: How to - Remove all Overlays from a Form ** Despite being comfortable with the labels personally, I do think there is a point to all this. But until that becomes a reality, just know that when you are in the best practice mode, the deletion of base objects is not allowed by the tool. So there is nothing to fear there. It's only when you switch the mode to Base Development that you risk loosing stuff. As a practice, YOU SHOULD NEVER be in the Base Development mode if you are using ITSM or any of the OTB Remedy applications. It offers you no benefit at all to be in the Base Development mode, UNLESS you are on one of the following exceptional cases: 1) Fixing a bug in the base object with BMC Remedy Support recommending that fix. So if you do not want to unnecessarily create an overlay because BMC Support explicitly tells you that they will be fixing that in an upcoming patch or release, feel free to modify the base object. 2) For whatever reason best known to you, you are in the need of creating a new base object which you know will not interfere with BMC developed objects because of the way your object is named (names using a prefix that identify your company, etc.) There is no other reason why you should be using the Base Development mode in my opinion. If you do so, you are violating one basic assumption BMC is making in order to make your upgrades an easier experience. An easy way to differentiate between the Best Practice mode and the Base Development mode is the message that occupies the bar below the menu bar that states that "All customization done in the Base Development mode might be lost during upgrade." If you see that message which occupies a visible and significant area, you are in a mode that is not recommended. Switch out. Joe ________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jason Miller Sent: Monday, April 27, 2015 4:24 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: How to - Remove all Overlays from a Form ** "especially if your users are point-blank telling you it matters" I think that is what I find the most humours (in a not so funny way). Here are numerous users relaying our experience, thoughts and feelings here and are told it is fine as is. For a BMC engineer, yes maybe. Real-world people using the tool, not so much. Any one of us that builds home-grown apps or customizations (extends) ITSM has come up with a great solution in the past; something that makes complete sense to us. But then roll it out and the users don't seem to see it the same way we do. This is one of those situations. The designers/developers of a tool do not see the tool the same way as users, they just don't. Developer/designers are in too deep and have too much understanding of beneath the covers. With that level of knowledge of a tool, yes it makes sense. But your users don't and will likely never lave that level of knowledge about the tool. I like your description "litany of little terrors." Have you ever noticed IT people/developers so damn gunshy to give a response. They have been beat too many times and live in terror. Give the wrong answer and you will be beat. After a decade or two (probably much less) it really does change a person. Jason On Mon, Apr 27, 2015 at 11:23 AM, Andrew Hicox <and...@hicox.com<mailto:and...@hicox.com>> wrote: ** Yes indeed! Holy moley, having to click delete on a core form on production server during a maintenance window, with absolutely zero indication in the GUI that you are not, in fact, deleting and/or fouling the form ... especially if the GUI behaves as if that is exactly what you have just done ... right down to pausing and going unresponsove for a very long time ... while simultaneously knowing that your ability to continue supporting your family may well be on the line ... and especially if you have lived through legitimately making that mistake in the past (I have, it wasn't pleasent) ... look ... It borders on psychological abuse, and I'm really not joking about that. Poorly designed industrial tools injure their users all the time. since the injuries are physical, they are hard to ignore, hence there are regulatory agencies like OSHA, etc. There is no such thing to protect IT workers, but I am of the opinion that the litany of little terrors that exist in our world like this, do take a toll after the decades we spend enduring them. Bottom line: be considerate to your users. Everything matters, especially if your users are point-blank telling you it matters. -Andy On Apr 27, 2015 12:57 PM, "Jason Miller" <jason.mil...@gmail.com<mailto:jason.mil...@gmail.com>> wrote: ** Thanks Lisa! I understand the logic the BMC dev team is using however now that people have some real-world experience working overlays there are enough people pointing out their discomfort in the verbiage "delete" meaning delete overlay and delete base. As Lisa pointed out there are times where we work in base mode and if for whatever reason we forget we are in base (I am sure I am not the only person that gets distracted mid-development and have to remember where I left off) and delete something, then we may have just ruined our whole day, week or even maybe our employment situation (if we were in production). If the logic is that a customer should never be in base mode then why can we switch to base mode? Because there are valid use cases for being in base mode. Therefore there is a valid use case for having different verbiage. I was at BMC's office last month and talking with some of the ITSM developers they pointed out they have to opposite problem we have with overlays. Their normal day is to work in base mode. If they start to develop a feature, patch, enhancement and don't realize they are in best practice they have to go back into base and rebuild their changes in base (ok, ultimately I wouldn't be surprised if they have some kind of merge tool). If the delete verbiage was different between base and best practice it would be one more visual indicator of "oh crap, I am in the wrong mode." Jason On Mon, Apr 27, 2015 at 9:44 AM, Kemes, Lisa A DLA CTR INFORMATION OPERATIONS <lisa.kemes....@dla.mil<mailto:lisa.kemes....@dla.mil>> wrote: Created new idea if you would like to vote for it: https://communities.bmc.com/ideas/10022 Thanks everyone! Lisa -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Harsh Sent: Monday, April 27, 2015 10:46 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: How to - Remove all Overlays from a Form ** Yes William, Sometime it really do paranormal activity like forms overlay from backend doesn't get deleted and makes the form corrupted then really it's such a pain to delete the overlay references from database to restore the base form. Even backup doesn't works in that case. Regards, Harsh On Mon 27 Apr, 2015 8:06 pm William Rentfrow <wrentf...@stratacominc.com<mailto:wrentf...@stratacominc.com>> wrote: That's a good nomination for a product upgrade. In BP mode the delete really should be "Delete all overlays". You should put that in the communities - I'd upvote it. Even though I know it's only going to delete the overlays I REALLY dislike clicking the delete. I normally make a backup first just due to paranoia/experience (pick one :) William Rentfrow wrentf...@stratacominc.com<mailto:wrentf...@stratacominc.com> Office: 715-204-3061<tel:715-204-3061> or 701-232-5697x25<tel:701-232-5697x25> Cell: 715-498-5056<tel:715-498-5056> -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Kemes, Lisa A DLA CTR INFORMATION OPERATIONS Sent: Monday, April 27, 2015 9:23 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: How to - Remove all Overlays from a Form Then when in Best Practice, can the Delete be called Delete Overlay? That seems so easy to do and assures us that we would be deleting the overlay and not the form. Sometimes I'm in Base and mean to be in Best Practice (doing research or something). Lisa -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Hullule, Kiran Sent: Monday, April 27, 2015 6:22 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: How to - Remove all Overlays from a Form ** Update: I did talk to product development team in this regards, developers mentioned that , whatever we do within Best Practice Customization Mode is all overlay, so whatever the options you see, add/delete/create etc . they are only applicable to the overlay objects.. if the object/s is/are non-overlay then you won't see delete option unless you are in Base mode. This being the reason there is no need to label the options explicitly for overlay as a person who is dealing with developer studio know what he/she is doing and what is the significance of each mode. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Jason Miller Sent: 23 April 2015 20:30 To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: How to - Remove all Overlays from a Form ** That would be great! I am glad to see I am not alone in thinking there should be difference verbiage. I mentioned it in either the 7.6.03 (before it was pulled from that version) or 7.6.04 beta; before this features was GA but it went forward as is. On Thu, Apr 23, 2015 at 6:37 AM, Kemes, Lisa A DLA CTR INFORMATION OPERATIONS <lisa.kemes....@dla.mil<mailto:lisa.kemes....@dla.mil>> wrote: Wow thanks Kiran! That would be great! -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Hullule, Kiran Sent: Thursday, April 23, 2015 4:34 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: How to - Remove all Overlays from a Form I am providing this feedback to our development team to see if this enhancement can be incorporated in developer studio. I will update you all. Regards Kiran BMC Software -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Kemes, Lisa A DLA CTR INFORMATION OPERATIONS Sent: 22 April 2015 22:05 To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: How to - Remove all Overlays from a Form It looks like "Delete" with no "overlay" label. It's really scary when I delete an overlay using this, because I'm always scared that I'm going to be deleting the form. But if it's overlaid, then you will only be deleting the overlay of the form. Lisa -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of San Diego Sent: Wednesday, April 22, 2015 11:41 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: How to - Remove all Overlays from a Form ** Sorry, while creating overlay is in the form menu, delete form overlay is NOT, else I would not have posted. Thanks, though. On Apr 22, 2015 10:38 AM, "Hullule, Kiran" <kiran_hull...@bmc.com<mailto:kiran_hull...@bmc.com>> wrote: create and delete view overlay option can be found under Form menu -- deleting the view will only delete the overlay of the view. hth -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of Tim Genworth Sent: 22 April 2015 20:25 To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: How to - Remove all Overlays from a Form How do I remove all view and permission overlays from a form? I'm in Dev Studio and don't see a command or function for doing so. I could manually remove permissions, but the view overlay appears to be permanent??? TIA _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> <http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> <http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> <http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> <http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> <http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" ----- No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2014.0.4800 / Virus Database: 4311/9524 - Release Date: 04/12/15 Internal Virus Database is out of date. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
