(In reply to comment #0)

rights, but on test2wiki "Selenium user" has

autochecked user, bureaucrat, editor, reviewer,***administrator***

I has Sysop Rights, It's just labelled Administrator on wiki, and it has rights to block, see: https://test2.wikipedia.org/wiki/Special:ListGroupRights#sysop

D'oh, so it must be something else.

No, something is wrong with the permissions for Selenium_user to see "Block" and also to see "Suppress" under Actions in Flow. Whatever is required, my user Chrismcmahon(WMF) also lacks those permissions.

I mean Cmcmahon(WMF)

It seems that neither local 'sysop' nor global 'administrator' has the 'oversight' right:

Flow.php:$wgGroupPermissions['oversight']['flow-suppress'] = true;

Is this fixed?

This is working now

This is again a problem.

Selenium_user on test2wiki cannot Delete or Suppress topics or posts, so several tests are failing. Selenium_user on test2wiki can't see its own Special:UserRights but Special:UserList shows Selenium_user has
(autochecked user, editor, reviewer)

For comparison, Selenium_user on en betalabs can visit Special:UserRights and has (oversight, administrator).

Special:UserRights is only visible if you have rights to change group members. I'm unsure what test2 is setup as but autochecked, editor and reviewer generally don't have those rights.

OK. Chris Steipp had asked if we could curb the permissions on test2wiki for Selenium_user. We seem to have gone too far.

Let's restore the minimum set of permissions to make the Flow tests pass, and also do the password-change and security dance at the same time.

Just to clarify, my concern was that I think I've seen the password for the Selenium_user account, and I we probably store it in Cloudbees somewhere. So it's likely several people have had access to it at one time or another.

Because test/test2 is a production domain, a sysop who inserts malicious javascript there can escalate their privileges across the cluster. We can take away CORS access from test/test2, but then cross-domain gadgets and other things that should be tested will fail. So after talking to Chris McMahon, I remove sysop and bureaucrat from Selenium_user.

Options for going forward:

• Don't run tests that require sysop on the production cluster
• Move the permissions that we need for the tests (I'm guessing these are all flow specific currently?) into a new group on test/test2, and assign Selenium_user as the only user in that group.
• Have the tests use OAuth, with a grant that only contains the necessary rights and is only valid on those wikis, so that the Selenium_user's actual password doesn't have to be shown/stored anywhere.

(In reply to Chris Steipp from comment #11)
Yes, giving Selenium_user oversight and admin in production seems crazy.

• Move the permissions that we need for the tests (I'm guessing these are

all flow specific currently?) into a new group on test/test2, and assign
Selenium_user as the only user in that group.

Sounds good. I don't understand the nuances of groups, but we want something that ends up with a "qa_automation" group on test2wiki that does:

$wgFlowGroupPermissions['qa_automation']['flow-delete'] = true;
$wgFlowGroupPermissions['qa_automation']['flow-suppress'] = true;

and then some admin can add Selenium_user to this group. I don't fully understand wgOverrides/wgOverrides2/wgAddGroups, but I have a patch anyway 8-)

Change 113311 had a related patch set uploaded by Spage:
Add qa_automation group and grant it Flow rights

https://gerrit.wikimedia.org/r/113311

Change 113311 merged by jenkins-bot:
Add qa_automation group and grant it Flow rights

https://gerrit.wikimedia.org/r/113311

Mostly fixed. qa_automation also needs the 'block' right on test2wiki, or we should remove that browser test.

It has been a couple of weeks since the last commit. Is this fixed in the meantime?