nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Hide shared items from being discoverable

jtmouw_NCDOT

A typical issue that we run into in our organization is that for an end product, be it a map, dashboard, experience, etc. to be shared, every building block also has to be shared as well. The reason this is cumbersome, confusing, and sometimes risky for data quality is that end users often stumble upon the layer or map instead of the end product when searching for.

That means that there is way that they could circumvent a carefully constructed smart forms with important calculations, or reach a dashboard that does not contain the information that they actually need.

It would be nice to maintain the items' shared status, while making it not discoverable for two main reasons.

1. A user would ONLY find the dashboard/Experience/end product when searching, but still be able to view and use it.

2. A user could only find the web map with the smart forms, and NOT be able to find the isolated layer itself to pull into their own map where some of the calculations might break or the form is not configured at all.

See the attached example - we have an experience with 2 embedded dashboards - we would prefer users to only be able to find the experience, not the dashboards AND map that the dashboards are built from.

2024-10-17_11-48-06.jpg

SaraJL_1-1737566042792.png

Find more posts tagged with

Status: Open

Comments

kenbuja

I have a similar use case. I have a Web AppBuilder app with a custom widget (which is in the process of getting rewritten for Experience Builder) to gather information from a defined group of users. A separate feature layer is created for each user and shared with the user in a unique group for that user. The widget imposes constraints on the editing capabilities of the user, such as limiting the user to making edits on only a certain percentage of the features.

If the user edited the feature layer outside the app, they wouldn't be subjected to those constraints. I've had a few cases where a user had enough experience with AGOL and accessed the layer through their account, which created problems with the data they attempted to submit. Making the layer invisible to the user would solve this problem.

ClarkLangridge

We have several such use cases. Often we are sharing potentially sensitive information with outside groups who have no GIS capability whatsoever and can't pay for the AGOL licenses for all the end users. We try to restrict the data as much as possible to limit the release of anything potentially personal, but at some point we (the Information Security Officer and I) with business and basically say "look, there is the possibility that anyone in the world could find this app pretty easily, are you OK with that?"

Similarly with the underlying services and web maps. There are lots of support calls I've gotten about a web app being broken, only to find that they've found the web map, not the web app. We've taken to having to start the name of any web map to be used in a dashboard or app with "DO NOT USE!"

In fact, most my users assume that this functionality already exists and point out that I've shared things like the web map by accident, then give me funny looks when I have to explain to them that I actually can't hide the underlying web map.

PeterKnoop

We often have similar use cases, where we want the user to go to something specific, and not the parts that make it up. Not necessarily for security concerns, but more about getting the end user to the right place. Things like getting the user to the Instant app, not the web map or layers used in the instant app

Perhaps a way to address such use cases would be to enable the user to specify a redirect for an item. If they try to open the Web Map used in an Instant App, the user would be automatically redirected to the Instant App. Or, if they tried to open a feature layer used in a web map, then they would be directed to the web map; and, on to the instant app, if a redirect was set for that.

It would still be helpful for some use cases for the user to able to view the item details for a component, so they would still be able to get to that page. The redirect for would be for URLs for "viewing" the content, such as opening a web map or feature layer in the map viewer, opening the data or visualization tab for a feature layer, etc.

The redirect could be to send users to Dashboards or Experiences as well. If user tries to view a layer you've used in a dashboard, then the author could set a redirect for that layer to send the user to the Dasbhoard.

Richard Howe

Just adding my support for this. It could be an optional parameter on a custom role perhaps? So people with a specific role can only view certain items (say maps and apps).

We have thousands of items in our portal, and when users look at the "shared with me" pane they can quite easily be overwhelmed or accidentally happen on a layer, mistakenly think that is a map and then open it in the map viewer and be none the wiser