Latest Contributions by MTaft-Ferguson

We can suppress alerts related to having location services disabled in surveys themselves, but it would be nice to also suppress this screen on startup: We use Survey123 for a number of data collection workflows where the device's location is unimportant and those surveys are usually filled out on desktop computers that have location services disabled. Users find the above error (which appears every time the app is opened) confusing or annoying, especially for new or infrequent users. ... View more

invite_users should actually take a list, of course. But if I pass a string by mistake/by not reading the docs closely enough, I encounter two different responses, neither of which indicates that the format was the issue, and one of which suggests there is any issue at all. If I pass a nonsense string ("boo"), the value returned is simply True-- aka the same response as when I pass a list of valid usernames. Obviously with "boo" I wouldn't expect an actual user to have been invited, but I also get this response with invalid usernames, including for example a colleague's username with one letter missing. This non-error also occurs when I pass nonsense or invalid usernames via a list, which would make troubleshooting typos almost impossible. If I pass a valid username as a string, though, I get the error "Unable to invite Public Account to a group owned by an organization." These users are not public accounts, they are organizational accounts owned by the same org that owns the group (OR are organizational accounts owned by a different org-- in both cases, it seems to recognize that the username is valid, even when external users' accounts are not publicly visible). But a string is the wrong format, period. Why first of all is this not recognized or flagged in some way (an integer throws a TypeError)? Second, what is going on such that something evidently distinguishes between a string which is a valid username (in-org or not) and a string which is not even if it conforms to the same format as a proper organizational username (bsmith_umafm vs bmith_umafm, say)?  ... View more

For security/clarity purposes, it seems like a good idea to indicate to users whether a group belongs to their organization or not, especially when they share data to an external group. Our org (a university) administers two AGOL instances, one for internal/administrative work and one for educational purposes. The internal org is managed by administrative IT, and only certain staff members have accounts there as-needed. The educational instance, however, is open to any student, faculty, or staff member. Using the Python API (invite_users) it is possible for a user on the educational side to invite internal users to groups on the educational org, even though those internal users' profiles are not publicly visible. Internal users can then share internal datasets to the educational group. This may be desirable in some cases, i.e. to support a student project using administrative data (location of parking spaces, for example-- something genuinely non-sensitive).  However, because there is no indication to users that they are sharing data to a group that doesn't belong to their organization, there is no good way for users to then not accidentally share sensitive data: say for instance, six months later, that user accidentally shares parking ticket information to the educational org group, because its name is similar to the internal parking group. A different color for external groups, or even a confirmation popup ("this group does not belong to your organization, would you still like to share this item?") would give users a chance to reconsider. ... View more

If this older idea cannot be implemented: Option to not use UTC time offset in ArcGIS Online  Could we instead have the option to set ArcGIS Pro to display time in UTC, rather than in the local time zone of the machine it is running on? The use case that prompts this request is as follows: an organization has some users with Pro, and many more users who only use ArcGIS Online. These AGOL-only users sometimes create new hosted feature services with time fields. It is not feasible for them to publish these feature services from Pro or ArcMap (which I understand would allow them to  associate the local time zone with these feature services). However, when Pro users then interact with those feature services in Pro, time is displayed in the local time; similarly, if Pro users add features, those features' time attributes are added in local time and so display the "wrong" time in AGOL. As we are trying to use AGOL + Pro for event management, the four/five hour difference between UTC (displayed on AGOL) and Eastern Time (displayed in Pro) is a potential cause for major confusion. It doesn't matter much to us whether the data is actually stored in UTC or not, but it matters that everyone working on this data see the same event occurring at the same hour, regardless of whether they view it via Pro or via AGOL.  ... View more

If this older idea cannot be implemented: Option to not use UTC time offset in ArcGIS Online  Could we instead have the option to set ArcGIS Pro to display time in UTC, rather than in the local time zone of the machine it is running on? The use case that prompts this request is as follows: an organization has some users with Pro, and many more users who only use ArcGIS Online. These AGOL-only users sometimes create new hosted feature services with time fields. It is not feasible for them to publish these feature services from Pro or ArcMap (which I understand would allow them to  associate the local time zone with these feature services). However, when Pro users then interact with those feature services in Pro, time is displayed in the local time; similarly, if Pro users add features, those features' time attributes are added in local time and so display the "wrong" time in AGOL. As we are trying to use AGOL + Pro for event management, the four/five hour difference between UTC (displayed on AGOL) and Eastern Time (displayed in Pro) is a potential cause for major confusion. It doesn't matter much to us whether the data is actually stored in UTC or not, but it matters that everyone working on this data see the same event occurring at the same hour, regardless of whether they view it via Pro or via AGOL.  ... View more