-
Notifications
You must be signed in to change notification settings - Fork 88
Group permission behaviour #184
Comments
Yes, Adding version references to groups doesn't make a lot of sense. The whole point is that the group permissions are applied to all posts that reference the group when the group is updated. Since a version can never be updated, referencing a version wouldn't have any benefit over specifying the entities in Referencing groups from another entity won't work well, because the server isn't guaranteed that it will get updates about the group. This type of synchronization could be done trivially with an application. |
It's trivial for an app to hardcode permissions by adding all members of a group to a post's permissions when that behavior would be desirable. Otherwise, dynamic permissions are the norm |
Not so trivial if the group has a lot of members and you want this behaviour fore each one of your posts. |
In that case the app would just update a group post instead of the individual posts. |
I don't understand. |
Let's do an example. There is a chat service for a company. Every employee is in the group. Conversation in the chat is confidential. Someone (Bob) got fired and so he's removed from the group. Remaining employees talk about the firing. After an amount of time Bob is hired back, so he's added back to the group. With the current model he's able to get the messages about him and this is unwanted. Another case. The company is working on a project. To accomplish to a particular task, an external group of professionals is added to the group. They must not have to look at all the previous iterations of the project, they can only access the current status and the future one until they are in the group. If you have huge groups (Foxconn's employees, universities' students) converting the group to list of entities for each post is a huge waste. My proposal is to simply honor the version property when specified. The server has nothing special to do while retrieving the group post than it has to do for any other post. |
@poweruser82 The In very large institutional environments, expect institutions to be running their own Tent servers or using an enterprise SaaS provider who will doubtless implement optimizations for very large groups when used internally. This is a server implementation detail for an edge use case. An alternative to manually listing all entities from a group would be to create a new group with the specific members you want (and repeat this process in the future). There's nothing stopping apps from creating and using groups as though they were static, although other apps can still alter the groups later (editing/creating groups will probably be a specific permissions scope when authing apps) |
Can you provide details about how groups are going to work? There's no spec on tent.io and it looks like previous specs differ a lot. |
@poweruser82 The basic concept is that there will be a "group" post that contains the name of the group, and one or more "group member" posts containing a single entity that mention/ref the group post. |
@titanous What's the reason of not just mention/ref entities in the group post? |
@poweruser82 Mentions/refs are limited to 100 elements and the content is limited to 1MB. Using a post per entity allows for large groups because we can utilize the built-in feed pagination system. |
(It also solves concurrency and change tracking) |
So to get members of group "Static" groups could have the same type of standard group with a |
Groups will be dynamic. There are a variety of ways apps can achieve the same results as a "static" group without changing the standard group behavior. |
Considering #176 and #182 suppose this use case:
g
with 2 people (e1
,e2
).p
with group permission set tog
.g
addinge3
.g
removinge2
.Can
e3
after time 3 see postp
?Can
e2
after time 4 see postp
?I suggest changing
permission.groups
to a list of objectIf version is specified, the permission applied is just the one specified.
If no version is given, the last version applies.
The entity attribute can be omitted if is the same of the author of the post. Otherwise it could be useful to use public group permission managed by someone else.
If no entity and version is specified for an entry in the list, that entry could be a string with the post id instead of an object.
The text was updated successfully, but these errors were encountered: