On 10 April 2017 at 02:09, Craig Russell <craig.russ...@oracle.com> wrote: > >> On Apr 9, 2017, at 5:42 PM, Chris Lambertus <c...@apache.org> wrote: >> >> >>> On Apr 9, 2017, at 5:22 PM, Craig Russell <craig.russ...@oracle.com> 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.
GivenName is not an ideal attribute name, because many people have more than one given name, and they don't necessarily use the first one in daily life. However if it is treated as a Preferred name, this problem disappears. > 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 <ru...@intertwingly.net> 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): >> The more fields there are in a single CSV entry the easier it is to accidentally use the wrong one or omit one, especially if the record is manually created or editted. It's also harder to review manually. So I think a more structured file would be better. Maybe even use the LDAP attribute names as prefixes? (i.e. something like LDIF output) If suitably implemented, this would allow additional fields to be added without further coding. >> 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. >> What languages are used? >> >> >> Thanks for the input so far. Technical/implementation details can be >> captured in INFRA-13850. >> >> -Chris >> >> > > Craig L Russell > c...@apache.org > >
