Improve permissions

[JanCizmar]

• [ ] Let's add a granular scopes which can be specifically added to each member of project, this will be the same scopes as the Scopes for the API key, but let's join
  • [ ] New permission scopes: translations.view, translations.edit, translation.review, keys.edit, screenshots.view, screenshots.edit, activity.view, import, languages.edit, project.info.edit, project.members.edit, oraganization.info.edit, organization.members.edit, import, export
  • [ ] We should also describe each type in the UI and disable illogical combinations like "screenshots.edit" without "screenshot.view", so when user selects "screenshot.edit", we should automatically select "screenshot.view" and disable it so user cannot unselect it.
• [ ] Enable language specificaction for "translations.view","translations.edit" and "translation.review"
• [ ] Keep the current permission types like "VIEW", "TRANSLATE", "EDIT", "MANAGE" and the new types mentioned further as a templates for the granular selection.
• [ ] Enable zero permissions as base organization permission, so user can be in organization, but see no projects without explicitly set permissions
• [ ] Add view languages for VIEW and TRANSLATE permission types
• [ ] Add REVIEW permission type, which enables user to only REVIEW strings, but not modify it
• [ ] Add REVIEW_AND_TRANSLATE permission type which would enable users do to both

---

I think the current approach to permissions is not optimal. We should probably to remove Permission types on backend and provide granular scopes to satisfy current roles. Then we can use sets of these scopes to define 'Role' templates. But enable user to customize the roles per user.

[jdimeo]

I really like this game plan. Thank you Jan! Related to #1324

[vascYT]

I almost wanted to open an issue for this, because I do not want my translators to approve translations. Thanks!

[JanCizmar]

I have updated this specification. @ZuzanaOdstrcilova, can you please prepare a UI design proposal?

[ZuzanaOdstrcilova]

Here is the design of Permissions. We are discussing the final visual optimizations. https://www.figma.com/file/UCvcqHZe6owmJV5QolBMoj/tolgee-tasks?node-id=1242%3A1444&t=nIZJBNVUQutAMawU-0

[jdimeo]

This looks great. Is it in scope to provide a Billing user or Organization admin that can admin account settings, invite users, things like that but NOT actually edit translation, keys, etc? We have a use case for that but it's not a big deal- our Billing admin just doesn't use the tool itself (even though she CAN)

[JanCizmar]

Good points john. We can add a billing admin role as Oragnization role, that makes sense. I was thinking about separate permission scope for member management, but it felt like nonsense, since this user would be able to generate invitation for themself and have the other permission anyway, right?

[jdimeo]

Right! when I saw the admin at the top of the permissions tree I had the same thought ("why is it covering all the other permissions? Oh right, because they would have all the other permissions! :-)")