IDEA
|
@TanuHoque That is not what I am seeing in 2.6.2 Here is an example feature service in Pro: Same service in AGOL: Honestly I don't know which timestamp is correct (aka reflects the time the editor would have seen on his computer's clock when he did the edits). I believe it's probably the AGOL time. It doesn't really matter-- what matters is that they are being displayed differently in AGOL/browser vs Pro. Its properties show that its time zone is UTC:
... View more
11-25-2020
08:28 AM
|
0
|
0
|
6274
|
IDEA
|
Operations Dashboard and Experience both! We have use cases very similar to Tanner's list of counties/impacts above and it's a real shame we can't use Ops Dash for these.
... View more
07-28-2020
05:29 AM
|
0
|
0
|
5536
|
POST
|
I see this was reported fixed in 2.4, but in 2.5 the same behavior is occurring for me Kory Kramer
... View more
07-02-2020
10:56 AM
|
0
|
1
|
878
|
IDEA
|
Our IT has disabled location services for almost all devices for security reasons, and as mentioned above, device location is unimportant for many surveys that our users complete. In our case, we need an option to suppress the error, because we will not/cannot turn location services on and because the error does not convey any relevant information for our workflows.
... View more
04-02-2020
04:39 AM
|
1
|
0
|
3122
|
IDEA
|
Hi Juan, Forgive me if I misunderstand, but I have the most recent version of the desktop app (3.7.57) and still get the error every time I open the app:
... View more
01-08-2020
09:44 AM
|
2
|
1
|
3119
|
IDEA
|
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
08-27-2019
01:05 PM
|
29
|
12
|
5635
|
POST
|
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
08-01-2019
05:30 AM
|
1
|
2
|
595
|
IDEA
|
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
07-31-2019
01:31 PM
|
1
|
0
|
266
|
IDEA
|
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
11-16-2018
09:40 AM
|
8
|
23
|
9730
|
IDEA
|
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
11-16-2018
09:40 AM
|
3
|
0
|
568
|
Title | Kudos | Posted |
---|---|---|
1 | 08-01-2019 05:30 AM | |
29 | 08-27-2019 01:05 PM | |
1 | 04-02-2020 04:39 AM | |
3 | 11-16-2018 09:40 AM | |
8 | 11-16-2018 09:40 AM |
Online Status |
Offline
|
Date Last Visited |
02-13-2024
09:03 AM
|