When I drag/drop, these are the kinds of errors I get on the server console:
Error: Unable to find file. Error: Failed to open PDF file: /var/folders/mx/t44d3_bs437dpnywzk_mwl_0002msd/T/image003.jpg20160106-89526-neygnb.pdf Error: Unable to find file. Error: Failed to open PDF file: /var/folders/mx/t44d3_bs437dpnywzk_mwl_0002msd/T/image005.png20160106-89526-17qyeu5.pdf Errors encountered. No output created. Done. Input errors, so no output created. 127.0.0.1 - - [06/Jan/2016:18:23:36 -0800] "POST /actions/drop HTTP/1.1" 200 246 2.1588 127.0.0.1 - - [06/Jan/2016:18:23:37 -0800] "GET /201601/16c8ec8707/image003.pdf HTTP/1.1" 200 - 0.4341 Error: Unable to find file. Error: Failed to open PDF file: /var/folders/mx/t44d3_bs437dpnywzk_mwl_0002msd/T/image001.jpg20160106-89526-8c4ji9.pdf Error: Unable to find file. Error: Failed to open PDF file: /var/folders/mx/t44d3_bs437dpnywzk_mwl_0002msd/T/image002.jpg20160106-89526-8e5lqj.pdf Errors encountered. No output created. Done. Input errors, so no output created. > On Jan 6, 2016, at 6:14 PM, Craig L Russell <craig.russ...@oracle.com> wrote: > > Hi Sam, > >> On Jan 6, 2016, at 6:53 AM, Sam Ruby <ru...@intertwingly.net >> <mailto:ru...@intertwingly.net>> wrote: >> >> Cool! This is the type of feedback I've been looking for! >> >> More inline. >> >> On Tue, Jan 5, 2016 at 5:06 PM, Craig L Russell >> <craig.russ...@oracle.com <mailto:craig.russ...@oracle.com>> wrote: >>> 1. When a message is selected, only the from:, to:, and subject: fields are >>> displayed. The text of the message is not visible. This appears to be just >>> in some cases, e.g. 2016-01-05T18:24:03Z and 2016-01-05T17:52:10Z . >> >> That was indeed a bug. Fixed. >> >>> 2. The left frame doesn't size correctly. It initially displays with a >>> scroll bar at the bottom. If the vertical bar separating the data entry >>> from the display is moved, the scroll bar still shows and the last few >>> pixels in the fields are not visible. >> >> Odd. I don't see this with Safari, Firefox, or Chrome, all on a Mac. >> Can you tell me what browser you are using, and perhaps send a screen >> capture? > > MacOSX 10.10 Safari Version 9.0.2 (10601.3.9) > see below. there is a horizontal scroll bar in the icla form. >> >>> 3. When File is pushed, 90 seconds later the alert comes up "stub for ICLA, >>> filename: chaudhary--sunaina". Is it supposed to take over a minute to svn >>> add /Users/clr/apache/documents/iclas/chaudhary--sunaina.pdf? >> >> What's happening here is: >> >> 1) cleanup/revert of any partial commits that may have failed. > ok > >> 2) svn updates to retrieve the latest copy of both foundation/officers >> and documents/iclas > > This is an unwelcome change from the way it works now. If it is a second or > so, ok. But reloading the main page should svn update the repositories. > >> 3) svn add of the relevant document. > ok > >> >> Only #2 above should take a noticeable amount of time, particularly if >> you haven't updated recently. On my machine, I'm seeing a total of 5 >> to 6 seconds average for the whole operation. Hopefully we should see >> comparable or better times when this is deployed on whimsy-test. >> >> I may be able to eliminate one svn update. Of course, svn commit and >> email need to be added, which will add to the elapsed time. Overall, >> this should be no worse than the current workbench, and actually >> should be a half-second or so per server interaction better. Note >> that NOT displaying the svn commands as they are being executed >> reduces the number of server interactions. > > But you could still save them and display them after they complete? >> >>> 4. When doing File a second time with the same document name, there is no >>> error that there is already a document by that name. Only when I tried to >>> svn rm the document did it give me the error. There is an error when doing >>> a File with a document that is already in the repository. >> >> The previous (incomplete) commit is cleaned up first. > > It doesn't do a commit, just leaves the document as new in the repository. I > hope the intent is to preserve the current work flow and have an explicit > commit after file. > And doing it a second time without a commit just overwrites the file. This > might not be so bad because the filed document will disappear from the list > of documents that can be processed. > clr% svn rm robert-po-arickij/ > svn: E195006: Use --force to override this restriction (local modifications > may be lost) > svn: E195006: '/Users/clr/apache/documents/iclas/robert-po-arickij/icla.txt' > has local modifications -- commit or revert them first > >> >>> 5. I'd prefer the cursor to change to a "wait for response" instead of the >>> slowly rotating clock. >> >> OK, done. > > When a document is being fetched (press the .pdf file name in the left area) > can the cursor spin? It's not clear what is going on while the document loads > into the right pane. >> >>> 6. It's not clear from the layout of the panel whether the pmc and podling >>> fields are effective with the File button. Perhaps pmc and podling fields >>> should be above the File button? >> >> The file button only updates iclas.txt and placed the pdf into >> documents/iclas. The pmc and podling fields are only used for new >> account requests. > > The current tool uses the pmc and podling fields to send emails on commit. So > I'd still vote for having pmc and podling fields above the File button. >> >>> 7. The flow with the current tool is to fill all the fields, File, Commit, >>> and then request account. What is the intent of the Request Account button >>> on this screen? >> >> The proposed new flow is File (which will do a commit) then Request >> Account (which is now a button). > > I like a separate Commit after File when I can look at the svn diff of the > iclas.txt before commit. >> >>> 8. In the current tool, File brings up the svn commands that can be double >>> checked for errors. The new tool should do something similar. There is an >>> alert if there is a problem with an svn command but the current tool has a >>> better way to present the problem, with the svn commands and then an alert >>> to ask whether it should continue. >> >> I'll look at that in a subsequent pass. >> >>> 9. When filing a document with a digital signature, error: Exception: >>> #<IOError: invalid filename: duncan-godwin>. It should be >>> duncan-godwin/icla.txt and icla.txt.asc. But then I tried again and this >>> time, success: stub for ICLA, filename: duncan-godwin. But sadly, only the >>> .asc file was added. >> >> The first is a bug, and has been fixed. > > Agree. It's fixed. >> >> The second (only filing the .asc) may have occurred if you had >> selected the asc file separately. To prevent this, I've now committed >> a change which will no longer prompt you for the document type of >> files ending in .asc or .sig. > > This is good. >> >>> 10. There should be a button to return to the main screen. >> >> Suggestion for where the button should go? > > Tippy top above "text". > >> Meanwhile, up arrow will >> return you to the main screen. > > That works. >> >>> 11. The drag/drop of .jpg files doesn't appear to work. It should also >>> display the convert commands that are being executed. And there doesn't >>> appear to be an "undo" in case the drag/drop order was wrong. Drag/drop of >>> pdf files works as expected. >> >> What problem are you seeing? If I go to "2015-12-19T17:50:43Z" and >> drag "IMG_1119.JPG" and drop it on "IMG_1118.JPG", I get >> "IMG_1118.png". > > I went to 2016-01-06T06:16:13Z and dragged image005.jpg onto image001.jpg and > ended up with image001.pdf (good) but there is nothing in image001.pdf. > >> >> Where should the convert commands be displayed? > > Whenever there is a message displayed, there should be a File: menu with > operations, dup, spam, incomplete, processed, and unsigned buttons. Perhaps > underneath the text, headers, raw section? > > Whenever there is a file displayed (image003.jpg) there should be a (Do) menu > with burst, flip, etc. that applies to that specific file. > > Whenever there is a bad signature, there should be a menu with email button. > The email should say "bad signature; please try again." I can give you the > exact text from history. > Whenever there is a missing public key, there should be a menu with email > button. The email should say "unable to download public key." > > Right now, the document menu shows icla, grant, ccla, nda, and mem. This menu > should only be for .pdf files and .txt files with matching .txt.asc files. > > Speaking of signed files, we often get Johnny-ICLA.pdf and > Johnny-ICLA.pdf.asc. These should be renamed icla.pdf and icla.pdf.asc before > being put into iclas/john-jacob-jingleheimer-schmidt. Same for > johnny-icla.txt and johnny-icla.txt.asc. > >> At the moment, the >> right pane will typically show the contents of the file being dragged >> before the drop is complete, and will show the contents of the >> combined file afterwards. > > I have not seen any of this behavior. All I see is the file being dragged > changing the proposed drop target in a green oval. And dropping the file goes > silent for a bit and then nothing appears in the right pane. >> >> A "right click" should bring up a menu that will burst a PDF. > > Do not like right click. Prefer to always have a menu (see above for > suggestions). >> >>> 12. Once a mail has been processed, what should be the indication on the >>> main page? How do I tell that there is new work to do? >> >> Like with the current secretary workbench, the idea is that once a >> document is filed or deleted it will no longer show up in the main >> index. > > Ok. This is fine. >> >> That may mean that with emails such as "2016-01-05T10:54:59Z", you >> will need to file the ICLA and then delete the rest (either >> individually via the context menu or collectively using >> command-delete). > > Once I process the icla.pdf from that email, the rest of the stuff (random > banners, vcf signatures, etc.) is still there, and I'm still looking at the > same email. > > With this new work flow, the extra stuff isn't in svn so it doesn't need to > be removed. But the email needs to be marked as complete. Maybe a "processed" > button that tells the system that nothing else is needed for this email? Or > "ignore" that is used for pure spam as well? > > Craig >> >>> Good progress. >> >> Thanks! >> >>> Craig > <PastedGraphic-2.png> >>> >>> Craig L Russell >>> Architect, Oracle >>> http://db.apache.org/jdo <http://db.apache.org/jdo> >>> 408 276-5638 mailto:craig.russ...@oracle.com >>> <mailto:craig.russ...@oracle.com> >>> P.S. A good JDO? O, Gasp! >> >> - Sam Ruby > > Craig L Russell > Architect, Oracle > http://db.apache.org/jdo <http://db.apache.org/jdo> > 408 276-5638 mailto:craig.russ...@oracle.com <mailto:craig.russ...@oracle.com> > P.S. A good JDO? O, Gasp! Craig L RussellArchitect, Oraclehttp://db.apache.org/jdo408 276-5638 mailto:craig.russ...@oracle.comp.S. A good JDO? O, Gasp!
