This may be a wrong idea (still playing) but can we have collection permissions NONE (as a new 5th top level permission) i.e. no read, no write.



Then we can just use the entity level permissions and not have to worry about what the collection level permissions are (e.g. if mainly using groups as the permission basis on a specific collection)

Hmm, but you can't set collection-level permissions for a group (this is on our roadmap btw), so a user can never create a document in a None collection. This could only make sense in the case where all entities are pre-created by a master user - is that what your use case is?



If you describe in more detail the permissions model in your app, I can help recommend the best way to implement it.

Hi Ivan

What I really meant was no permission at collection level, then some kind of permissions at group level (or entity level)



What I am trying to do is have two collections

- LIVE data (Will be read only collection)

- EDIT mode data (will also include all the edit audit trail fields that due to how all fields get sent in the API, should only be transferred on the data in edit mode)



ON THE EDIT MODE COLLECTION

1000 users who can read nothing (i.e. the group can't be read for everyone). These are the regular users

I have say 10 editors who can create content (read all, write just their own)

Master editors - say 3 of them - who can read all, write all (not just their own).....



Now I think this collection will HAVE to be full access permission, and then, onprefetch, onpresave, check whether I should give access or not. WOULD HAVE PREFERRED NO PERMISSION and be selectively GIVING permission (hence the original request)



(And I will have to do the groups myself at the moment, as although seems to be half documented in REST API, I keep hearing mentions of this coming in the future, so will wait until that time)



Ummm - still thinking this through, if I am honest.



(My other challenge is that with some mobile based coding, the security assumption is that anyone can find the app credentials..... so all the data security has to be on the Kinvey end - or on collection hooks - because any other client code has to be assumed to be insecure)

I would recommend the following:

1) create a ContentCreators group

2) create a MasterEditors group

3) set EditCollection to have 'private' permissions. This accomplishes your 'content creators' requirement.

4) add Business Logic for EditCollection for onPreFetch, onPreSave and onPreDelete. The code checks whether the incoming user is a member of ContentCreators or MasterEditors and denies the request if that's not the case. This accomplishes the requirement that regular users can't read EditCollection, and is sort of in line with your no-access thinking. By default nobody has access, and access is given by adding the user to the two user above

5) add Business Logic for EditCollection for onPreSave. The code automatically adds write access for new entities to the MasterEditors group. This accomplishes your read-all, write-all requirement.



We have a feature in the roadmap, which will allow groups to get collection-level permissions. This directly gives you #5, but the feature won't be ready for a few months.



I understand your suggestion about 'None' permissions now - thank you. We'll add it to the roadmap, but in the meantime, I hope the above is workable for you.



>with some mobile based coding, the security assumption is that anyone can find the app credentials..... so all the data security has to be on the Kinvey end

But to be clear, this is true whether you are using Kinvey or a DIY backend.

Thank you Ivan. I will have a play



Yes - no permissions then coding a collection hook to give permission is preferable to having full permission and coding to restrict permission, as I think you see now ;) [In case we make a mistake in the code]



Re the comment about code security - yeap - just was pointing that out to reinforce (as we all know) that the security has to be on the data permissions in some way - rather than in our own business logic code layer. (Thats why it was in brackets!)

Hi Ivan

Could you add some insight into how to create groups?

http://devcenter.kinvey.com/rest/guides/users#usergroups



More specifically, I found the REST API has most info (I think), but still, you don't define what LIST or GROUPS does within the context of creating a group.



If I should just manage groups myself right now (in my own collection) do say :) I know there are tweaks coming to your core group functionality, so if I should just wait, thats fine.

Sure - may I just ask you to post that as a separate question in REST API?

Thank you Ivan



Done



http://support.kinvey.com/hc/communities/public/questions/201260356-Create-a-group-document-what-list-and-groups-means