[Fedora-infrastructure-list] Account system updates

[Dennis Gilmore]

On Wednesday 05 July 2006 10:20 pm, Elliot Lee wrote:
> Hey Tom! Thanks for keeping us on task here :)
>
> Here are some of the things I have been thinking of for the new
> account system:
>
> For users:
> 	- Allow listing more than one e-mail address per account
> (linkedin.com is the site I remember doing this right)
> 	- Clean up the interface
> 		- Have a top-level menu that is shown on all pages, with quick
> links to different pieces of the account system
> 		- Allow doing the sign-up process as a wizard-style step-by-step
> interface, instead of a bunch of random links to
> 		- Make documentation a part of the interface
> 			- In particular, there is a lot of concern that getting a GPG key
> is too complicated for a lot of people such as translators, who are
> not technical types. We need to make that process as clear and simple
> and documented as possible
can we provide a script for nontechnical types?

> 	- The user info screen might want to evolve from just an "edit my
> information" screen
All sounds good I read it to mean simpler and more integrated 

> For administrators:
> 	- Clean up the interface
> 		- 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
> reapply...
> 	- 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. I did it nicely
> with the old Red Hat build system, but it requires using text fields
> instead of numeric IDs to specify the names of the group members...
with the right interface it shouldn't matter if GID's/UID's  are numerical or 
text
> For everyone:
> 	- 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...
> 	- Privacy issues need to be thought out more clearly and addressed.
> In particular, this relates to what information we store
> 	- 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)
> 		- Account System 2.0 should get run by Red Hat's legal department
> to just make them feel comfortable with the change
I would imagine  this is a must.  We cant freak them out :D
> 	- 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 CCLA, 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...
Sounds good.  is there many corporate CLA's? 
> Behind the scenes:
> 	- 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
Why not use both? some thing will be  just easier in ldap, some in SQL,  use 
SQL as a backend  to ldap Its a little more work  but would provide greatest 
flexibility.
> 	- 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
>
> Hope this helps,
> -- Elliot


-- 
Dennis Gilmore, RHCE
Proud Australian