Block users from accessing the items that create the APP on ArcGIS.com & Portal

236
0
01-18-2024 08:47 AM
Status: Open
DylanKennard-tt
New Contributor II

Idea: When creating an app for someone, it would be great if they could somehow be limited to only viewing the app, rather than logging in to ArcGIS.com with their username and seeing all of the content behind the app.

Issue: This is a growing issue as many users have powerful accounts, group controls are limited, and as the GIS community we need to create and foster a healthy User Experience and User Interface. When users login to AGOL or Portal directly they can then start playing with items. This appears healthy on the surface but causes overal support issues, control issues, etc. We have users that we give access to the App. They then accidently go to the main AGOL URL, start messing with items, make goofy maps, then call and complain they cannot see xyz, the app doesn't work, etc but it's because they had access to all the items and just went nuts. This then creates a negative view of ESRI, GIS Staff, etc because we are wrong but they went and mangled it all up.

How it Use to be: I think it's key that people can only access the APP front end. This is how it use to be with ArcServer before Portal and AGOL. The App Link is provided. Then the App itself uses a Service Account to access all the underlying map services, etc. This setup has been around for 20+ years. With Portal and AGOL this simple, but super important, architecture was removed.

Suggested Solution/Idea: To reimplement that 20+ year old theory in the modern ESRI Enterprise Pattern it could be as simple as:

  1. Make a Group
    1. Group configuration is "Let Group Members Access these item types:"
      1. App
      2. Map
      3. Data Items
  2. You then just check on the boxes you want the group to access.

Fundamental Issue: I firmly believe ESRI needs to stop pushing "everyone can make maps". It's belittling and no other field out there says "Everyone can be a biologist bird observer or a train engineer". If ESRI stops thinking that way then addressing a feature like this would move into a top priority. 

Tags (3)