Stephen Hahn wrote: >> New in this version: the ability to manage a user's source code agreement. > > I see the user_agreement.action page, but don't see how it represents > a history of agreements. The use cases I'm thinking of are the > various changes in user state we've seen over the past few years: > > independent -> contractor -> independent > independent -> intern -> independent -> employee > independent -> employee -> contractor -> independent > employee -> independent -> employee (coa #2) > > Would this be shown in the Agreement page, or somewhere else?
The user agreement table only holds the current agreement. If you want to track history, there are two ways could be done, firstly we could write a summary audit record in the audit log each time the SCA is replaced, secondly we could extend the user agreement table to hold multiple rows for each user. Option 1, holding the data in the audit table, requires it to be 'flattened' into a generic form - in general terms it is more like the database equivalent of an application log. The data would be read-only, and the 'auditing' submenu is where it would be visible from. Option 2 would make it easier to query the full history of a user's SCAs, but it isn't as straightforward to implement as it at first seems. To follow this explanation, please refer to the definitions of the os_agreement_type and os_agreement tables at http://src.opensolaris.org/source/xref/website/auth/trunk/AuthDB/src/sql/create_db.sql#157 The model where a user signs a SCA directly is only a subset of the possible SCA types. For example, Sun employees work under a 'blanket' SCA, and employees of another company may be covered by a group SCA signed by their employer. That kind of SCA may have a limited duration, and it isn't the individual employees that are signing, but they do have to be associated with the group SCA. So if the company (say) extends its SCA by 6 months, it is the *group* SCA that needs modification, not the individual ones. In this case the record for the group SCA (in os_agreement_type) is the source of the start and end dates for the SCA, not the date fields in the per-employee records (in os_agreement), which would be null. Some other considerations are what does it mean to 'edit' a SCA? Once it is entered, what changes do we allow? Do we allow the dates to be altered, or are they immutable? What about the user's reference? Do we only allow the 'latest' SCA to be edited, or do we allow the previous ones to be edited as well? Do we allow overlapping dates, or always reject them as an error? And if a user is covered ny a group SCA you can't edit the details of the user's SCA, you have to edit the underlying 'group' SCA. I'm not saying that option 2 isn't possible, and it may in fact be the best option, but it would need careful consideration to get the semantics right. -- Alan Burlison -- _______________________________________________ website-discuss mailing list [email protected]
