Granular Permissions
Noah Callen
Most relational database applications I have worked with have the ability to set read/write permissions on a more granular level. I like the concept of having permissions wrapped up into 'types' but there are use cases where those types don't work. Rather than adding more permission 'types' to cover every scenario people can come up with, it would be great to introduce something like 'advanced permissions' where you can get to more granular levels of permissions. An example, while not totally practical, would be the ability to set a team to have write permissions where they can create records on a table, but then have no read permissions.
Jon Darbyshire
Hello Noah Callen! I have a few more questions for you:
- Can you provide specific examples of scenarios where the current permission 'types' do not meet your needs?
- What would be the ideal level of granularity for permissions in your use case?
- Are there any specific functionalities or operations that you would like to restrict or allow with these 'advanced permissions'?
Noah Callen
Jon Darbyshire
- Some basic examples:
a) A user can create records, but are not able to read any records (submit only)
b) A user has access to one table within a solution to view all records but on another table the same user has no access
2&3. I've attached an idea for how this could look. With this though, there would have to be some 'behind the scenes' logic. For example, if a user is given no read permissions, then inherently the user wouldn't be able to comment or edit existing records.