Hi Gal, thank you for taking the time to answer in such detail!
I get your points and can see now that I was approaching the problem the wrong way. I have to think about business logic much more.
In order to enable users to leave a group "on free will", using mongoDBs $pull should do the trick.
Thanks again for pointing me in the right direction!
almost 10 years ago
Improving group support (in particular adding a Console interface for adding/removing/modifying groups) is definitely on our roadmap.
As for your other questions/points:
First, there is a distinction between being a member of a group and having write access to the group entity. It is true that if a user is added to both the group and the group entity’s _acl, that user has to be removed from both when “leaving” the group, but as these are two very different use cases (group admin vs. group member) this is expected.
The intention of the groups feature is to allow access control by an administrator user (or a number of these), rather than allowing each member of the group to edit the user list. To see why, consider that if any member was able to add anyone else to the _acl record of the group entity, giving them write access to the group itself, then if this new user was malicious, he could remove all members from the group or even delete it entirely. The recommended model is that the creator of the group is the primary administrator, and he can selectively add trusted users to the _acl record of the group, thus making them group administrators as well. It is true that if an admin was to stop using your app without first giving someone else access to modify the group, the group would be “frozen”, but then again that first user could also decide to just delete the group at any point, so there’s always an element of trust that the user will do the “right thing”. Even if this happens, the other group members can always email you, the app creator, and you can “fix” the group using your master secret.
I’m not sure what you meant by “fetching all these to edit the acl seems quite inefficient”— the group itself, and its list of members, is only stored once in a special collection. Each entity that provides access to the group simply adds that group’s ID to the entity’s _acl record. The group itself is never duplicated, and editing it does not require fetching any entities that provide access to that group. The only time you would need to modify the individual entities is if you would like to add or remove access to this group.
Finally, you can add members to a group without first retrieving the entire group by using business logic. You can create a custom endpoint that accepts a group ID and a user ID, and then uses the MongoDB $push operator (http://docs.mongodb.org/manual/reference/operator/update/push/) to add the user to the group’s users.list array. The endpoint would look something like this:
I have read the article and got the creation of groups working via a simple ajax request.
But I find the handling of the groups still quite complicated.
What's a bit of a bummer is that the group can only be maintained by the creator and setting permissions of the group to itself doesn't seem to work either.
So each group member has to get separate write permission to be able to leave the group without "permission" of the creator.
Also, is there a way to add members to the group without fetching the whole group, pushing a user reference in users.list and then saving it?
So for now my workflow is like this:
- user one creates group and adds himself to the acl
- second user makes entrance request
- user one
- fetches the group
- adds second user to users.list and grants him rw access
- saves group.
The second user (who has write access now) can leave the group by removing himself from users.list. But he then still has rw access!
What happens if user one leaves the group? Then there's no one left to manage permissions?
I will probably go by duplicating the whole group and any entities bound to it, using the first user who accepts being "group admin". This would then set him as the creator of the new group and he can manage new entrance requests.
All this seems to work somehow for now, but I don't know what happens when there are a couple of thousand users in one group and the group has access to thousands of entities in different collections. Fetching all these to edit the acl seems quite inefficient.
I might be missing something essential but I can't see how it is possible to create a proper community app using Kinvey as backend only.
For DataStorage usage only I'm very happy with how fast one can get things done. Just the user management is missing some core features in my opinion.
To be able to view the groups in the dashboard would be nice, too! I have no idea how many unused groups I set up during testing and as the test users don't exist anymore, the only way to retrieve and delete them all is to write some frontend and use the master key.
Any pointers in the right direction on how to handle groups of users and any other community-like functions would be great"!
almost 10 years ago
Hi Johannes- we have an article that deals with Groups & Permissions: http://support.kinvey.com/hc/en-us/articles/200713218-Groups-Permissions
almost 10 years ago
Just realized something more or less embarrassing:
User groups are something like users and one make an entity a user group!
I will try to write a custom ajax, or http request with respective headers from the REST api.