You are back to the same issue I was describing…. When you have no permission to the hidden page holder, that page holder is not constructed in the html page (just like if you had no permission to any field). Now that that page holder is not constructed, there is no construction of any of the things that are on that page – that includes fields, table fields, and attachments.
As I discussed in my previous message, we have real data fields data held in structures separate from the html constructs. However, attachment pools and table fields are html constructs – they are not real data fields. So, when the page holder is not accessible, it takes out the constructs for attachments and tables as if they are not there so they don’t work. The field still works because we have storage for all the data fields held separate from the html. NOTE: Even display only data fields are OK and held separately. It is only the table field and attachment pools that are tied into the html structures. I hope this makes sense and explains what is happening in the various scenarios…. It is all about the display constructs fields – table fields, attachment pools – vs. actual fields (physical or display only). If the display constructs are not there – not in view – or are taken out because of being on some other construct that is not there -- like a page holder without permission for the user – you cannot interact with them. They have to be present on the html (visible or hidden is fine, but just present) to work. Fields that are not display constructs can be accessed and interacted with whether they are present visible or hidden on the view as they are always represented in the html in internal data structures. Note that lines and boxes and such would fall with display constructs but they have no values or interaction so the issue is moot for them. Doug From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Thomas Miskiewicz Sent: Friday, January 27, 2017 11:41 AM To: [email protected] Subject: Re: ARS 9.1: Question about hiding fields ** Thanks for this insight Doug! Can you please elaborate on the other discovery? When we place a character field and an attachment field on a hidden page holder with public permissions the active links have access to both. For instance they can open an attachment to present it to the user or can access data in some temp fields. However when we the user does not have permissions to the hidden page holder the active links cannot perform the open attachment action anymore yet they can access the data in the character fields. Also isn't this a bug when active links can access data in fields that are placed on a page holder the user has no access to? If this for some reason isn't a bug why can't the active links perform that open attachment action? Thanks Thomas On 27 Jan 2017, at 19:36, Mueller, Doug <[email protected]<mailto:[email protected]>> wrote: ** I had some testing done on the original question – what happens when you set focus to a field that is hidden or not in view. The results we had were that doing this quietly did nothing (as expected). We even defined an operation to set focus to a field that doesn’t even exist on the form and it also quietly did nothing. So, the behavior we observe is correctly taking no action and doing nothing when the field doesn’t show on the screen. If you are not seeing this result, I would work with the support team on the issue (assuming you have not already fixed it). On the topic of table fields… I believe you are correct that table fields must be present on the view (can be hidden but cannot be “not in view”). The issue here is that there is really no field. The entire field is the table construct and trying to interact with a logical construct without the construct does not work. So, to interact with table fields, you do need the table field to be in the view, but it can be hidden. We need the structure to work on when working with the table. Without it, the behavior of trying to work on a construct that doesn’t exist quietly does nothing. My suspicion on attachments is the same. The construct on the web is a display construct. You interact with that and when you drill down, you do the connect to a real field, but it is second order. So, you should find that things that are not in view are just fine if they are anything but table fields (or columns of course) or attachments. This is not something that is possible to fix given the structure of the system at this time. The table object is a display object and not really a data field (and the attachment display table is also a display object not a data field). Yes, both have data behind them, but the system doesn’t know how to interact with a display construct if it is not present so it doesn’t interact with it. The system does have direct data fields handled as there is storage for those direct fields in the core data model of the page. But, not for the “indirect” data from tables and attachments. Doug From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Jarl Grøneng Sent: Friday, January 27, 2017 2:04 AM To: [email protected]<mailto:[email protected]> Subject: Re: ARS 9.1: Question about hiding fields ** I have seen similar behavior when using hidden tablefields in workflow. -- J 2017-01-27 9:06 GMT+01:00 Thomas Miskiewicz <[email protected]<mailto:[email protected]>>: ** Doug, we discovered some other issues with in this area too. 1. When an attachment field is not in the view PERFORM-ACTION-OPEN-ATTACHMENT fieldId stops working 2. When you place all kind of fields on a tab and the use has no access to the page holder, the Active Link workflow can access fields of all type but the attachment field. Do you think the engineering time would mind fixing those things? I’m very hesitant lately reporting any bugs then most of the time they would like to fix things. Thomas On 27 Jan 2017, at 08:57, Mueller, Doug <[email protected]<mailto:[email protected]>> wrote: ** Thomas, I would consider this a bug. The system should be gracefully degrading by noting that the fieldID is not in the view and so take no action quietly. If you are getting an error or failure of the screen, this is not what I would expect. Doug From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Thomas Miskiewicz Sent: Thursday, January 26, 2017 3:01 AM To: [email protected]<mailto:[email protected]> Subject: Re: ARS 9.1: Question about hiding fields ** Hi Doug, you said: "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." We got a form with views. We moved all hidden fields to the other view in order to hide the temp fields from the Advanced Search field selection for the user. This however broke some workflow which was doing a Set Focus on fields that are not in the other view. I know, doind a set Focus on the hidden field is WIRED, but fully accessible is fully accessible. Is this a bug or what kind of full accessibility did you have in mind saying that even fields that are in neither view are fully accessible to the user? Thomas On Tue, Nov 22, 2016 at 6:56 PM, Mueller, Doug <[email protected]<mailto:[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]<mailto:[email protected]>] On Behalf Of Brittain, Mark Sent: Friday, November 18, 2016 12:23 PM To: [email protected]<mailto:[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]] On Behalf Of LJ LongWing Sent: Friday, November 18, 2016 3:02 PM To: [email protected]<mailto:[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]<mailto:[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]<mailto:[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_ _ARSlist: "Where the Answers Are" and have been for 20 years_ Show Quoted Content ** Doug, we discovered some other issues with in this area too. 1. When an attachment field is not in the view PERFORM-ACTION-OPEN-ATTACHMENT fieldId stops working 2. When you place all kind of fields on a tab and the use has no access to the page holder, the Active Link workflow can access fields of all type but the attachment field. Do you think the engineering time would mind fixing those things? I’m very hesitant lately reporting any bugs then most of the time they would like to fix things. Thomas On 27 Jan 2017, at 08:57, Mueller, Doug <[email protected]<mailto:[email protected]>> wrote: ** Thomas, I would consider this a bug. The system should be gracefully degrading by noting that the fieldID is not in the view and so take no action quietly. If you are getting an error or failure of the screen, this is not what I would expect. Doug From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Thomas Miskiewicz Sent: Thursday, January 26, 2017 3:01 AM To: [email protected]<mailto:[email protected]> Subject: Re: ARS 9.1: Question about hiding fields ** Hi Doug, you said: "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." We got a form with views. We moved all hidden fields to the other view in order to hide the temp fields from the Advanced Search field selection for the user. This however broke some workflow which was doing a Set Focus on fields that are not in the other view. I know, doind a set Focus on the hidden field is WIRED, but fully accessible is fully accessible. Is this a bug or what kind of full accessibility did you have in mind saying that even fields that are in neither view are fully accessible to the user? Thomas On Tue, Nov 22, 2016 at 6:56 PM, Mueller, Doug <[email protected]<mailto:[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]<mailto:[email protected]>] On Behalf Of Brittain, Mark Sent: Friday, November 18, 2016 12:23 PM To: [email protected]<mailto:[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]] On Behalf Of LJ LongWing Sent: Friday, November 18, 2016 3:02 PM To: [email protected]<mailto:[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]<mailto:[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]<mailto:[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_ _ARSlist: "Where the Answers Are" and have been for 20 years_ ** Doug, we discovered some other issues with in this area too. 1. When an attachment field is not in the view PERFORM-ACTION-OPEN-ATTACHMENT fieldId stops working 2. When you place all kind of fields on a tab and the use has no access to the page holder, the Active Link workflow can access fields of all type but the attachment field. Do you think the engineering time would mind fixing those things? I’m very hesitant lately reporting any bugs then most of the time they would like to fix things. Thomas On 27 Jan 2017, at 08:57, Mueller, Doug <[email protected]<mailto:[email protected]>> wrote: ** Thomas, I would consider this a bug. The system should be gracefully degrading by noting that the fieldID is not in the view and so take no action quietly. If you are getting an error or failure of the screen, this is not what I would expect. Doug From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Thomas Miskiewicz Sent: Thursday, January 26, 2017 3:01 AM To: [email protected]<mailto:[email protected]> Subject: Re: ARS 9.1: Question about hiding fields ** Hi Doug, you said: "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." We got a form with views. We moved all hidden fields to the other view in order to hide the temp fields from the Advanced Search field selection for the user. This however broke some workflow which was doing a Set Focus on fields that are not in the other view. I know, doind a set Focus on the hidden field is WIRED, but fully accessible is fully accessible. Is this a bug or what kind of full accessibility did you have in mind saying that even fields that are in neither view are fully accessible to the user? Thomas On Tue, Nov 22, 2016 at 6:56 PM, Mueller, Doug <[email protected]<mailto:[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]<mailto:[email protected]>] On Behalf Of Brittain, Mark Sent: Friday, November 18, 2016 12:23 PM To: [email protected]<mailto:[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]] On Behalf Of LJ LongWing Sent: Friday, November 18, 2016 3:02 PM To: [email protected]<mailto:[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]<mailto:[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]<mailto:[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_ _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"
