Does "Apply Edits request" ignor layer definition query?

232
2
Jump to solution
06-09-2021 03:20 PM
EdgarRunnman
New Contributor II

I am able to edit and delete features which are otherwise not queryable due to layer definition query. Does that mean that "applyEdits" ignor layer definition rules defined by AGS feature service and has accsess to all features in featureclass?
I want editor to be able to edit/delete specifik features within feaature class but not entire content of feature class.

1 Solution

Accepted Solutions
jcarlson
MVP Regular Contributor

That would be very troubling if so. I've got a few "testing" layers I keep around for things like this, so here goes:

Parent Layer: 4 fields, objectID 250 is presentParent Layer: 4 fields, objectID 250 is present

 

View Layer: No objectID 250, only 2 fieldsView Layer: No objectID 250, only 2 fields

For testing, I'm going to use ObjectID 250.

 

Query the View

Attempted to query the layer simply specifying the objectID:

{"objectIdFieldName":"OBJECTID","uniqueIdField":{"name":"OBJECTID","isSystemMaintained":true},"globalIdFieldName":"","features":[]}

Second attempt, querying by field value, same response.

 

Edit the View

Attempted to update the feature, setting the "GRID_ID" attribute to "GOTCHA". Response:

{
"updateResults" : [
{
"objectId" : 250,
"uniqueId" : 250,
"globalId" : null,
"success" : true
}
]
}

So, that's alarming. But let's double check the parent layer.

jcarlson_2-1623289117638.png

Sure enough. Remember, that objectID wasn't present in the view layer from a query. And what about attributes that aren't in the view?

{
"updateResults" : [
{
"objectId" : 251,
"uniqueId" : 251,
"globalId" : null,
"success" : false,
"error" :
{
"code" : 1000,
"description" : "Incorrect syntax near the keyword 'WHERE'."
}
}
]
}

So it would appear that I can edit whole features that aren't present in the view, but not fields.

 

Delete the Feature

I think I know how this one ends, but let's test it for the sake of being thorough.

jcarlson_3-1623289276313.png

There's where it use to be.

 

Conclusion

I think the answer to your question is, unfortunately, "yes". An editable view layer can "touch" all features in the layer, even if they can't see them. Which honestly feels like a pretty glaring issue, and major kudoes to you for pointing this out, it's given me some things to consider.

Still, users can't edit fields that are hidden in the view layer. That may be cold comfort when all the features, fields and all, can simply be deleted, though. Not seeing the features, there'd be no way of knowing what you're deleting, though you could just do a blind sweep through objectIDs on a loop and nuke them all...

I would say that if deleting is not necessary for the view, you should absolutely disable it in the view layer settings to avoid this sort of "doomsday scenario", and you might consider other editing / editor tracking settings to prevent unintentional (or intentional) data loss.

You might be able to enable the settings where users can only edit "their" features, but then you'd need some way of "assigning" a feature to your users...

- Josh Carlson
Kendall County GIS

View solution in original post

2 Replies
jcarlson
MVP Regular Contributor

That would be very troubling if so. I've got a few "testing" layers I keep around for things like this, so here goes:

Parent Layer: 4 fields, objectID 250 is presentParent Layer: 4 fields, objectID 250 is present

 

View Layer: No objectID 250, only 2 fieldsView Layer: No objectID 250, only 2 fields

For testing, I'm going to use ObjectID 250.

 

Query the View

Attempted to query the layer simply specifying the objectID:

{"objectIdFieldName":"OBJECTID","uniqueIdField":{"name":"OBJECTID","isSystemMaintained":true},"globalIdFieldName":"","features":[]}

Second attempt, querying by field value, same response.

 

Edit the View

Attempted to update the feature, setting the "GRID_ID" attribute to "GOTCHA". Response:

{
"updateResults" : [
{
"objectId" : 250,
"uniqueId" : 250,
"globalId" : null,
"success" : true
}
]
}

So, that's alarming. But let's double check the parent layer.

jcarlson_2-1623289117638.png

Sure enough. Remember, that objectID wasn't present in the view layer from a query. And what about attributes that aren't in the view?

{
"updateResults" : [
{
"objectId" : 251,
"uniqueId" : 251,
"globalId" : null,
"success" : false,
"error" :
{
"code" : 1000,
"description" : "Incorrect syntax near the keyword 'WHERE'."
}
}
]
}

So it would appear that I can edit whole features that aren't present in the view, but not fields.

 

Delete the Feature

I think I know how this one ends, but let's test it for the sake of being thorough.

jcarlson_3-1623289276313.png

There's where it use to be.

 

Conclusion

I think the answer to your question is, unfortunately, "yes". An editable view layer can "touch" all features in the layer, even if they can't see them. Which honestly feels like a pretty glaring issue, and major kudoes to you for pointing this out, it's given me some things to consider.

Still, users can't edit fields that are hidden in the view layer. That may be cold comfort when all the features, fields and all, can simply be deleted, though. Not seeing the features, there'd be no way of knowing what you're deleting, though you could just do a blind sweep through objectIDs on a loop and nuke them all...

I would say that if deleting is not necessary for the view, you should absolutely disable it in the view layer settings to avoid this sort of "doomsday scenario", and you might consider other editing / editor tracking settings to prevent unintentional (or intentional) data loss.

You might be able to enable the settings where users can only edit "their" features, but then you'd need some way of "assigning" a feature to your users...

- Josh Carlson
Kendall County GIS

View solution in original post

EdgarRunnman
New Contributor II

Thank you, Josh, for confirming this issue with additional tests.

Ownership-based access would be a solution in my case if i could make ownership refer to "last edited by" which unfortunately is not an option, but thanks for suggesting it.

0 Kudos