| ivo | |
| Jun 3 2016, 11:54 AM |
| F1674539: pasted_file | |
| Jun 3 2016, 12:56 PM |
| F1674554: pasted_file | |
| Jun 3 2016, 12:56 PM |
| F1674511: Screen Shot 2016-06-03 at 5.38.25 AM.png | |
| Jun 3 2016, 12:40 PM |
| F1674507: Screen Shot 2016-06-03 at 5.37.22 AM.png | |
| Jun 3 2016, 12:40 PM |
| F1674515: Screen Shot 2016-06-03 at 5.38.28 AM.png | |
| Jun 3 2016, 12:40 PM |
| F1674509: Screen Shot 2016-06-03 at 5.37.39 AM.png | |
| Jun 3 2016, 12:40 PM |
| F1674447: pasted_file | |
| Jun 3 2016, 11:54 AM |
| F1674443: pasted_file | |
| Jun 3 2016, 11:54 AM |
The e-mail notification now announces that an inline comment was marked as done:
However, when looking at the revision itself the comment is still not done:
When the author looks at the revision, it turns out the done mark is still unsubmitted:
I've seen this happen on our install several times now.
The "Inline Comments" section shows new inline comments. It does not show inlines marked "Done".
Given this, is the behavior still unexpected?
The author of the revision intended to mark the comment Done, but this didn't happen when he submitted the form. For me that seems to be unexpected behaviour.
Second, I understand that the section just shows new comments, but the first line of the email says:
elian marked an inline comment as done.
So I would expect the comment to actually have been marked Done.
Okay. I can't reproduce that. Here's what I did.
I viewed a revision with an un-"Done" inline comment:
I clicked the "Done" checkbox, typed some text, then hit submit:
This generated the transaction I expected (note "Marked inline as done"):
This also marked the inline as done:
Interestingly, the comment is suddenly marked as done when the revision is closed:
As you can see there are two transactions marking the comment as done, but only the last one actually marks it.
Here's another example:
None of those screenshots demonstrate inconsistencies on their own.
This needs reproduction instructions which I can follow to recreate the issue before we can move forward with it.
This report doesn't include reproduction instructions and doesn't clearly demonstrate a problem: all of the screenshots are explicable through user error.
Although it's entirely possible that there's a real bug here, we can't move forward without being able to reproduce the issue.
Feel free to file a new issue if you come up with reliable reproduction instructions.
If there is an issue here, it may also be resolved indirectly as a side effect of future infrastructure work like T11114.