Replace GroupACL with something more reasonable [$50 awarded]

[nijel]

While the GroupACL is certainly better than having just group based access Django provides, it turns out to be pretty hard to configure properly due to permission filtering and layering of GroupACLs. Also the logic to evaluate this is unnecessarily complex.

Summary of this is available in the wiki: https://github.com/WeblateOrg/weblate/wiki/Access-control-design

Problems with current GroupACL:

• Unclear layering of them, it's pretty much coded here, but ordering within same group is pretty much random:

weblate/weblate/permissions/helpers.py

Lines 61 to 71 in 90c2d8e

	# more specific rules are more important:
	# subproject > project > language
	acls.sort(reverse=True, key=lambda a: (
	a.subproject is not None,
	a.project is not None,
	a.language is not None))
	for acl in acls:
	groupacls.append((
	acl.groups.all() & user.groups.all(),
	acl.permissions.values_list('id', flat=True)
	))

• The idea of permissions filtering is usually to complex to setup
• Exposing all permissions in the admin interface adds unnecessary complexity as most of the automatically generated Django permissions are not used
• The can_access permission can not be used with per language ACL as it's only applied to the translation (leading to confusing situations that user can not access /project/foo/ but can access /project/foo/bar/cs/)
• The project and language ACL does not seem to work (this might be just bug in the current implementation)

We probably should focus on creating something simple which will cover most of the use cases and then potentially extend it.

What we need from the access control system:

• Define access to individual projects, translations or languages (not sure about components)
• Granular permissions (access project, translate, suggest, review, ...)
• Interface to edit per project groups directly in Weblate
• Automatic adding of users to groups

What can be probably omitted from current feature:

• Restrict access by additional rules (currently GroupACL can be used to revoke permissions)
• Defining permissions for individual users, having groups is good enough in most cases

Following use cases should work (some of them might be duplicate, but that's real world situations I've met so far):

• Grant every user translation permission to a project
• Grant project visibility to group only
• Grant group review permission to a language in all projects
• Grant group translation permission to a language in all projects
• Grant group translation permission to a language in single project
• Grant admin access to a project to a group

[nijel]

List of related issues:

• Enabling ACL for a project blocks the acces of ACL group with permissions for it #1687 - Per language access control
• Allow access to billing information to more people #1640 - Billing access control

This will probably end up in completely replacing Django User/Group models, so it should address limits we're hitting there as well like maximal length of full name.

[nijel]

Possible implementation:

Models

User

• Username
• Full name
• E-mail
• Password
• Superuser flag (used also as staff flag)
• Active flag (used to delete)
• Timestamps (date joined, last login)
• Groups (many to many)

Group

• Name
• Projects (many to many, defines projects this group has access to)
• Language (many to many, defines languages this group has access to)
• Permissions (many to many)
• Flags [manual/automatic, all_projects/selected, all_languages/selected] (to allow automation for language/project selection and to distinguish Weblate managed groups from user managed ones)

Permission

• ID
• Verbose name (translatable)

Permission check

Access project

• To check permission: user.groups.filter(project=x).exists()
• To list allowed projects: Project.objects.filter(group__user=x)

Access translation

• To check permission: user.groups.filter(project=x.component.project, language=x.language).exists()
• To list allowed translations: component.translation_set.filter(language__group__in=user.groups.filter(project=x.component.project)

Individual permissions

• On translation level user.groups.filter(project=x.component.project, language=x.language, permission=PERM).exists()
• On project level user.groups.filter(project=x, permission=PERM).exists()

[lawmaestro]

Agreed. The way the permissions currently work feels a bit overly complicated for the (relatively) simple use cases outlined. A simplified replacement of this with a basic interface on it would much better suit our needs (imo)

[michaelplatt]

After meeting Michal last week I have to admit that the GroupACL method still leaves me confused.

My feeling is that the whole thing can be simplified a great deal as follows:

• Use Groups to manage the list of specific rights applicable for that set of users.
• As part of Project/Component admin, specify which groups can access it.
• Specify Languages at the group level to enable access to those languages for the projects they can access.

If necessary, individual users can be given additional rights, languages, and project/component access beyond that provided by the group(s) they belong to.

In general, I believe access rights should always be additive and a user should have the aggregate rights of their specific settings plus any groups they belong to.

[stanislav-brabec]

Group ACL is a work-around of the limitations of Django Groups. Django groups assign permissions globally, for all projects. It cannot assign permission for a particular language, project, component or list. Group ACL excludes non-members of group from work on a project.

Ideal new permission system should integrate:

• Good granularity: per project, per component, per language, per list
• Positive permissions: Each user in group Czech Reviewers can review Czech strings.
• Negative permissions: Don't apply the above for Foo. Nobody else than Foo Translation Team can access.
• Intersection: User in groups Czech Reviewers and Foo Translation Team can review Foo/Czech.
• Priorities: Each user in group Foo Wizards is allowed to do everything in the Foo/Czech even without membership in Czech Reviewers group.
• Transitivity: User in group Foo Admins can dedicate selected permissions to other users.

Negative permissions can be turned into a positive permissions: The Project, Component, List requires membership in one of these Groups.

Permissions for groups of projects could be integrated with component lists, so it could be easily kept in sync. It could be also integrated with system-wide glossaries (glossaries per list, #1158).

[nijel]

• Good granularity: I'm not so sure about the per component permissions
• Positive permissions: In above proposal having group Czech Reviewers with rewiew permission, Czech language and all projects would do that
• Negative permissions: just remove Foo project from all other groups
• Intersection: That would need separate group Foo Czech Reviewers
• Priorities: IMHO this again adds too much complexity
• Transitivity: Admin permission will be there

[stanislav-brabec]

Assigning projects/components/lists to groups sounds like a good idea.

Per component permissions use case

• master branch: community version, open for anybody
• maintained branch: commercially supported version, open for contracted translators only

just remove Foo project from all other groups
Imagine that you have 50 language groups for community reviewers, and you want to exclude all those reviewers from an access to a certain project/component without making the project private. It would require editing of 50 groups. Group ACL can do it in a single line.

That would need separate group Foo Czech Reviewers
But more probably that would require 50 separate groups Foo * Reviewers, and regular sync of user list between Czech Reviewers and Foo Czech Reviewers. Group ACL can do it in a single line.

IMHO this again adds too much complexity
I can imagine an ordered list of rules that are tested

[nijel]

Group ACL can do it in a single line.

Yes, but at costs that you can not do many other things which are needed way more. No Group ACL is not a way to go (I think you've learned that yourself as well).

I can imagine an ordered list of rules that are tested

Certainly it can be tested, that's not a problem. Problem is that you can not test all possible combinations (what can be clearly seen at current Group ACL code - it's quite well tested, but it's not that hard to come up with configuration that will just block any access). Also any complexity you add makes it harder to setup by users and that is important as well.

[davidnorthetal]

I'm very much for restricting groups to individual components within a project.

The idea would be to have variation components of a shared global component (think forks), then restrict users to these forks, and within the same group they would only see their component and the shared component between them and can take suggestions from the shared component.

[ieugen]

Hi,

Is using groups the right thing? Having permissions is great. In other systems, they are grouped in Roles. Does django support that?

Whenever I have to create new group for language, I have to setup all permissions again and again. Managing this is very error prone.

Having roles as a way to group permissions is a nice thing.

Wdyt?

[nijel]

The Django permission system does not work well for us for several reasons. The attempt to adapt it to our needs with Group ACL didn't seem to go well. So in the end I'm convinced we need custom permission system that will fit our needs. I've looked at several existing ACLs for Django and I didn't find anybody what would fit.

Having roles might be useful, however I was rather considering simplification of permissions, so that setting up them would not be that hard. The question is whether existing privileges really can be reasonably reduced...