3 ms·
The system described in the article is pretty good. But why restrict tags to have only users and not let include groups ( all users of a group)? Also the issue
by polote 5y ago
The system described in the article is pretty good. But why restrict tags to have only users and not let include groups ( all users of a group)? Also the issue with tags is that if you don't tied them to another structuring object there are too much of them and it starts being difficult to choose and manage them.
I actually had to write a permission system for a collaborative b2b tool, and the answer for tags was to tied them to a folder.
When you add nested folders, things become easier to maintain. You have rights on folders or files and, and you have tags on folders which can grant rights too
- chipsa 5y ago> But why restrict tags to have only users and not let include groups ? Tags are associated with a role. Someone in the "Engineering" role can apply a "source-code" tag to a file. There's no such thing as a group, but rather everyone fills a role.
- polote 5y agoSorry I meant role instead of group. Ah so tags are tied to a role, all good then. But you could still give permissions for a role through a tag. Like Someone in "Engineering" role can apply a "source-code" tag to a file, which will grant permission to person A, person B, person C but also to people of Role 1 and Role 2
- chipsa 5y agoSomeone in the "engineering" role can apply the "source-code" tag to a file, which will grant people in the "engineering" role read-write permissions, and the "dev-ops" role read permissions. Users don't have tags associated with them, so they don't get permissions from having a tag assigned. They can't because the policy doesn't allow you to stick a bare user into the (role,tag,permission) tuple. So when you're auditing permissions, you can check to see if the tags have the appropriate permissions, the roles have appropriate tags, and users have appropriate roles.