> On Jul 13, 2021, at 8:12 AM, sebb <seb...@gmail.com> wrote:
>
> On Sat, 10 Jul 2021 at 22:33, Craig Russell <apache....@gmail.com> wrote:
>>
>> Hi Sebb,
>>
>>> On Jul 8, 2021, at 4:51 AM, sebb <seb...@gmail.com> wrote:
>>>
>>>> One entry point is the secretary workbench where ICLAs are recorded. I
>>>> believe that we need to add three fields to the ICLA form for the LDAP
>>>> fields: family first, given name, and family name.
>>>
>>> I agree about given name and family name.
>>> The field 'family first' is unnecessary and confusing.
>>
>> I'm referring here specifically to the secretary workbench ICLA screen, not
>> the ICLA.pdf form. The "[x] Family First" is on the ICLA form, and should be
>> shown on the ICLA screen as a yes/no box that can be edited if secretary
>> decides that it is incorrect (or an old form that doesn't include it).
>>>
>>>> By default, if the requested id is filled, the given name should be the
>>>> (family first)? cn[0] : cn[-1]
>>>> And the sn should be (family first)? cn[-1] : cn[0]
>>>
>>> We should not try to parse the Public Name; instead family name should
>>> be required on the ICLA.
>>
>> The LDAP fields are an artifact of how we choose to handle things in infra
>> and have nothing to do with the legal document. We might choose in future to
>> put stuff into a database instead of LDAP and get rid of the cn, sn,
>> givenName artifacts entirely.
>>
>> But secretary still needs to fill the LDAP fields from information on the
>> ICLA and as it is today, there just is not enough information to do it. But
>> with the Family First flag, we have enough information to derive the sn and
>> givenName from the Public name.
>
> The Family first flag gives enough information to make a guess at the
> sn and givenName.
> It does not guarantee these will be derived correctly, and there is no
> guarantee that the person has understood whether they need to check
> the box or not.
> However the latest proposed wording is at least easier to understand.
What I failed to say earlier is that if the family first box is checked, the
file name should be reversed to <given>-<family>.pdf to be consistent with the
existing file names. So I do believe that we should add the check box to the
ICLA screen. And add the givenName and sn to the screen as well.
I looked at workbench/views/forms/icla.js.rb and found a place for the family
first flag, probably just after:
_tr do
_th 'Public Name'
_td do
_input name: 'pubname', value: @pubname, required: true,
disabled: (@filed or @pdfbusy), onFocus: lambda {@pubname ||=
@realname}
end
end
We would need to add a _th 'Family First' with an _input field, value
@familyfirst, required true.
And the givenName and sn fields should be added, perhaps after the User ID
field because it's only needed for new account creation?
What I could not find is how to use _input to define a check box. I found a
reference volume for the Vue stuff but I'm missing our extensions.
We also need to adapt the PDF parser (I think the parsing is done in the back
end).
I'm pretty sure I do not have the technical skills to complete this project.
Would it be ok to start a new branch with a sketch of what we need to update
the icla screen for the new ICLA?
Or is there a better way to proceed?
>
>> So the ICLA screen needs to add the Family First flag, the derived (editable
>> by Secretary) sn and givenName fields. These will be needed only for account
>> creation so they should be listed below the "requested Apache id" part of
>> the screen.
>
> We don't *need* the flag.
> We could ask for family name and givenName instead.
> Or we could guess them.
Yes, and whatever the computer guesses should be overridden by the Secretary
with a bit more deep learning under their belt. I just hate to make the
Secretary type stuff that some shallow learning computer can offer as a good
guess.
>
> Or we could set the family name to a fixed value and omit the givenName.
> That would satisfy the LDAP schema and AFAICT would not affect
> anything that LDAP is used for.
>
> If it were important to have accurate sn and givenName I would have
> expected to see complaints that the incorrect values are causing
> problems.
It would be an interesting bit of history to figure out exactly who decided
that we should use the LDAP "person" protocol that *requires* both cn and sn.
Our usage of Public Name does not fit that description of "person" and we
should have left well enough with only having a cn instead of going full
"person" LDAP.
Craig
>
>> Regards,
>> Craig
>>
>> Craig L Russell
>> c...@apache.org
>>
Craig L Russell
c...@apache.org
