On Sat, Jun 10, 2017 at 8:13 PM, Craig Russell <apache....@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 <craig.russ...@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 <apache....@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 <apache....@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...@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 > c...@apache.org http://db.apache.org/jdo - Sam Ruby
