Jim Walker wrote: >> That is why the new database schema distinguishes between different >> classes of SCA - if we know a particular person is covered by a Sun >> SCA, we also know that their 'reference' will be a Sun employee ID, >> and that could be checked against the corporate LDAP database. > > Why do we need employee numbers?
Because they are the definitive primary key for Sun employees. They remain the same across email and username changes. > It seems like we just need a SCA number field and a Commit role field > in addition to whatever other roles that person has. And, an entry and > exit process, so as people change companies we always have the right > number. We already have multiple people that work for companies using > the same SCA number and we don't track their employee numbers. Sun > shouldn't be any different. Sun just needs it's own SCA number. The > employee number granularity shouldn't be needed. User roles should > define what an OpenSolaris user can and can not do. Multiple employees (of Sun or any other company) may be covered by a single SCA, but we still need to distinguish one employee from another. For other companies, we might not track their employee number, but we *do* track them as individuals. For Sun employees, the employee number is the only unique way of matching their 'inside' and 'outside' personas, as there is no requirement for their SWAN username and their OpenSolaris usernames to match, nor for their email addresses to match. And as for commit roles, it is still completely unclear how commit rights are going to be allocated - for example are these managed centrally for all ON committers, or does each project that contributes to ON manage its own pool of committers? In the absence of any such design decisions, it is difficult to come up with a database design. > (And, if you get the user names to match inside and outside Sun like you > want then you can cross check that person via LDAP if for some reason > you need to do that.) Getting the names to match internally and externally may be desirable, but may not in reality always be possible. And even if they do match, we cannot assume that they are immutable - people can and do change their SWAN usernames. The new OSO auth application allows usernames to be edited if required, the thing that uniquely identifies an OpenSolaris is a unique integer, not their username. You can try it if you like ;-) http://auth.opensolaris.org/admin/user.action?edit&userId=26 -- Alan Burlison --
