WebGIS Best Practices? - All fields MUST be visible when publishing ArcGIS Utility Network with Branch Versioning
A little later than you 🙂 but we are struggling with the same problem.
Given that all devices or junctions are in a single feature class, there are many fields that are not relevant for each AssetGroup=Subtype. These should be disabled. Not only in the pop-up config, but everywhere in general.
Before publishing the Feature Service with UN, none of the fields can be turned off.
So, to compile a map for publishing(/sharing as a WebMap), the data source for the Subtype Group Layers will be the Feature Service and not the database feature classes.
Then we save/share the configured map symbolized in this way as a WebMap.
We made a deep dive:
Pro does not treat the following two cases in the JSON schema "behind" aprx in the same way:
A: When the Map still exists "only" as a Project Item, (a regular Map before sharing the WebMap)
B: When the Map has already been published/shared as a WebMap and the WebMap has been downloaded (Add and open) and we are working on it in Pro. [This is the version that needs to be addressed, because WebMap must be able to change even after deployment.]
The schema of the downloaded and referenced WebMap CIM is more complex than usual Map behind APRX.
There is a JSON named based on a GUID which is the portal item of the downloaded (add an open) WebMap itself.
Which GUID to search for? can be found in GISProject.json.
In this file, we find that each layer has its own JSON, and if it is a Group or Subtype Group layer, each sublayer also has its own JSON. This is always referenced by its parent with a GUID.
This is how you should search for a specific JSON belonging to a "subtype group layer --> subtype
layer".
Pro stores the visibility of the field in this JSON. specified layer --> featureTable --> fieldDescriptions --> [id] --> visible: false/true
However, when we publish this on the actual WebMap, the portal saves the entire map as a single JSON file.
In JSON, this information is stored in a completely different way and in a different place:
For the layer where even a single field has one of the following properties set
- Visibility
- ReadOnly
- Alias
It creates a fieldOverrides array in the json and lists ALL fields with potentially modified properties, EXCEPT FOR THE FIELD WHOSE VISIBILITY WE HAVE DISABLED IN PRO.
This array in WebMap can also be found here in the specification: https://developers.arcgis.com/web-map-specification/objects/fieldOverride/
However, there is no mention in the documentation that WebMap stores the visibility of a field in such a way that it creates a list containing the names of all other fields except for the one whose visibility is turned off.
If I’m right(?) this fieldOverrides attribute can ONLY be edited under PRO. There is no interface for it under MapsSDK for JS, and the portal cannot see it at all.
Consequence in WebMap:
So, if there is a fieldOverrides array for a layer in WEB MAP:
Then, the items listed there will influence which layers FieldInfo returns in the Maps SDK for JS and what properties they have.
If a layer does not have a fieldOverrides array, FieldInfo returns the original list provided by the service or the values specified in WebMap's own popupInfo --> fieldInfos.
In this Blog: https://www.esri.com/arcgis-blog/products/js-api-arcgis/developers/subtypegrouplayer-with-arcgis-api...
They suggest setting this in PopUp config. But if I want to disable the field for the given subtype layer in all other respects, this is not a solution.
What is the easiest way to solve this programmatically without having to click around in Pro for a week 🙂 ?
We think the best solution is to write the fieldOverrides arrays directly into the WebMap stored on the Portal using a JS script. And we leave out the irrelevant fields based on a configuration. This can be done in JS, and although it's not very elegant, BUT it seems MUCH simpler than the CIM-based solution with py in Pro.
What do you think?
Have you found a solution? What was it?
Regards,
Robert
