Failing phpunit test: h1[text() = "Administration"] not found

chetan 11 → made their first commit to this issue’s fork.

Please check the above MR.

Hi chetan11,
Thank you for working on this. But it is polite when someone has just created an issue, and also created an issue fork branch, to ask if they are doing the work before jumping in and making your own commit, within one hour of the issue being created.
You are welcome to work on this now, I will stop the work I had started.
By the way, your test failed, and you also introduced new phpcs faults.

Why is a wait needed in order to view the h1 text? That should be returned in the initial response, right?

@moshe You are right, no wait is needed. That was not the problem, and adding it did not fix the test. I don't know if chetan11 ran it locally or was just taking a guess. I was working on the actual fix locally, but stopped when chetan11 pushed to the MR. I can pick it up again, but was waiting for their response, as I did not want to clash again.

I'd say go ahead and create a separate branch/MR to address this. It not only did not fix it, it also broke the one phpunit that was still working.

Done. The pipeline passes all green now. I looked at the generated html and the final page was 'access denied'. I looked back at some other tests for admin users (eg in Scheduler) and saw that they had the extra permission 'administer site configuration'. Adding this fixed the test, and both permissions are now required in 10.2. The previous passing test was in 10.1 where just 'access administration pages' was sufficient.

I have not investigated exactly what core change from 10.1 to 10.2 caused this extra permission to be needed. I guess it was always to be there, and this is a tightening of security, as it prevents one permission showing the top admin page, it needs to be more speciifc now.

jonathan1055 → changed the visibility of the branch 3409652-phpunit to hidden.

In the committed comment I said . This is not precisely correct. Yes 'administer site configuration' is sufficient, but any other "real" admin permission would also be enough to give access to the top-level /admin url.

Can this be closed?

Yes it can be marked 'fixed'. That comment can stay as-is, it might be right or wrong depending on what happens in core issue 🐛 Admin page access denied even when access is given to child items RTBC which was the cause of the problem. Either way, the test passes now.

Automatically closed - issue fixed for 2 weeks with no activity.