Latest Contributions by AllenScully

Hi Pierre -  I have the same issue - I thought my custom GP script was set up and published to allow for the Select Widget results to be used as Geoprocessing Input but I am not seeing that option (in AGOL so I know it's current).  Did you ever figure this out? One thing I have been able to do is create a layer from the Selection results and use that as input to the Geoprocessing widget, but that's clunky and feels like a work-around Thanks -  Allen ... View more

Thanks Dan -  I actually got it work simply by removing the 'parameters' from:  def updateParameters(self, parameters): So -  def updateParameters(self): got me rolling.  But it was all for naught, since validation code appears to be ignored when your script tool is published as a GP Service.   Allen ... View more

Thanks Victoria -  I confirmed that at 2.14 the behavior is fixed - we'll make that works with the 3rd party application involved and get our environment upgraded. ... View more

I'm curious - we're seeing pretty much the exact same behavior, but in Portal 10.7.1 with WAB dev edition, v. 2.9. Essentially when we click on a point that has multiple features present, and toggle through the pop-ups - the selection to reflect which pop-up is active is offset from the actual feature - point, line or polygon, doesn't matter - all show this behavior.   Have there been any other reports of this happening in 10.7.1? This doesn't happen in the WebMap that's used in the App. Thanks -  Allen ... View more

Hi Nels -  We did figure this out - it may not be helpful for your purposes. Our issue was actually data related.  The application that generated our input data allowed users to submit 'bad' polygons, with only 3 vertices, where the 1st and 3rd vertices were the same - so, basically a line, not a valid polygon.  GeoEvent would then attempt to process the 3-point geometry string into a polygon feature, and it would fail.   The real take-away though that may be applicable elsewhere is that when this error happened, GeoEvent input connector would not just skip the bad record (after logging an error) and move on to the next record, but instead it just got stuck at the bad record and wouldn't process anything more from the source/input data. Eventually we wrote some error trapping for the front-end application telling users to re-draw the polygon, and preventing the bad record from being written into our data. Hope some of that is helpful -  Allen ... View more

Hopping on here to ask if this works in Portal (10.7.1) as well? I see the 'Set Default Option' as well but it is not doing quite what I thought.  I can troubleshoot, it may be another issue on our end, but wanted to confirm that in Portal, clicking the 'Set Default Option' supposed to revert back to whatever the service-level symbology is? Thanks -  Allen ... View more

Thanks Trevor - Yes, looking at some Python-based Portal/Enterprise administrative options for setting the IDP username property - will follow up when/if that gets figured out, along with any other things that may be of interest that come up as we go forward. Allen ... View more

Thanks Trevor -  The issue we have essentially is how to get AD FS SSO to work with existing Portal accounts created with the 'Add members based on existing enterprise users' before we hooked up to AD FS.  See above response to Angus. But yes, my initial question was about Authentication in IIS - and as you say, we did get things behaving mostly as desired by enabling anonymous and disabling IWA at the Portal Web Adaptor level. ... View more

Hi Angus -  The issue is that for an existing Portal with 100+ users, SSO is not working for everyone using the IIS method of setting authentication at the Web Adaptor level.  Works for most, but not all, and we have users who are on Virtual (VDI) machines which don't work with this method of SSO (our VDI environment conveniently sits on a different domain than our users).  And yes, some users can't sign in when configured this way, some are prompted to sign in and authentication fails.   Also Firefox requires some changes to advanced settings at the client level which is just not feasible for us. So, in our Test Portal site, we are trying to implement AD FS, and were having trouble.  However, it turns out that we can create new accounts through the SAML option and that works fine with AD FS.  The problem is for existing Portal accounts created through the 'Add members based on existing enterprise users' method - those have the Username@DOMAIN format, which is not the format that AD FS server needs. We did find that for those existing accounts, you can make them work with AD FS if you go into Portaladmin > Security > Users > Update Enterprise User and enter the Username@DOMAIN in the 'Username' box, then enter 'Username' (removing the @DOMAIN) in the IDP Username box and updating.   After doing this, a user can use SSO via AD FS, but a few clicks are required (no actual typing of user name/password though, which is acceptable for our purposes) and this works for our VDI users. No we need to figure out how to programatically run existing enterprise users through this tool instead of manually doing that for 100+ accounts in our production Portal. ... View more

We typically make sure that account is part of an admin group on the server instead of manually granting rights on specific directories - also, seems obvious but we've been burned before - make sure the AD account will be exempt from any mandatory password changes enforced at your organization. ... View more