[Date Prev] [Date Next] [Prev in Thread] [Next in Thread] [Date Index] [Thread Index]

Re: ARS 9.1: Question about hiding fields



**
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 <lj.longwing@gmail.com> 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 <andrew@hicox.com> 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 <doug_mueller@bmc.com> 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:arslist@ARSLIST.ORG] On Behalf Of Brittain, Mark
Sent: Friday, November 18, 2016 12:23 PM


To: arslist@ARSLIST.ORG
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:arslist@ARSLIST.ORG] On Behalf Of LJ LongWing
Sent: Friday, November 18, 2016 3:02 PM
To: arslist@ARSLIST.ORG
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 <FAWVER@mail.etsu.edu> 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

fawver@etsu.edu

_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_
_ARSlist: "Where the Answers Are" and have been for 20 years_