You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by Craig Russell <ap...@gmail.com> on 2017/06/11 00:13:07 UTC
Re: Secmail feature request
Hi Sam,
I totally missed this email in the forest.
> On May 20, 2017, at 7:56 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Mon, May 15, 2017 at 5:31 PM, Craig Russell <cr...@oracle.com> wrote:
>>
>>> On May 15, 2017, at 12:38 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>
>>> On Mon, May 15, 2017 at 11:54 AM, Craig Russell <ap...@gmail.com> wrote:
>>>> Hi Sam,
>>>>
>>>>> On May 13, 2017, at 7:41 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>
>>>>> On Fri, May 12, 2017 at 6:51 PM, Craig Russell <ap...@gmail.com> wrote:
>>>>>>
>>>>>> I know up front that this is a second icla. So good idea for this to be a different action.
>>>>>> (O) icla
>>>>>> (O) additional icla
>>>>>> (O) ccla
>>>>>>
>>>>>> Full Name: this is the key to find the entry in iclas.txt
>>>>>> Public Name: this should replace the public name in the entry
>>>>>> email: this should replace the email in the entry
>>>>>> file name: this is generated from Full Name and is the directory for the iclas
>>>>>>
>>>>>> If a third icla comes in, I can handle this manually. Unless it's easy to put in now:
>>>>>>
>>>>>> if full-name/full-name.pdf (or full-name/icla.pdf and icla.pdf.asc) already exists:
>>>>>> find the largest n in full-name/full-name<n>.pdf
>>>>>> file the new icla under full-name/full-name<n+1>.pdf
>>>>>>
>>>>>> and replace Public Name and email in iclas.txt as for the second one.
>>>>>
>>>>> Handling the 'nth' case doesn't concern me.
>>>>>
>>>>> What does concern me is the ability to change the Full Name (and
>>>>> therefore the filename). If you do that, this won't be a second ICLA,
>>>>> and the code won't be able to identify an existing line in iclas.txt
>>>>> to update.
>>>>
>>>> Select (O) additional icla
>>>>
>>>> The Full Name is the key to the entry you want to change. I don't know if there are any cases where the Full Name does not exactly match the file name (modulo converting Non-US-ASCII letters to latin letters). That is, someone changed file name after filling full name. But that is not the usual case. For our purposes, we can disallow changing the file name and always take it from the full name. This might be a good thing to do for all iclas.
>>>>
>>>> Maybe an update to icla-lint would catch any cases where the full name and file name do not match.
>>>
>>> The part of the 5th field after a semicolon is, indeed, a key field.
>>> Many of which reflect decisions that were made before the workbench
>>> existed, or before I was secretary for that matter. :-)
>>>
>>>>> I'd like to suggest as an alternative, two fields: one identifying the
>>>>> existing user,
>>>>
>>>> This is the full name ~== file name
>>>
>>> I was thinking of a field like the one present here:
>>> https://whimsy.apache.org/roster/committer/
>>>
>>> You will be able to enter a name, and id, or an email, and it will
>>> find the correct entry. It could then display the full name value for
>>> confirmation.
>>
>> This would be excellent. I don't know though if the committer roster interaction is simple enough to copy for secmail tool. If so:
>>
>> (O) additional icla
>> search: _______________
>> existing Full Name: <from iclas.txt>
>> existing Public Name: <from iclas.txt>
>> existing email: <from iclas.txt>
>>
>> proposed Public Name: ________<from email>______
>> proposed email: _____<from email>_________
>
> Client side logic is roughed in.
Looks great! The search field is really responsive. Did you cache the entire iclas.txt file?
The more I test this the more I want it as part of the Categorize menu, just above Links.
>
>> (File)
>>
>> And then the fun of fitting the new icla into the documents/iclas/ directory begins.
>
> Looking at the server logic, if I were to submit a new icla (not that
> I have any need to),
>
> Step 1 would be to mkdir sam-ruby and move sam-ruby.pdf to sam-ruby/icla.pdf
>
> Step 2 would be create sam-ruby/icla2.pdf
>
> Step 3 would be to update iclas.txt with new email (and possibly new
> public name)
>
> Step 4 would be to send out an email.
>
> Notes:
>
> 1) Step 1 wouldn't be done if iclas/sam-ruby already existed
>
> 2) Step 2 would use icla3 or icla4 or whatever until a unique number is found
>
> Questions:
>
> 1) would it be icla.pdf or icla1.pdf in step 1?
icla.pdf
>
> 2) who should the email go out to and what should be in the email?
To: the sender, <root@ if infra needs to do something>
cc: everyone on the bcc: and cc: lists, the email in the iclas.txt file, the apache-id@apache.org, and secretary.
Dear <public name>,
This message acknowledges receipt of your additional ICLA, which has been filed in the Apache Software Foundation records.
<one of the paragraphs below>
Warm regards,
-- standard footer
If infra needs to update the forwarding email address, add something like this to the email above:
With this email, our administrators are requested to update the forwarding email in our records for <apache-id> to <new email address> so you can change your password using https://id.apache.org .
If whimsy can update the forwarding email address to enable id.apache.org password change, add:
You can change your password using https://id.apache.org .
>
> 3) is it worth trying to send an email to the old email address so
> that they know of the change? Yes, it would normally bounce, but if
> it didn't...
Yes. Any time something like this happens I try to notify all known addresses. We have a similar situation right not with someone who wants a new identity and I have included all known addresses in the recent dialog.
Craig
>
>> Craig
>
> - Sam Ruby
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
Re: Secmail feature request
Posted by Craig Russell <cr...@oracle.com>.
On Jun 10, 2017, at 6:28 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> On Sat, Jun 10, 2017 at 8:13 PM, Craig Russell <ap...@gmail.com> wrote:
>> Hi Sam,
>>
>> I totally missed this email in the forest.
>
> It happens :-)
>
>>> On May 20, 2017, at 7:56 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>
>>> On Mon, May 15, 2017 at 5:31 PM, Craig Russell <cr...@oracle.com> wrote:
>>>>
>>>>> On May 15, 2017, at 12:38 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>
>>>>> On Mon, May 15, 2017 at 11:54 AM, Craig Russell <ap...@gmail.com> wrote:
>>>>>> Hi Sam,
>>>>>>
>>>>>>> On May 13, 2017, at 7:41 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>>
>>>>>>> On Fri, May 12, 2017 at 6:51 PM, Craig Russell <ap...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I know up front that this is a second icla. So good idea for this to be a different action.
>>>>>>>> (O) icla
>>>>>>>> (O) additional icla
>>>>>>>> (O) ccla
>>>>>>>>
>>>>>>>> Full Name: this is the key to find the entry in iclas.txt
>>>>>>>> Public Name: this should replace the public name in the entry
>>>>>>>> email: this should replace the email in the entry
>>>>>>>> file name: this is generated from Full Name and is the directory for the iclas
>>>>>>>>
>>>>>>>> If a third icla comes in, I can handle this manually. Unless it's easy to put in now:
>>>>>>>>
>>>>>>>> if full-name/full-name.pdf (or full-name/icla.pdf and icla.pdf.asc) already exists:
>>>>>>>> find the largest n in full-name/full-name<n>.pdf
>>>>>>>> file the new icla under full-name/full-name<n+1>.pdf
>>>>>>>>
>>>>>>>> and replace Public Name and email in iclas.txt as for the second one.
>>>>>>>
>>>>>>> Handling the 'nth' case doesn't concern me.
>>>>>>>
>>>>>>> What does concern me is the ability to change the Full Name (and
>>>>>>> therefore the filename). If you do that, this won't be a second ICLA,
>>>>>>> and the code won't be able to identify an existing line in iclas.txt
>>>>>>> to update.
>>>>>>
>>>>>> Select (O) additional icla
>>>>>>
>>>>>> The Full Name is the key to the entry you want to change. I don't know if there are any cases where the Full Name does not exactly match the file name (modulo converting Non-US-ASCII letters to latin letters). That is, someone changed file name after filling full name. But that is not the usual case. For our purposes, we can disallow changing the file name and always take it from the full name. This might be a good thing to do for all iclas.
>>>>>>
>>>>>> Maybe an update to icla-lint would catch any cases where the full name and file name do not match.
>>>>>
>>>>> The part of the 5th field after a semicolon is, indeed, a key field.
>>>>> Many of which reflect decisions that were made before the workbench
>>>>> existed, or before I was secretary for that matter. :-)
>>>>>
>>>>>>> I'd like to suggest as an alternative, two fields: one identifying the
>>>>>>> existing user,
>>>>>>
>>>>>> This is the full name ~== file name
>>>>>
>>>>> I was thinking of a field like the one present here:
>>>>> https://whimsy.apache.org/roster/committer/
>>>>>
>>>>> You will be able to enter a name, and id, or an email, and it will
>>>>> find the correct entry. It could then display the full name value for
>>>>> confirmation.
>>>>
>>>> This would be excellent. I don't know though if the committer roster interaction is simple enough to copy for secmail tool. If so:
>>>>
>>>> (O) additional icla
>>>> search: _______________
>>>> existing Full Name: <from iclas.txt>
>>>> existing Public Name: <from iclas.txt>
>>>> existing email: <from iclas.txt>
>>>>
>>>> proposed Public Name: ________<from email>______
>>>> proposed email: _____<from email>_________
>>>
>>> Client side logic is roughed in.
>>
>> Looks great! The search field is really responsive. Did you cache the entire iclas.txt file?
>
> There is no round-trip to the server as you make your data entry.
> When you select additional icla, I download the entries in iclas.txt
> that are NOT notinavail and all searching is done on the client.
>
>> The more I test this the more I want it as part of the Categorize menu, just above Links.
>
> Just so I'm clear, it is currently a part of the Categorize menu,
> where you originally asked for it:
>
> https://github.com/apache/whimsy/blob/master/www/secretary/workbench/views/parts.js.rb#L104
>
> You now want this moved down to about here:
>
> https://github.com/apache/whimsy/blob/master/www/secretary/workbench/views/parts.js.rb#L159
>
> Easy enough.
It's a bit hard for me to tell whether it belongs at line 104 or 159.
Right now, it's part of the Additional ICLA menu.
I'd prefer it to be part of the Categorize menu so I can take a look before I have to choose whether it's an icla or additional icla.
Just the Search field and the list of candidates below. Not the Current Values and Updated Values.
Craig
>
>>>
>>>> (File)
>>>>
>>>> And then the fun of fitting the new icla into the documents/iclas/ directory begins.
>>>
>>> Looking at the server logic, if I were to submit a new icla (not that
>>> I have any need to),
>>>
>>> Step 1 would be to mkdir sam-ruby and move sam-ruby.pdf to sam-ruby/icla.pdf
>>>
>>> Step 2 would be create sam-ruby/icla2.pdf
>>>
>>> Step 3 would be to update iclas.txt with new email (and possibly new
>>> public name)
>>>
>>> Step 4 would be to send out an email.
>>>
>>> Notes:
>>>
>>> 1) Step 1 wouldn't be done if iclas/sam-ruby already existed
>>>
>>> 2) Step 2 would use icla3 or icla4 or whatever until a unique number is found
>>>
>>> Questions:
>>>
>>> 1) would it be icla.pdf or icla1.pdf in step 1?
>>
>> icla.pdf
>>>
>>> 2) who should the email go out to and what should be in the email?
>>
>> To: the sender, <root@ if infra needs to do something>
>
> It looks like the secretarial team (and therefore whimsy) can update
> mail addresses:
>
> https://github.com/apache/infrastructure-puppet/blob/deployment/modules/ldapserver/templates/slapd.conf.erb#L159
>
>> cc: everyone on the bcc: and cc: lists, the email in the iclas.txt file, the apache-id@apache.org, and secretary.
>>
>> Dear <public name>,
>>
>> This message acknowledges receipt of your additional ICLA, which has been filed in the Apache Software Foundation records.
>>
>> <one of the paragraphs below>
>>
>> Warm regards,
>>
>> -- standard footer
>>
>> If infra needs to update the forwarding email address, add something like this to the email above:
>>
>> With this email, our administrators are requested to update the forwarding email in our records for <apache-id> to <new email address> so you can change your password using https://id.apache.org .
>>
>> If whimsy can update the forwarding email address to enable id.apache.org password change, add:
>>
>> You can change your password using https://id.apache.org .
>>>
>>> 3) is it worth trying to send an email to the old email address so
>>> that they know of the change? Yes, it would normally bounce, but if
>>> it didn't...
>>
>> Yes. Any time something like this happens I try to notify all known addresses. We have a similar situation right not with someone who wants a new identity and I have included all known addresses in the recent dialog.
>
> OK, easy enough.
>
>> Craig
>>>
>>>> Craig
>>>
>>> - Sam Ruby
>>
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> clr@apache.org http://db.apache.org/jdo
>
> - Sam Ruby
Craig L Russell
Architect
craig.russell@oracle.com
P.S. A good JDO? O, Gasp!
Re: Secmail feature request
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jun 10, 2017 at 8:13 PM, Craig Russell <ap...@gmail.com> wrote:
> Hi Sam,
>
> I totally missed this email in the forest.
It happens :-)
>> On May 20, 2017, at 7:56 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>>
>> On Mon, May 15, 2017 at 5:31 PM, Craig Russell <cr...@oracle.com> wrote:
>>>
>>>> On May 15, 2017, at 12:38 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>
>>>> On Mon, May 15, 2017 at 11:54 AM, Craig Russell <ap...@gmail.com> wrote:
>>>>> Hi Sam,
>>>>>
>>>>>> On May 13, 2017, at 7:41 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>
>>>>>> On Fri, May 12, 2017 at 6:51 PM, Craig Russell <ap...@gmail.com> wrote:
>>>>>>>
>>>>>>> I know up front that this is a second icla. So good idea for this to be a different action.
>>>>>>> (O) icla
>>>>>>> (O) additional icla
>>>>>>> (O) ccla
>>>>>>>
>>>>>>> Full Name: this is the key to find the entry in iclas.txt
>>>>>>> Public Name: this should replace the public name in the entry
>>>>>>> email: this should replace the email in the entry
>>>>>>> file name: this is generated from Full Name and is the directory for the iclas
>>>>>>>
>>>>>>> If a third icla comes in, I can handle this manually. Unless it's easy to put in now:
>>>>>>>
>>>>>>> if full-name/full-name.pdf (or full-name/icla.pdf and icla.pdf.asc) already exists:
>>>>>>> find the largest n in full-name/full-name<n>.pdf
>>>>>>> file the new icla under full-name/full-name<n+1>.pdf
>>>>>>>
>>>>>>> and replace Public Name and email in iclas.txt as for the second one.
>>>>>>
>>>>>> Handling the 'nth' case doesn't concern me.
>>>>>>
>>>>>> What does concern me is the ability to change the Full Name (and
>>>>>> therefore the filename). If you do that, this won't be a second ICLA,
>>>>>> and the code won't be able to identify an existing line in iclas.txt
>>>>>> to update.
>>>>>
>>>>> Select (O) additional icla
>>>>>
>>>>> The Full Name is the key to the entry you want to change. I don't know if there are any cases where the Full Name does not exactly match the file name (modulo converting Non-US-ASCII letters to latin letters). That is, someone changed file name after filling full name. But that is not the usual case. For our purposes, we can disallow changing the file name and always take it from the full name. This might be a good thing to do for all iclas.
>>>>>
>>>>> Maybe an update to icla-lint would catch any cases where the full name and file name do not match.
>>>>
>>>> The part of the 5th field after a semicolon is, indeed, a key field.
>>>> Many of which reflect decisions that were made before the workbench
>>>> existed, or before I was secretary for that matter. :-)
>>>>
>>>>>> I'd like to suggest as an alternative, two fields: one identifying the
>>>>>> existing user,
>>>>>
>>>>> This is the full name ~== file name
>>>>
>>>> I was thinking of a field like the one present here:
>>>> https://whimsy.apache.org/roster/committer/
>>>>
>>>> You will be able to enter a name, and id, or an email, and it will
>>>> find the correct entry. It could then display the full name value for
>>>> confirmation.
>>>
>>> This would be excellent. I don't know though if the committer roster interaction is simple enough to copy for secmail tool. If so:
>>>
>>> (O) additional icla
>>> search: _______________
>>> existing Full Name: <from iclas.txt>
>>> existing Public Name: <from iclas.txt>
>>> existing email: <from iclas.txt>
>>>
>>> proposed Public Name: ________<from email>______
>>> proposed email: _____<from email>_________
>>
>> Client side logic is roughed in.
>
> Looks great! The search field is really responsive. Did you cache the entire iclas.txt file?
There is no round-trip to the server as you make your data entry.
When you select additional icla, I download the entries in iclas.txt
that are NOT notinavail and all searching is done on the client.
> The more I test this the more I want it as part of the Categorize menu, just above Links.
Just so I'm clear, it is currently a part of the Categorize menu,
where you originally asked for it:
https://github.com/apache/whimsy/blob/master/www/secretary/workbench/views/parts.js.rb#L104
You now want this moved down to about here:
https://github.com/apache/whimsy/blob/master/www/secretary/workbench/views/parts.js.rb#L159
Easy enough.
>>
>>> (File)
>>>
>>> And then the fun of fitting the new icla into the documents/iclas/ directory begins.
>>
>> Looking at the server logic, if I were to submit a new icla (not that
>> I have any need to),
>>
>> Step 1 would be to mkdir sam-ruby and move sam-ruby.pdf to sam-ruby/icla.pdf
>>
>> Step 2 would be create sam-ruby/icla2.pdf
>>
>> Step 3 would be to update iclas.txt with new email (and possibly new
>> public name)
>>
>> Step 4 would be to send out an email.
>>
>> Notes:
>>
>> 1) Step 1 wouldn't be done if iclas/sam-ruby already existed
>>
>> 2) Step 2 would use icla3 or icla4 or whatever until a unique number is found
>>
>> Questions:
>>
>> 1) would it be icla.pdf or icla1.pdf in step 1?
>
> icla.pdf
>>
>> 2) who should the email go out to and what should be in the email?
>
> To: the sender, <root@ if infra needs to do something>
It looks like the secretarial team (and therefore whimsy) can update
mail addresses:
https://github.com/apache/infrastructure-puppet/blob/deployment/modules/ldapserver/templates/slapd.conf.erb#L159
> cc: everyone on the bcc: and cc: lists, the email in the iclas.txt file, the apache-id@apache.org, and secretary.
>
> Dear <public name>,
>
> This message acknowledges receipt of your additional ICLA, which has been filed in the Apache Software Foundation records.
>
> <one of the paragraphs below>
>
> Warm regards,
>
> -- standard footer
>
> If infra needs to update the forwarding email address, add something like this to the email above:
>
> With this email, our administrators are requested to update the forwarding email in our records for <apache-id> to <new email address> so you can change your password using https://id.apache.org .
>
> If whimsy can update the forwarding email address to enable id.apache.org password change, add:
>
> You can change your password using https://id.apache.org .
>>
>> 3) is it worth trying to send an email to the old email address so
>> that they know of the change? Yes, it would normally bounce, but if
>> it didn't...
>
> Yes. Any time something like this happens I try to notify all known addresses. We have a similar situation right not with someone who wants a new identity and I have included all known addresses in the recent dialog.
OK, easy enough.
> Craig
>>
>>> Craig
>>
>> - Sam Ruby
>
> Craig L Russell
> Secretary, Apache Software Foundation
> clr@apache.org http://db.apache.org/jdo
- Sam Ruby