nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Collector can't handle required fields, i.e. Nulls Not Allowed?

Anonymous User

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!

タグ付けされた投稿をもっと見る

Accepted answers

All comments

PeteCrosier

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.

PaulCone

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
	},

PeteCrosier

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.

PaulCone

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

Anonymous User

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.

ANRGIS

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.

会話に参加する

サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。

クイックリンク

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.