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

"Emilio A. Sánchez López" <> Mon, 31 January 2011 17:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FE9A3A699E for <>; Mon, 31 Jan 2011 09:25:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.817
X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J3casTENmTwG for <>; Mon, 31 Jan 2011 09:25:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8FD0C3A67F0 for <>; Mon, 31 Jan 2011 09:25:36 -0800 (PST)
Received: by wyf23 with SMTP id 23so5968087wyf.31 for <>; Mon, 31 Jan 2011 09:28:50 -0800 (PST)
Received: by with SMTP id v12mr6398550wbw.177.1296494930381; Mon, 31 Jan 2011 09:28:50 -0800 (PST)
Received: from [] ([]) by with ESMTPS id t5sm10899567wes.33.2011. (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 31 Jan 2011 09:28:49 -0800 (PST)
Message-ID: <>
Date: Mon, 31 Jan 2011 18:28:45 +0100
From: =?windows-1252?Q?=22Emilio_A=2E_S=E1nchez_L=F3pez=22?= <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [yaco-liaison-tool] From Field in Liaison Tool
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of the Yaco / Liaison Statement Management Tool Project details <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Jan 2011 17:25:38 -0000

    Hi Glen.

    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 :)

    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.

    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.

    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.

    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.


El 31/01/11 17:32, Glen escribió:
> Hi Emilio -
> The statement of work is technically correct, but it looks like
> somewhere a case was not taken into account:
> The secretariat staff, to use your phrasing, represents ALL entities
> (i.e. should be given all access to all properly-defined functions in
> the program.) They can and should be able to perform all legitimate
> actions that ANY user of the system could perform - as though they were
> that user - whilst logged in as themselves - without having to log in as
> a different user to accomplish that.
> This is a global requirement for anything IETF-wide that is written, I
> am guessing that was not spelled out clearly in the SOW, which is why
> this didn't happen. So somehow we're going to need to get that
> functionality added... and make sure that it is spelled out in future
> contracts clearly.
> Henrik -
> How do you suggest we proceed?
> Glen
> On 1/31/2011 5:08 AM, "Emilio A. Sánchez López" wrote:
>> Hi everyone,
>> In the "Liaison Statement Management Tool Enhancements" statement of
>> work the point 2.6.1 says:
>> """
>> The “From:” field: The leadership of all recognized IETF entities will
>> have accounts on the tool. (Please see Section A.1 in the Appendix.)
>> When the submitter logs on to the tool, if the submitter represents a
>> single IETF entity (e.g., a WG), then the “From:” field will include the
>> name of the entity that the submitter represents, followed by the
>> submitter’s name in parenthesis, e.g.,
>> IETF CCAMP WG (Adrian Farrel)
>> If the submitter represents multiple entities (e.g., is a chair of two
>> or more WGs), then the “From:” field will provide a drop-down list of
>> these entities, and the submitter can select the appropriate one for the
>> current liaison statement.
>> The submitter’s name will be a link to a “mail-to” form that will be
>> pre-populated with whatever address is inserted into the “Reply-To:”
>> field of the form. Initially, the “Reply-To:” field will be
>> pre-populated with the submitter’s e-mail address. However, the field
>> will be editable, so that he or she can replace that address with
>> another address in cases where it is appropriate for responses to go to
>> another individual.
>> """
>> So, the tool always add the submitter name after the entity name but
>> allows you to change the email address that submitter name points to.
>> When submitting a Liaison on behalf of the IETF you can not avoid that
>> "Stephannie McCammon" (or the name of the person logged into the tool)
>> appears between parenthesis after "The IETF", but you can change the
>> address it points using the reply-to field.
>> Regards,
>> El 28/01/11 16:36, Alexa Morris escribió:
>>> Henrik, everyone,
>>> We have another question about something in the tool. When Stephanie, as
>>> the liaison administrator, uploads a liaison, the tool makes it look
>>> like the liaison is FROM her, see here:
>>> While the liaison is from THE
>>> IETF, if it is also going to be tied to a person there it should be tied
>>> to the person who sent in the liaison OR a generic IETF address that
>>> comes to us. Does that make sense?
>>> Alexa
>>> -----------
>>> Alexa Morris / Executive Director / IETF
>>> 48377 Fremont Blvd., Suite 117, Fremont, CA 94538
>>> Phone: +1.510.492.4089 / Fax: +1.510.492.4001
>>> Email:
>>> Managed by Association Management Solutions (AMS)
>>> Forum Management, Meeting and Event Planning
>>> <>
>>> _______________________________________________
>>> yaco-liaison-tool mailing list
> _______________________________________________
> yaco-liaison-tool mailing list

Emilio A. Sánchez