Eloy Lafuente authored Jul 13, 2017 and Damyon Wiese committed Jul 13, 2017

While participants page is being refactored, there are links (fullname)
going and changing, leading to inestability in tests that were using
those links.

When possible, provide an alternative, stable path, in this case, the
tags page itself can be used to jump to the user profile, keeping the
tag tests better isolated.

Eloy Lafuente authored Jul 13, 2017 and Damyon Wiese committed Jul 13, 2017

There use to be a little cot to easily navigate from the
participations page to the enrollments page.

In boost it was already hidden, but present and the test was still
working (non-javascript).

With the conversion, the functionality is 100% gone so, right now,
the only way to navigate from participats to enrollments (that will
dissappear with with unification), is using the course admin cog.

Fixes for the new enrol users popup with behat.

Part of MDL-59333.

Part of MDL-59333.

Part of MDL-59333.

Part of MDL-59333.

Part of MDL-59333.

It turned out that behat's "I should see ..." does not work for buttons
rendered as `<input>` elements so this assertion worked only in Boost
where the button is rendered as `<button>` but not in Clean.

But we do not really need this check here. All we need is to make sure
that the form has been saved successfully. For which, checking for the
text on the page is enough.

p.s. Another mistake of mine to not double-check behat on both standard
themes. Sigh ...

This Behat scenario was not failing only because it actually relied on
the bug in the wrongly set accepted_types for submission attachments.
Now that the previous commit has fixed that bug, this scenario started
to fail correctly.

We need to do the same trick here as we are doing in the latter
scenario: we first upload a valid file to bypass the upload repository
checks, and rename it before submitting the form. That allows us to see
that the invalid file is caught finally.

p.s. It was a silly mistake of mine. I should had been wondering why
the same procedure worked for one field and not for the other. I would
spot the bug with wrong accepted_types earlier.

It was a copy&paste mistake that the accepted_types option for the
submission attachments used the value configured for overall feedback
attachments.

Credit goes to Marina Glancy for catching this during testing.