Hi Sam, > On May 11, 2017, at 5:41 AM, Sam Ruby <ru...@intertwingly.net> wrote: > > On Wed, May 10, 2017 at 9:10 PM, Craig Russell <apache....@gmail.com> wrote: >> If an icla comes in, and the generated name user-name.pdf already exists, a >> warning is raised. >> >> Warning: documents/iclas/craig-russell.pdf already exists >> (proceed anyway) (cancel) >> >> This is almost good. It prevents filing a new icla where the icla already >> exists. [The (cancel) button doesn't work. It probably is not needed because >> if there is a problem, the input fields can be fixed and (File) button still >> works. I understand this is generic error handling. ] >> >> But this is exactly the case for an icla being filed because an account is >> unusable because of an inaccessible email address. In this case, both iclas >> should be filed. But instead of creating a new entry in iclas.txt, the >> existing entry should have its email address changed. >> >> So, in the duplicate icla file name case, the processing should be: >> >> svn mkdir user-name >> svn mv user-name.pdf user-name >> svn add user-name/user-name2.pdf >> >> And in the iclas.txt processing: >> find the User Name entry >> replace the email-address with the incoming email-address >> >> The warning (proceed anyway) will perform the above actions if in fact the >> second icla should be filed. > > Looking at the icla filing code: > > https://github.com/apache/whimsy/blob/master/www/secretary/workbench/views/actions/icla.json.rb > > What you are suggesting is to have a different document commit logic, > different logic to update iclas.txt, similar but possibly tweaked > email logic and no need for the account request logic. > > So to start with, it feels like a different action. This will keep > the code cleaner: one set of code for filing a new icla, and a > separate set of code for an email address change. > > Now lets talk about workflow: > > Do you generally know up front that this is an email change request, > if is so would it make more sense to either select that up front or > start over with a new action in the rare cases where you discover this > later? > > Or is it generally the case where you have entered an amount of data, > started the request, discovered that it is an email address change, > and would like to be prompted to reissue the request? > > Or is it the case that you want the software to determine what is > necessary and just do it without any need for you being aware that > this is a separate action?
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. Craig > >> Craig L Russell >> Secretary, Apache Software Foundation >> c...@apache.org http://db.apache.org/jdo > > - Sam Ruby Craig L Russell Secretary, Apache Software Foundation c...@apache.org http://db.apache.org/jdo
