Important Announcement: Please read the latest status update for Fedora infrastructure (2008-08-22 1200 UTC). Additional details can be found in RHSA-2008-0855.
New SSH Fingerprints for Public Servers: Please verify SSH Fingerprints against https://admin.fedoraproject.org/fingerprints.
Archive:Infrastructure/AccountSystem2
From FedoraProject
(Redirected from Infrastructure/AccountSystem2)
Contents |
Requirements for the new Account System
Important! This page is obsolete. All feature requests should now be added to the trac instance on the FAS project page: https://fedorahosted.org/fas
User Interface Modifications
- Please allow users to add their wiki usernames -- ThomasChung
- Allow doing the sign-up process as a wizard-style step-by-step interface, instead of a bunch of links.
- Make documentation a part of the interface. This is in response to concern that getting a GPG key is too complicated for a lot of people such as translators who aren't tech people. This can possibly be done by providing scripts to the users.
- The user info screen might want to evolve from just an "edit my information" screen. Instead of just letting the user edit their information, we should also have links to other places where they might want to change their settings - the Wiki, OTRS, package database, bugzilla, etc. - and maybe a status summary from each of those places.
- Allow listing the timezone that the user is in.
- Allow listing more than one e-mail address per account possibly mimicing the linkedin.com interface.
- Have a top-level menu that is shown on all pages, with quick links to different pieces of the account system.
- User apply (often to early) for cvsextras and we can't find the bugs where people put up something for review. We need a link here so we can easily find the review-bugs.
- Users apply accidentally for cvsextras, but don't plan to participate in Extras. The welcome message after signing the CLA seems the culprit here (I don't now the exact text, but it seems it suggest to ask for membership in cvsextras).
- Allow a user to set themselves as "inactive" in a group (because of lack of time, extended vacations, etc, they may want to stop work on Fedora temporarily. Mailing List Post
- Logout button Ticket #298
- Easy searching of groups that can be applied for. Ticket #298
- Make sure we fix this (incrementing the serial of user certificates) Fedora Infrastructure Ticket 131 (closed duplicate)
- Mention the sync delay when adding or updating ssh keys on the account system.
- Display the user's public ssh key so
1. They can verify which one it is. 2. Others can easily give access to a contributor by copying the key to their machines.
- Show full gpg key fingerprint and better support for gpg, see also FAS ticket full gpg key verification
- Get Fedora L10n to translate the UI in multiple languages
Admin Interface Modifications
- With hundreds of users and 10s of groups, we definitely need a nicer way to find specific users or groups than paging through them 1 by 1...
- The part of the interface where you add users to or remove users from a group is clunky. In particular, it's currently possible to add a user to a group more than once, and if a user is rejected from a group, there is no way to let them come back at a later date and apply...
- Make the e-mail reminders a bit smarter and nicer to read
- Allowing administrators to mark membership applications as "acknowledged" would be nice for administrators, especially for Extras.
- Allow setting a per-group e-mail message to be sent to people when their membership in a group reaches different stages...
- Allow groups to be members of other groups (i.e. you are a member in group B because you are a member in group A, and A is a member of B). Can't do this nicely with the current SQL schema.
- Auto subscribe new packagers to the fedora-devel-announce mailing list when their cvsextras status is approved.
Legal Stuff
- Privacy issues need to be thought out more clearly and addressed. In particular, this relates to what information we store. Basically, we need to think more about what information we store, but even more importantly, what information is displayed to the general public when viewing a user's info, what information is displayed to registered Fedora users when viewing that user's info, and so on.
- Account System 2.0 should get run by Red Hat's legal department to just make them feel comfortable with the change
- On a related note, we need to add proper support for the corporate CLA. If we had 'groups being members of other groups' implemented, it would be fairly easy to create a group for each corporation that signed the CLA, have each of those groups be a member of the cla_done group and having access to the corporate CLA groups administered by a designated contact...
- Need to make iron-clad sure that the rewrite does NOT muck with the legal issues surrounding the CLA (i.e. we have to continue to guarantee that people have submitted the CLA form by a GPG signature with a key that is tied to a verified e-mail address)
Implementation Details
- Rewrite the code to be cleaner (maybe use turbogears, or maybe that is too heavyweight)
- Make it easier to embed into other apps, especially the signup process (so that Extras can have a custom "sign up as an extras contributor" wizard that can easily do the basic account system steps as part of its workflow
- Figure out the whole LDAP vs SQL thing . Or is it the LDAP + SQL thing?
- At the end, port the application interface parts (get_auth, have_auth, have_group, etc.) to perl and php so that we can use them from all our applications
- Need more free-form text fields everywhere (e.g. comments that are visible only to admins, or whatever). Maybe it should just be something that holds XML that is processed by the apps...
- Updates to replicate as close to immediately as possible. This may end up being more the way our end apps communicate with the accounting system.
- We need a documented API in major supported languages.
- History/Rollback functions. With so many trusted people working on different parts of the system, this may become a necessity.
- Encrypted passwords
- More focus on 'key' based access when appropriate.
- use subkeys.pgp.net gpg keyserver rotation (other may break some gpg (sub)keys)
- Use a gpg key to sign users gpg keys and send this signature to the user's e-mail address encrypted with the user's public key and make him publish this signature to subkey.pgp.net to make it easier to verify the gpg key of other Fedora people.
- Make the code i18n-aware: export strings as PO files.
Ideas
Fedora People Integration
Have a 'blog' field for each account, which will automatically sync with the planet. This would free up some cycles for the planet admins, and essentially make it self-maintaining. -lmacken (and unbelievably crap-ridden) - skvidal
