Latest Contributions by AdamMesser1

We have an ArcGIS Online hub site that we recently reviewed and updated for accessibility. We have several gallery objects and updated them to "Open in Same tab" based on the included WCAG notice recommending this choice in the hub site manager. Implementing this choice results in the browser not retaining its history. A user opens a new blank browser page, navigates to the hub site, clicks on an application card in the gallery, the new application opens. However, the browser back button goes back to the new blank browser page, not the hub site. One of my developers said it appears that Esri is treating this as a single page application (SPA), and is rewriting the hub page in place, thus updating the URL and the page contents, but a new page is not created. Use of a SPA without history is considered bad practice. Is this intended? Is there a setting to change this behavior? Until this is fixed, the "recommended" Same tab is worse behavior and more confusing than New tab for accessibility. ... View more

Was trying to update an ArcGIS Online hosted feature service definition. This service was created by publishing a Survey 123 Connect form, where both the hosted feature service and the *_form view were created. To allow our internal systems to access and query the feature service, we need to update the service definition to change the allowAnonymousToQuery and allowAnonymousToUpdate values to true. When clicking on Update Service Definition, the "Invalid definition for 'SourceSchemaChangesAllowed'." and "Invalid definition for System.Boolean" errors are returned. In researching this it appears the SourceSchema variable is only valid for the View, which I was able to update successfully. However, for the source feature service, you actually don't even have to change anything to get the error. You can click update and the errors appear immediately. The only way to update the allowAnonymous values was to remove all references to sourceSchema before clicking to update the definition.  Is this a bug?  Hopefully this helps anyone else with the same issue. Anything not changed is returned the next time you update, so removing the SourceSchemaChangesAllowed entries does not remove them. You will have to remove them each time you need to update the service definition. Please provide suggestions if there is a better way to approach this. ... View more

I was testing the use of the API Key functionality for conducting python automation via the arcgis python api and I expected API Key privileges to apply. However, testing indicated API key privileges were following the user role that owns the key, not the privileges set in the key itself. I'm wondering if there is a bug in the Arcgis API or if I am missing something? Testing steps: Using ArcGIS Online, I created an API key to test allowing access to organization resources via an automation script. I gave the key one privilege: Admin>Content>View all. This also automatically selects the additional privileges: General>Members>View; General>Content>View content shared with organization; Admin>Members>View all. A referrer url was not designated. The test used arcgis python api version 2.3.0.3. After using gis = arcgis.gis.GIS(api_key="*KEY*”) to authenticate, I was able to retrieve content as expected. However, I was also able to add records (using layer.edit_features(adds=itemList)) which I did not expect. I tried this with an editable feature layer I own and a non-editable layer another account owned. My account role includes General>Features>Edit with full control, so I assumed the API Key was using my user role privileges. To test this, I logged on as a test user with a similar role and created an API Key with the same privileges as described above. The editing capability was available and I was able to add records to the two layers as previously described. I then changed the test user role to only allow General>Content>Create/Update/Delete. The API Key authenticated. As expected, I could not query items from the other accounts. I updated the test role to include Administrative>Content>View All. The data could now be queried as expected. However, the edit test again allowed me to add data to both feature layers. When logged on as the test user directly to AGOL, I was able to manually edit the data for the editable layer, but not for the non-editable layer. I examined Privileges | Documentation | Esri Developer  to learn about the scope. It appears that the AGOL Portal Service privileges have personal scope “that require additional permissions from your account to perform operations.” However, in this case it seems the privileges for the API Key are being overridden by the user role permissions not enabled by them. When using the arcgis python api, it is not adhering to the privileges of the API Key, nor is it adhering to the privileges of the user role. This test would suggest if I set up an API Key as an administrator, any workflow using that key via the python api can conduct any action on my site regardless of the privileges in the key. Obviously that is not great. ... View more

Automation workflows on dedicated scheduled task machines running ArcGIS Pro suffer from named user authentication time outs. To avoid the task user being timed out, the current suggestion is to use a dedicated single use license. With the move to named user/user type licensing, we need a method that will allow the task user to re-log in or remain logged in to ArcGIS Pro. Ideally, this would be made possible via a programmatic process that could work with any scripted workflow conducted on the task machine. Benefits Scheduled task user will remain logged in to the task machine to provide uninterrupted capability Named user user type/ licensing will allow the same licensing model to be applied to all organization users ... View more