We struck the opposite with Portal 10.5.1 and the Edit widget in a Web App. By setting not null i.e. nullable:false and a template with fieldname:null it breaks the Edit widget. The edit widget doesn't show the attribute editing table after creating the feature and the edit fails with the server recording, "0 : ERROR: null value in column "deviceposition" violates not-null constraint ..."
If we use the Smart Edit widget it works properly and highlights to users it's a required field which must be entered. The Save button is greyed out until the required field is given a value.
By editing the Feature Service via the admin API (thanks Kelly Gerrow) to change the Template fieldname to be nothing (""), this fixes it (the opposite of what Kelly suggested for ArcGIS Online).
Before:
After:
Thanks Ronnie,
You have described what causes this issue well. The issue is that when publishing a default value of 0 or null is added, which is automatically added when editing in Javascript Applications. It was built this way to support the workflows in the past, but now results in an unideal user experience. There is a way to workaround this with ArcGIS Online Feature Services. When publishing a default value is added to the editing template. This default value can be changed to null through the feature Services admin API, which will result in records without required fields being rejected.
You can see this behaviour with the following web map where i modified the template for the field RatsFound to have a default of null:
http://arcg.is/1fL99W
https://services5.arcgis.com/cuQhNeNcUrgLmYGD/ArcGIS/rest/services/Rat_Tracker/FeatureServer/0?f=pjson
To change this you will need to access the feature service admin api, and modify the template to include null the correct template value.
In this example, I changed the template from example A To example B in the updatedefinition call of the feature service admin:
Example A: Space for default value
{"templates": [ { "name": "Rats", "description": "", "drawingTool": "esriFeatureEditToolPolygon", "prototype": { "attributes": { "Inspection": null, "DogBreed": null, "RatsFound": "" } } } ]}
{"templates": [
{
"name": "Rats",
"description": "",
"drawingTool": "esriFeatureEditToolPolygon",
"prototype": {
"attributes": {
"Inspection": null,
"DogBreed": null,
"RatsFound": "" } } } ]}
Example B: null for default value
{ "templates": [ { "name": "Rats", "description": "", "drawingTool": "esriFeatureEditToolPolygon", "prototype": { "attributes": { "Inspection": null, "DogBreed": null, "RatsFound": null } } } ]}
{ "templates": [
"RatsFound": null } } } ]}
I have had this complaint for a while only to be told by ESRI Support this is the way the geodatabase works and based on my research is related to shapefile exports. Only some of the ArcGIS applications (Ie: Collector) will support the NON NULLABLE field property, while their flagship products (ArcMap, ArcGIS Pro, Web Maps) ignore it and post space values (in the case of string fields). Even the latest version of ArcGIS Pro when editing a local file geodatabase will "work around" the data model and not respect the NON NULL or REQUIRED FIELD settings. It seems rather pointless to have these tools around for fields if the platform is inconsistent with the way the are validated (or not).
I submitted this idea several months ago but it probably needs a better description after reading it again.
Fix Feature Services so they do not bypass the data model
Also here is a section from ArcGIS Help which states how these field properties will be dealt with when exporting to shapefiles but this seems to be the default behavior of most of the applications when editing a file, sde gdb or feature service with field properties set for NON NULLABLE or REQUIRED.
Defining feature class properties—ArcGIS Help | ArcGIS Desktop
Geoprocessing considerations for shapefile output—Help | ArcGIS Desktop
I really wish the tools (especially web maps) would not create a record if the user does not interact, complete the required or non-null fields or hit "x" on the form it just ends up creating a lot of garbage data. The web map actually creates the record before the popup comes up kinda of a bad design and does not have to be this way. Geometry can be stored in a memory along with the form attributes. Can you imagine if our bank transfers still went thru if we hit the "X" to close the window? Results in a confusing user experience and bad data the administrator has to clean up later.
Yes, exactly. Is there another way to do it?
Thanks
How did you set the required filed? By not allowing null values?
Similar issue for me. Not using collector, but the webmap allows creation of features, with null values for required fields. I am seeing the yellow triangle indicator, but I would expect the 'close' (save) button to be disabled until all req fields are populated.
I don't know how far this question has gone but when I set required fields in collector 10.4.2, the warnings show but empty required fields are allowed to save without any prompt. Please is there any workaround to fix this?
When I change 'Allow NULL Values' in Feature Class Properties on ArcMap Desktop from 'Yes' to 'No', it doesn't make the field required in my Geoform. It prevents the question from showing up in the form at all! Anyone else having this issue and know how to resolve?
I'd like to make questions required in my Geoform, but it seems the only question that can be required is the one used with symbology.
Thanks!
I meant to say I've tried editing the feature service URL by changing the field property from "nullable" : false to "nullable: true...
I've been trying to use the new Smart Editor widget to edit certain fields of a feature service,however, it's preventing me from saving these edits because, as far as I can tell, a 'required' field in the service must also be edited. As Josh White inquired in his original post, I'm also unclear how this field got flagged as being required (see image). More importantly, how can I remove this field requirement? Re-publishing the service is not an option as field crews are actively editing the data using Collector. I've tried editing the feature service URL by changing the field property from "nullable" : true to "nullable: false; however, this is not persisting after I update the layer definition. Any ideas on how to get rid of this feature service field requirement would be appreciated.
The problem is it that it is difficult to change whether a field is nullable or not after the fact. I would rather have the ability to control this through the app. Of course, if a field is non-nullable then that would override any settings in the app until the field could be changed.
It was showing up in any field with a domain value which was confusing users. Also the ability to change the attribute for a column that the editing template uses to symbolize is also an issue which then clears out fields that do not have a default value. This behavior does not exist in Arcmap, ArcGIS mobile so it is very confusing to users.
Hey Josh -
I see, so currently the workflow is that the yellow exclamation marks will appear if no value is entered in a field and the field is set to non-Nullable. You would like the option to have those yellow warnings appear even if the field is nullable, is that right? With our products, setting a field to be nullable/non-nullable is the property you use to set the field requirements. Granted, there are a few bugs out there for our APIs (ArcGIS Online, Collector iOS, Collector Android) but the theory is:
NULLABLE = "not required"
NON-NULLABLE = "required"
We are actively working on the issues surrounding this particular setting (i.e. enforcing the setting in the APIs), but that's the gist of it.
Julia,
My original problem was really the opposite of that and yes some of the issues are likely resolved for me in 10.2.4. I want the ability to require fields have a value regardless of whether they are nullable. Others have mentioned domain fields. Sometimes these would be required, sometimes not, depends on the feature.
An enhancement request has been logged for this: http://support.esri.com/en/bugs/nimbus/role/beta10_1/TklNMTAzMzk5
This issue has been fixed in Collector for ArcGIS version 10.2.4! Hopefully this is helpful. If this issue is still happening at version 10.2.4 for anyone, let us know - get in touch with Esri Support and we can take a look at it
I agree on the editor tracking, I've really only used Collector in a test state so far so I'm not sure how it is working. I have noticed that when I used the editing feature in my Flex webmap using a feature service, the editor always showed up as Esri_Anonymous which is completely useless. Of course there isn't a log in required so that might be what causes that. I just wish it would use Windows credentials.
I totally agree the flexibility to control the required value property in AGOL would be a really nice enhancement. I would also like to see the ability to include date/time stamps for inserting vs updating data configurable within AGOL as well so I don't have to use the editor tracking functionality within the database.
I haven't worked with this much since. I would recommend that Esri just make the required property editable in AGOL. It seems this would be a quick fix. Plus this would give you options to require fields that the REST endpoint says are nullable if desired.
I just want to revive this thread and ask if anyone knows the exact step to set required field in arcgis online ? I tried replicating by assiging a Domain with coded value to an attribute field of a fc in a feature service, but did not see the same result as what others have mentioned about seeing the required field show up in AGOL ?
Me too. It appears that the API assumed a field to be required if a coded domain is specified.
I see the behavior in AGOL that you are describing when I assign a Domain with Coded Values to an attribute field of a featureclass in a feature service.
Has there been any progress on this issue? I'm searching for way to control which feature service fields are marked as "required" in ArcGIS Online/Collector.
I posted a reply in that forum thread as well. Thanks for bringing it up.
I noticed the same issue as well and I am also having issues that I think are related to this as well when it comes to adding new features. It seems like ESRI currently knows this is an issue based on the forum posting below since it is not reading the REST endpoint settings for non-nullable fields. I still don't get why ArcGIS.com editing is showing an icon for fields that are not required as well.
https://community.esri.com/message/320756?sr=search&searchId=4d3af6bf-8ab4-4458-9606-0392d8090869&searchIndex=3#320756
Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
