> On Apr 9, 2017, at 5:42 PM, Chris Lambertus <[email protected]> wrote: > > >> On Apr 9, 2017, at 5:22 PM, Craig Russell <[email protected]> wrote: >> >> tl;dr Adding title field is fine. I see it as secretary's responsibility to >> harmonize iclas.txt and ldap. > > Ack. > >> We might as well add Suffix to LDAP to cater for the 23 III and 6 II that we >> have. I've added a comment to IIINFRA-13850 > > Agreed. Are there any other person-data related fields we should consider > capturing/adding? Now’s the time, since I’m committed to updating the infra > ldap/adduser tooling at this point. > I just took a look at some self-proclaimed Name Data Entry Standards and it looks like adding Prefix (or title) and Suffix should do fine for our purposes. Sometimes Middle Name(s) is also called out but I don't think there is any reason for us to distinguish Middle Name(s) from Given Name. And if John P Erwin III MD shows up we will just have to deal with it.
Craig https://www.lehigh.edu/lewis/data_standards.htm#Name https://www.lehigh.edu/lewis/suffix.htm > > >>> On Apr 9, 2017, at 10:05 AM, Sam Ruby <[email protected]> wrote: > > <snip> > >>> Once created, we need to nail down the responsibility for updating >>> names. Given that names change infrequently and at least one copy >>> (iclas.txt) isn't updateable by users themselves, this responsibility >>> should go to the secretary (Craig, please confirm?), and the necessary >>> tooling needs to be in place to allow the secretarial team to do so. >> >> Secretary is up to this task, given adequate tooling. > > Excellent. I think this will be a good use for the existing LDAP/ICLA > comparison tool, which could probably be extended to allow for some simple > “on the fly” editing of the various fields to correct any discrepancies. > >>> --- >>> >>> The format of a new-account-request isn't flexible, but is workable >>> (I'd prefer JSON or YAML, but adding still more fields at the end is >>> probably easier): > > I’m not opposed in theory, but grafting a JSON or YAML parser onto the > existing ap-adduser code is out of scope right now, and more than likely not > worth the effort. If we want to go down that road, it would make more sense > to rewrite the acreq process from the ground up. > > > > Thanks for the input so far. Technical/implementation details can be captured > in INFRA-13850. > > -Chris > > Craig L Russell [email protected]
