Latest Contributions by DavidColey

Doesn't this only matter if you care to track other pages, views or widgets in the contained app?  Otherwise, if we only care about traffic to the app (ala web app builder), don't we just need the tag in the html? ... View more

I should probably rescind this post.  It looks like the arcgis api version 2.1 will go with the upcoming Pro 3.1 release.  That would be my guess anyway. ... View more

Yeah that happened to me too.  Something about the way the 2x aprx file keeps pointing to older locator directories that I had built at various 2x releases.  Since not all of my projects had the locators from the file directories loaded into them, for those projects I didn't get the errors after a 'save' to 3x ... View more

So for me I created a new project folder to hold all of my 3.x projects.  Then, I created a new aprx in 3x and named it the same as my old 2.9.x project.  Then I copied any gdbs from the old project to the new project in windows explorer.  Then I opened the 2.9.x in one Pro instance, and the new project in a 2nd Pro instance.  From there I just copied my maps, notebooks, charts from the 2x project to the 3x projects.   For any custom scripts and models I just created new toolboxes in 3x and copied the scripts and models from 2x.  Then I added in any folders and directories I needed, lastly in each map I re-sourced the layers to point at the correct 3x directory file gdb (if file gdb sourced). I know this sounds like a lot of work, but really the most time consuming part was re-sourcing the layers in the maps and models.  Even then, the benefits of re-building new 3.x aprx's was well worth the effort to have new clean projects and no more locator errors - or any other 2.9x errors. ... View more

Hi @tigerwoulds - I don't suppose you know if your method still applies at Eb Dev 1.10 - as far as the node version goes?  Definitely will be moving from VSCode to VisualStudio though - Security really dislikes the Chocolately as do I. ... View more

Yes hello @David_Brooks - I don't know how that would help you, unless you don't belong to an existing agol org.  Because even in a partnered collab there will still be sign-in prompts for layers depending on their share level, whether as-copies or by-reference. It really comes down to workflows and trust.  One thing you could do would be to have the agol org host that you are working with add you and members of your team to their agol org (without using up their seats as long you have an agol org) - i.e they add you to their agol org using your orgs agol credentials.  That way, when you get the prompt, you login using your own agol credentials.  Another thing you could explore: If the collab is a send and receive workflow you could try setting up the participating group or groups as shared update groups. ... View more

Hello -  I have 17 collaborations set up between our Enterprise portal (guest) and our ArcGIS Online org (host)., for about 7 yeas now. All of the collaborations are by reference.  As a county government, we have to provide data, and so for us, this means I can manage all of our layers in Enterprise and then send them to our ArcGIS Online org in the collaborations' groups, where those groups are part of our Hub / Open Data site. All of the layers that participate in the Open Data site are shared publicly in Enterprise, and the share level of the ArcGIS Online, by-reference version of the layer is also public, as are the AGOL groups that participate in the Open Data site.  In this way, no login prompts are ever displayed. We protect the Enterprise by not allowing anonymous access, and by disabling the Hosting site REST directory.  We chose not to collaborate webmaps (for say basemaps) but just the layers to make the basemap for the AGOL side. Nor do we have any Enterprise Configurable or Instant Apps that participate. We DO have Enterprise-registered, WAB developer-edition apps and  Enterprise-registered, JavaScript api apps that do participate in a collaboration.   I also have a collaboration where I am sending content from our Org to the Enterprise.  If the Org layer is public, then no login prompt is asked for the Enterprise user, but you have to be signed into the Enterprise. If I don't want the Org layer shared with the public, then yes - the Enterprise user will have to provide their AGOL login.  All of this by design. More:  the reason we use by-reference collaborations is due to how we manage data to keep it updated for the public:  GIS staff update layers in an SDE traditional  version space, we extract to file gdb via python and upload/overwrite SD-generated hosted layers via the arcpy sharing module.  We don't use the as-copies model because the as-copies model requires that the hosted layer have editing and sync enabled (as shown earlier) but that means the hosted layer is never over-written.  Should you want to use the as-copies model, then you are then instead setting up a workflow where the hosted layer is the edit layer, and edits are synced at maybe a shorter interval. Point is, we and I went through all of this pain to make this work precisely because we no longer wanted to use the add-item, stored credential method for several hundred layers.  And although the arcgis api will let you script doing that (now, but not when we started this) you are still adding performance overhead as the layer has to go through the ArcGIS Online proxy to read those stored credentials every time the layer is accessed. Hope this helps.  ... View more

Yup thanks @BernSzukalski  - I am already doing that with my org. I share select basemaps from the Living Atlas website OR now, I can add the ones I want to our group via the 'Update Basemaps' button on the Organization>Settings>Map.  Either way, esri, ESRI and esri_en continue to own the maps and their tile layers and that is the way I want to keep it (unless I absolutely have to save a modified vector tile layer) so I am always getting the latest updates. Yes, I agree with you here: "That message about not having permissions to update sharing does not mean that it isn't public - it just means you don't own it and can't change sharing." which is what I thought as well because they are (continue to be, have always been, etc) public. And that is OK, and thanks for the ENH request...   ... View more

So I always thought that when you select 'Edit with IDLE (ArcGIS Pro)', and your ArcGIS Pro PackageManager>Active Environment is set to the cloned environment, that meant it would use the pythonw.exe from: C:\Users\myProfile\AppData\Local\ESRI\conda\envs\arcgispro-py3-clone\pythonw.exe   Are you saying that is not the case and the IDLE is still using the default environment at: C:\Program Files\ArcGIS\Pro\bin\Python\envs\arcgispro-py3\pythonw.exe ?     ... View more

Yes. the living atlas basemap webmaps are all shared publicly, as is our custom basemap group. The custom basemap group is shared publicly. The custom basemap group does contain some distributed vector tile content from our enterprise portal, but that content is all public as well. Not all of the living atlas basemaps layers appeared in the our custom basemap group when I selected 'Update Basmaps'  from Organization>Settings>Map>Update Basemaps. For example, the tile layer from the Community basemap webmap does not appear in the group.  The tile layers for the Human Geography Map DO appear in the group - and these are shared publicly as is the map. ... View more

Hi @RussRoberts  - After some time in reviewing my maps, layers and various share settings, it appears that the 'Update Sharing' dialog will appear anytime something in the map is not shared at the same level or with the same org groups as the map itself. It's fine - it's just that this is a new behavior I did not see described anywhere in any of the 'What's New' blog articles and so was unexpected (for me anyway). As far as Living Atlas content:  the permission update dialog warning is only occurring with publicly shared maps.  When the map is owner only, owner- group, or org-only, this warning does not appear. @MicheleLundeen  ... View more

Hi @RussRoberts - yes it would appear the fix for the Sidebar app has occurred.  The app now loads its map in both the configuration editor and when launched to view, so thanks to the team. For the issues regarding the permissions error about living atlas basemap layers upon a map save in map viewer, that is still occuring: It doesn't seem, so far, to have an adverse affect on apps, but I can't be sure until there is time for more testing.   In the meantime, I do have a support case started for this issue: Esri Case #03195989, but have not yet been able to begin work with the analyst @MicheleLundeen    ... View more

@sarah_maisel it would appear the fixes for the Sidebar app have occured. The apps' map in both the configuration editor and when launched as a viewer does now load properly. @MicheleLundeen  ... View more

I'm sorry but this update has created some problems with Instant Apps and with Living Atlas layers.   For me and others, all of our Sidebar apps stopped loading their map.  There are problems with the Gallery Instant app also. More - all of the ESRI Living Atlas layers contained in the the ESRI Living Atlas basemaps that I have shared with our custom basemap gallery now throw an 'insufficient permissions' error whenever I try to save a map in the map viewer.  The Sidebar app problem can be found under BUG-000153630 and the Living Atlas problem can be found under my case submittal at Esri Case #03195989 ... View more