Historic: SowIesgDatatracker

#!rst

Task: Porting the IESG datatracker interface to Django
======================================================

The first Work Order will merge the Existing Django Application and  
the Existing Perl Application to create the Replacement Application.

Application Requirements
------------------------

The Replacement Application must conform to the following  
requirements.

1.	The Replacement Application should retain the same functionality  
and database structure as the Existing Django Application and the  
Existing Perl Application to the greatest extent possible.  Any proposed
reduction in functionality must be described, and accepted by the PM.
The  look-and-feel of the Replacement Application should be reasonably
close to the Existing Django Application.  This means that there is no
imperative to keep the look-and-feel of the Existing Perl Application.
Please note that the look-and-feel of the Existing Django Application has
changed substantially between November 2009 and March 2010.  

2.	The Existing Perl Application maintains metadata about a document,  
including a state machine and ballot positions from evaluators.  There  
is also an administrative interface, which allows the administrator to  
record ballot positions that are provided offline and maintain  
additional data.

3.	All actions on a document are logged in a comment log and  
optionally sent by email to a list of interested parties.  In  
addition, certain workflow actions cause a template email message to  
be sent to a wider audience (e.g., IETF Last Call, or document  
approval messages).

4.  The Replacement Application must be implemented in Python using  
the Django framework, maintaining all of the functionality of the  
Existing Django Application and adding the functionality of the  
Existing Perl Application.  Read-only access will not require login,  
but read-write access will require a login.  It is expected that  
Django models for many of the relevant database tables already exist,  
but may have to be augmented for this work.

5.	The code must be readable and have adequate comments.  The
porting work would produce design documentation and code.

6. The database schema used by the Existing Perl Application and the  
Existing Django Application should be used as-is by the Replacement  
Application; any database schema refactoring work (although sorely
needed) will be part of a separate work order.

7.	The Existing Django Application on which the Replacement
application will be based shall be branched from the most recent
release from the branch/2.00/ branch of the SVN repository at
http://svn.tools.ietf.org/svn/tools/ietfdb/ at the time the work
is started.  The SVN rev corresponding to the most recent release
can easily be found by checking the tags at
http://trac.tools.ietf.org/tools/ietfdb/browser/tags/ .


Authentication
--------------

In the resulting application, no login will be required to view much  
of the data, and login will be required to update the database.   
Presently, there are two authentication levels: IESG and Secretariat.   
Additional authentication levels will be introduced in future  
enhancements.

Access-control functionality for the Django application will be added  
to the datatracker code.  It makes no sense to have separate "public  
tracker" and "non-public tracker" code.  The first access-controlled  
functionality will be common tasks done by IESG, such as balloting.

For authentication, the existing Apache htpasswd files will be used.   
These files are maintained by the IETF Secretariat.  Initially, there  
won't be any automatic functionality for creating accounts or  
resetting lost passwords.

The Django code will not access the htpasswd files in any way; the  
actual authentication is done by Apache.  Apache configuration will be  
modified so that "/login/" URL (or similar) requires a password.   
Then, the Django authentication framework is used to get the user name  
from the REMOTE_USER environment variable set by Apache.  (Note: this  
requires Django version 1.1).

Apache will not request authentication for any other URLs; instead,  
access control is done by Django code, based on a cookie set by the  
login page.  Pages that absolutely require authentication would  
redirect the client to /login/; other pages might show different views  
to unauthenticated users (e.g., anyone can view the ballot page, but  
filling in a ballot is only available to IESG members after login.

Authorization information will be used to determine which users are  
allowed to perform various tasks.  The Django framework will be used  
to access existing database tables to determine authorization, for  
example, which users are IESG members. These database tables are  
maintained by the IETF Secretariat.  It is also be possible to read  
the Apache .perms file, but it's not clear if this will be needed.

Volunteers will be available for consulting on the authentication and  
authorization architecture if needed.


References
----------

The Existing Perl Application is available from the SVN repository at
http://svn.tools.ietf.org/svn/tools/ietfdb/branch/legacy/iesg/idtracker.cgi

The cleaned database is available as a dump at
http://trac.tools.ietf.org/events/raw/sqldump/ietf_db_dump.sql

It requires authentication; to create a login one goes, as usual, to
http://tools.ietf.org/newlogin and uses the web interface.

The Existing Django Application is available for browsing at
http://trac.tools.ietf.org/tools/ietfdb/browser/branch/2.00/
and for SVN access at 
http://svn.tools.ietf.org/svn/tools/ietfdb/branch/2.00/

A read-write clone of the current IESG datatracker  application
(Existing Perl Application) is available to the Contractor at the
following URL: http://merlot.tools.ietf.org/cgi-bin/idtracker.cgi .
Login credentials to the clone has been provided earlier.

For reference, there's also a diagram of the old database table  
relationships here (big image file): 
http://merlot.tools.ietf.org/src/db/new/redesign/old-models.png