Re: [yaco-liaison-tool] From Field in Liaison Tool

Glen <glen@amsl.com> Mon, 31 January 2011 18:00 UTC

Return-Path: <glen@amsl.com>
X-Original-To: yaco-liaison-tool@core3.amsl.com
Delivered-To: yaco-liaison-tool@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257B53A6977 for <yaco-liaison-tool@core3.amsl.com>; Mon, 31 Jan 2011 10:00:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.285
X-Spam-Level:
X-Spam-Status: No, score=-102.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMyyegjsxGMj for <yaco-liaison-tool@core3.amsl.com>; Mon, 31 Jan 2011 10:00:21 -0800 (PST)
Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by core3.amsl.com (Postfix) with ESMTP id 47FA63A6844 for <yaco-liaison-tool@ietf.org>; Mon, 31 Jan 2011 10:00:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 610C1E08CE; Mon, 31 Jan 2011 10:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ8-H+XDcKwN; Mon, 31 Jan 2011 10:03:36 -0800 (PST)
Received: from [192.168.1.111] (173-8-133-91-SFBA.hfc.comcastbusiness.net [173.8.133.91]) by c1a.amsl.com (Postfix) with ESMTPSA id 2D181E0760; Mon, 31 Jan 2011 10:03:36 -0800 (PST)
Message-ID: <4D46F977.2030201@amsl.com>
Date: Mon, 31 Jan 2011 10:03:35 -0800
From: Glen <glen@amsl.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: yaco-liaison-tool@ietf.org
References: <D0DD124C-E261-4702-99BB-CC67DA173BBB@amsl.com> <4D46B432.4040600@yaco.es> <4D46E427.4060506@amsl.com> <4D46F14D.6030904@yaco.es>
In-Reply-To: <4D46F14D.6030904@yaco.es>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [yaco-liaison-tool] From Field in Liaison Tool
X-BeenThere: yaco-liaison-tool@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of the Yaco / Liaison Statement Management Tool Project details <yaco-liaison-tool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yaco-liaison-tool>, <mailto:yaco-liaison-tool-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yaco-liaison-tool>
List-Post: <mailto:yaco-liaison-tool@ietf.org>
List-Help: <mailto:yaco-liaison-tool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yaco-liaison-tool>, <mailto:yaco-liaison-tool-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Jan 2011 18:00:22 -0000

Hi Emilio -

On 1/31/2011 9:28 AM, "Emilio A. Sánchez López" wrote:
> I'll understand that secretariat staff has to be able to perform any
> action on the system. However, the fact that they can impersonate any
> user does not seem a good idea. In that case you will not be able to
> know if the user X made some change of was a staff user impersonating X.
> But this is only my opinion :)

Unfortunately, that turns out not to be the case.  We have many 
situations in which IETF leaders expect us to be able to do things "on 
their behalf" - including cast and/or clear ballot positions, post 
comments, etc.

> I see in other parts of the idtracker that the secretariat staff can
> access some features but always as their user. For example, they can add
> comments to a draft, but they can not add a comment as if they were
> another person. Henrik knows the tool better than myself so correct me
> if I'm wrong.

Where such situations exist, that is a deficiency that should be 
corrected - and where those situations exist, I generally have to go in 
to the database by hand to "fix" the record(s) in question.  And those 
deficiencies in no way change the fact that IETF leaders expect us to be 
able to do those things, whether right or wrong, alas.

> I think that are mainly two options to address this. One, as you said,
> is to make sure that this requirement is spelled out and then each new
> tool developed will need to allow a user from secretariat act as any
> other user.

Agreed.  The secretariat needs to be more involved in the review of all 
the IETF contracts that go out; alas, such is outside of my purview, but 
I hope those in command will consider this going forward.

> And two, modify the auth system so any secretariat user will be able to
> "jump" from one user to another and perform actions as this user
> transparently to the system. This has the advantage that old code will
> work properly and new code don't need to implement any special functions
> to allow that change for the secretariat members. The disadvantage, of
> course, is that the system will log actions as the "fake" member instead
> of the secretariat user.

That sounds a bit overwhelming from a usage standpoint, but I will defer 
to others on that.

> Leaving aside this second option, in the case of the liaison tool I see
> some ways of solving the issue:
> * Allow to edit the name of the submitter when the user is in the
> secretariat group placing a text input.
> * Allow to select the submitter when the user is in the secretariat
> group placing a select box.
> * Inserting a previous view in which the secretariat member selects
> which user he/she wants to impersonate.

Thank you for taking the time to reply.  It looks like Alexa also 
replied to you (I didn't see that when I sent my reply) so it sounds 
like she and you have this well in hand.

Best,
Glen