Latest Contributions by JeffShaw2

‎06-01-2020

Not irrelevant. Views are great but if you share one publicly it is visible (and editable if configured as such) everywhere, and not just within the intended app (geoform in the case above). By Esri's own admission, numerous AGOL apps/forms have security vulnerabilities as a result. See: A brief document describing security considerations. The recommended "solution" of only allow "Add" only works for some workflows. There needs to be a way of restricting service access to only the intended app(s). The existing method of securing a service using an account and specifying referrer URLs is not viable given that it uses an individual user account, and the account generally has a password that expires. Using Enterprise with a service account works, but not everyone has Enterprise. Restricting access to editable services to specific forms would enable use of more sophisticated form logic to control access. Similarly, being able to restrict read-only services to their intended apps would help reduce problems with data misinterpretation and representation (feature generalization, accuracy at various scales, etc) that have resulted in numerous problems for landowners.

‎05-12-2020

I have posted another idea that addresses how to improve the sign-in experience for accessing Hub Community content. Separate the AGOL and Hub Community login screens‌

‎05-12-2020

I have posted another idea that addresses how to improve the sign-in experience for accessing Hub Community content. Separate the AGOL and Hub Community login screens‌

‎05-12-2020

I have posted another idea that addresses how to improve the sign-in experience for accessing Hub Community content. Separate the AGOL and Hub Community login screens‌

‎05-12-2020

When an organization licenses Hub Premium and gets an additional portal for issuing Hub Community accounts to external users, the Hub Community sign in options are added to the existing screen that staff see. That creates a very confusing mix of options for both sets of users, and can lead to users in both orgs trying to sign in to or create accounts that they shouldn’t or can’t use. I propose instead that when Hub Community accounts are activated by an org, and a user accesses that Org’s content, that users first be asked how they want to sign in. For example: That will enable the actual sign-in screen to be much simpler, and relevant. For example, only people who can actually use Facebook or Google to sign in will see those options. The same is true for Enterprise login options. If our organization enabled Facebook and Google sign in options for Hub Community members as we would like to, the sign-in screen used for both AGOL and Community accounts would appear as shown below. Unfortunately, we have decided that we cannot enable the Facebook and Google options because of the problems it would create. Issues with the current sign-in screen include: We do not allow staff to use Facebook or Google to sign in to AGOL. If they click the Facebook or Google option, it will auto-provision a Hub account, which Esri’s terms say they cannot use, resulting in extra work and cost for us. Staff/contractors who find our content and want to sign in see the “No account?” text which tells them to create a Hub Community account. But Esri’s terms of use stipulate that you cannot create Community accounts for staff or contractors (other than for administrative purposes). Community members see the STAFF enterprise login option even though it does not apply to them. Similarly, when we federate our Community accounts with a different provider, I am guessing that staff will unnecessarily see that option. Another issue is that when someone creates a Hub Community account by using the email option and comes back to sign in, they have to know to choose the ArcGIS login option. But they have no idea what that is because the option they chose to create the account refers to it as a “Hub Community” account. Adding the screen proposed above would address that. These issues are all in addition those related to Enterprise logins as addressed inImprove app sign-in experience (button naming & org-specific help) Improve app sign-in experience (button naming & org-specific help) Improve app sign-in experience (button naming & org-specific help)

‎05-12-2020

When an organization licenses Hub Premium and gets an additional portal for issuing Hub Community accounts to external users, the Hub Community sign in options are added to the existing screen that staff see. That creates a very confusing mix of options for both sets of users, and can lead to users in both orgs trying to sign in to or create accounts that they shouldn’t or can’t use. I propose instead that when Hub Community accounts are activated by an org, and a user accesses that Org’s content, that users first be asked how they want to sign in. For example: That will enable the actual sign-in screen to be much simpler, and relevant. For example, only people who can actually use Facebook or Google to sign in will see those options. The same is true for Enterprise login options. If our organization enabled Facebook and Google sign in options for Hub Community members as we would like to, the sign-in screen used for both AGOL and Community accounts would appear as shown below. Unfortunately, we have decided that we cannot enable the Facebook and Google options because of the problems it would create. Issues with the current sign-in screen include: We do not allow staff to use Facebook or Google to sign in to AGOL. If they click the Facebook or Google option, it will auto-provision a Hub account, which Esri’s terms say they cannot use, resulting in extra work and cost for us. Staff/contractors who find our content and want to sign in see the “No account?” text which tells them to create a Hub Community account. But Esri’s terms of use stipulate that you cannot create Community accounts for staff or contractors (other than for administrative purposes). Community members see the STAFF enterprise login option even though it does not apply to them. Similarly, when we federate our Community accounts with a different provider, I am guessing that staff will unnecessarily see that option. Another issue is that when someone creates a Hub Community account by using the email option and comes back to sign in, they have to know to choose the ArcGIS login option. But they have no idea what that is because the option they chose to create the account refers to it as a “Hub Community” account. Adding the screen proposed above would address that. These issues are all in addition those related to Enterprise logins as addressed inImprove app sign-in experience (button naming & org-specific help) Improve app sign-in experience (button naming & org-specific help) Improve app sign-in experience (button naming & org-specific help)

‎02-07-2020

The Survey123 product team implemented this idea a few months ago (see red text in example below). Thank you!! Now we just need more of the Esri product teams (e.g. Collector) to do the same. What's new in Survey123 Features have been added to Survey123 progressively. This topic lists the features that were added at the different stages of release this year. For a list of all updates made throughout the life of Survey123, see the What's new archive. Update January 21, 2020 Survey123 website Fixes and improvements include the following: ...

‎02-07-2020

The Survey123 product team implemented this idea a few months ago (see red text in example below). Thank you!! Now we just need more of the Esri product teams (e.g. Collector) to do the same. What's new in Survey123 Features have been added to Survey123 progressively. This topic lists the features that were added at the different stages of release this year. For a list of all updates made throughout the life of Survey123, see the What's new archive. Update January 21, 2020 Survey123 website Fixes and improvements include the following: ...

‎02-05-2020

Adding same comment I posted on what I suspect will be marked as a duplicate idea: Hide webmaps in Explorer for ArcGIS This is important for our organization also. We have nearly 200 webmaps that are either public or shared with the organization. Most are designed for use within a specific application interface, and some of the org webmaps exist only for demonstration and template purposes. These along with many of our 600+ group-level webmaps also not intended for use in Explorer make it difficult to find those that are designed for use in Explorer. The current situation is confusing and inefficient for users and can result in data being used inappropriately. What we really need is a better method of making webmaps and layers available only to the interface for which they are intended (rate limiting is not a viable solution given that passwords expire). Turning off access to Explorer doesn't prevent misuse in Web Viewer, but it would certain make Explorer much more useful for our members and the public.

‎02-05-2020

Adding same comment I posted on what I suspect will be marked as a duplicate idea: Hide webmaps in Explorer for ArcGIS This is important for our organization also. We have nearly 200 webmaps that are either public or shared with the organization. Most are designed for use within a specific application interface, and some of the org webmaps exist only for demonstration and template purposes. These along with many of our 600+ group-level webmaps also not intended for use in Explorer make it difficult to find those that are designed for use in Explorer. The current situation is confusing and inefficient for users and can result in data being used inappropriately. What we really need is a better method of making webmaps and layers available only to the interface for which they are intended (rate limiting is not a viable solution given that passwords expire). Turning off access to Explorer doesn't prevent misuse in Web Viewer, but it would certain make Explorer much more useful for our members and the public.

‎02-03-2020

This is important for our organization also. We have nearly 200 webmaps that are either public or shared with the organization. Most are designed for use within a specific application interface, and some of the org webmaps exist only for demonstration and template purposes. These along with many of our 600+ group-level webmaps also not intended for use in Explorer make it difficult to find those that are designed for use in Explorer. The current situation is confusing and inefficient for users and can result in data being used inappropriately. What we really need is a better method of making webmaps and layers available only to the interface for which they are intended (rate limiting is not a viable solution given that passwords expire). Turning off access to Explorer doesn't prevent misuse in Web Viewer, but it would certain make Explorer much more useful for our members and the public.

‎01-16-2020

It appears that with the December 2019 update that Admins lost the ability to unshare another member's item from an "update all" group when selecting the item from the member's Content page. As Paul indicated, you need to temporarily drop that sharing in order to transfer ownership. You now need to go to the group and then removed the item. That is an additional, much slower process. I plan to open a ticket on that soon and presume the change was unintentional. We use the headless account method also. It's hard to imagine any large organization not doing so for purposes of reducing risk and work as members come and go and change responsibilities. Much less all the other benefits such as having content owned by less-privileged accounts. I submitted an idea similar to this some years back to address the challenges with these groups and using them for content management purposes. The idea (admittedly complex) didn't get a lot of traction. There has been some progress, but there is still a long way to go before these workflows are efficient and can easily be delegated to others. Enable Content Manager role by improving/fixing item sharing options and interfaces‌

‎01-16-2020

It appears that with the December 2019 update that Admins lost the ability to unshare another member's item from an "update all" group when selecting the item from the member's Content page. As Paul indicated, you need to temporarily drop that sharing in order to transfer ownership. You now need to go to the group and then removed the item. That is an additional, much slower process. I plan to open a ticket on that soon and presume the change was unintentional. We use the headless account method also. It's hard to imagine any large organization not doing so for purposes of reducing risk and work as members come and go and change responsibilities. Much less all the other benefits such as having content owned by less-privileged accounts. I submitted an idea similar to this some years back to address the challenges with these groups and using them for content management purposes. The idea (admittedly complex) didn't get a lot of traction. There has been some progress, but there is still a long way to go before these workflows are efficient and can easily be delegated to others. Enable Content Manager role by improving/fixing item sharing options and interfaces‌

‎01-16-2020

These are significant issues for our organization also. We manage published content as teams, not individuals, and use one "maintenance group" per topic area (20 so far). Most of our content creators do not retain ownership of items after they are published, so these types of groups are very important in our workflow. But there are many challenges, especially in terms of transferring ownership of items and sharing with these groups.

‎01-16-2020

These are significant issues for our organization also. We manage published content as teams, not individuals, and use one "maintenance group" per topic area (20 so far). Most of our content creators do not retain ownership of items after they are published, so these types of groups are very important in our workflow. But there are many challenges, especially in terms of transferring ownership of items and sharing with these groups.

Online Status	Offline
Date Last Visited	‎03-22-2024 05:38 PM

My Ideas

Latest Contributions by JeffShaw2

Re: Service Proxy to access your own Content on ArcGIS Online

Re: Improve app sign-in experience (button naming & org-specific help)

Re: Improve app sign-in experience (button naming & org-specific help)

Re: Improve app sign-in experience (button naming & org-specific help)

Separate the AGOL and Hub Community login screens

Separate the AGOL and Hub Community login screens

Re: Provide Survey123 release date for Current release

Re: Provide Survey123 release date for Current release

Re: Allow web maps to be hidden from Explorer

Re: Allow web maps to be hidden from Explorer

Re: Hide webmaps in Explorer for ArcGIS

Re: Improve Groups where members can update all items and documentation

Re: Improve Groups where members can update all items and documentation

Re: Improve Groups where members can update all items and documentation

Re: Improve Groups where members can update all items and documentation

Re: How to add an Organization's Domain Name to th...

Re: Automatically Open Map Feature Popup When Sele...

Allow Viewer user types to view Survey123 forms

Make legend boxes smaller

Does the Survey123 web app support readonly expres...