Permissions on Arrays

When granting permissions on a field, if the field contains array data, you must grant the permission on the array field. This grants access not only to array data in the field, but also nested documents and scalar data. It is also possible to set permissions on subfields within nested documents that are stored in an array.

Note: This topic describes the behavior of permissions in HPE Ezmeral Data Fabric Database version 6.1 and later, regardless of the data-fabric version you used to grant the permissions.

Granting Permissions on Array Elements

Suppose you have the following documents where person is:

An array of nested documents in document id001
A single nested document in document id002
A scalar value in document id003

{
    "_id" : "id001",
    "person" : [
        {"name" : {"last" : "Smith", "first" : "John"}},
        {"name" : {"last" : "Subramanium", "first" : "Ananya"}}
    ]
}
{
    "_id" : "id002",
    "person" : {"name" : {"last" : "Doe", "first" : "Jane"}}
}
{
    "_id" : "id003",
    "person" : "Unknown"
}

If you grant a user read permission on the array person[], that user can read every field in every nested document within the array in document id001. The permission also enables the user to read the person field in documents id002 and id003.

If you receive an error when trying to grant permission on person[] because you previously granted permission on person, then you (or an administrator with the appropriate permissions) must first remove the existing permission on person. If you expect the schema of the person field to evolve to include non-array and array data, then you should grant the permission on person[] rather than person, to avoid having to remove the conflicting person permission.

You cannot grant permissions on individual elements in an array; for example: person[1]. Granting permission on an array enables access to the entire array.

Granting Permissions on Nested Document Fields in an Array

If you want to restrict read access to only specific fields in person, whether the field is an array of nested documents or a single nested document, perform the following steps:

Deny the user read permission on the array person[].
Grant the user traverse permission on the array person[].
Grant the user read permission on the specific fields.

For example, to grant the user read permission on only the first names in the nested documents, for the third step, grant read permission on person[].name.first. The permission enables the user to read the field in all nested documents in documents id001 and id002.

If permissions already exist on person.name.first, then all attempts to define permissions on person[].name.first fails. You (or an administrator with the appropriate permissions) must first remove the existing permission on person.name.first. Similar to the scenario described in the previous section, if you expect the schema of the person field to evolve to include individual nested documents as well as arrays of nested documents, then you should grant the permission on person[].name.first to avoid having to remove the conflicting permission.

If you already have permissions on person[].name.first, then attempting to define permissions on person.name.first fails. There is no need to add this permission.