[Fedora-infrastructure-list] Account system updates

[Elliot Lee]

On Jul 5, 2006, at 23:38, Dennis Gilmore wrote:

>> 			- 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?

One good possible solution...

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

Argh, ANOTHER thought I forgot to finish - thanks Dennis! :)

I meant to say that 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 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

This was where I diverged into an implementation detail rather than  
stating a problem. At the SQL schema level, it does matter. All this  
should be totally transparent to the user...

>> 	- 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?

I believe Dell and IBM are the only ones (I know Dell, not sure about  
IBM).

>> 	- 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.

Can you explain more of what you're thinking in this area? In my  
thinking you have to have one authoritative place to store the data,  
and while you can do things like offer other interfaces as desired,  
it's not really a matter of using two solutions where one will do...

(BTW, how hard would it be to implement an LDAP server whose tables  
were the direct results of SQL queries, with no gatewaying done? Is  
there a python module to make it easy to implement an LDAP server?)

Best,
-- Elliot