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.
Solved! Go to Solution.
That would be very troubling if so. I've got a few "testing" layers I keep around for things like this, so here goes:
For testing, I'm going to use ObjectID 250.
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.
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.
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.
I think I know how this one ends, but let's test it for the sake of being thorough.
There's where it use to be.
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...
That would be very troubling if so. I've got a few "testing" layers I keep around for things like this, so here goes:
For testing, I'm going to use ObjectID 250.
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.
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.
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.
I think I know how this one ends, but let's test it for the sake of being thorough.
There's where it use to be.
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...
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.