A user noticed an issue this week (20230322) with attachments submitted through Field Maps. The submitter can see the attachment but no other users can see it. However, if the attachment is loaded from ArcPro or the webmap in Portal, other users can see it. Same issue if a photo is taken. If the webmap is reloaded in Field Maps, the submitter no longer sees the attachment. My best guess is the photo remains on the ipad.
The WFS has been updated over the past few weeks as we prep for the spring melt. Other operational teams have not noticed any issues with their attachments. I chose one service to test - overwrote, deleted, rebuilt, published - same issue. I created a new webmap. Field Maps was removed and reloaded. Two different ipads were reset. Tested with different user roles (admin, creator/user, mobile worker/data editor). I can not find any references to bugs on the most recent versions of Field Maps. This older reference is the closest I can find... BUG-000116972
The issue presented in Field Maps 23.1.0 Build 984 and Field Maps 22.4.2 Build 954.
WFS was published from ArcPro 2.9.5 / ArcGIS Server 10.8.1 Build 14362
Testing on ipad OS Version 16.3.1 (reset on 20230324).
Any help is appreciated.
Solved! Go to Solution.
Yes, ESRI created a bug for this issue. BUG-000157495
We are having the similar issue in the Field Maps, attachments in related table are not saved in the database. However in ArcGIS collector works fine. We have tested publishing from different version of ArcGIS pro, different device IOS and android and different enterprise geodatabase versions (10.8.1, 10.9.1). Same ArcGIS server version 10.8.1 (build 14362).
We are experiencing the same issue in Field maps 23.1 and Server 10.6.1. Anybody had any feedback from ESRI?
Yes, ESRI created a bug for this issue. BUG-000157495
I will give that fix a try. Thanks!
Are you working with offline data?
R_
We are seeing the exact issue described in the original post but have confirmed all referenced feature services, and layers in them, have attachments enabled. Seems to have started recently, around 5/25/2003 going by date stamps on attachment records in the database. No changes to the services or map were made prior to that which could be correlated to this issue. All changes to the map and services were made well before we noticed attachments were not being submitted. We also see the same issue in maps that are configured for offline sync, occasionally attachments do not get saved server side but we have not found any error either on the device (troubleshooting logs) or in our server logs. In fact, if we turn on debugging logging, we can see log entries for the edit operation which includes adding the attachment, but no error messages.
Thanks @DianneMichalak ! It's just too bad that we have to resort to magic combinations, and figuring them out all over again whenever a new version of Field Maps comes out, or endless hours spent googling the interwebs for workarounds.
Hi, I've recently encountered this issue as well. My set up is that I have a referenced feature class (Tree Inventory) and related form (Tree Maintenance Form), each with attachments enabled, and another referenced feature class (Trails) without them. This has been working well in Field Maps until a few days ago when attachments no longer stuck on the first feature class, but still work on the related form. I used this thread to troubleshoot:
1. Published a new service with only the Tree Inventory and related form. According to that thread/BUG workaround, if all layers in the service have attachments enabled, Field Maps should successfully save attachments. This did not work.
2. Enable attachments on the Trails layer, same reasoning as above. Did not work.
3. Publish a service containing ONLY the Tree Inventory feature class, no related form. This did allow the attachments to stick, but it is not a great solution because we need to have the related maintenance table in the feature service.
Any ideas?