ArcGIS Online (November 2022 ) Release

[RussRoberts]

@BernSzukalski released a post on the ArcGIS blog site going over some great highlights of features that were released last night. 

Check it out here: https://www.esri.com/arcgis-blog/products/arcgis-online/announcements/whats-new-arcgis-online-novemb...

Also blogs will be tagged with whats-new-november-2022 and you can look them up with this link: https://www.esri.com/arcgis-blog/?s=#&tag=whats-new-november-2022

[DavidColey]

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

[RussRoberts]

@DavidColey I dont work on the instant apps team but I do know they have some fixes for minimalist and sidebar that is rolling out tonight. Do you have a ticket referencing the living atlas issue? 

[DavidColey]

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 

[RussRoberts]

If you can share a map showing the issue to a group and invite russell_jsapi into it I can take a look as well.

[DavidColey]

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 

[RussRoberts]

For the living atlas basemap layers are they shared publicly or only to the organization ?

[DavidColey]

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.

[RussRoberts]

If you can share a sample with me would be great. thanks!

[BernSzukalski]

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. I'll get an ENH in to get that message to make more sense.

As far as basemaps, I recommended curating your own custom basemap gallery. You can sign in at the the Living Atlas website and as admin you can share what you want from there into your organization's custom gallery.

That also lets you leverage some of the new, still in beta, basemaps, like Outdoor Map and Topographic w. Contours. 

This blog article describes how to do all that:

https://www.esri.com/arcgis-blog/products/arcgis-online/mapping/living-atlas-custom-basemap-gallery/

[DavidColey]

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...

[TanGnar]

@BernSzukalski @RussRoberts @DavidColey 

Regarding "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)."

The problem with this is that it's now asking permission to change publicly shared layers BACKWARDS to organizational (or owner) level when the map is set to that. That hasn't happened before and is confusing. People are used to that warning to bring stuff FORWARD to public when needed. Unfortunately, they are accepting that some layers need to be brought BACKWARD to the org to match their basemap and pulling public layers they are using offline by accident. This is causing our public facing apps to show login screen and disrupting our users.

A layer that is already public does not need to be brought BACKWARD to internal.