On Thu, Sep 15, 2016 at 8:24 PM, Craig Russell <[email protected]> wrote: > Hi Sam, > >> On Sep 15, 2016, at 5:01 PM, Sam Ruby <[email protected]> wrote: >> >> On Thu, Sep 15, 2016 at 3:24 PM, Sam Ruby <[email protected]> wrote: >>> As luck would have it, rewriting how emails are constructed was going >>> to be next on my list. If you look at icla.json.rb, the svn tasks are >>> fairly clean and the mail tasks are a bit brute force, and contain a >>> lot of common code. This code would be required for each of the >>> actions, so I plan to factor it out into a common method. >>> >>> I'll look at it later this afternoon. Part of that commit will be >>> support for the various reject actions (incomplete, unsigned, etc), >>> which will become trivial (jump immediately to the tasklist with no >>> form, the task consists of a single email which you can browse before >>> proceeding). >> >> Done for now. Here's the commit: >> >> https://github.com/apache/whimsy/commit/6aefcd7ce2121a389588dd7279cfab302ed48b2c > > W O W lots of code in there. I’m just a bit surprised there is not more > common code in unsigned.json.rb, pubkey.json.rb, incomplete.json.rb. I > thought there would be more in message.rb that could be reused more easily. > I’m a big fan of DRY. ;-)
If those three files were symlinked together, the one remaining difference (the name of the template) could possibly be extracted from the URL, which in turn is available in the env variable. An example of what can be found in the env variable: https://whimsy.apache.org/racktest >> For what it is worth, the documentation on the FromField can be found here: >> >> http://www.rubydoc.info/github/mikel/mail/Mail >> >> I'll state that I find the API that gem provides to be a little... >> quirky. Apparently email can have multiple from fields (who knew?) > > Not I. Never saw any mail from more than one address. > >> and some of the methods provide the full email string (including name >> and optional comment) and others provide only the email address >> itself. Add to that the fact that the secmail tool will allow you to >> edit the cc and bcc fields, and merging addresses from the original >> email and the input from the form and there being multiple fields >> (from, to, cc, bcc) and you have a bit of a mess. > > Certainly not easy to just add a bit of logic. I tried that. :( Hopefully the hard stuff continues to get factored out, leaving just the "business logic" in places like: https://github.com/apache/whimsy/blob/master/www/secmail/views/forms/icla.js.rb https://github.com/apache/whimsy/blob/master/www/secmail/views/actions/icla.json.rb You saw how easy it is to add a button that does something useful. Most of the credit goes to React.js. In your case,you just set three variables, and React.js figured out what updates to make to the DOM to reflect the new values. I'd like to extend that. Don't just fill in the real name, but also fill in the file name. And not just initially, but update as the real name changes. Of course, once you have entered the real name you can go and change the file name should you be so inclined, but that rarely would be necessary. I'd like to explore tailoring the icla responses depending on the input. Right now it is fairly generic. A different body could be provided for cases where there is a project (PMC or podling) and yet another one if there is a userid and votelink. The beauty of this is that you won't have to do anything to select which template is used. >> In any case, this mess is encapsulated now, so once debugged it >> hopefully will work consistently for all replies. > > Looks good so far. > > Do you have a schedule for the rest of the doc types so we can get rid of > duplicate handling of the incoming mails? I've got a wedding to go to this weekend, so probably early next week. CCLA and SG can be done quickly by copying the first three tasks of ICLA and the forms from the workbench. I'd have to research to remember the membership application process, but that should also be fairly quick, and not something we will need anyway for a few months. - Sam Ruby > Thanks! > > Craig >> >> - Sam Ruby > > Craig L Russell > Architect > [email protected] > P.S. A good JDO? O, Gasp!
