When I publish a 10.3 service from ArcGIS Server and subsequently edit the service in the Collector app, the "Done" button will not be tapped if the field is required. But if I change the field in Catalog to allow Null values, the "Done" button in the collector app will work.
Is this a known limitation, is there a workaround, or is it a bug?
Thanks!
This is by design.
If you are not allowing Nulls, something will need to be added into the dialog for that field before it's committed to the database.
Not necessarily a limitation in this case, as it's enforcing the rule that you set on the feature class.
However, flipping the coin, we should have the ability to set a field requirement on a feature class that DOES allow nulls in the application, IMO.
I'm describing a scenario where the editor does fill in the field. So the field isn't null. It is the presence of the No Nulls constraint which seems to inhibit the "Done" button -- even when the field is not null.
I'm wondering if this functionality is still working or was broken in the recent 10.3.1 release. It was working for me in initial testing, but we just did a bunch of field testing and now users are able to submit records without filling out all the required fields. I check the Layer Definition directly via a browser and the fields are still set to "nullable" : false. We are running a hosted service.
Paul
-------------------------------------------
Paul Cone
Corporate GIS
Bureau of Technology Services
City of Portland, Oregon
Is Collector trying to be clever and putting some data in there for you when the field is not allowed to be null?
E.g. if you have a text field that's not allowed to be null, it will silently pre-populate it with a space so the user can just submit the feature without entering anything. It will only prompt them if they manually delete the space, which they probably wouldn't realise was even there.
Well, the extra space thing is a different annoyance, but in this case it is a picklist. The user must choose one of the options for the record, but Collector is no longer enforcing it.
{ | |
"name" : "Posting", | |
"type" : "esriFieldTypeString", | |
"alias" : "Posting", | |
"sqlType" : "sqlTypeOther", "length" : 20, | |
"nullable" : false, | |
"editable" : true, | |
"domain" : | |
{ | |
"type" : "codedValue", | |
"name" : "PostingPlacard", | |
"codedValues" : [ | |
{ | |
"name" : "Inspected (Green)", | |
"code" : "Inspected" | |
}, | |
{ | |
"name" : "Restricted (Yellow)", | |
"code" : "Restricted" | |
}, | |
{ | |
"name" : "Unsafe (Red)", | |
"code" : "Unsafe" | |
} | |
] | |
}, | |
"defaultValue" : null | |
}, |
In our setup, with 10.3.1, a not-nullable drop-down field can be left empty by the user and Collector will actually store a space (if nullable was true it would store null). It was only obvious to me by looking at the attribute table of the feature layer in ArcGIS Desktop / Pro that a space was being stored because Collector and AGOL will only show you the drop-down choices. Not seen it actually set the value to null, but I guess a space is equally as useless.
I think the space issue is perhaps new. I noticed that in the table as well, and I didn't see that happening before 10.3.1. So maybe this is the cause.
I also just changed the service I am working on and made CreateDate and EditDate required fields and now my Submit button is greyed out. So it seems the functionality still working overall.
So I talked with ESRI about this. The issue is, there's a template that gets created in the Layer Definition, that Collector is using is populating the all the fields, even the mandatory ones. It's beyond a Collector issue, and more of an AGOL issue, that they said they'll work on a solution, but in the meantime you can work around it by going into admin mode and doing Update Layer Definition and then deleting the default values out of the template.
We are having the same issue only using Portal instead of AGOL. However, I don't think there is an admin mode in Portal where you can override the template. Hopefully Esri will address this in Portal as well.