LOL ... omg dude. Thanks. I can't believe that's been there all along and I never noticed it.
-Andy On Wed, Nov 23, 2016 at 9:34 AM LJ LongWing <[email protected]> wrote: > ** > Andrew, > Within Dev Studio there are options (in the outline section) to show > fields that are not in the current view, or, if you switch to the > 'Definitions' tab of the form, you can see all fields, regardless of if > they are in a view or not.....These options were added back in the 7.6 > days...I forget which version. > > On Wed, Nov 23, 2016 at 8:23 AM, Andrew Hicox <[email protected]> wrote: > > ** > > I would like to point something out, and maybe someone can tell me a > better way but ... > > Especially on out of the box forms. This is without a doubt a tremendous > pain. Even though we shouldn't necessarily have to, a huge part of my day > to day as a remedy person is debugging out of the box code. > > So here I am, tracing logs through, trying to figure out what's going on, > and I encounter a field that is hidden on an out of the box form, by virtue > of being in no view. > > What kind of field is it? What are it's limits? Who has permission to it? > Is it display only, or is there a corresponding db column? What other > workflow touches it? Etc etc. > > The only way I've found to get the answers to these kinds of questions is > to actually overlay the out of box form, JUST so that I can pull the dang > field into a view, so that I can inspect it I dev-studio. > > Is there a better way I've been missing all this time? If not, can we > expect future versions of Dev-Studio to give us some sort of access to > no-view fields? > > Thanks, > > -Andy > > On Tue, Nov 22, 2016 at 11:58 AM Mueller, Doug <[email protected]> > wrote: > > ** > > Dustin, > > > > A field that is “not in view” has multiple advantages: > > > > 1) It is not in Field list dropdowns as noted so it is “more hidden” > than other fields > > 2) It has no view properties so it in fact is more efficient. There > is no screen widgetry defined, there is less html in the page (think about > it, if it is just hidden, it COULD be made visible so you have to define > the widget, have html that describes it and positions it and cares for it > and …. While if not in view it is NEVER possible to show it so there is no > view definition at all. It is lighter and if you have many of them, it > does have a notable impact on the volume of html in the screen so it is > more efficient) > > > As has been noted this is NOT security, the field is still fully > accessible to the user it is just not possible to show it on the screen > from the mid-tier. You can reference it through workflow and work with it > programmatically like any other field. If you don’t want the user to have > access, control with PERMISSIONS not with hiding or making not in view. > > > > As a general suggestion, if a field is NEVER visible on the screen, I > strongly suggest you have it not in view. It reduces overhead and makes > the system more efficient. Only have things in view that have the > possibility of being displayed under some condition. > > > > Doug Mueller > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Brittain, Mark > *Sent:* Friday, November 18, 2016 12:23 PM > > > *To:* [email protected] > *Subject:* Re: ARS 9.1: Question about hiding fields > > > > ** > > Dustin, > > > > A field that is not in the view does not appear in the Field menu for an > Advanced Search. So this might be a good way to limit what users are > searching on. Of course if you have a savy user they can always type the > field name with quotes (e.g. ‘Wigit Name’) but I haven’t found anyone who > does that. > > > > Mark > > > > *From:* Action Request System discussion list(ARSList) [ > mailto:[email protected] <[email protected]>] *On Behalf Of *LJ > LongWing > *Sent:* Friday, November 18, 2016 3:02 PM > *To:* [email protected] > *Subject:* Re: ARS 9.1: Question about hiding fields > > > > ** > > Dustin, > > The main advantage is the fact that the field isn't taking up any screen > real estate anywhere on the form. The object still exists on the form, is > still transferred to the client, so it's not a transport advantage, but the > fact that the field's not cluttering up the display is a maintenance > advantage :) > > > > On Fri, Nov 18, 2016 at 12:45 PM, Fawver, Dustin <[email protected]> > wrote: > > ** > > Greetings! > > > > During my analysis of workflow for the migration to ARS 9.1, I have found > that fields can be hidden in several ways. > > > > - Hidden explicitly by the field's properties > > - Placed in a panel page that the user doesn't not have permissions to. > > - Removed from the user's view > > - The field not being placed in any view > > > > I found some fields being referenced in workflow that existed on the form > but that weren't in any views. Are there any advantages or disadvantages > to having a field that's not present in any view versus a field that is > simply hidden? > > > > Thanks for your input. > > > > --Dustin Fawver > > > > HelpDesk Technician > > Information Technology Services > > East Tennessee State University > > [email protected] > > _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_ > > _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"
