The easiest and least ambiguous solution, in my mind, is to have dev-studio behave exactly like migrator does.
Treat the overlay and the original form as separate objects ... In fact, if you import a form with an overlay, you'll see that in some ways it already does. You'll see the form and form__o (the overlay) as separate objects. This would be perfect! There's no need to hide things from me ... I'll know darn well what I'm deleting if you just show it to me in an obvious way, 'eh? Andy On Apr 28, 2015 12:45 PM, "Mueller, Doug" <doug_muel...@bmc.com> wrote: > ** > > 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 <arslist@ARSLIST.ORG>] *On Behalf Of *Jason > Miller > *Sent:* Monday, April 27, 2015 4:24 PM > > *To:* 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> 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> 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> 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] On Behalf Of Harsh > Sent: Monday, April 27, 2015 10:46 AM > To: 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> > 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 > Office: 715-204-3061 or 701-232-5697x25 > Cell: 715-498-5056 > > > -----Original Message----- > From: Action Request System discussion list(ARSList) [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 > 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] On Behalf Of Hullule, Kiran > Sent: Monday, April 27, 2015 6:22 AM > To: 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] On Behalf Of Jason Miller > Sent: 23 April 2015 20:30 > To: 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> wrote: > > Wow thanks Kiran! That would be great! > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Hullule, Kiran > Sent: Thursday, April 23, 2015 4:34 AM > To: 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] On Behalf Of Kemes, Lisa A DLA CTR > INFORMATION OPERATIONS > Sent: 22 April 2015 22:05 > To: 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] On Behalf Of San Diego > Sent: Wednesday, April 22, 2015 11:41 AM > To: 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> 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] On Behalf Of Tim Genworth > Sent: 22 April 2015 20:25 > To: 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> "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_ > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at 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> "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_ > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at 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 > 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 > "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" > > > > _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_ > _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"
