Re: [Codematch-develop] DataTracker and CodeMatch access control

Robert Sparks <> Wed, 26 August 2015 14:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 18EB71B2D65 for <>; Wed, 26 Aug 2015 07:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z3MxR2BNI4UP for <>; Wed, 26 Aug 2015 07:54:39 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A7F81B2CE4 for <>; Wed, 26 Aug 2015 07:54:39 -0700 (PDT)
Received: from unnumerable.local ( []) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id t7QEsb09031830 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 26 Aug 2015 09:54:38 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be unnumerable.local
Message-ID: <>
Date: Wed, 26 Aug 2015 09:54:32 -0500
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Lisandro Zambenedetti Granville <>, codematch-develop <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: Henrik Levkowetz <>
Subject: Re: [Codematch-develop] DataTracker and CodeMatch access control
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"Discussion forum for the planning, coordination, and development of CodeMatch\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Aug 2015 14:54:42 -0000

Hi Lisandro -

Before we go too deep into this, I want to call out a way we expected 
Role to be used and make sure you've considered it.

You are not necessarily restricted to the Role names that are defined 
now (like "chair"). We could add Role names like
"codematcher" or "codematch_approver" or whatever other name matches the 
semantic for the permission you're wanting to manage.

You could then have things like Lisandro Granville is codematch_approver 
in nmrg.

Does that address the need? If not, could you walk me though a scenario 
where it makes it harder than it should?


On 8/25/15 1:52 PM, Lisandro Zambenedetti Granville wrote:
> Dear All
> Last week we had our traditional CodeMatch meeting. One of the questions discussed in the meeting was about role-based access control (RBAC) in CodeMatch. We would like to propose adding an extra table in the current data model to support RBAC. However, because we want to be as aligned with DataTracker style as possible, we are sending this message to start a discussion, specially with Henrik and Robert.
> 1) Style of checking users’ permission
> We observed the DataTracker code and it seems that in general, permission checking is hardcoded, in the following style (using “Area Director”, “IAB Chair”, and “Secretariat" as examples):
> if has_role(request.user, ["Area Director", "IAB Chair", "Secretariat"]):
> 	// do something that only area diretor, IAB chair, and secretariat could do, like “Create CodeRequest"
> In CodeMatch, we would like to check permissions in the following way:
> if has_right(request.user, “Create CodeRequest”):
> 	// do something that only authorized people should be able to do, like “Create CodeRequest”
> The “has_right” function would check the database to retrieve the users’ roles and, for each role, check if it has permission to “Create CodeRequest”. In this way, permissions are associated to roles, and roles associated to users.
> Because permissions and roles in CodeMatch are being defined together with the implementation of the system prototype, the use of “has_right” would allow us to assign permissions to roles just changing the database, instead of changing the CodeMatch code if we use “has_role” instead.
> 2) Database
> Today, permissions are listed in table auth_permission. Roles are listed in table group_role. We would need a intermediate table linking permissions to roles, i.e., a table linking author_permissions and group_role. That would allow us to say, for example, that a mentor (inside group_role) can add documents to a codeRequest (i.e., a permission inside auth_permission). Adding this intermediate table (let’s call it role_permission for the moment) would not affect today’s database, although it would expand today’s data model.
> Do you think doing that is ok?
> Best regards,
> Lisandro, Wanderson, Matheus