Fix Text Answer review redirect

[geromequa]

closes #1696

[niklasmohrin]

This doesn't work yet. Firstly, when coming from the full view and editing an answer, I still get redirected to the quick view afterwards. Secondly, the question selection in the quick view also still shows the first unreviewed question, not the one from the fragment. Is it just broken on my computer?

Here is what I think we need to do: In quick-review-slider.ts we are calling this.startOver(StartOverWhere.Undecided);. I believe that we should move this out of QuickReviewSlider.attach and into the calling code (staff_evaluation_textanswers_quick.html) where we can then check if the page URL has a fragment for a specific textanswer - in that case we startOver with that. Otherwise, we do what we did before.

For the redirect into the correct view, I think we have to include the view we want to return to in the request to evaluation_textanswer_edit. We have this pattern already in the index view after logging in (check the end of the index function in evap/evaluation/views.py). Although here we don't need the full url, so maybe ?next-view=full or so would make for shorter / nicer urls.

[niklasmohrin]

I also think it would be awesome if we could get a quick frontend test going for this, otherwise someone might mess it up again in the future. After all, we didn't notice that the logic for the fragment is doing nothing after we introduced the quick view and redirected to it by default. To be fair, three years had passed between #530 and #1154

[geromequa]

The redirect to the proper view (quick, full etc.) should work now. The view is passed to the edit view via url parameter inside staff_evaluation_textanswers_section.html and then used to reverse to the correct view afterwards. Because the quick view does not render staff_evaluation_textanswers_section.html inside its own template, the redirect to the quick view is based on it being the fallback case (see views.py, line 1831).

[janno42]

@geromequa Do you want to continue working on this or should we hand it over to someone else?

[geromequa]

Current behavior: the page correctly jumps to the textanswer that was just edited. After editing a textanswer it is added to the back of the list of textanswers, unclear where this logic is implemented. Jumping to edited textanswer works without problems though.

[niklasmohrin]

This is looking very promising, just some finishing touches are needed.

Most importantly, the quick view works, but removing the fragment= part breaks the functionality on the full view (I wrote a more detailed comment below). (there is no test for this, so it's not your fault)

Can you a) change the PR title to reflect the added functionality of the PR, and b) add a short frontend test for this behavior in the quick view?

I would also like to have a frontend test for the full view, but I don't know if there is a nice and robust way to do it since all the text is always shown in that view. Either way, you don't have to worry about that in this PR.

After editing a textanswer it is added to the back of the list of textanswers

The answers are just in whatever order the database gives them to us, I think they just appear in a random place. Do they always appear at the end for you? For me they also sometimes show up in the middle

[niklasmohrin]

Can you add (frontend) tests? Implementation looks good 👍

[niklasmohrin]

implementation looks good, tests need a little more work :)

[niklasmohrin]

the [0] also seems like it could break arbitrarily depending on the order in which the answers were returned from the database; I think we can just check that the edited text is visible and the one from the other questions is invisible, take a look at existing tests that contain self.wait.until(visibility_of_element ...)

[niklasmohrin]

Very cool, thanks! I have some final remarks, but unless you have some questions or disagree, I don't need to review again

[richardebeling]