165: "publish" should imply "save"

skippy.*******@gmai***** (Google Code) (Is this you? Claim this profile.)
Dec. 7, 2007 
A minor usability issue.  After filling out a new issue form, I hit the
"publish" button.  This has the effect of publishing the unsaved
information - ie, the new information in the text fields was lost
(interestingly, the reviewer was *not* lost!)

I believe "publish" could safely imply the data in the form is also to be
saved.
david
#1 david
  • -Type-Defect
    +Type-Enhancement
    +Component-Reviews
grossag
#2 grossag 
Yeah I agree, I had this happen to me a couple of weeks ago.  In hindsight, it seems
that reviewboard is expecting you to hit Save before you hit Publish which is not
necessarily true.  I saw this in the inline comment feature...I was supposed to hit
"Save Comment" before I selected the "Review" tab and hit "Publish"
jameslin
#3 jameslin 
As I noted in issue 232:

1. It's confusing that after you enter edits into the text box, you need to
click both "OK" and "Save".  I clicked "OK" and forgot that I needed to
confirm my changes a second time.

2. Clicking Publish should either save edits automatically or should warn
that there are unsaved edits.
chipx86
#4 chipx86
  • +Fixed
jcasares
#5 jcasares 
This happens to me all the time. 
I don't think there is a need for "saving". Just save always.
chipx86
#6 chipx86 
We do, though. When you click Publish, every field that has new data is automatically
saved. If not, there's a regression, but we added this some time ago.
jameslin
#7 jameslin 
I've lost comments twice in the past week due to this.  Here's what I did:

1. Click on a line in the diff.  Start typing a comment.  Neglect to click "Save
Comment".

2. Switch to the Review tab.  Click the "Ship It!" checkbox (probably unnecessary).
Click Publish.

Result:
My "Ship It!" note gets published, but the comment from step 1 is lost.  Admittedly
the comment from step 1 is not listed in the Review tab, but that's easy for people
to overlook.