Mango Revamp
Aim of the project
GNOME is using mango to ease management of track based structure. This includes account management. Mango should let maintainers to grant account request for an applicant for a given project.
This project aims to minimize account team work load by organizing account related requests and making it easier to track requests from sysadmin point of view.
Prospects of the project
- In order to make streamlined application control possible, request, and information change should be done using mango interface. Using mango interface, user should able to (but not limited to) these;
- Request an account
- Submit ticket about his account request
- Keep track of the status of his account request
- Request changes to his accounts. (like password change, private key change etc.)
- Change of e-mail address.
Use Cases
- Contributor needs git account in order to push patches/translations.
- Maintainer needs access to shell in order to run his application on servers.
- Someone with an account lost his key pair and wants to replace it.
- Foundation member would like to gain @gnome.org alias.
- Someone wants to use two different keys for home use and office use.
- Someone wants to change their email address
Instruments
All account related work should be handled through the mango interface. Account team, or contributors should not need to use other interactions apart from mango web page. (Although e-mail might be necessary for taking some actions). Only status and inquiry messages should be kept in RT3 archives, if any. Backend infrastructure is not covered by this project. (ie. assigning public keys to git, or enabling access to shell from LDAP information.) This kind of helper tools should accompany mango.
A new LDAP scheme will be necessary to hold maintainer information and other good to keep information (like Bugzilla e-mail, PGP keys etc.)
Structure
All codes should be done in PHP version 5. PHP will use LDAP communications in order to alter settings. MySQL usage might be required. RT3 is not considered to be used. Mango interface will use XSLT templates, all styling should be done using seperate CSS. JavaScript usage should be limited (only for enhancing usability not for doing actual work) for compatibility issues. Project does not plan to enable translations at this point.
Mail communication will use token based authentication as decided on. PGP (Pretty Good Privacy) implementation code might be included using GPG (GnuPG). Client certification is not covered with this project however notes about this should be included in documentation.
MAINTAINERS are the project leaders/responsible people. This information will be kept in LDAP directory and necessary data definitions in LDAP scheme should be ready. All maintainer information should be added to LDAP and should be associated with real users of mango in order to use their e-mail information in LDAP.
All data should be UTF-8 if that standard can be used (ie. e-mail addresses should be ASCII, but names should be kept as UTF-8).
Deliveratives
- New mango application with XSLT templates and necessary style sheets.
- MySQL database structure scripts and dumps (if any)
- LDAP scheme file to be used for LDAP structure
- Documentation related with usage of mango.
Timeline
No strict dates.
May 28th, 2007 / May 30th, 2007
- Serving initial setup with the new ldap scheme
May 30th, 2007 / June 06th, 2007
- Preparing necessary data for ldap sceme like MAINTAINERS / MODULE LIST etc.
June 6th 2007 / June 6th, 2007
- Mango refactoring for using new ldap scheme. - Coding necessary script for adding mass data into ldap - Adding new accounts/account tracking and designing overall mango interface.
June 25th, 2007 / June 30th, 2007
- Testing ldap consistancy upon usage - Testing use-cases
June 30th, 2007 / July 9th, 2007
- Completing missing parts for use-cases.
July 9th, 2007 / July 25th, 2007
- GUADEC
July 30th, 2007 / August 5th, 2007
- Post-GUADEC actions, fixing missing parts.
August 5th, 2007 / August 19th, 2007
- Testing, Bug fixing, last touches - Preparing delivaretives (database structures, ldap scheme, code etc.)
August 19th, 2007 - GSoC Ends.
Comments
Put your comments in here.
- Shell use case: it is actually meant to just 'install' the stuff on 'ftp.gnome.org'
- Additional use case (optional): access to some group, e.g. bugzilla or gnomeweb
- Extra points:
- Store more information in LDAP and let the person edit that as they see fit; e.g.:
- IRC nick
- Bugzilla email addresses (important for better Bugzilla integration)
- Modules they are developer for
- Modules they are maintainer for
- GPG ?
- Public keys can be kept (Baris)
See also: http://db.debian.org/userdir-ldap.schema
- Store more information in LDAP and let the person edit that as they see fit; e.g.:
- there's also an overlap between ldap and the foundation members database. Could this be fixed?
- Problem is not all foundation members have LDAP account (like translators, expired developers). Foundation members database also necessary for election stuff. But having foundation member tag on LDAP might be useful for @gnome.org aliases. (Baris)
Problem could be fixed by creating LDAP accounts for foundation members and putting them in a 'foundation' LDAP group
(RossGolder)
- Problem is not all foundation members have LDAP account (like translators, expired developers). Foundation members database also necessary for election stuff. But having foundation member tag on LDAP might be useful for @gnome.org aliases. (Baris)