I stand corrected.
> On Jul 25, 2018, at 3:04 AM, sebb <[email protected]> wrote:
>
> On 23 July 2018 at 18:50, Craig Russell <[email protected]> wrote:
>> Looks like there are a couple of issues here.
>>
>> The entries in new-account-reqs.txt that have not been processed are
>> incorrect. It looks like the Public Name was put into the Full Name field.
>
> Are you sure?
>
> I thought the Full Name field was only used in iclas.txt.
>
> AFAIK there is no LDAP attribute for the Legal Name (it would need to
> be private)
Right. So we have to deal with new account requests with a single name in the
second field.
>
>> This is probably just a bug in the code that creates the new account
>> request. Is the same code used in whimsy.new account creation and in
>> workbench.new account creation? Can anyone confirm?
>
> I suspect the format of new-account-reqs.txt assumes that the second
> field is the 'cn' attribute and can be space-split to produce
> givenName and sn.
>
> This only works consistently if the Public Name consists of exactly two words.
>
> I suspect the new-account-reqs.txt layout needs to be adjusted to
> include the 3 fields:
> cn
> sn
> givenName
How about this:
cn = name with no changes
sn = name.split(' ').last
givenName = name.split(' ').first
Or as Sebb suggests, split name into three fields in the account request so we
don't need to go back and fix e.g. William J. Rowe Jr.
Then both new account request and workbench whimsy programs would need to be
amended to include all three fields (my favorite choice).
Craig
>
>
>
>> Craig
>>
>>> Begin forwarded message:
>>>
>>> From: Chris Thistlethwaite <[email protected]>
>>> Subject: Re: New Account doesn't have full name
>>> Date: July 23, 2018 at 8:43:38 AM PDT
>>> To: Craig Russell <[email protected]>
>>> Cc: Secretary <[email protected]>, [email protected]
>>>
>>> Agreed, single named committers exist, I'm not sure how they were
>>> created (like in the FJ instance, manually edited, then later cleaned
>>> up in LDAP).
>>>
>>> The problem is that Gerben has a full name that didn't get into new-
>>> account-reqs.txt, instead it was just Public Name
>>>
>>> From iclas.txt
>>> notinavail:Gerben van den Broeke:Gerben:[email protected]:Signed
>>> CLA;gerben-van-den-broeke
>>>
>>> but in new accounts it's:
>>> gerben;Gerben;[email protected];incubator;incubator;07-14-
>>> 2018;yes;yes;no
>>>
>>> It's two problems, Public Name is being confused with something else so
>>> when people fill out the ICLA, the just put whatever in there.
>>> Secondly, some script/workflow/process is using Public Name over Full
>>> Name. I just don't know enough of the flow of signed ICLA being
>>> submitted to it getting into new-account-reqs.txt for us to create the
>>> account.
>>>
>>> -Chris T.
>>>
>>> On Mon, 2018-07-23 at 07:45 -0700, Craig Russell wrote:
>>>> Hi Chris,
>>>>
>>>> I'm very confused.
>>>>
>>>> We have committers with a single name. They are rare but they exist.
>>>>
>>>> If there is an issue where some scripts insist on two names in either
>>>> Public Name or Full Name then the scripts need to be fixed.
>>>>
>>>> I looked just now at the account request form and tried Gerben and
>>>> everything looks fine there.
>>>>
>>>> Where is the problem exactly?
>>>>
>>>> We recently changed LDAP and now have some extra fields. Maybe we
>>>> need to discuss mapping ICLA form to LDAP entries?
>>>>
>>>> Craig
>>>>
>>>>> On Jul 23, 2018, at 4:04 AM, Chris Thistlethwaite <[email protected]
>>>>> g> wrote:
>>>>>
>>>>> So we have two more new account submissions that are missing "Full
>>>>> Name". While the script is in need of updating, there seems to be
>>>>> something missing upstream. Perhaps the wording around "Public
>>>>> Name" on
>>>>> the ICLA needs to be clarified (as per INFRA-16752). I don't know
>>>>> which
>>>>> tool/process creates the new-account-req.txt file, but that should
>>>>> always take first/last name instead of Public Name.
>>>>>
>>>>> I understand that not everyone/all cultures use First/Last name,
>>>>> but in
>>>>> order for us to automate this process in the future (hopefully)
>>>>> this
>>>>> manual check of the ICLA wouldn't work.
>>>>>
>>>>> -Chris T.
>>>>>
>>>>>
>>>>> On Mon, 2018-07-09 at 22:45 +0100, sebb wrote:
>>>>>> I see you editted the file to change the field to FJ FJ.
>>>>>>
>>>>>> It would be better to fix the script to handle the original entry
>>>>>> as
>>>>>> the result is not correct.
>>>>>>
>>>>>> The cn should be FJ, not FJ FJ.
>>>>>>
>>>>>> On 9 July 2018 at 19:03, Chris Thistlethwaite <[email protected]>
>>>>>> wrote:
>>>>>>> That's fine with me, I wanted to make sure there wasn't some
>>>>>>> upstream
>>>>>>> error before creating the account.
>>>>>>>
>>>>>>> -Chris T.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 2018-07-09 at 16:02 +0100, sebb wrote:
>>>>>>>> On 9 July 2018 at 15:21, Chris Thistlethwaite <christ@apache.
>>>>>>>> org>
>>>>>>>> wrote:
>>>>>>>>> Just hit an error where a new account doesn't have a full
>>>>>>>>> first/last
>>>>>>>>> name.
>>>>>>>>>
>>>>>>>>> fjy;FJ;[email protected];incubator,druid;incubator;07-
>>>>>>>>> 07-
>>>>>>>>> 2018;yes;yes;no;
>>>>>>>>>
>>>>>>>>> Do we have more detail on FJ?
>>>>>>>>
>>>>>>>> The ICLA shows the public name as just FJ
>>>>>>>>
>>>>>>>> https://svn.apache.org/repos/private/documents/iclas/fangjin-
>>>>>>>> yang
>>>>>>>> .pdf
>>>>>>>>
>>>>>>>> I don't think we can insist on there being two names (cf.
>>>>>>>> Upayavira)
>>>>>>>> nor on how long the public names are.
>>>>>>>>
>>>>>>>> If the script cannot handle FJ then IMO that is a problem
>>>>>>>> that
>>>>>>>> has to
>>>>>>>> be fixed in the script.
>>>>>>>>
>>>>>>>> I'm guessing the problem is that it is trying to split the
>>>>>>>> name
>>>>>>>> into
>>>>>>>> sn and givenName.
>>>>>>>> If so, just set them both to FJ (this is how Upayavira is
>>>>>>>> treated)
>>>>>>>>
>>>>>>>>> -Chris T.
>>>>
>>>> Craig L Russell
>>>> Secretary, Apache Software Foundation
>>>> [email protected] http://db.apache.org/jdo
>>>>
>>
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> [email protected] http://db.apache.org/jdo
>>
Craig L Russell
Secretary, Apache Software Foundation
[email protected] <mailto:[email protected]> http://db.apache.org/jdo
<http://db.apache.org/jdo>
