Readaccess, they cannot see anything on the lower levels. For example, if a user lacks
Readaccess at the Realm-level, they cannot see any data in the Realm, even if they have
Readat the class or object-level. However, just because they have higher-level
Readaccess does not mean they can see everything on the lower level -- just that they can see anything at all. In this way, the app developer can decide for themselves what granularity they want for permissions in their data model.
everyonewhen they first connect.
__User:<syncIdentity>. The user is also automatically a member of this role.
administratorrole which has yourself as a member, and then reduce the privileges of the
everyonerole. Note that an
administratorrole is different than an
adminuser on the Realm Object Server.
SetPermissionsprivilege can never give other users higher privileges than they themselves have.
canReadis set at the Realm-level, it is possible to set
canReadto false at the Class-level, which will prevent the Role from seeing just this single class. However, if
canReadwas not set set the Realm-level, the value of
canReadat the Class-level will be ignored and the class will not be readable.
canCreateprivilege, but not
canUpdate,they are still able to modify newly-created objects inside the same transaction that object was created in.
canReadis enabled at the Class-level, it is possible to disable
canReadat the Object-level which will prevent the Role from seeing just this single object. However, if
canReadwas disabled at the Class-level, no matter the value of
canReadat the Object-level the object will not be readable.
canQuery/canReadpermission at the Class level).
Usercan be part of multiple roles with many different permissions, it is often useful to be able to determine exactly what the current user can do with an object (or class, or the Realm file).