Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Permissions #915

Open
Tracked by #842
jsmorabito opened this issue Apr 7, 2021 · 4 comments
Open
Tracked by #842

Permissions #915

jsmorabito opened this issue Apr 7, 2021 · 4 comments

Comments

@jsmorabito
Copy link
Contributor

jsmorabito commented Apr 7, 2021

for #843

to be managed in #881

references

@jsmorabito jsmorabito mentioned this issue Apr 7, 2021
3 tasks
@shanberg
Copy link
Collaborator

shanberg commented Apr 8, 2021

Are permissions set per invitee per database, or per invitee per block, or per invitee per workspace, or something else?

@tangjeff0
Copy link
Collaborator

tangjeff0 commented Apr 8, 2021

That is a loaded question!

First thought is 1 workspace = 1 database

Per Database: pretty straightforward. Everyone has same permissions, except for perhaps admin who can add or remove users. No private spaces though haha (Notion has this).

Block- and Page-level: the 1st order seems straight forward. Search and auto-complete would have to ignore private blocks/pages. 2nd order: What about children? What about parents?

@tangjeff0 tangjeff0 mentioned this issue Apr 12, 2021
6 tasks
@latvia234
Copy link

Will there be an option that can give permissions to certain roles?

For example I have a team with around 10 video editors, and there is another team with around 8 writers, there is another team with 5 voice overs.

It would be easier to add people to a role, that already does have certain permissions. And maybe add some custom permissions for a team member if needed later on.

@makoConstruct
Copy link

I thought a lot this week about the near future of systems like Athens or Roam as wiki/forum/realtime chats/social networks, and permissioning was a big part of things, it has to be gotten right. You can read the neschat design overview, I'd recommend all of these ideas to Athens, but I'll repeat the permissioning model here in athenian terms:

The neschat model: Every block (including a sort of workspace root entities) should have the following permission groups: Read, Edit, Reply (the ability to add additional blocks under, or inline), Prune (the ability to remove or reorder replies), and Own (the ability to change who's in the permission groups).

The permissions take a combination of users and usergroups. They can also be set to inherit the permissions of the parent block. (if you ever support having multiple parents (you wont though, right? That'd just be block references), one of them has to be designated as the primary parent).

I think this covers all of the diverse use cases I can see athens eventually supporting (except for some other stuff that needs Web of Trust Moderation, but I will hold off on talking about that until I've developed a way to make it scalable.)


It occurs to me that when someone creates a new block, all of these would have to automatically default to something. This could be somewhat complicated.

I think in the current focal use case, when alice creates a block, having everything default to inherit + alice, would work. (In my speculated forum or chat modes, though, I think, it would have to be different. When alice creates a new block, Own and Edit would default to just alice.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants