First, a status update. Processing of ICLAs is now roughed in... you will now see what actions would be performed, but no commits or sending of emails is actually done.
On Sun, Sep 11, 2016 at 6:03 PM, Craig Russell <[email protected]> wrote: > >> On Sep 10, 2016, at 5:59 AM, Sam Ruby <[email protected]> wrote: >> >> On Sat, Sep 10, 2016 at 12:04 AM, Craig Russell >> <[email protected]> wrote: >>> 1. When filing an ICLA, “File” brings up a screen with >>> Operations to be performed >>> • svn commit documents/iclas/caleb-meier >>> • svn commit foundation/officers/iclas.txt >>> • email [email protected] >>> >>> I’d like to see what this will do, specifically: >>> svn status documents/iclas >>> svn diff foundation/officers/iclas.txt >>> email subject:, to:, cc: and references: >> >> I can look into showing the line to be inserted into iclas.txt and the >> full draft email to be sent. In fact, these could be displayed in >> input or textarea boxes allowing you to tweak them before they are >> applied. > > Box! Box! Box! > > The current order of applying the svn commit to the repository followed by > the update of the text file followed by the email message is good. This way, > if there is a failure to commit to the repository I can abort the whole thing > and start over. And I like the idea of a dialog box with the proposed change > to the text file and another box with the proposed email. Maybe here is where > we could put the “edit cc: list”. If I want to edit the cc:list it’s right > there. I need to think through validation. Editing the message body is one thing (garbage in-garbage out). Editing the headers is another. Getting a header wrong can cause the sending of the email to be aborted. At that point, the svn commits are done. On my personal wish list is to convert the editing of cc and bcc lists to input fields with validation. That could be done from the task list page, but I just want to think this through. In any case, function parity with the current secretary workbench is a higher priority to me at the moment than new features. The good news is that adding new features like this should be considerably easier with the new code base. >> Note that the secmail tool will not require or make use of a full >> checkout of repositories. There will be no local working copy to do a >> svn status on. > > Can we at least do a check on whether a document of the proposed name already > exists? Sure. Of course, if the document already exists, the very first commit will fail. Going to svn to check if it exists will take approximately the same amount of time as attempting to store it and failing. And doesn't absolutely guarantee that it still won't exist when the commit is actually done. Checking to see if the file was there the last time a cron job updated the files would be much quicker and probably good enough. Finally, there may be an opportunity for parallelism. Opportunistically display the list of tasks to be done immediately and in the background perform a check to see if the file exists. This check may complete before you get a chance to push the button to complete the actions. >>> 2. Similarly, when filing a CCLA or SGA, show the operations to be >>> performed as above >> >> Ack. >> >>> 3. Under the “edit” tab, the “restore” option is missing. This does a pdftk >>> xxx cat 1-endNorth output yyy.pdf which is sometimes useful if the document >>> is strangely formatted. >> >> I don't know whether it is new or I missed it the first time, but in >> addition to operations relative to the original orientation, pdftk >> supports operations relative to the current orientation. So to >> reverse a flip, do a flip again. So to reverse a rotate left do a >> rotate right. Or keep doing a rotate right until the orientation >> looks correct. >> >> Give this a try and see if it makes more sense. > > The reason I asked for 1-endNorth in the first place is that some documents > display as though they are oriented West or East and when I use the 1-endEast > they don’t properly end up North. I don’t have an example but every couple of > months a document comes in where the only thing that works is North. Apparently, I'm tripping over the words as I haven't explained the difference. In code, I'm no longer using the 'north', 'south', 'east', or 'west' options. Pdftk refers to these options as absolute. What these options appear to be is relative to what is stored in the PDF, which may not only be different than what you are currently looking at, they may (as you have seen) be different than what you originally looked at, leaving you to guess at what the original orientation was, and simply push buttons until you get it right. I'm now using 'left', 'right', and 'down'. These are always relative to what you are currently looking at. No need to guess any more. If it looks like the top of the page is pointing right, click left to correct it, etc. Again, I encourage you to give it a try. I'm confident that you will find it to be much more intuitive. >>> 4. Under the “categorize” tab, I think we need a “junk” disposition. This >>> would remove the message from the queue without doing anything else. Is >>> that the “x delete” option? The x delete option doesn’t always appear. >> >> Lets talk about spam and unwanted files. With the secmail tool, these >> files will never make it into svn. So there will be no svn rm or the >> like, or even a need for a confirmation dialog. > > Right. But I thought that eventually I would be able to have an empty “to do” > list. The main page shows all the mail that I haven’t processed yet. > > That might be enough until I actually start using it. Once this is ready for production, I plan to wipe all of the emails that have already been processed by other means. The front page will then, indeed, be a todo list. >> Deleting an individual attachment can be done with the “x delete”. I >> can't see any path in the code where that option wouldn't show, >> perhaps you need to scroll down? > > Select a jpg file e.g. > September 7, 2016 at 3:11:25 AM PDT [email protected] Cycling World > Holidays Year Book. > image001.jpg > There is no x delete option > > I see now that the x delete option is on the edit tab. OK, so you found "x delete". It feels more like an action to me than a category, but moving it would be simple enough. Once I finish roughing things in, I would like to see you be able to run this on your own machine, make changes, and deploy them, much like you have done with the current workbench. I also believe that deleting the entire email as spam is likely to b more common than deleting a single attachment. >>> 5. For mails that are immediately recognizable as spam, I think we need a >>> “spam” disposition, without even clicking on the file attachment. There are >>> often multiple documents in the same email. Maybe this should be an option >>> on: >>> ASF Secretary Mail >>> • text >>> • headers >>> • raw >> >> Deleting the entire email from the index can be done quickly and >> easily using 'command-delete', and this can be done either from the >> index view or the message view. For more information, please see >> https://whimsy.apache.org/secmail/HOWTO.html > >> Try this out and see if it works for you. Otherwise, I could add >> 'spam' to the list of categories, but it would be different in that >> there would be no list of commands to be confirmed. > > I see it now. Where does command-delete delete from? Just curious. When I > reload the page, the command-deleted items are gone. Short answer: the /srv/mail/secretary directory on whimsy-vm3.apache.org. Longer answer: The previous/current secretary workbench process was that emails sent to secretary@ are stored in mailboxes for use by the mail-search.apache.org tool. (Note: the plan is for this tool to be retired in favor of ponymail!) There is a script (secmail.py) associated with a cron job that will scan those mailboxes, look for new emails, extract attachments and drop them into svn. The workbench then picks up those files from svn and acts on them. The first thing the workbench does when starting up is to update from svn. The proposed/new process is that whimsy-vm3 is subscribed to secretary@ and immediately drops any message received into /srv/mail/secretary. This generally means that by the time the email hits your inbox it already is ready to be processed by the new secmail tool. Deleting from /srv/mail/secretary is quick, easy, and complete. No need to update svn. No emails are sent out. P.S. You shouldn't need to refresh to have the messages be gone from the list. What should be happening is that the message is immediately greyed out, the selected item is moved to another message, and a request is sent to the server to delete the file. Once that request is complete (it generally should be sub-second), the line should be removed from the list. If this isn't what you see, let me know what is happening and I will look into it. And yes, once deleted, it shouldn't show up again if you refresh. >>> 6. The “Mail” option needs a field to enter the text of the message I want >>> to send. For example, >>> Dear Arthur, >>> >>> Unfortunately, the SGA is incomplete. >>> >>> Please do not reformat the SGA. It is very difficult to tell if it has been >>> altered. >>> >>> I hope this is enough to get started. >> >> That probably will be another category, perhaps "reject with message" >> or the like. > > Yes. Should remove the item from the queue and allow me to send an email > reply with to: and subject: filled and allow me to cc: whoever I want. Again, I want to think through the validation. Shouldn't be hard. > Something I forgot about earlier. With the current tool, attachments of the > form icla-xxx.pdf and icla-xxx.pdf.asc are not recognized as a pair. > > I’d like to see these presented with the option to file them as icla.pdf and > icla.pdf.asc. It should be recognized by the current code: https://github.com/apache/whimsy/blob/master/www/secmail/views/check-signature.js.rb#L64 At the moment, if there are two files, I don't rename them when putting them into a directory. Renaming wouldn't be difficult. > While trying to find a example to show, I used the tool to show all of the > incoming mail. It would be useful to have a count of attachments and > attachment sizes on the front page. Something like > > Files > 2 / 38K > > I don’t think there is room to show the names of the attachments. Should be easy to change. The data is available. Again, my current priority is function parity with the secretary workbench. Once that is obtained, my second priority will be taking you though setting this up so that you can make changes and deploy them. Having a few easy tasks (like adding a column to an existing table) will help that process. > Craig >> >>> Craig >>> >>> Craig L Russell >>> [email protected] >> >> - Sam Ruby > > Craig L Russell > Architect > [email protected] > P.S. A good JDO? O, Gasp! - Sam Ruby
